linux-kernel mailing list

FromSubjectsort iconDate
Chris Friesen
fair group scheduler not so fair?
I just downloaded the current git head and started playing with the fair group scheduler. (This is on a dual cpu Mac G5.) I created two groups, "a" and "b". Each of them was left with the default share of 1024. I created three cpu hogs by doing "cat /dev/zero > /dev/null". One hog (pid 2435) was put into group "a", while the other two were put into group "b". After giving them time to settle down, "top" showed the following: 2438 cfriesen 20 0 3800 392 336 R 99.5 0.0 ...
May 21, 4:59 pm 2008
Adrian Bunk
[2.6 patch] avr32: export strnlen_user
This patch fixes the following build error: <-- snip --> ... MODPOST 1327 modules ERROR: "strnlen_user" [drivers/input/misc/uinput.ko] undefined! ... make[2]: *** [__modpost] Error 1 <-- snip --> Reported-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Adrian Bunk <bunk@kernel.org> --- 0318ae73cb3e61e5c192d62c22d988424e04f354 diff --git a/arch/avr32/kernel/avr32_ksyms.c b/arch/avr32/kernel/avr32_ksyms.c index 3a090ba..84a7d44 100644 --- ...
May 21, 3:01 pm 2008
Randy Dunlap
[PATCH] netfilter: conntrack_helper needs to include rculist.h
Sure, makes sense. Looks like it's some sched/auto-sched tree/branch if I'm reading correctly. Ingo, is there a sched tree that add rculist.h file? If so, one of its users needs to #include it. Patch below. --- From: Randy Dunlap <randy.dunlap@oracle.com> nf_conntrack_helper users rcu hlist functions so it needs to #include rculist.h. linux-next-20080521/net/netfilter/nf_conntrack_helper.c:58: error: implicit declaration of function ...
May 21, 2:55 pm 2008
Vegard Nossum
[PATCH] kmemcheck: use tasklets instead of timers
From: Vegard Nossum <vegard.nossum@gmail.com> Date: Wed, 21 May 2008 22:58:37 +0200 Subject: [PATCH] kmemcheck: use tasklets instead of timers Instead of triggering a timer every HZ, we use the new tasklet function which guarantuees not to touch any other tasklets on the tasklet list, and is thus safe to use from the page fault handler. Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com> --- arch/x86/kernel/kmemcheck.c | 16 ++++++++-------- 1 files changed, 8 insertions(+), 8 ...
May 21, 2:37 pm 2008
Rafael J. Wysocki
Suspend and hibernation patchset for 2.6.26-rc3
Hi, For everyone interested, I have put together a patchset containing some "fresh" patches related to suspend and hibernation, on top of 2.6.26-rc3, located at: http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.26-rc3/patches/ Patches 01-06 and 11 have been sent to Len as 2.6.27 material. They have been tested by me for some time (except for the most recent changes in patches 01 and 11) and have not lead to any problems so far. Patches 07-10 are in the Jesse's PCI tree, targeted at ...
May 21, 2:29 pm 2008
Rene Herman
Re: [alsa-devel] Moving sound/* to drivers/ ?
Suggestion for sound/drivers: drivers/sound/generic :-) Rene. --
May 21, 3:08 pm 2008
Timur Tabi
Re: [alsa-devel] Moving sound/* to drivers/ ?
That gets my vote. -- Timur Tabi Linux kernel developer at Freescale --
May 21, 3:05 pm 2008
Sam Ravnborg
Re: Moving sound/* to drivers/ ?
Something like: include/asm-$ARCH/ => arch/$ARCH/include/asm/* ? I can cook up something simple so kbuild will try both so we can move the archs that do symlinks later than the rest. I really like to keep the 'asm' directory so we can kill the asm symlink. Sam --
May 21, 2:54 pm 2008
Linus Torvalds
Re: Moving sound/* to drivers/ ?
I would certainly personally like drivers/sound more, and the placement at the top level is actually because the sound maintainers wanted it that way, probably to avoid the confusion with the old OSS drivers that used to live in drivers/sound. I forget the exact details. It's been many many years, and there may have been some real technical issues too. But basically sound/ was created when ALSA was first merged, and we had a lot of renames from drivers/sound/xyz to ...
May 21, 2:44 pm 2008
Paul Mackerras
Moving include/asm-* [was: Re: Moving sound/* to drivers/ ?]
We could git mv include/asm-xyz arch/xyz/asm and then arrange to pass -Iarch/$(ARCH) to gcc. The only downside is that "asm" is a slightly strange name for a directory of include files, but I assume we don't want to have to change all the #include <asm/blah.h> lines in all the *.c files. Paul. --
May 21, 4:21 pm 2008
Adrian Bunk
Re: Moving sound/* to drivers/ ?
Under drivers/media/ it would only generate confusion regarding who's responsible for what. But drivers/sound/ sounds good. The only possible problem that comes into my mind is to check what cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed --
May 21, 3:23 pm 2008
Linus Torvalds
Re: Moving include/asm-* [was: Re: Moving sound/* to dri ...
That would work, but there's a few alternatives that I think would work even better. The downside with what you suggest is that I'd like the arch-specific include files to be clearly separated (ie I think the naming should be "something/include/something", which makes things clearer. Also, I hate how doing '-Iarch/$(ARCH)' would basically make any random arch/xyz/ subdirectory be a potential location for a header file. I'd hate for the include-path to contain subdirectories that ...
May 21, 4:51 pm 2008
Jeff Garzik
Re: Moving sound/* to drivers/ ?
Speaking as a former OSS driver maintainer, I always preferred drivers/sound. Though Rene's suggestion (use both sound/ and drivers/sound/) might make sense if the subsystem code is huge -- I supported the drivers/block/ -> block/ code movement for example. Jeff --
May 21, 4:37 pm 2008
Rene Herman
Re: Moving sound/* to drivers/ ?
Well, not _huge_ but ALSA is very much structured like that; large middle layer with "miniport" drivers (I do by the way expect this was also Takashi plan originally due to him using sound/* and not just "sound/"; that is, I took the * to be shorthand for isa, pci, usb and so on) From a structural view, the PCM core is just as much not a driver as the IP protocol isn't one and moving all of sound/ to drivers/ would trade the current "why are the drivers not under drivers/?" issue for a ...
May 21, 4:53 pm 2008
Rene Herman
Re: [alsa-devel] Moving sound/* to drivers/ ?
I'd personally like the net/ structure more. So subsystem code under And a few symlinks will do wonders as well. I do/did that when I "port" patches developped against mainline to the alsa-kernel HG repo. Not a And one would not forget to add the include directory to a "git log" or "git bisect" path specification... Rene. --
May 21, 2:58 pm 2008
Takashi Iwai
Moving sound/* to drivers/ ?
While we are at the issue ALSA HG <-> GIT transition... One thing that annoys me sometimes is that the sound driver codes are on a different subdirectory than other normal drivers, namely under /sound. I don't remember exactly why it came there, but this often makes people forget to change the necessary code for the sound subsystem, or slip from the statistics (I'm not sure whether Linus counted sound/* with recent his posts). If I understand correctly, with git, we can move the files ...
May 21, 2:20 pm 2008
Vegard Nossum
[PATCH] tasklets: new tasklet scheduling function
Hi, Does this seem like anything that has even a remote possibility of entering the Kernel? It's not a strict requirement for kmemcheck, but it's extremely nice compared to the 1 Hz timer I've been using till now. (Again, I can put it in my queue for now, but it would be nice to have the necessary Signed-off-bys for when it gets merged. I mean, _if_ it gets merged...) Vegard From: Vegard Nossum <vegard.nossum@gmail.com> Date: Wed, 21 May 2008 22:53:13 +0200 Subject: [PATCH] tasklets: ...
May 21, 2:11 pm 2008
Maciej W. Rozycki
[PATCH 8/8] x86: I/O APIC: Timer through 8259A second-chance
Some systems incorrectly report the ExtINTA pin of the I/O APIC as the genuine target of the timer interrupt. Here is a change that copies timer pin information found to the other pin if one has been found only. This way both a direct and a through-8259A route is tested with the pin letting these problematic systems work well enough. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> --- patch-2.6.26-rc1-20080505-timer-pins-0 diff -up --recursive --new-file ...
May 21, 2:10 pm 2008
Maciej W. Rozycki
[PATCH 7/8] x86: I/O APIC: Clean up the 8259A on a NMI w ...
There is no point in keeping the 8259A enabled if the I/O APIC NMI watchdog has failed and the 8259A is not used to pass through regular timer interrupts. This fixes problems with some systems where some logic gets confused. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> --- patch-2.6.26-rc1-20080505-timer-8259-6 diff -up --recursive --new-file linux-2.6.26-rc1-20080505.macro/arch/x86/kernel/io_apic_32.c linux-2.6.26-rc1-20080505/arch/x86/kernel/io_apic_32.c --- ...
May 21, 2:10 pm 2008
Maciej W. Rozycki
[PATCH 6/8] x86: APIC/SMP: Downgrade the NMI watchdog fo ...
If configured to use the I/O APIC, the NMI watchdog is deemed to fail if the chip has been deactivated as a result of "nosmp". Downgrade to the local APIC watchdog similarly to what is done for the UP case. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> --- patch-2.6.26-rc1-20080505-nosmp-watchdog-0 diff -up --recursive --new-file linux-2.6.26-rc1-20080505.macro/arch/x86/kernel/smpboot.c linux-2.6.26-rc1-20080505/arch/x86/kernel/smpboot.c --- ...
May 21, 2:10 pm 2008
Maciej W. Rozycki
[PATCH 5/8] x86: APIC/SMP: Correct the message for "nosmp"
The local APIC is no longer forced off when "nosmp" has been specified. Correct the message printed. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> --- patch-2.6.26-rc1-20080505-nosmp-apic-0 diff -up --recursive --new-file linux-2.6.26-rc1-20080505.macro/arch/x86/kernel/smpboot.c linux-2.6.26-rc1-20080505/arch/x86/kernel/smpboot.c --- linux-2.6.26-rc1-20080505.macro/arch/x86/kernel/smpboot.c 2008-05-05 02:56:19.000000000 +0000 +++ ...
May 21, 2:09 pm 2008
Maciej W. Rozycki
[PATCH 4/8] x86: I/O APIC: Keep IRQ off when changing LV ...
Disable the 8259A acting in the "virtual wire" mode to keep the interrupt line inactive while fiddling with local APIC interrupt vector registers associated with its destination inputs. To be on the safe side, especially concerning flipping the trigger mode. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> --- patch-2.6.26-rc1-20080505-timer-8259-nmi-unmask-0 diff -up --recursive --new-file linux-2.6.26-rc1-20080505.macro/arch/x86/kernel/io_apic_32.c ...
May 21, 2:09 pm 2008
Maciej W. Rozycki
[PATCH 3/8] x86: I/O APIC: Clean up after a fasteoi failure
Disable the 8259A when routing of the timer interrupt through the chip to the local APIC of the primary processor has failed. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> --- patch-2.6.26-rc1-20080505-timer-fasteoi-cleanup-0 diff -up --recursive --new-file linux-2.6.26-rc1-20080505.macro/arch/x86/kernel/io_apic_32.c linux-2.6.26-rc1-20080505/arch/x86/kernel/io_apic_32.c --- linux-2.6.26-rc1-20080505.macro/arch/x86/kernel/io_apic_32.c 2008-05-21 18:51:28.000000000 +0000 +++ ...
May 21, 2:09 pm 2008
Maciej W. Rozycki
[PATCH 2/8] x86: I/O APIC: Remove parameters to fiddle w ...
Remove the "disable_8254_timer" and "enable_8254_timer" kernel parameters. Now that AEOI acknowledgements are no longer needed for correct timer operation, the 8259A can be kept disabled unconditionally unless interrupts, either timer or watchdog ones, are actually passed through it. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> --- patch-2.6.26-rc1-20080505-timer-8254-2 diff -up --recursive --new-file linux-2.6.26-rc1-20080505.macro/arch/x86/kernel/early-quirks.c ...
May 21, 2:09 pm 2008
Maciej W. Rozycki
[PATCH 1/8] x86: I/O APIC: AEOI timer acknowledgement cl ...
The code that used to be in do_slow_gettimeoffset() that relied on the IRR bit of the master 8259A PIC for IRQ0 to check the state of the output timer 0 of the PIT is no longer there. As a result, there is no need to use the POLL command to acknowledge the timer interrupt in the "8259A Virtual Wire", except for the NMI watchdog when the i82489DX APIC is used (this is because this particular APIC treats NMIs as level-triggered and keeping the input asserted would keep motherboard NMI sources held ...
May 21, 2:09 pm 2008
Maciej W. Rozycki
[PATCH 0/8] x86: Timer through APIC and related clean-ups
Hello, This is a set of patches replacing patch-2.6.26-rc1-20080505-timer_ack-1 and patch-2.6.26-rc1-20080505-timer-8259-0 sent previously. The patches have been split up into smaller logically self-contained chunks to make tracking down problems easier. The patch-2.6.26-rc1-20080505-nosmp-watchdog-0 change fixes a problem with timer interrupts getting masked in the 8259A as a result of patch-2.6.26-rc1-20080505-timer-8259-6 in the corner-case scenario of "nmi_watchdog=1 nosmp" being ...
May 21, 2:08 pm 2008
Yinghai Lu May 21, 1:35 pm 2008
Yinghai Lu May 21, 4:23 pm 2008
Yinghai Lu
Re: Suspected regression in "x86: extend e820 ealy_res s ...
noticed that bootmap_size is shifted already... please use attached patch to see if bootmap is right... YH
May 21, 3:40 pm 2008
Jeremy Fitzhardinge
Re: Suspected regression in "x86: extend e820 ealy_res s ...
Thanks for the quick response. I definitely confirmed that "x86: extend e820 ealy_res support 32bit" is the source of the regression, and reverting the change makes the system bootable under Xen. (My previous reversion failed because I didn't actually have the x86.git changes applied :-/) This patch generates the warning: CC arch/x86/kernel/setup_32.o /home/jeremy/hg/xen/paravirt/linux/arch/x86/kernel/setup_32.c: In function ‘setup_arch’: ...
May 21, 3:01 pm 2008
Jeremy Fitzhardinge
Re: Suspected regression in "x86: extend e820 ealy_res s ...
Unfortunately its a bit difficult because printk() output isn't appearing at early boot (not sure why). I'll try to extract something useful tomorrow. Perhaps this is helpful: This the e820 map of a regular boot: BIOS-provided physical RAM map: Xen: 0000000000000000 - 000000000009f000 (usable) Xen: 0000000000100000 - 0000000010000000 (usable) debug: ignoring loglevel setting. limit_regions start: 0000000000000000 - 000000000009f000 (usable) limit_regions start: 0000000000100000 ...
May 21, 4:23 pm 2008
Johannes Weiner
Re: Suspected regression in "x86: extend e820 ealy_res s ...
Hi, Besides, what did you want to accomplish? Hannes --
May 21, 4:14 pm 2008
Justin Mattock
success
AAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHH finally after three weeks I have finished my task of figuring out what the hell Linus did to the kernel to mess me up....... Love or regards you choose.... -- Justin P. Mattock --
May 21, 1:05 pm 2008
Steven Rostedt
[PATCH RT] rwlocks fix for non PREEMPT_RT
Seems that the addition of RT_RW_READER broke the non PREEMPT_RT case. This patch fixes it. Signed-off-by: Steven Rostedt <srostedt@redhat.com> --- kernel/rtmutex.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) Index: linux-2.6.24.7-rt9/kernel/rtmutex.c =================================================================== --- linux-2.6.24.7-rt9.orig/kernel/rtmutex.c 2008-05-20 23:38:08.000000000 -0400 +++ linux-2.6.24.7-rt9/kernel/rtmutex.c 2008-05-21 ...
May 21, 12:35 pm 2008
Philipp Marek
[patch] kmalloc returns (void*), don't do type conversions
Hello everybody, as requested on http://kernelnewbies.org/KernelJanitors/Todo here's a first patch that removes type conversion on kmalloc() (which returns a (void*)): It was done against current linus-git=20 (d40ace0c7b4a329f7d869d0fbf27435543bb2acc, if I'm not mistaken), and looks like that: list_del(&bss->list); local->num_bss_info--; } else { =2D bss =3D (struct hostap_bss_info *) =2D kmalloc(sizeof(*bss), GFP_ATOMIC); + bss =3D kmalloc(sizeof(*bss), ...
May 21, 12:13 pm 2008
Johannes Weiner May 21, 3:15 pm 2008
Johannes Weiner
Re: [patch] kmalloc returns (void*), don't do type conversions
Hi Phillip, You can include the diffstat in the patch as comment. And please don't attach patches, include them inline. See How about: Better use: Real Name <user@domain> Hope that helps, Hannes --
May 21, 1:17 pm 2008
Jesper Juhl
Re: [patch] kmalloc returns (void*), don't do type conversions
I agree, keep things seperate. One mail with patch to fix casts, Thank you, I'll keep an eye on this patch. Philipp: Johannes makes some good points, please address his comments and re-submit the patch with trivial@kernel.org on Cc: if it draws no negative comments it looks good to me to add to the trivial tree. -- Jesper Juhl <jesper.juhl@gmail.com> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html --
May 21, 3:24 pm 2008
David Daney
[PATCH] mips: Remove board_watchpoint_handler.
mips: Remove board_watchpoint_handler. It is not used anywhere in tree. Signed-off-by: David Daney <ddaney@avtrex.com> --- arch/mips/kernel/traps.c | 6 ------ include/asm-mips/traps.h | 1 - 2 files changed, 0 insertions(+), 7 deletions(-) diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c index f9165d1..6e7e4a2 100644 --- a/arch/mips/kernel/traps.c +++ b/arch/mips/kernel/traps.c @@ -71,7 +71,6 @@ extern asmlinkage void handle_reserved(void); extern int ...
May 21, 11:39 am 2008
Gabriel C
[PATCH] scripts/ver_linux use 'gcc -dumpversion'
These magic greps and hacks in ver_linux to get the gcc version always break after some gcc releases. Since now gcc >4.3 allows compiling with '--with-pkgversion' ( which can be everything 'My Cool Gcc' or something ) ver_linux will report random junk for these. Simply use 'gcc -dumpversion' to get the gcc version which should always work. Signed-off-by: Gabriel C <nix.or.die@googlemail.com> --- Andrew sorry to bug you about that but I have no clue how is maintaining scripts/* ...
May 21, 11:36 am 2008
Vegard Nossum
initialization of static per-cpu variables
Hi, I encountered this comment in kernel/softirq.c: /* Some compilers disobey section attribute on statics when not initialized -- RR */ static DEFINE_PER_CPU(struct tasklet_head, tasklet_vec) = { NULL }; static DEFINE_PER_CPU(struct tasklet_head, tasklet_hi_vec) = { NULL }; So I assume it's the combination of static and whatever section DFINE_PER_CPU puts the variable in which is the problem. However, there's a LOT of these "static DEFINE_PER_CPU" without any initializer in the rest ...
May 21, 11:28 am 2008
Christoph Lameter
Re: [RFC/PATCH 3/3] SLOB: make ksize() more strict for p ...
I also would prefer to keep this out of SLUB. Set/Clear PageSlab dirties the cacheline and it forces the unlining of kmalloc_large. --
May 21, 2:12 pm 2008
Pekka Enberg
Re: [RFC/PATCH 3/3] SLOB: make ksize() more strict for p ...
Hmm, well, that leaves ksize() open for more abuse. I guess we'll just have to live with that then. --
May 21, 2:13 pm 2008
Pekka J Enberg
[RFC/PATCH 3/3] SLOB: make ksize() more strict for page ...
From: Pekka Enberg <penberg@cs.helsinki.fi> This patch re-uses the PG_slab flag for marking SLOB bigblock pages so we can check that the pointer passed ksize() was really allocated by SLOB. Cc: Christoph Lameter <clameter@sgi.com> Cc: Matt Mackall <mpm@selenic.com> Cc: Paul Mundt <lethal@linux-sh.org> Cc: David Howells <dhowells@redhat.com> Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi> --- mm/slob.c | 34 ++++++++++++++++++++++++++++++---- 1 files changed, 30 insertions(+), 4 ...
May 21, 11:26 am 2008
Matt Mackall
Re: [RFC/PATCH 3/3] SLOB: make ksize() more strict for p ...
Ok, first, BUG_ON is wrong. We already know users (ie nommu memory usage reporting) are abusing this interface. Making them blow up is unnecessary. Just give them wrong answers. Issuing a warning might be a good idea for debugging. Second, I'd prefer to keep this sort of debugging code out of SLOB. SLUB is much better suited to debugging allocator abuse. -- Mathematics is the supreme nostalgia of our time. --
May 21, 12:07 pm 2008
Pekka Enberg
Re: [RFC/PATCH 3/3] SLOB: make ksize() more strict for p ...
But kobjsize() never calls ksize() with SLOB as it doesn't set PageSlab. Or are you talking about something else here? Fair enough. I'll drop the patch. --
May 21, 12:11 pm 2008
Christoph Lameter
Re: [RFC/PATCH 3/3] SLOB: make ksize() more strict for p ...
SLUB could add a BUG_ON(!PageCompound ) since we added buffering for order 0 allocs. So only order 1 and higher go through kmalloc large. That should catch the general case. --
May 21, 2:16 pm 2008
Christoph Lameter
Re: [RFC/PATCH 2/3] SLUB: make ksize() more strict for p ...
Why is it too big? Without your additions it is converting kmallocs inline to get_free_pages(). That results in a simple function call with two constant parameters. The patch touches the page struct uselessly. I think the PageSlab marking is useful for debugging but not for a production kernel. --
May 21, 11:52 am 2008
Pekka Enberg
Re: [RFC/PATCH 2/3] SLUB: make ksize() more strict for p ...
Oh, kmemcheck is a separate config option already and it's *much much* more expensive than the ksize() checks will ever be so they shouldn't be bundled together anyway. Pekka --
May 21, 2:15 pm 2008
Christoph Lameter
Re: [RFC/PATCH 2/3] SLUB: make ksize() more strict for p ...
If it has to be then add CONFIG_KSIZE_DEBUG. There are a number of debugging techniques (kmem_check?) that should not be compiled in. Maybe add a new config option for those. CONFIG_SLUB_ENABLE_EXPENSIVE_DEBUG? --
May 21, 2:14 pm 2008
Pekka Enberg
Re: [RFC/PATCH 2/3] SLUB: make ksize() more strict for p ...
Well, it's a PITA because of #include dependencies in any case. Is moving it out-of-line a problem? Hmm, where? page_address() already references ->virtual. I suppose CONFIG_SLUB_DEBUG is a no no as well then so do we want to add a CONFIG_KSIZE_DEBUG config option...? (Btw, I removed the BUG_ON() from kfree() as spotted by Vegard Nossum.) Pekka --
May 21, 11:56 am 2008
Christoph Lameter
Re: [RFC/PATCH 2/3] SLUB: make ksize() more strict for p ...
The ->virtual case is a very special case. page_address() currently should reduce to a simple shift and an add with VMEMMAP. --
May 21, 2:18 pm 2008
Pekka J Enberg
[RFC/PATCH 2/3] SLUB: make ksize() more strict for page ...
From: Pekka Enberg <penberg@cs.helsinki.fi> This patch changes ksize() to be more strict with objets passed to it. We now set PageSlab also for objects allocated with page allocator and use page->slab to check whether page is a regular slab page or a pass-through page. Also moves kmalloc_large() out-of-line as it's too big for inlining now. Cc: Christoph Lameter <clameter@sgi.com> Cc: Matt Mackall <mpm@selenic.com> Cc: Paul Mundt <lethal@linux-sh.org> Cc: David Howells ...
May 21, 11:25 am 2008
Paul Mundt
Re: [RFC/PATCH 1/3] SLAB: Add PageSlab checking to ksize()
This series seems to work ok with all of SLAB/SLUB/SLOB when also applying the kobjsize() patch. Without the kobjsize() patch in place, SLAB and SLUB both work, while SLOB still triggers the >= MAX_ORDER BUG_ON() for page cache pages. Note that this is still an improvement over SLUB blowing up, as it was before, even without the kobjsize() change. --
May 21, 4:45 pm 2008
Pekka J Enberg
[RFC/PATCH 1/3] SLAB: Add PageSlab checking to ksize()
From: Pekka Enberg <penberg@cs.helsinki.fi> The ksize() function is meant for objects allocated from the slab caches, not for arbitrary objects. Add a BUG_ON() to enforce that. Cc: Christoph Lameter <clameter@sgi.com> Cc: Matt Mackall <mpm@selenic.com> Cc: Paul Mundt <lethal@linux-sh.org> Cc: David Howells <dhowells@redhat.com> Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi> --- mm/slab.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/mm/slab.c ...
May 21, 11:25 am 2008
P. Christeas
Patch: usblp quirk for zebra printers
Hi, I guess such a quirk may be a little odd, but it has been a blocking point in my system not being able to support more than one printer. Please comment. (and cc. me)
May 21, 10:57 am 2008
Pete Zaitcev
Re: Patch: usblp quirk for zebra printers
Personally, I don't like this. In kernel, we typically try not to fake things in lower levels in order to fool upper levels. There are always knock-off effects. Sometimes we have to do it, but in my experience CUPS folks always were for doing the right thing. Let's ask them if extracting the S/N from sysfs is too onerous. I'm cc-ing this to Tim Waugh. BTW, Please try to tinker with the following udev ruleset: BUS="usb", KERNEL="lp[0-9]*", SYSFS{serial}=="XXXXXXX", ...
May 21, 3:37 pm 2008
Randy Dunlap
[PATCH -next] sound/pcmcia/vx build error
From: Randy Dunlap <randy.dunlap@oracle.com> menuconfig in Sound PCMCIA drivers needs to be tristate so that SND_PCMCIA can have a value of m so that following drivers can be restricted to m when needed. sound/built-in.o: In function `vxpocket_detach': vxpocket.c:(.text+0x20cfa): undefined reference to `pcmcia_disable_device' sound/built-in.o: In function `vxpocket_probe': vxpocket.c:(.text+0x20f46): undefined reference to `pcmcia_request_io' vxpocket.c:(.text+0x20f5a): undefined reference ...
May 21, 11:37 am 2008
Gabriel C
linux-next: sound/pcmcia/vx build error
Hi, I got the following error with a randconfig on linux-next-20080521 ... sound/built-in.o: In function `vxpocket_detach': vxpocket.c:(.text+0x20cfa): undefined reference to `pcmcia_disable_device' sound/built-in.o: In function `vxpocket_probe': vxpocket.c:(.text+0x20f46): undefined reference to `pcmcia_request_io' vxpocket.c:(.text+0x20f5a): undefined reference to `pcmcia_request_irq' vxpocket.c:(.text+0x20f73): undefined reference to ...
May 21, 10:47 am 2008
Takashi Iwai
Re: [PATCH -next] sound/pcmcia/vx build error
At Wed, 21 May 2008 11:37:21 -0700, Thanks, applied to my tree now. --
May 21, 11:53 am 2008
David Howells
Re: [2.6 patch] don't offer BINFMT_FLAT on frv
Looks fine, though I can't test it till next week. Acked-by: David Howells <dhowells@redhat.com> --
May 21, 11:56 am 2008
Adrian Bunk
[2.6 patch] don't offer BINFMT_FLAT on frv
This patch fixes the following compile error: <-- snip --> ... CC fs/binfmt_flat.o In file included from /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/binfmt_flat.c:36: /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/flat.h:14:22: error: asm/flat.h: No such file or directory /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/binfmt_flat.c: In function 'create_flat_tables': /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/binfmt_flat.c:124: error: implicit declaration of function ...
May 21, 10:42 am 2008
Adrian Bunk
[2.6 patch] frv: export empty_zero_page
cu Adrian <-- snip --> This patch fixes the following build error: <-- snip --> ... MODPOST 1845 modules ERROR: "empty_zero_page" [fs/ext4/ext4dev.ko] undefined! ... make[2]: *** [__modpost] Error 1 <-- snip --> Reported-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Adrian Bunk <bunk@kernel.org> --- arch/frv/mm/init.c | 3 +++ 1 file changed, 3 insertions(+) 69b697b58fe1a9d7f871285768efdbec443ad2e8 diff --git a/arch/frv/mm/init.c ...
May 21, 12:54 pm 2008
David Howells
Re: [2.6 patch] frv: export empty_zero_page
EXPORT_SYMBOL() as elsewhere please. I can't test it till I get home next week. David --
May 21, 11:55 am 2008
Adrian Bunk
Re: [2.6 patch] frv: export empty_zero_page
cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed --
May 21, 12:16 pm 2008
David Howells
Re: [2.6 patch] frv: export empty_zero_page
Okay, everywhere barring ia64 then. David --
May 21, 12:24 pm 2008
Adrian Bunk
[2.6 patch] frv: export empty_zero_page
This patch fixes the following build error: <-- snip --> ... MODPOST 1845 modules ERROR: "empty_zero_page" [fs/ext4/ext4dev.ko] undefined! ... make[2]: *** [__modpost] Error 1 <-- snip --> Reported-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Adrian Bunk <bunk@kernel.org> --- arch/frv/mm/init.c | 2 ++ 1 file changed, 2 insertions(+) 55cf8b72a4e2a78f61de2ef01e70bdd533c6bcf5 diff --git a/arch/frv/mm/init.c b/arch/frv/mm/init.c index b841ecf..94ea3d8 100644 --- ...
May 21, 10:42 am 2008
Matthew Wilcox
Re: [2.6 patch] scsi/advansys.c: fix compile errors
Last time this came up, I think the consensus was that those architectures should be providing a stub free_dma(). -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." --
May 21, 12:53 pm 2008
Adrian Bunk
[2.6 patch] scsi/advansys.c: fix compile errors
This patch fixes the following compile error on architectures not providing free_dma(): <-- snip --> ... CC [M] drivers/scsi/advansys.o /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/scsi/advansys.c:71:2: warning: #warning this driver is still not properly converted to the DMA API /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/scsi/advansys.c: In function 'advansys_board_found': /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/scsi/advansys.c:13876: error: implicit declaration of ...
May 21, 10:41 am 2008
Adrian Bunk
Re: [2.6 patch] scsi/advansys.c: fix compile errors
I tried building as many modules as possible on frv, and this was the only driver that failed this way. Another possibility would be to let this driver depend on ISA_DMA_API (similar to e.g. SCSI_EATA). Sorry for being lazy, but touching X architectures for fixing the compiliation of a driver whose hardware will anyway most likely never be used on this architecture is IMHO not worth the effort... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out ...
May 21, 1:07 pm 2008
Greg Smith
PostgreSQL pgbench performance regression in 2.6.23+
PostgreSQL ships with a simple database benchmarking tool named pgbench, in what's labeled the contrib section (in many distributions it's a separate package from the main server/client ones). I see there's been some work done already improving how the PostgreSQL server works under the new scheduler (the "Poor PostgreSQL scaling on Linux 2.6.25-rc5" thread). I wanted to provide you a different test case using pgbench that has taken a sharp dive starting with 2.6.23, and the server ...
May 21, 10:34 am 2008
Adrian Bunk
[2.6 patch] CONFIG_SOUND_WM97XX: remove stale makefile line
The driver is gone for a long time. Reported-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Adrian Bunk <bunk@kernel.org> --- 5aead6331a39f4e2e2ee31f9ea1ff092843a3f99 diff --git a/sound/oss/Makefile b/sound/oss/Makefile index 1f86299..d0440be 100644 --- a/sound/oss/Makefile +++ b/sound/oss/Makefile @@ -32,8 +32,6 @@ obj-$(CONFIG_SOUND_AU1550_AC97) += au1550_ac97.o ac97_codec.o obj-$(CONFIG_SOUND_TRIDENT) += trident.o ac97_codec.o obj-$(CONFIG_SOUND_BCM_CS4297A) += ...
May 21, 10:38 am 2008
Adrian Bunk
[2.6 patch] remove some more tipar bits
Some bits were missed when the tipar driver was removed. Signed-off-by: Adrian Bunk <bunk@kernel.org> --- Documentation/00-INDEX | 2 -- Documentation/kernel-parameters.txt | 7 ------- drivers/char/Makefile | 1 - 3 files changed, 10 deletions(-) 144d2868af6e355ef15a831b82dda80b8d2cc31e diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 1977fab..6de7130 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -361,8 ...
May 21, 10:38 am 2008
Adrian Bunk
[2.6 patch] powerpc/boot/Makefile CONFIG_ variable fixes
This patch corrects the names of two CONFIG_ variables. Note that the CONFIG_MPC86XADS fix uncovers another bug (with mpc866_ads_defconfig) that will require fixing: <-- snip --> ... arch/powerpc/boot/dtc -O dtb -o arch/powerpc/boot/mpc866ads.dtb -b 0 /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/dts/mpc866ads.dts DTC: dts->dtb on file "/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/dts/mpc866ads.dts" WRAP ...
May 21, 10:38 am 2008
Gabriel C
linux-next: UML build error
Hi, I get the following UML compile error on linux-next-20080521 , 64bit box : ... CC arch/um/sys-x86_64/ksyms.o arch/um/sys-x86_64/ksyms.c:5: error: '__memcpy' undeclared here (not in a function) arch/um/sys-x86_64/ksyms.c:5: warning: type defaults to 'int' in declaration of '__memcpy' make[1]: *** [arch/um/sys-x86_64/ksyms.o] Error 1 make: *** [arch/um/sys-x86_64] Error 2 ... config is UM's defconfig. Regards, Gabriel --
May 21, 10:26 am 2008
Gabriel C
Re: linux-next: UML build error
Yes is fixes this error , however I get now another one but this one seems to be an compiler bug. ... CC arch/um/sys-x86_64/um_module.o LD arch/um/sys-x86_64/subarch.o LD arch/um/sys-x86_64/built-in.o LD arch/x86/crypto/built-in.o CC kernel/sched.o In file included from kernel/sched.c:1842: kernel/sched_idletask.c: In function 'check_preempt_curr_idle': kernel/sched_idletask.c:20: internal compiler error: in cgraph_estimate_size_after_inlining, at ...
May 21, 1:20 pm 2008
Jeff Dike
Re: linux-next: UML build error
Does the patch below help? There's gcc-version-dependent logic in include/asm-x86/string_64.h which decides whether to declare memcpy or __memcpy and it looks like you're hitting that. Jeff -- Work email - jdike at linux dot intel dot com Index: linux-2.6.22/arch/um/sys-x86_64/ksyms.c =================================================================== --- linux-2.6.22.orig/arch/um/sys-x86_64/ksyms.c 2008-04-23 13:07:23.000000000 -0400 +++ ...
May 21, 1:05 pm 2008
Tom Spink
Re: 2.6.24 not recognizing 2G MMC card?
Hi, What does: lsmod | grep ricoh, give you? Anything? -- Tom Spink --
May 21, 11:01 am 2008
J. Bruce Fields
2.6.24 not recognizing 2G MMC card?
Please forgive a somewhat naive question--I'm not sure how to go about debugging this kind of thing: I have a Dell 1420n with card readers reported by lspci as: 03:01.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22) 03:01.2 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 12) I have a 512MB MicroSD card which seems to be recognized fine, but a 2GB MMC card is not. I'm using a stock Ubuntu 8.04 kernel, which reports itself ...
May 21, 10:21 am 2008
Martin Willi
[PATCH 2.6.26-rc3] xfrm: Installing NULL encryption IPSe ...
Installing NULL encryption IPSec SAs works using the .compat name "cipher_null", but fails with the .name "ecp(cipher_null)" due the missing check in key length verification.  Signed-off-by: Martin Willi <martin@strongswan.org> --- a/net/xfrm/xfrm_user.c 2008-05-21 11:34:56.000000000 -0500 +++ b/net/xfrm/xfrm_user.c 2008-05-21 11:20:08.000000000 -0500 @@ -57,6 +57,7 @@ case XFRMA_ALG_CRYPT: if (!algp->alg_key_len && + strcmp(algp->alg_name, ...
May 21, 9:55 am 2008
David Miller
Re: [PATCH 2.6.26-rc3] xfrm: Installing NULL encryption ...
From: Martin Willi <martin@strongswan.org> Herbert does this look Ok to you? Thanks.
May 21, 1:37 pm 2008
Herbert Xu
Re: [PATCH 2.6.26-rc3] xfrm: Installing NULL encryption ...
I think we should get rid of the zero check altogether as a zero-length key will fail on setkey of a real algorithm anyway because of the min_keysize/max_keysize checks in the crypto API. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --
May 21, 4:59 pm 2008
Miklos Szeredi
[patch 13/14] vfs: dont use dentry_permission()
From: Miklos Szeredi <mszeredi@suse.cz> Move most calls of dentry_permission() to path_permission(). The remaining few uses are all in namei.c, so dentry_permission() can be made static, further simplifying the API. This will have the side effect, that MNT_NOEXEC checking on the mount will be performed for these callers as well. But this should not cause any problems. At this point file_permission() is just a helper for path_permission(), so remove comment about not being ...
May 21, 10:15 am 2008
Miklos Szeredi
[patch 12/14] vfs: create path_permission()
From: Miklos Szeredi <mszeredi@suse.cz> Push nameidata further up the call chain, completely removing it from the permission API. Switch calls of vfs_permission() to path_permission(). Instead of nameidata, pass the path and nameidata->flags to this function. This is a trivially equivalent transformation. Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> --- fs/exec.c | 4 ++-- fs/inotify_user.c | 2 +- fs/namei.c | 23 ++++++++++++----------- fs/open.c ...
May 21, 10:15 am 2008
Miklos Szeredi
[patch 14/14] vfs: path_permission() clean up flags
From: Miklos Szeredi <mszeredi@suse.cz> Currently callers of path_permission() either pass zero or nameidata->flags as the flags argument. Passing lookup flags to filesystems is completely unecessary, only the "intent" flags are interesting. More specifically nfs uses LOOKUP_ACCESS and LOOKUP_OPEN flags, while fuse uses LOOKUP_ACCESS and LOOKUP_CHDIR flags. So clean up path_permission() calls to just pass these flags. In case of LOOKUP_CHDIR and LOOKUP_ACCESS the lookup routines need ...
May 21, 10:15 am 2008
Miklos Szeredi
[patch 09/14] security: dont pass nameidata to security_ ...
From: Miklos Szeredi <mszeredi@suse.cz> Only pass nameidata->flags instead of the nameidata to security_inode_permission(), synchronizing it with i_op->permission(). Currently no security module uses the nameidata parameter. The other change in ->permission() is that a dentry is passed instead of an inode. Leave this till AppArmor integration, since that will need a struct path instead of an inode. Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> CC: James Morris ...
May 21, 10:15 am 2008
James Morris
Re: [patch 09/14] security: dont pass nameidata to secur ...
Acked-by: James Morris <jmorris@namei.org> -- James Morris <jmorris@namei.org> --
May 21, 3:52 pm 2008
Miklos Szeredi
[patch 10/14] vfs: pass flags to dentry_permission()
From: Miklos Szeredi <mszeredi@suse.cz> Switch last argument of dentry_permission() from nameidata to flags. This requires the MNT_NOEXEC checking to be moved from dentry_permission() to vfs_permission(). The following dentry_permission() callers passed a non-NULL nameidata: vfs_permission() This remained almost equivalent, except that ordering of the MNT_NOEXEC check and the IS_RDONLY/IS_IMMUTABLE checks has been changed. However the IS_RDONLY check should never trigger, ...
May 21, 10:15 am 2008
Trond Myklebust
Re: [patch 11/14] vfs: move executable checking into ->p ...
OK, but when I see something with the name 'exec_permission()', I assume that it is going to check for whether or not I have execute permission. If that is not the case, then can we please either change the function, or change the name? Cheers Trond --
May 21, 12:26 pm 2008
Miklos Szeredi
Re: [patch 11/14] vfs: move executable checking into ->p ...
No, we don't want to deny read or write (that's up to the filesystem how it handles it), just want to deny execute if no x bits are set in the mode. I didn't really pay attention to individual filesystems, including NFS, just mechanically moved the check from permission() to ->permission(). So it's possible that the code could be further optimized in some cases. Miklos --
May 21, 12:09 pm 2008
Trond Myklebust
Re: [patch 11/14] vfs: move executable checking into ->p ...
Hmm... What if !(mask & MAY_EXEC)? AFAICS, the above will return 0. A better approach would be to use something like if (!(mask & MAY_EXEC)) return -EACCES; if (S_ISREG(inode->i_mode) && !(inode->i_mode & S_IXUGO)) return -EACCES; return 0; --
May 21, 11:16 am 2008
Miklos Szeredi
[patch 11/14] vfs: move executable checking into ->permi ...
From: Miklos Szeredi <mszeredi@suse.cz> For execute permission on a regular files we need to check if file has any execute bits at all, regardless of capabilites. This check is normally performed by generic_permission() but was also added to the case when the filesystem defines its own ->permission() method. In the latter case the filesystem should be responsible for performing this check. So create a helper function exec_permission() that checks returns -EACCESS if MAY_EXEC is present, ...
May 21, 10:15 am 2008
Miklos Szeredi
Re: [patch 11/14] vfs: move executable checking into ->p ...
Yeah, the name's not very good. Especially that there's an exec_permission_lite() in the same file, which has nothing to do with this. Will try to think of something better. Miklos --
May 21, 12:34 pm 2008
Miklos Szeredi
[patch 08/14] vfs: cleanup i_op->permission()
From: Miklos Szeredi <mszeredi@suse.cz> Signature of i_op->permission() is changed from int (*permission) (struct inode *inode, int mask, struct nameidata *nd); to int (*permission) (struct dentry *dentry, int mask, int flags); Lots of filesystems need to be updated, but the only ones actually making use of the dentry (instead of the inode) or flags are: - ecryptfs: uses both dentry and flags - fuse: checks LOOKUP_ACCESS and LOOKUP_CHDIR in flags - nfs: checks LOOKUP_ACCESS and ...
May 21, 10:15 am 2008
Al Viro
Re: [patch 07/14] vfs: pass dentry to permission()
No. Take a good look at the instances. a) only one aberrant case cares about dentry, and for extremely wrong reasons. /proc/sys/ stuff. ecryptfs, of course, will be happy with any variant. b) few flags that are looked at are trivially mapped to new MAY_... I have a patch series that does it, but it involves tons of fixing the sysctl handling to be finished ;-/ And yes, we need sysctl to quit doing the "I want to get ctl_table entry, so I'll do very painful search by dentry every damn ...
May 21, 1:29 pm 2008
Miklos Szeredi
[patch 07/14] vfs: pass dentry to permission()
From: Miklos Szeredi <mszeredi@suse.cz> The following patches clean up the i_op->permission() method and the related VFS API. Here's an overview of the changes: - ->permission() is passed a dentry instead of an inode - ->permission() is passed a integer flags parameter instead of a nameidata pointer - all nameidata pointer passing is removed from the permission API - the check for execute bit on regular files is moved into ->permission() - the permission() and vfs_permission() ...
May 21, 10:15 am 2008
Miklos Szeredi
[patch 05/14] hpfs: dont call permission()
From: Miklos Szeredi <mszeredi@suse.cz> hpfs_unlink() calls permission() prior to truncating the file. HPFS doesn't define a .permission method, so replace with explicit call to generic_permission(). This is equivalent, except that devcgroup_inode_permission() and security_inode_permission() are not called. The truncation is just an implementation detail of the unlink, so these security checks are unnecessary. I suspect that even calling generic_permission() is unnecessary, since we ...
May 21, 10:15 am 2008
Roman Zippel
Re: [patch 06/14] hfsplus: remove hfsplus_permission()
Hi, No, it's not, it allows for HFS+ specific special case to allow the lookup of the resource fork. bye, Roman --
May 21, 1:35 pm 2008
Miklos Szeredi
[patch 06/14] hfsplus: remove hfsplus_permission()
From: Miklos Szeredi <mszeredi@suse.cz> I'm not sure what this function is trying to achieve, but it's not succeeding: the condition for which it is returning zero is exactly the same as checked by permission(), which results in -EACCES. So in the end this is equivalent to the default action. A similar check is in hfs_permission() but that does actually do something, though I'm doubtful if it's the right thing. But we should probably leave that alone, lest we break something ...
May 21, 10:15 am 2008
Miklos Szeredi
[patch 04/14] gfs2: dont call permission()
From: Miklos Szeredi <mszeredi@suse.cz> GFS2 calls permission() to verify permissions after locks on the files have been taken. For this it's sufficient to call gfs2_permission() instead. This results in the following changes: - IS_RDONLY() check is not performed - IS_IMMUTABLE() check is not performed - devcgroup_inode_permission() is not called - security_inode_permission() is not called IS_RDONLY() should be unnecessary anyway, as the per-mount read-only flag should provide ...
May 21, 10:15 am 2008
Miklos Szeredi
[patch 03/14] hppfs: remove hppfs_permission
From: Miklos Szeredi <mszeredi@suse.cz> hppfs_permission() is equivalent to the '.permission == NULL' case. Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> CC: Jeff Dike <jdike@linux.intel.com> --- fs/hppfs/hppfs.c | 7 ------- 1 file changed, 7 deletions(-) Index: linux-2.6/fs/hppfs/hppfs.c =================================================================== --- linux-2.6.orig/fs/hppfs/hppfs.c 2008-05-21 13:13:29.000000000 +0200 +++ linux-2.6/fs/hppfs/hppfs.c 2008-05-21 ...
May 21, 10:15 am 2008
Miklos Szeredi
[patch 02/14] vfs: add path_listxattr()
From: Miklos Szeredi <mszeredi@suse.cz> Introduce path_listxattr(). Make vfs_listxattr() static. Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> --- fs/xattr.c | 15 ++++++++------- include/linux/xattr.h | 2 +- 2 files changed, 9 insertions(+), 8 deletions(-) Index: linux-2.6/fs/xattr.c =================================================================== --- linux-2.6.orig/fs/xattr.c 2008-05-21 13:30:33.000000000 +0200 +++ linux-2.6/fs/xattr.c 2008-05-21 ...
May 21, 10:15 am 2008
Miklos Szeredi
[patch 01/14] vfs: add path_getxattr()
From: Miklos Szeredi <mszeredi@suse.cz> Introduce path_getxattr(). Make vfs_getxattr() static. Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> --- fs/nfsd/nfs4xdr.c | 2 +- fs/nfsd/vfs.c | 25 ++++++++++++++++--------- fs/xattr.c | 15 ++++++++------- include/linux/nfsd/nfsd.h | 3 ++- include/linux/xattr.h | 2 +- 5 files changed, 28 insertions(+), 19 deletions(-) Index: ...
May 21, 10:14 am 2008
Miklos Szeredi
[patch 00/14] vfs: permission API cleanup
Highlights are: - remove nameidata from the i_op->permission() method - remove nameidata passing and consolidate permission()/ vfs_permission()/file_permission() API It's all fairly trivial stuff, but I will do some LTP testing on it. This series is based on the vfs-cleanups(*) tree. If no problems are found, I'll commit the patches to that tree. Thanks, Miklos (*) git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git vfs-cleanups -- --
May 21, 10:14 am 2008
Sitsofe Wheeler
Re: [BISECTED] linux-next-20080519 does not boot on x86 (ACPI)
<posted & mailed> OK I've finally bisected this down to the following commit: commit 86a2e1a7ec8c6363e502ac8ccf5fe50dd46b39c2 Author: Alexey Starikovskiy <astarikovskiy@suse.de> Date: Wed May 14 19:02:57 2008 +0400 x86: complete move ACPI from mpparse.c Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Ingo Molnar <mingo@elte.hu> Reverting that commit made the problem go away. Here's the bisection log: # bad: ...
May 21, 10:09 am 2008
Mathieu Desnoyers May 21, 4:24 pm 2008
Mathieu Desnoyers
Re: [PATCH] Fix Immediate Values x86_64 support old gcc
Yes, I guess this worth being commented, you are right. I'll write Hrm, if I do that, I would have to add USE_IMMEDIATE to each architecture's makefiles for which immediate values are supported, e.g.: export USE_IMMEDIATE := $(CONFIG_IMMEDIATE) The "BROKEN_IMMEDIATE" (negative) approach only needs to be defined on I could pass the USE_IMMEDIATE as a -D to the compiler flags. That would I think USE_IMMEDIATE is the way to go then. Thanks, -- Mathieu Desnoyers OpenPGP key ...
May 21, 2:28 pm 2008
Mathieu Desnoyers
Re: [PATCH] Fix Immediate Values x86_64 support old gcc (v2)
Given that I want to change every use of CONFIG_IMMEDIATE into USE_IMMEDIATE, both in architecture specific and independant C files and also in arch spec. and indep. Makefiles, I will have to define USE_IMMEDIATE on other arch too. Here is the updated patch. It applies on top of the sched-devel.git tree. Fix Immediate Values x86_64 support old gcc GCC < 4, on x86_64, does not accept symbol+offset operands for "i" constraints asm statements. Fallback on generic immediate values if this ...
May 21, 2:57 pm 2008
Mathieu Desnoyers
[PATCH] Fix Immediate Values x86_64 support old gcc
Does this fix make more sense ? GCC < 4, on x86_64, does not accept symbol+offset operands for "i" constraints asm statements. Fallback on generic immediate values if this compiler is detected. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> --- arch/x86/Makefile | 3 +++ arch/x86/kernel/Makefile | 4 +++- include/asm-x86/immediate.h | 5 +++++ include/linux/immediate.h | 4 +++- kernel/Makefile | 4 +++- 5 files changed, 17 ...
May 21, 10:01 am 2008
Sam Ravnborg
Re: [PATCH] Fix Immediate Values x86_64 support old gcc (v2)
tabs has a special sematic purpose in makefiles so do not tabs -> spaces again. Other than that I like this patch much better. Thanks, Sam --
May 21, 3:38 pm 2008
Sam Ravnborg
Re: [PATCH] Fix Immediate Values x86_64 support old gcc
So here we introduce a global environment variable that tells us that gcc has "BROKEN_IMMEDIATE". I have absolutely no clue what "BROKEN_IMMEDIATE" is so I guess others are in the same boat. Comment please! Consider something like this (note: no negative logic involved): export USE_IMMEDIATE := $(call cc-ifversion, -ge, 0400, $(CONFIG_IMMEDIATE)) And now in the source we use a direct check of the GNUC version. So this is a duplicate of GCC_BROKEN_IMMEDIATE and not sensible comments. "I ...
May 21, 1:37 pm 2008
Sam Ravnborg
Re: [PATCH] Fix Immediate Values x86_64 support old gcc
Same with USE_IMMEDIATE - as USE_IMMEDIATE is only used in a x86 Makefile. Or did I miss sothing? Sam --
May 21, 2:46 pm 2008
Jochen Friedrich
[PATCHv2] i2c: adds support for i2c bus on Freescale CPM ...
This driver uses the port of 2.4 code from Vitaly Bordug <vitb@kernel.crashing.org> and the actual algorithm used by the i2c driver of the DBox code on cvs.tuxboc.org from Felix Domke (tmbinc@gmx.net) and Gillem (htoa@gmx.net) converted to an of_platform_driver. Tested on CPM1 (MPC823 on dbox2 hardware) and CPM2 (MPC8272). Signed-off-by: Jochen Friedrich <jochen@scram.de> --- drivers/i2c/busses/Kconfig | 10 + drivers/i2c/busses/Makefile | 1 + drivers/i2c/busses/i2c-cpm.c | 745 ...
May 21, 9:39 am 2008
Jochen Friedrich
[PATCHv2] [POWERPC] Add i2c pins to dts and board setup
Initialize I2C pins on boards with CPM1/CPM2 controllers. Signed-off-by: Jochen Friedrich <jochen@scram.de> --- Documentation/powerpc/booting-without-of.txt | 42 ++++++++++++++++++++++++++ arch/powerpc/boot/dts/mpc8272ads.dts | 11 +++++++ arch/powerpc/boot/dts/mpc866ads.dts | 11 +++++++ arch/powerpc/boot/dts/mpc885ads.dts | 11 +++++++ arch/powerpc/platforms/82xx/mpc8272_ads.c | 4 ++ arch/powerpc/platforms/8xx/mpc86xads_setup.c | 4 ++ ...
May 21, 9:37 am 2008
Cyrill Gorcunov
Re: [RFC] x86: merging nmi 32/64 to nmi.c v2
[Hiroshi Shimamoto - Wed, May 21, 2008 at 11:20:17AM -0700] | Cyrill Gorcunov wrote: | > This is a second attempt to merge nmi-32/64 to nmi.c | | Hi Cyrill, | | cool work! | | > Summary changes: | > | ... | > - last_irq_sums and alert_counter was defined as static arrays in 32bit | > mode, so they were changed to per_cpu variables | | This was already done, see http://lkml.org/lkml/2008/5/2/525. | But it doesn't affect the unified file. | | > +#ifdef CONFIG_X86_64 | > +static ...
May 21, 11:47 am 2008
Cyrill Gorcunov
[RFC] x86: merging nmi 32/64 to nmi.c v2
This is a second attempt to merge nmi-32/64 to nmi.c Summary changes: - a few helper functions added (placed on top part of nmi.c) - nmi_watchdog_default() now handles both 32/64 modes - check_nmi_watchdog() uses for_each_online_cpu() even in 32bit mode since cpu_online_map is set up after cpu_callin_map anyway - last_irq_sums and alert_counter was defined as static arrays in 32bit mode, so they were changed to per_cpu variables - and the most notable change is that I've changed ...
May 21, 9:30 am 2008
Hiroshi Shimamoto
Re: [RFC] x86: merging nmi 32/64 to nmi.c v2
Hi Cyrill, This was already done, see http://lkml.org/lkml/2008/5/2/525. I'm guessing we can move these functions to traps_64.c. I've tried to move these functions from traps_32.c to nmi_32.c, but it caused build error on some 32bit configs. thanks, Hiroshi Shimamoto --
May 21, 11:20 am 2008
Cyrill Gorcunov
Re: [RFC] x86: merging nmi 32/64 to nmi.c v2
[Hiroshi Shimamoto - Wed, May 21, 2008 at 11:20:17AM -0700] | Cyrill Gorcunov wrote: | > This is a second attempt to merge nmi-32/64 to nmi.c | | Hi Cyrill, | | cool work! | | > Summary changes: | > | ... | > - last_irq_sums and alert_counter was defined as static arrays in 32bit | > mode, so they were changed to per_cpu variables | | This was already done, see http://lkml.org/lkml/2008/5/2/525. | But it doesn't affect the unified file. | | > +#ifdef CONFIG_X86_64 | > +static ...
May 21, 12:21 pm 2008
Mimi Zohar
[RFC][Patch 4/4]integrity: IMA as an integrity service p ...
This is a re-release of Integrity Measurement Architecture(IMA) as an independent Linunx Integrity Module(LIM) service provider, which implements the new LIM must_measure(), collect_measurement(), store_measurement(), and display_template() API calls. The store_measurement() call supports two types of data, IMA (i.e. file data) and generic template data. When store_measurement() is called for the IMA type of data, the file measurement and the file name hint are used to form an IMA ...
May 21, 8:55 am 2008
Mimi Zohar
[RFC][PATCH 3/4]integrity: Linux Integrity Module(LIM)
This is a request for comments for a redesign of the integrity patches. The new version addresses a number of issues, including - generalizing the measurement API beyond just inode measurements. - separation of the measurement into distinct collection, appraisal, and commitment phases, for greater flexibility. - redesigning the interactions with LSM modules (Selinux and Smack) to be acceptable to those groups. Extended Verification Module(EVM) and the Integrity ...
May 21, 8:54 am 2008
Mimi Zohar
[RFC][Patch 2/4] integrity: special fs magic
- Move special fs magic number definitions to magic.h - Add magic.h include Signed-off-by: Mimi Zohar <zohar@us.ibm.com> --- Index: linux-2.6.26-rc3-git2/mm/shmem.c =================================================================== --- linux-2.6.26-rc3-git2.orig/mm/shmem.c +++ linux-2.6.26-rc3-git2/mm/shmem.c @@ -50,14 +50,12 @@ #include <linux/migrate.h> #include <linux/highmem.h> #include <linux/seq_file.h> +#include <linux/magic.h> #include <asm/uaccess.h> #include ...
May 21, 8:54 am 2008
Mimi Zohar
[RFC][Patch 1/4]integrity: TPM internel kernel interface
This is a request for comments for a redesign of the integrity patches. This patchset contains 4 patches. Patch 1/4 integrity: TPM internal kernel interface Patch 2/4 integrity: special fs magic Patch 3/4 integrity: Linux Integrity Module(LIM) Patch 4/4 integrity: IMA as an integrity service provider Resubmitting integrity-tpm-internal-kernel-interface.patch, which was previously Signed-off-by Kylene Hall. Adds the following support: - internal kernel interface to transmit TPM ...
May 21, 8:54 am 2008
Andrew G. Morgan
[PATCH] security: protect legacy apps from insufficient ...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is a fail-safe additional feature for filesystem capability support. Cheers Andrew -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFINES/+bHCR3gb8jsRAmPdAJsG8fKTNBXYmUb3CJDchLQ1MCYgDQCg2uQl ltlVX1O9D6BtDK/4+gsoq8U= =AUc0 -----END PGP SIGNATURE-----
May 21, 8:50 am 2008
Serge E. Hallyn
Re: [PATCH] security: protect legacy apps from insuffici ...
Assuming (as it appears) the only change from last time is that you dropped the part changing cap_bprm_apply_creds() contraints for a ptraced process, then Acked-by: Serge Hallyn <serue@us.ibm.com> I'll try to give it a good test-run next week. thanks, --
May 21, 1:34 pm 2008
Serge E. Hallyn May 21, 1:03 pm 2008
Cedric Le Goater
[PATCH -mm] remove node_ prefix_from ns subsystem
From: Cedric Le Goater <clg@fr.ibm.com> This is a slight change in the namespace cgroup subsystem api. Signed-off-by: Cedric Le Goater <clg@fr.ibm.com> --- kernel/cgroup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: 2.6.26-rc2-mm1/kernel/cgroup.c =================================================================== --- 2.6.26-rc2-mm1.orig/kernel/cgroup.c +++ 2.6.26-rc2-mm1/kernel/cgroup.c @@ -2903,7 +2903,7 @@ int cgroup_clone(struct task_struct *tsk cg = ...
May 21, 8:47 am 2008
Vivek Goyal
Re: [-mm][PATCH 4/4] Add memrlimit controller accounting ...
On Wed, May 21, 2008 at 09:00:12PM +0530, Balbir Singh wrote: Hi Balbir, How does rcu help here? We are not dereferencing mm->owner. So even if task_struct it was pointing to goes away, should not be a problem. OTOH, while updating the mm->owner in mmm_update_next_owner(), we are not using rcu_assing_pointer() and synchronize_rcu()/call_rcu(). Is this the right usage if mm->owner is rcu protected? Thanks Vivek --
May 21, 10:20 am 2008
Balbir Singh
[-mm][PATCH 0/4] Add memrlimit controller (v5)
This is the fifth version of the address space control patches. These patches are against 2.6.26-rc2-mm1 and have been tested using KVM in SMP mode, both on a powerpc box The goal of this patch is to implement a virtual address space controller using cgroups. The documentation describes the controller, it's goal and usage in further details. Reviews, Comments? Changelog Patches [1/4] and [2/4] are unchanged Patch [3/4] and [4/4] now formally use mmap_sem to protect mm->owner ...
May 21, 8:29 am 2008
Balbir Singh
[-mm][PATCH 1/4] Add memrlimit controller documentation (v5)
Documentation patch - describes the goals and usage of the memrlimit controller. Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com> --- Documentation/controllers/memrlimit.txt | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff -puN /dev/null Documentation/controllers/memrlimit.txt --- /dev/null 2008-05-16 21:23:36.290004010 +0530 +++ linux-2.6.26-rc2-balbir/Documentation/controllers/memrlimit.txt 2008-05-21 20:53:33.000000000 +0530 @@ -0,0 +1,29 ...
May 21, 8:29 am 2008
Balbir Singh
[-mm][PATCH 2/4] Setup the memrlimit controller (v5)
This patch sets up the rlimit cgroup controller. It adds the basic create, destroy and populate functionality. The user interface provided is very similar to the memory resource controller. The rlimit controller can be enhanced easily in the future to control mlocked pages. Changelog v3->v4 1. Use PAGE_ALIGN() 2. Rename rlimit to memrlimit Acked-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com> --- include/linux/cgroup_subsys.h | 4 ...
May 21, 8:29 am 2008
Balbir Singh
[-mm][PATCH 3/4] cgroup mm owner callback changes to add ...
This patch adds an additional field to the mm_owner callbacks. This field is required to get to the mm that changed. Hold mmap_sem in write mode before calling the mm_owner_changed callback Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com> --- include/linux/cgroup.h | 3 ++- kernel/cgroup.c | 4 +++- kernel/exit.c | 3 +++ 3 files changed, 8 insertions(+), 2 deletions(-) diff -puN include/linux/cgroup.h~cgroup-add-task-to-mm-owner-callbacks ...
May 21, 8:29 am 2008
Balbir Singh
[-mm][PATCH 4/4] Add memrlimit controller accounting and ...
This patch adds support for accounting and control of virtual address space limits. The accounting is done via the rlimit_cgroup_(un)charge_as functions. The core of the accounting takes place during fork time in copy_process(), may_expand_vm(), remove_vma_list() and exit_mmap(). Changelog v5->v4 Move specific hooks in code to insert_vm_struct Use mmap_sem to protect mm->owner from changing and mm->owner from changing cgroups. Signed-off-by: Balbir Singh ...
May 21, 8:30 am 2008
johnson_Michael4
Test
Hello, My Name is Dr. Johnson Michael from Harlesden , working with Natwest Bank Corporation , North West London , England.I am contacting you for a transaction amounting to $12.5 belonging to one of our late customers who died with his family in the plane crash of Alaska Airlines Flight 261 on the 31st January 2000. Due to the sensitivity and the confidentiality of this transaction,I am contrained to issue further details until your positive response is received. Thank you for your time and ...
May 21, 6:23 am 2008
Francois Romieu
Re: [PATCH][TRIVIAL] r8169.c : fix misleading comment
I do not approve: - the patch does not follow the comment style of the driver - the comment should be removed, not silly augmented -- Ueimor --
May 21, 11:53 am 2008
Emmanuel Colbus
[PATCH][TRIVIAL] r8169.c : fix misleading comment
Calling "PCI base addr 1" something that can actually lie at PCI_BASE_ADDR_2 is misleading. Patch follows. signed-off-by : emmanuel colbus <emmanuel.colbus@ovh.net> --- diff -Naur drivers/net/r8169.c.old drivers/net/r8169.c --- drivers/net/r8169.c.old 2008-05-21 15:20:46.000000000 +0200 +++ drivers/net/r8169.c 2008-05-21 15:22:16.000000000 +0200 @@ -1632,7 +1632,8 @@ if (rc < 0) goto err_out_disable_2; - /* make sure PCI base addr 1 is MMIO */ + ...
May 21, 7:08 am 2008
Gabriel C
linux-next: [PATCH] infiniband/hw/ipath/ipath_sdma.c , f ...
On linux-next from today , allmodconfig, I see the following warnings on 64bit: ... CC [M] drivers/infiniband/hw/ipath/ipath_sdma.o drivers/infiniband/hw/ipath/ipath_sdma.c: In function 'sdma_abort_task': drivers/infiniband/hw/ipath/ipath_sdma.c:267: warning: passing argument 2 of 'constant_test_bit' from incompatible pointer type drivers/infiniband/hw/ipath/ipath_sdma.c:267: warning: passing argument 2 of 'variable_test_bit' from incompatible pointer ...
May 21, 7:06 am 2008
Anton Vorontsov
[PATCH] [SPI/MMC] mmc_spi.h should include linux/interrupts.h
Since mmc_spi.h uses irqreturn_t type, it should include appropriate header, otherwise build will break if users didn't include it (some of them do not use interrupts). Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> --- include/linux/spi/mmc_spi.h | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/linux/spi/mmc_spi.h b/include/linux/spi/mmc_spi.h index e9bbe3e..d5ca78b 100644 --- a/include/linux/spi/mmc_spi.h +++ b/include/linux/spi/mmc_spi.h @@ ...
May 21, 6:29 am 2008
Thomas Nemeth
PCI driver architecture
Hi! I was going to ask a few questions to Greg KH when he told me=20 =2D-=20 Thomas Nemeth - Ing=E9nieur d'=C9tudes en Informatique Industrielle =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Industrial Computing Software Designer BETAtech - 15, rue Apollo, Z.A. de Montredon, 31240, L'Union. 05 34 30 40 00 (standard) =A0/ =A005 34 30 40 09 (ligne directe)
May 21, 6:05 am 2008
Thomas Nemeth
PCI driver architecture [repost]
[sorry - bad previous post] Hi! I was going to ask a few questions to Greg KH when he told me that my questions "look very reasonable for there, as long as I also post my code". So here is the context: we are developping 2 multi-IO boards at the request of our customer and, unfortunately, they asked us to develop their driver for Linux 2.4. As they are evaluating the possibility to switch to 2.6 in some months I'm writing the driver with 2.6 in mind. ...
May 21, 6:14 am 2008
Pekka Enberg
Re: Suggestion About Kernel Releases
You keep saying that but it simply is not true. The more people we have _waiting_ for a "stable" kernel to graduate from the "testing" series, the less people we have actually _testing_ the kernel. So it's probable that your suggestion actually makes the current situation worse, not better. --
May 21, 8:26 am 2008
Chris Wright
Re: Suggestion About Kernel Releases
Arjan already pointed out that this was about the merge window, not the (BTW, Greg does 2.6.x.y as well). What you are missing is that it is not Greg and I who are doing the bulk of testing for 2.6.x.y. It's the entire community, and adding additional stage to the tail or the release cycle will not increase testing coverage. History shows it'll just postpone it. thanks, -chris --
May 21, 10:31 am 2008
Arjan van de Ven
Re: Suggestion About Kernel Releases
On Wed, 21 May 2008 16:08:37 +0300 what would you want to accomplish with your idea? --
May 21, 6:38 am 2008
Arjan van de Ven
Re: Suggestion About Kernel Releases
On Wed, 21 May 2008 16:59:56 +0300 sorry but you're wrong ;( calling something -test won't change anything. It just means it'll get tested less, not more. Also the "Slow DOWN please" had NOTHING to do with releases, but only with what happens during the actual merge window. --
May 21, 7:28 am 2008
Tarkan Erimer
Suggestion About Kernel Releases
Hi, After long discussions about kernel release methodology, an idea has came to ( Any comments welcomed :-) ) my mind : - 2 weeks of merge window for each "rc" releases should remain the same . - When decided the 2.6.xx-rcx is ready to become 2.6.xx, it should be 2.6.xx-test1 instead of 2.6.xx - Chris Wright (or whoever will handle these "testX" maintaining) can maintain these "testX" releases as like 2.6.x.y maintaining. - After releasing the "testX" releases, the new kernel release ...
May 21, 6:08 am 2008
Tarkan Erimer
Re: Suggestion About Kernel Releases
To make kernel releases more stable/tested via "testX" series, as recently discussed by David Miller's "Slow DOWN, please!!!" thread. These "testX" releases will give more opportunity and time to test more these new releases. Also, with the aim of the "testX" series, the new kernel release schedules/merge windows will be not slow down. Even, Linus can releases new kernels more quickly. Because, testing purpose should be handled by someone else like Chris did for 2.6.x.y. --
May 21, 6:59 am 2008
Mike Snitzer
Re: Suggestion About Kernel Releases
I think you're missing Arjan and Pekka's point: your proposal doesn't _really_ offer any change to the current procedure. It might make you feel more warm and fuzzy but in practice: 1) Linus would still release a kernel (be it to -testX or "final") when he and others feel it is time 2) The stable team will track fixes and release stable kernels as needed The only thing that is different in your approach is the "final" release would theoretically be more well tested. Unfortunately that is ...
May 21, 7:32 am 2008
Arjan van de Ven
Re: Suggestion About Kernel Releases
On Wed, 21 May 2008 17:50:00 +0300 no you're not. You're talking about the tail of a cycle, while the Slow Down thing was ONLY about the first 2 weeks merge window. Since this discussion has all the signs of a derailing thread.. I would strongly suggest we end it here. Not trying to just cut you off, but this has been discussed a lot, and your posts aren't adding something new to that. --
May 21, 8:12 am 2008
Tarkan Erimer
Re: Suggestion About Kernel Releases
Please see my reply to Arjan's post. --
May 21, 7:00 am 2008
Pekka Enberg
Re: Suggestion About Kernel Releases
And how is it different from what we do now, modulo the -test1 postfix to the name? --
May 21, 6:48 am 2008
Tarkan Erimer
Re: Suggestion About Kernel Releases
Yes, that's what I'm talking about. The change will be the "testX" Of course as didn't embrace like the "rc" releases. I don't think that it will cause early stable fixes. Contrarily, it will produce more It is. As I described above : the "testX" series will change the things as producing more tested /stable releases. BTW, it should be much better to release less, trouble free kernels instead of releasing fast but fixing soon. Also, it will take the load of deep kernel testing. Linus ...
May 21, 8:15 am 2008
Tarkan Erimer
Re: Suggestion About Kernel Releases
It's just a suggestion. Of course, I may be wrong ;-) Yes, I know. That's what I'm talking about :-) --
May 21, 7:50 am 2008
Oliver Pinter
Re: Suggestion About Kernel Releases
now: linux-2.6.x -> linux-2.6.(x+1)-rcY -> linux-2.6.(x+1) \->2.6.x.y \->2.6.(x+1).y \->2.6.x.(y+1)-rc1->2.6.x.(.y+1) \->2.6.x.(y+1)-rc1->2.6.x.(.y+1) your idea: linux-2.6.x -> linux-2.6.(x+1)-rcY -> linux-2.6.(x+1) \->2.6.x.y \->2.6.(x+1).y \->2.6.x.(y+1)-test1->2.6.x.(.y+1) \->2.6.x.(y+1)-test1->2.6.(x+1).(.y+1) only the namig is was other, rc -> test, -- Thanks, Oliver --
May 21, 7:37 am 2008
Rik van Riel
Re: Suggestion About Kernel Releases
On Wed, 21 May 2008 16:59:56 +0300 If Linus were to go straight from merge window to merge window, with stabilization happening in parallel, then there would be no stable basis at the start of each merge window and bugs can just pile up. Speeding things up could lead to the same kind of code quality issues we used to have in the 1.3, 2.1, 2.3 and 2.5 kernel series. Slowing down regularly is good, not bad. -- All rights reversed. --
May 21, 12:55 pm 2008
Stefan Richter
Re: [PATCH] firewire: fix some broken hardware NMI interrupt
PS: And does the parity error happen with the ohci1394 driver too? -- Stefan Richter -=====-==--- -=-= =-==- http://arcgraph.de/sr/ --
May 21, 3:56 pm 2008
Stefan Richter
Re: [PATCH] firewire: fix some broken hardware NMI interrupt
Which card? Is the problem still present in linux-2.6.26-rc3? Or if you don't want to test 2.6.26-rc yet, please test 2.6.25.4 with the firewire patchkit from http://me.in-berlin.de/~s5r6/linux1394/updates/. There were changes to fw-ohci which influence chip initialization. -- Stefan Richter -=====-==--- -=-= =-=-= http://arcgraph.de/sr/ --
May 21, 8:28 am 2008
jszhang3
[PATCH] firewire: fix some broken hardware NMI interrupt
From JiSheng Zhang <jszhang3@mail.ustc.edu.cn> Some broken pci-1394 card does not clear completely on-chip memory during boot, it may cause pci parity error, then NMI interrupt. It will emit kernel message such as"Uhhuh. NMI received for unknown reason b1 on CPU 0. You have some hardware problem, likely on the PCI bus. Dazed and confused, but trying to continue" etc. If panic_on_unrecovered_nmi is set to 1, the system will panic. This patch will fix it --- ...
May 21, 6:08 am 2008
Matthias Cramer
Wired behaviour with IPv6 over PPP
Hi All I have a very wired behaviour when doing IPv6 over PPPoE. The situation: A linux box connected to a DSL Modem, on the other side is a Cisco LNS wh= ich terminates the PPP session (actually L2TP). I have control over both ends. When I have net.ipv6.conf.all.forwarding set to 0 then the ppp Interface = gets a IPv6 address from the Cisco via IP6CP. When I have net.ipv6.conf.all.forwarding set to 1 them the ppp Interface = does not get an address, it has only a normal link local ...
May 21, 5:56 am 2008
Takashi Iwai
Re: [alsa-devel] HG -> GIT migration
At Wed, 21 May 2008 16:40:37 +0200, I thought linux-next does fresh merges at each time, thus it doesn't matter whether a subsystem tree is rebased or not... Takashi --
May 21, 7:52 am 2008
Takashi Iwai
Re: [alsa-devel] HG -> GIT migration
At Wed, 21 May 2008 11:25:25 -0700 (PDT), Ah, that's what I missed. This suggestion actually makes sense. Takashi --
May 21, 11:49 am 2008
Rene Herman
Re: [alsa-devel] HG -> GIT migration
I'm also still frequently trying to figure out an/the efficient way of using GIT but it does seem it's not just a matter of "pure downstream" (which I do believe ALSA has few enough of to not make this be a huge problem). For example linux-next is also going to want to pull in ALSA and say it does, finds a trivial conflict with the trivial tree that it also pulls in and fixes things up. If you rebase that which linux-next pulls from I believe it will have to redo the fix next time it pulls ...
May 21, 7:40 am 2008
Rene Herman
Re: [alsa-devel] HG -> GIT migration
Over here: http://lkml.org/lkml/2008/5/17/203 Linus suggests to just not do many merges from upstream -- basically only at releases. I'm only looking at and experiencing things from the limited viewpoint of a leaf node though so I'll shut up for a bit first now as this might not be helpful. Rene. --
May 21, 8:40 am 2008
Linus Torvalds
Re: [alsa-devel] HG -> GIT migration
No it is NOT. Why should you have stuff from outside the subsystem tree? And quite frankly, the only reason to *need* those fixes in the first place is if you merge random test-kernels during the merge window. What you should strive for is to merge at the stable point, not random kernels to keep you "up-to-date", and suddenly you don't need to make more merges just to get (possibly) new fixes. See? If it's the ALSA tree, then what is it doing pulling all the random other ...
May 21, 9:16 am 2008
Takashi Iwai
Re: [alsa-devel] HG -> GIT migration
At Wed, 21 May 2008 12:02:29 -0700 (PDT), Thanks for clarification! Sounds like I should really do this more often to keep the devel tree clean without merge or rebase. Takashi --
May 21, 2:08 pm 2008
david
Re: [alsa-devel] HG -> GIT migration
one thing that you have missed in your explination in this thread (although you have made the point in other threads) is that subsystem maintainers have the fear that there are other changes that will interfere with their stuff and want to catch it early. per your instructions in prior threads, what they should do is to have a seperate branch on their system that they use as a throw-away branch to pull from your tree, and from their tree to spot problems. As they find problems they can ...
May 21, 11:25 am 2008
Linus Torvalds
Re: [alsa-devel] HG -> GIT migration
Well, that's actually fairly rare, but when it happens, either: - if you didn't get the fix (ie you're are just seeing random patches go in that happen to touch alsa), why should you then merge the WHOLE TREE with all my experimental stuff anyway? You can largely ignore it, knowing it's fixed, and when you ask me to pull, we'll have a good end result. - if you got the same fix as a patch, just apply it to your tree (ie just ignore what happens upstream). This ...
May 21, 10:43 am 2008
Rene Herman
Re: [alsa-devel] HG -> GIT migration
It's "worse" than that; rebasing is designed for a _private_ development model. git-rebase is a very handy tool for people like myself (people without a downstream that is) and it basically enables the quilt model of a stack of patches on top of git but public trees that have people pulling from them should generally not rebase or everyone who _is_ pulling finds a different tree each time. Linus is vehement about this also. There have a few threads about it and the most recent ...
May 21, 6:04 am 2008
Linus Torvalds
Re: [alsa-devel] HG -> GIT migration
Yes. However, that's not just a "my tree" issue. In fact, quite often other trees are more interesting from that angle: for driver subsystems like sound, the changes in Greg's driver core git tree may actually be oftne Yes. Doing throw-away merges is a great way to test not just whether there might be actual merge conflicts, but also to just test that things work together. And even if you want to concentrate your *development* on just ALSA-specific stuff, you may well want to ...
May 21, 11:39 am 2008
Takashi Iwai
Re: [alsa-devel] HG -> GIT migration
At Wed, 21 May 2008 09:16:05 -0700 (PDT), Well, what I meant is about the fixes to the subsystem (say, ALSA) by people in the outside. Not every ALSA-bugfix patch goes into the upstream from ALSA tree. You, Andrew and others pick individually ALSA-fix patches. They will be missing in the ALSA subsystem tree. And, what if that you need a fix for the fix that isn't in ALSA tree...? IMO, either a rebase or a merge is better than Hmm, that makes me thinking of the development model. We can ...
May 21, 9:51 am 2008
Linus Torvalds
Re: [alsa-devel] HG -> GIT migration
Btw, let me explain this another way. I do a *lot* of merges as being an "upstream" person. Since 2.6.25, I've done something like 247 merges (and that's not counting the fast-forward ones). If you do git log v2.6.25.. -author=torvalds you'll see pretty much just merges. It's simply what I do. I have a few fairly trivial patches every once in a while (although you almost have to add a "--no-merges" to filter out the merges to see them), but doing merges is what I do most. So ...
May 21, 11:11 am 2008
Linus Torvalds
Re: [alsa-devel] HG -> GIT migration
Cherry-picking can certainly cause merge errors, but not generally very often. Cherry-picking by definition will obviously apply the *same* patch to two different branches, and as a result, when you merge, that merge will generally be totally clean. So a trivial merge that succeeds without you even noticing is actually the common case. But you can certainly get merge failures where you then have to fix things up if there were *other* changes to that same area. At that point, you ...
May 21, 12:02 pm 2008
Takashi Iwai
Re: [alsa-devel] HG -> GIT migration
At Wed, 21 May 2008 10:43:43 -0700 (PDT), Don't get me wrong: I haven't suggested frequent rebases at all. This thread began actually because an update of the present alsa.git tree is required for applying my patches properly. [BACKGROUND: We are trying to make alsa.git tree with multiple committers. And, the current git-rebase doesn't care about sign-offs when a patch was committed by others. But, this is another topic...] However, I have to point that backport or backmerge is a rare ...
May 21, 11:47 am 2008
Takashi Iwai
Re: [alsa-devel] HG -> GIT migration
At Wed, 21 May 2008 15:04:53 +0200, Theoretically we can work only using merges. However, the resultant tree will look too complex with lots of merge points at the time of the next merge window. This is also a nightmare for bisecting. Thus, most subsystem trees do rebase before the merge window in practice, AFAIK. It'd be appreciated if someone can tell me any good workflow to keep a good-shaped tree without rebasing... Takashi --
May 21, 7:47 am 2008
Takashi Iwai
Re: [alsa-devel] HG -> GIT migration
At Wed, 21 May 2008 17:40:33 +0200, But, this means that the fixes done outside the subsystem tree cannot be in the subsystem tree itself until the next release. It's a pretty weird situation. Of course, we can do cherry-pick each fix in the upstream, but it doesn't work always, too. Suppose a fix that uses a newly introduced API after the merge window, which doesn't exist in the subsystem tree yet. Or, if you want add new patches during the merge window, etc. The method Linus ...
May 21, 9:02 am 2008
Rene Herman
Re: [alsa-devel] HG -> GIT migration
Let's ask... Fresh merges at each release boundary certainly but if it drops/remerges each subsystem when a bug in its for-next branch is found (a supposedly non rare occurence) all the hopefully hundreds or even thousands of linux-next pullers/testers would seem to have to deal with all those completely new merges everytime as well. I'd hope linux-next during a single release would just pull in the one fix (the subsystem's for-linus branch can still fold it in). Rene. --
May 21, 8:29 am 2008
Jaroslav Kysela
Re: [alsa-devel] HG -> GIT migration
I don't see big obstacles with this model. You can do changes in your local tree and when 'git pull' fails from the subsystem tree, pull new subsystem tree to a new branch and do rebasing in your local tree, too. Rebasing can keep the subsystem tree more clean I think. It's only about to settle an appropriate workflow. Jaroslav ----- Jaroslav Kysela <perex@perex.cz> Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc. --
May 21, 6:48 am 2008
vijay anand
[BUG] cdc-acm driver module
Hi All, This is vijay and new to this group. Normally I use to go through the Linux kernel source and try to understand how things work. Last week I was going through the cdc-acm driver source(linux-2.6.25). I think there is a bug with that driver and I am not sure about it. So I decided to post you guys and get your views on that. The interface is claimed in 'acm_probe' using 'usb_driver_claim_interface' and it has been released in 'acm_disconnect' using ...
May 21, 6:01 am 2008
Oliver Neukum
Re: [BUG] cdc-acm driver module
Even in this case disconnect() will be called. The only time it will not be called is if probe() was never called. But in that case no interface has been claimed. All is well. Regards Oliver --
May 21, 6:25 am 2008
Zdenek Kabelac
BUG: unable to handle kernel NULL pointer dereference
Hello This oops was generated while I've been playing with the vgchange -ay command. The previous warning were made by suspend WARNING: at drivers/base/power/main.c:77 device_pm_add+0x96/0x120() Thus I'm only pasting the oops itself - looks quite wierd: (my setup is 64bit T61 2GB - git commit: 8033c6e9736c29cce5f0d0abbca9a44dffb20c39 ) BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 IP: [__pollwait+78/272] __pollwait+0x4e/0x110 PGD 55634067 PUD 5c37e067 ...
May 21, 5:56 am 2008
Oliver Neukum
Re: [PATCH] USB: fix deadlock in HCD code
Are we sure the interrupt line is not shared with another driver that calls spin_unlock_irq() in its interrupt handler? Regards Oliver --
May 21, 1:03 pm 2008
Oliver Neukum
Re: [PATCH] USB: fix deadlock in HCD code
Which non-irq context is that? Regards Oliver --
May 21, 6:21 am 2008
Alan Stern
Re: [PATCH] USB: fix deadlock in HCD code
You could try testing the interrupt-enable flag at various places in ohci-hcd (start with finish_urb) and printing an error message if interrupts are enabled. One possibility is that in an earlier call to finish_urb, usb_hcd_giveback_urb was called with interrupts disabled and returned with interrupts enabled. In other words, some driver's callback routine may have enabled interrupts incorrectly. Alan Stern --
May 21, 7:46 am 2008
Jiri Kosina
Re: [PATCH] USB: fix deadlock in HCD code
You're right, this callchain can't cause the deadlock indeed. I'll go through the other possibilities. To give some background to others reading this thread -- Leonardo (in CC) reported [1] that this patch fixes hard kernel hangs he has been seeing when using USB CDMA modem. Still, we don't currently seem to see the place where the interrupts get enabled that makes the deadlock to trigger. [1] https://bugzilla.novell.com/show_bug.cgi?id=378509 -- Jiri Kosina SUSE Labs --
May 21, 6:36 am 2008
David Vrabel
Re: [PATCH] USB: fix deadlock in HCD code
This requirement is the only reason the whci-hcd driver disables interrupts. Removing this requirement would reduce the time that interrupts are disabled in the whci-hcd driver. David -- David Vrabel, Senior Software Engineer, Drivers CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562 Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/ --
May 21, 7:29 am 2008
David Vrabel
Re: [PATCH] USB: fix deadlock in HCD code
I can't see how urbs can be submitted to whci-hcd from an interrupt handler (urb callbacks are always called from a workqueue thread) but they could be submitted from a timer, so you are correct. David -- David Vrabel, Senior Software Engineer, Drivers CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562 Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/ --
May 21, 7:53 am 2008
Oliver Neukum
Re: [PATCH] USB: fix deadlock in HCD code
usb_hcd_flush_endpoint() is an obvious case. Used in the suspend code. Your patch is indeed correct, but I fear there might be a second bug caused by wrong calling conditions. Regards Oliver --
May 21, 6:47 am 2008
Jiri Kosina
Re: [PATCH] USB: fix deadlock in HCD code
One example -- assume usb_submit_urb() called from non-IRQ context. Then usb_hcd_submit_urb() -> rh_urb_enqueue() -> rh_queue_status() -> usb_hcd_link_urb_to_ep(). -- Jiri Kosina SUSE Labs --
May 21, 6:27 am 2008
Jiri Kosina
[PATCH] USB: fix deadlock in HCD code
hcd_urb_list_lock is used for synchronization between IRQ and non-IRQ contexts, so the non-IRQ context has to disable IRQs in order to prevent deadlocking with IRQ context. Signed-off-by: Jiri Kosina <jkosina@suse.cz> drivers/usb/core/hcd.c | 10 ++++++---- 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c index bf10e9c..19279ed 100644 --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c @@ -1000,8 +1000,9 @@ ...
May 21, 5:09 am 2008
Alan Stern
Re: [PATCH] USB: fix deadlock in HCD code
_Your_ callbacks are always called from a workqueue thread. Another driver's callbacks might not be, and that other driver might submit an Alan Stern --
May 21, 7:58 am 2008
Peter Zijlstra
Re: [PATCH] USB: fix deadlock in HCD code
Just wondering,... doesn't lockdep say anything about the situation? --
May 21, 3:26 pm 2008
Alan Stern
Re: [PATCH] USB: fix deadlock in HCD code
The functions you are worried about (usb_hcd_link_urb_to_ep and usb_hcd_unlink_urb_from_ep) are documented as requiring that interrupts be disabled by their callers. This patch isn't needed. (Of course, other patches may be needed to insure that the callers do It's not obvious to me. Where does usb_hcd_flush_endpoint() acquire The problem in the Novell bugzilla entry was caused by the fact that the OHCI irq routine was invoked with interrupts enabled, owing to a missing ...
May 21, 7:13 am 2008
Oliver Neukum
Re: [PATCH] USB: fix deadlock in HCD code
This turns out not to be the case. Interrupts are disabled. static int rh_queue_status (struct usb_hcd *hcd, struct urb *urb) { int retval; unsigned long flags; int len = 1 + (urb->dev->maxchild / 8); spin_lock_irqsave (&hcd_root_hub_lock, flags); if (hcd->status_urb || urb->transfer_buffer_length < len) { dev_dbg (hcd->self.controller, "not queuing rh status urb\n"); retval = -EINVAL; goto done; } retval = usb_hcd_link_urb_to_ep(hcd, urb); I'll ...
May 21, 6:32 am 2008
Oliver Neukum
Re: [PATCH] USB: fix deadlock in HCD code
Sorry, yes other code paths take it with enabled interrupts. The patch is good and necessary for 2.6.26. Regards Oliver --
May 21, 6:40 am 2008
Oliver Neukum
Re: [PATCH] USB: fix deadlock in HCD code
Sorry, yes looking again, it does complicated stuff with dropping the lock but leaving interrupts disabled. Sorry Oliver --
May 21, 7:31 am 2008
Alan Stern
Re: [PATCH] USB: fix deadlock in HCD code
That doesn't sound like a valid approach. If you don't disable interrupts then you aren't protected against an interrupt handler submitting an URB and accessing your data structures while whci-hcd is in the middle of updating them. Alan Stern --
May 21, 7:42 am 2008
Jiri Kosina
Re: [PATCH] USB: fix deadlock in HCD code
That indeed is 2.6.25 kernel. I guess you are talking about commit 442258e2ff69 here. If so, the reporter is definitely using the kernel containing this commit, and the lockups still trigger. Seems that my patch is papering over the real bug (someone enabling interrupts somewhere) indeed, but I can't seem to be able to find such codepath. Thanks, -- Jiri Kosina SUSE Labs --
May 21, 7:22 am 2008
Leonardo Chiquitto
Re: [PATCH] USB: fix deadlock in HCD code
Alan, I am trying your suggestion right now. Lets see if it finds something. Thanks, Leonardo --
May 21, 12:32 pm 2008
Robin Holt
Sony laptop battery has odd behavior with 2.6.26-rc3ish build.
A couple days ago, I updated my test build to commit 8033c6e9736c29cce5f0d0abbca9a44dffb20c39 and noticed an odd behavior with the battery. If I unplug the power, the battery discharges and that is reflected in /proc/acpi/battery/BAT0/state. I am not certain the discharge is continuous and uniform or if it goes in steps. When I plug the power back in, the level stays at a constant value (+-1mAh) for a considerable period of time. It then does a single step back to the fully charged ...
May 21, 4:57 am 2008
Alexey Starikovskiy
Re: Sony laptop battery has odd behavior with 2.6.26-rc3 ...
Could you please open bug report at bugzilla.kernel.org under ACPI/Battery and attach all the information to it? dmesg might be helpful too. Thanks, Alex. --
May 21, 5:08 am 2008
Glauber Costa
Re: 2.6.26: x86/kernel/pci_dma.c: gfp |= __GFP_NORETRY ?
probably andi has a better idea on why it was added, since it used to --
May 21, 5:49 am 2008
Miquel van Smoorenburg
2.6.26: x86/kernel/pci_dma.c: gfp |= __GFP_NORETRY ?
I've recently switched some of my boxes from a 32 to a 64 bit kernel. These are usenet server boxes that do a lot of I/O. They are running 2.6.24 / 2.6.25 Every 15 minutes a cronjob calls a management utility, tw_cli, to read the raid status of the 3ware disk arrays. That often fails with a segmentation violation .. tw_cli: page allocation failure. order:0, mode:0x10d0 Pid: 9296, comm: tw_cli Not tainted 2.6.25.4 #2 Call Trace: [<ffffffff802604b6>] __alloc_pages+0x336/0x390 ...
May 21, 4:30 am 2008
Wolfram Sang
Re: [PATCH] i2c: adds support for i2c bus on Freescale C ...
Hi Jochen, Works on MPC8260. path instead of patch? But well, I assume typos in this section do not All the best, Wolfram --=20 Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry
May 21, 7:33 am 2008
Jean Delvare May 21, 8:09 am 2008
Jochen Friedrich
[PATCH] i2c: adds support for i2c bus on Freescale CPM1/ ...
This driver uses the port of 2.4 code from Vitaly Bordug <vitb@kernel.crashing.org> and the actual algorithm used by the i2c driver of the DBox code on cvs.tuxboc.org from Felix Domke (tmbinc@gmx.net) and Gillem (htoa@gmx.net) converted to an of_platform_driver. Tested on CPM1 (MPC823 on dbox2 hardware) and CPM2 (MPC8272). Signed-off-by: Jochen Friedrich <jochen@scram.de> --- drivers/i2c/busses/Kconfig | 10 + drivers/i2c/busses/Makefile | 1 + drivers/i2c/busses/i2c-cpm.c | 745 ...
May 21, 3:43 am 2008
Matthew Garrett
Re: [PATCH] bay: Exit if notify handler cannot be installed
The bay driver still provides the only mechanism for calling the eject methods. -- Matthew Garrett | mjg59@srcf.ucam.org --
May 21, 3:59 am 2008
Holger Macht
Re: [PATCH] bay: Exit if notify handler cannot be installed
Yes, I'll send a patch on top of the libata hotplug fixes as soon as it's in for that. But this patch has nothing to do with this. Without it, you get an unusable system. Regards, Holger --
May 21, 4:06 am 2008
Holger Macht
[PATCH] bay: Exit if notify handler cannot be installed
If acpi_install_notify_handler() for a bay device fails, the bay driver is superfluous. Most likely, another driver (like libata) is already caring about this device anyway. Furthermore, register_hotplug_dock_device(acpi_handle) from the dock driver must not be called twice with the same handler. This would result in an endless loop consuming 100% of CPU. So clean up and exit. Signed-off-by: Holger Macht <hmacht@suse.de> --- diff --git a/drivers/acpi/bay.c b/drivers/acpi/bay.c index ...
May 21, 3:45 am 2008
Jochen Friedrich
[PATCH] [POWERPC] Add i2c pins to dts and board setup
Initialize I2C pins on boards with CPM1/CPM2 controllers. Signed-off-by: Jochen Friedrich <jochen@scram.de> --- Documentation/powerpc/booting-without-of.txt | 39 ++++++++++++++++++++++++++ arch/powerpc/boot/dts/mpc8272ads.dts | 11 +++++++ arch/powerpc/boot/dts/mpc866ads.dts | 11 +++++++ arch/powerpc/boot/dts/mpc885ads.dts | 11 +++++++ arch/powerpc/platforms/82xx/mpc8272_ads.c | 4 ++ arch/powerpc/platforms/8xx/mpc86xads_setup.c | 4 ++ ...
May 21, 3:31 am 2008
Jochen Friedrich
Re: [PATCH] [POWERPC] Add i2c pins to dts and board setup
There are still a bunch of i2c drivers using the old API (mainly v4l and dvb stuff) Sure. That's why the parameters are only optional. Once all i2c drivers are converted, these parameters won't be used anymore. Maybe they should be marked I was just confused by the fact that unlike a serial port, i2c is a bus itself. Thanks, Jochen --
May 21, 9:17 am 2008
Scott Wood
Re: [PATCH] [POWERPC] Add i2c pins to dts and board setup
s/nummer/number/ It'd be better to just convert any needed old-style drivers than add this clock-frequency is the standard name for such things. -Scott --
May 21, 8:10 am 2008
Uwe Kleine-König
[PATCH] fix comment for __printk_ratelimit
The comment assumed ratelimit_burst to be one and used an old name for ratelimit_jiffies. I also reintended the comment. Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com> --- kernel/printk.c | 5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/kernel/printk.c b/kernel/printk.c index 8fb01c3..f1c3c1c 100644 --- a/kernel/printk.c +++ b/kernel/printk.c @@ -1323,9 +1323,8 @@ void tty_write_message(struct tty_struct *tty, char *msg) /* * printk rate ...
May 21, 3:20 am 2008
Serge E. Hallyn
Re: [PATCH] capabilities: fix sys_prctl() returned unini ...
No, this case here means that the capability module is not taking responsibility for this call. So it should not be setting rc_p. So you'll want to find another path in kernel/sys.c:sys_prctl() where error doesn't get set. Do you know what 'i' was in prctl01 at the time of failure? For instance, I notice that PR_SET_DUMPABLE doesn't set the value of error if arg2 is valid. Also PR_SET_NAME and PR_GET_NAME don't set error. -serge --
May 21, 5:38 am 2008
Shi Weihua
[PATCH] capabilities: fix sys_prctl() returned uninitial ...
When we test kernel by the latest LTP(20080430) on ia64, the following failure occured: ------------------------------------- prctl01 1 PASS : Test Passed prctl01 0 WARN : prctl() returned 2048 errno = 0 : Success prctl01 1 PASS : Test Passed prctl01 2 FAIL : Test Failed ------------------------------------- We found commit 3898b1b4ebff8dcfbcf1807e0661585e06c9a91c causes this failure by git-bisect. And, we found *rc_p has not been initialized if switch-default ...
May 21, 2:37 am 2008
Alan Cox
Re: [PATCH] [mm] limit the min_free_kbytes
On Wed, 21 May 2008 17:34:41 +0800 You need to be root to set this value, and as root you could equally just type "halt", run a real time process in a tight loop or reformat the hard disk. NAK this patch --
May 21, 2:46 am 2008
Li Yang
[PATCH] [mm] limit the min_free_kbytes
From: Kong Wei <weikong@redflag-linux.com> Unlimited of min_free_kbytes is dangerous, An user of our company set this value bigger than 3584*1024*K, cause the system OOM on DMA. And I try a even more bigger number will cause the system hang immediately. Limited as 64M may not a good value, but as default in init_per_zone_pages_min. And this option may not need again? Signed-off-by: Kong Wei <weikong@redflag-linux.com> --- kernel/sysctl.c | 5 ++++- mm/page_alloc.c | 2 +- 2 files ...
May 21, 2:34 am 2008
Markus Armbruster
Re: [PATCH 0/5] xen pvfb: Para-virtual framebuffer, keyb ...
Yes, the console stuff works nicely for me, and the installer is happy. Note that I went with the stupidest solution that could possibly work there: have a global flag that gets set when the command line sets consoles, and don't mess with the console then. Mark McLoughlin suggested a somewhat less stupid way, namely to mark consoles selected on the command line with a flag. Critical review invited! --
May 21, 2:54 am 2008
Jeremy Fitzhardinge
Re: [PATCH 0/5] xen pvfb: Para-virtual framebuffer, keyb ...
Thanks Markus, This looks good. I'll stick it into my queue and feed it via Ingo when I've given it a bit of a test. Are we happy that the preferred console stuff is now the best solution? Does it solve your installer issues? J --
May 21, 2:09 am 2008
Markus Armbruster
[PATCH 5/5] xen pvfb: Dynamic mode support (screen resizing)
The pvfb backend indicates dynamic mode support by creating node feature_resize with a non-zero value in its xenstore directory. xen-fbfront sends a resize notification event on mode change. Fully backwards compatible both ways. Framebuffer size and initial resolution can be controlled through kernel parameter xen_fbfront.video. The backend enforces a separate size limit, which it advertises in node videoram in its xenstore directory. xen-kbdfront gets the maximum screen resolution from ...
May 21, 1:40 am 2008
Markus Armbruster
[PATCH 4/5] xen pvfb: Zero unused bytes in events sent t ...
This isn't a security flaw (the backend can see all our memory anyway). But it's the right thing to do all the same. Signed-off-by: Markus Armbruster <armbru@redhat.com> --- drivers/video/xen-fbfront.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c index 5553e51..291eef6 100644 --- a/drivers/video/xen-fbfront.c +++ b/drivers/video/xen-fbfront.c @@ -61,6 +61,7 @@ static void xenfb_do_update(struct ...
May 21, 1:40 am 2008
Markus Armbruster
[PATCH 3/5] xen pvfb: Module aliases to support module a ...
These are mostly for completeness and consistency with the other frontends, as PVFB is typically compiled in rather than a module. Derived from http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/5e294e29a43e While there, add module descriptions. Signed-off-by: Markus Armbruster <armbru@redhat.com> --- drivers/input/xen-kbdfront.c | 2 ++ drivers/video/xen-fbfront.c | 2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/input/xen-kbdfront.c ...
May 21, 1:40 am 2008
Markus Armbruster
[PATCH 2/5] xen pvfb: Pointer z-axis (mouse wheel) support
Add z-axis motion to pointer events. Backward compatible, because there's space for the z-axis in union xenkbd_in_event, and old backends zero it. Derived from http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/57dfe0098000 http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/1edfea26a2a9 http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/c3ff0b26f664 Signed-off-by: Pat Campbell <plc@novell.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> --- drivers/input/xen-kbdfront.c ...
May 21, 1:39 am 2008
Markus Armbruster
[PATCH 1/5] xen: Enable console tty by default in domU i ...
Without console= arguments on the kernel command line, the first console to register becomes enabled and the preferred console (the one behind /dev/console). This is normally tty (assuming CONFIG_VT_CONSOLE is enabled, which it commonly is). This is okay as long tty is a useful console. But unless we have the PV framebuffer, and it is enabled for this domain, tty0 in domU is merely a dummy. In that case, we want the preferred console to be the Xen console hvc0, and we want it without having ...
May 21, 1:38 am 2008
Karel Zak
[PATCH] MAINTAINERS: Add util-lilnux-ng package
Signed-off-by: Karel Zak <kzak@redhat.com> --- MAINTAINERS | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index b42dcfc..8779b53 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4361,6 +4361,14 @@ M: gregkh@suse.de L: linux-kernel@vger.kernel.org S: Maintained +UTIL-LINUX-NG PACKAGE +P: Karel ...
May 21, 1:18 am 2008
Andrew Morton
Re: [PATCH] VFS: Pagecache usage optimization on pagesiz ...
This is a bit presumptuous. A filesytem could in theory be able to work out if a section of a page is uptodate without necessarily maintaining per-page metadata at page.private. So one really should just do if (aops->is_partially_uptodate) however it's hard to conceive how a filesystem could sanely do this _without_ putting data at page.private, so the PagePrivate() test could perhaps be retained as a microoptimisation, as long as it is suitably commented. otoh, non-zero ...
May 21, 12:38 am 2008
Hisashi Hifumi
[PATCH] VFS: Pagecache usage optimization on pagesize != ...
Hi. When we read some part of a file through pagecache, if there is a pagecache of corresponding index but this page is not uptodate, read IO is issued and this page will be uptodate. I think this is good for pagesize == blocksize environment but there is room for improvement on pagesize != blocksize environment. Because in this case a page can have multiple buffers and even if a page is not uptodate, some buffers can be uptodate. So I suggest that when all buffers which correspond to a ...
May 20, 11:52 pm 2008
Andrew Morton
Re: [PATCH] VFS: Pagecache usage optimization on pagesiz ...
That's not a terribly good benchmark, IMO. It's too complex. To work out the best-case for a change like this I'd suggest a microbenchmark which does something such as seeking all around a file doing single-byte reads. Then one should think up a benchmark which demonstrates the worst-case, such as reading one-byte-quantities from a file at offsets 0, 0x2000, 0x4000, 0x6000, ... and then read more one-byte-quantities at offsets 0x1000, 0x3000, 0x5000, etc. That would be a pretty cruel ...
May 21, 12:19 am 2008
Yinghai Lu
[PATCH] x86: early dump pci conf space
so we can printout pci config before kernel touch it also fix write_pci_config_byte with offset and add write_pci_config_16 Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Index: linux-2.6/arch/x86/kernel/setup_64.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/setup_64.c +++ linux-2.6/arch/x86/kernel/setup_64.c @@ -350,6 +350,11 @@ void __init setup_arch(char **cmdline_p) parse_early_param(); +#ifdef CONFIG_PCI + if ...
May 21, 12:12 am 2008
Andrew Morton
Re: [RFC] [PATCH] To improve kretprobe scalability
On Wed, 21 May 2008 06:32:17 +0530 Are you sure that all the code which was previously globally serialised That's a large speedup. Do you have available the figures for the same workload when no probes An array of 64 spinlocks. These will all be crammed into two or four cachelines. If there is really any concurrency in here, the contention will be large. I suggest that you experiment with one-lock-per-cacheline here and see whether it is worth doing that permanently. Something ...
May 21, 4:32 pm 2008
Srinivasa D S
[RFC] [PATCH] To improve kretprobe scalability
Currently list of kretprobe instances are stored in kretprobe object (as used_instances,free_instances) and in kretprobe hash table. We have one global kretprobe lock to serialise the access to these lists. This causes only one kretprobe handler to execute at a time. Hence affects system performance, particularly on SMP systems and when return probe is set on lot of functions (like on all systemcalls). Solution proposed here gives fine-grain locks that performs better on SMP system ...
May 20, 6:02 pm 2008
Zhang Wei
RE: [PATCH] fsldma: fix incorrect exit path for initialization
____________________________________________________________ FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your desktop! Check it out at http://www.inbox.com/marineaquarium --
May 20, 11:35 pm 2008
Li Yang
[PATCH] fsldma: fix incorrect exit path for initialization
Signed-off-by: Li Yang <leoli@freescale.com> Cc: Zhang Wei <zw@zh-kernel.org> --- drivers/dma/fsldma.c | 31 ++++++++++++++++--------------- 1 files changed, 16 insertions(+), 15 deletions(-) diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c index 054eabf..724f6fd 100644 --- a/drivers/dma/fsldma.c +++ b/drivers/dma/fsldma.c @@ -809,8 +809,7 @@ static int fsl_dma_self_test(struct fsl_dma_chan *fsl_chan) if (!src) { dev_err(fsl_chan->dev, "selftest: Cannot alloc memory ...
May 20, 11:30 pm 2008
Christoph Hellwig
Re: [PATCH] Introduce down_nowait()
Actually, it does, and the kerneldoc comment explains it in every detail for those who need to read it up. Then again semaphores and on their way out, and I really hate the kind of churn this thing introduces at this moment. Please let all the semaphore to completion/mutex/other construct change settle for a while, and with a little chance this gem will just go away entirely. --
May 21, 1:04 am 2008
Rusty Russell
Re: [PATCH] Introduce down_nowait()
It is deeply annoying, even embarrassing, and trivial to fix. And as you say, process is glacial... Cheers, Rusty. --
May 21, 5:09 am 2008
Andrew Morton
Re: [PATCH] Introduce down_nowait()
Actually, I don't thing down_nowait() is a terribly good name, because it doesn't tell the reader anything about what to expect from the return value. Does a non-zero return mean that down_wait() acquired the lock, or does it not? Something like down_try() would be better, because if it returns 1 we can say "ah, the trying succeeded". otoh if all the kernel's "try" functions now return true on successful acquisition then there won't be any confusion any more so the name problably doesn't ...
May 20, 11:29 pm 2008
Daniel Walker
Re: [PATCH] Introduce down_nowait()
I must be missing something critical, but what's the logjam this is causing? Daniel --
May 21, 10:04 am 2008
Rusty Russell
[PATCH] Introduce down_nowait()
I planned on removing the much-disliked down_trylock() (with its backwards return codes) in 2.6.27, but it's creating something of a logjam with other patches in -mm and linux-next. Andrew suggested introducing "down_nowait" as a wrapper now, to make the transition easier. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Christoph Hellwig <hch@infradead.org> Cc: Matthew Wilcox <matthew@wil.cx> Cc: Stephen Rothwell ...
May 20, 11:00 pm 2008
Andrew Morton
Re: [PATCH] Introduce down_nowait()
No it doesn't. If anything, a "true" return from something called Shouldn't be necessary to look it up. By that argument we could Well, we can walk and chew gum at the same time. The number of down_trylocks in rc3 is 51 and the number of down_trylocks and down_nowaits in -mm is 47. So progress is pretty glacial. <wonders why -mm still has seven down_trlyocks> <oh> ./kernel/semaphore.c ./kernel/mutex.c ./include/linux/semaphore.h Anyway, yes, I agree that the whole effort is ...
May 21, 1:19 am 2008
Rusty Russell
Re: [PATCH] Introduce down_nowait()
What a great name! You're a genius! Subject: [PATCH] Introduce down_try() I planned on removing the much-disliked down_trylock() (with its backwards return codes) in 2.6.27, but it's creating something of a logjam with other patches in -mm and linux-next. Andrew suggested introducing "down_try" as a wrapper now, to make the transition easier. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Christoph Hellwig ...
May 21, 12:56 am 2008
Kamalesh Babulal
Re: [PATCH] linux-next: Tree for May 21 - build failure ...
>> net/netfilter/nf_conntrack_helper.c: In function
May 21, 6:29 am 2008
Kamalesh Babulal
[PATCH] linux-next: Tree for May 21 - build failure with ...
Hi Stephen, The next-20080521 kernel build fails, on x86_64 machine CC net/netfilter/nf_conntrack_helper.o net/netfilter/nf_conntrack_helper.c: In function ‘__nf_ct_helper_find’: net/netfilter/nf_conntrack_helper.c:58: error: implicit declaration of function ‘hlist_for_each_entry_rcu’ net/netfilter/nf_conntrack_helper.c:58: error: ‘hnode’ undeclared (first use in this function) net/netfilter/nf_conntrack_helper.c:58: error: (Each undeclared identifier is reported only ...
May 21, 4:32 am 2008
Stephen Rothwell
Re: [PATCH] linux-next: Tree for May 21 - build failure ...
Hi Kamalesh, On Wed, 21 May 2008 17:02:30 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ib= Thanks for the report and patch. This looks like it is probably broken in Linus' kernel. What config did you use to get the error? --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
May 21, 5:52 am 2008
Stephen Rothwell
linux-next: Tree for May 21
Hi all, Changes since next-20080520: New trees: input-current, rcu, locking, safe-poison-pointers, stackprotector and input. Three patches have been reverted in the driver-core tree as they have been merged into the pci tree (I expect that they will not be in the driver-core tree tomorrow). The driver-core build error went away. The sound tree required two patches for build problems. The semaphore-removal tree still needed three patches reverted because simi= lar patches were ...
May 20, 10:59 pm 2008
David Miller
Re: CFD: linux-wanking@vger.kernel.org
From: Andrew Morton <akpm@linux-foundation.org> Al may not have expressed himself the most pleasant way, but I do agree on some fundamental level with him. There is way to much useless crap being discussed on this list, and this is a list where the signal level is of an utmost importance for the lists usability. After deleting all of the noise posted here, I'm often too burnt out to do real work with what's left and just delete that too. :-/ It's worse than the postmaster and list owner ...
May 21, 2:19 am 2008
Jonathan Corbet
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
In theory, that's Documentation/HOWTO. In practice, quite a bit more is needed. I'm actually in the process of writing such a thing as well, with some support from the Linux Foundation. I'll not have it done in an hour or two, though; a version for review in June is more likely... jon --
May 21, 1:27 pm 2008
Jesper Juhl
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
What I'm doing right now is basically reformatting my own notes, emails I've written on the subject, pieces of other documents I've written etc etc and trying to put them in the shape of a Getting Started document. Perhaps getting that compiled into a reasonable document in a few hours is a bit too optimistic, but I'll give it a go, post what I have for review and we can take it from there. :-) I'd love to read your document once it's ready for review. -- Jesper Juhl ...
May 21, 1:37 pm 2008
Al Viro
CFD: linux-wanking@vger.kernel.org (was [PATCH] Standard ...
This is a call for discussion for new maillist on vger. List name: linux-wanking@vger.kernel.org Rationale: the need for such list has been demonstrated during the last few months by rapid increase in the amount of traffic topical for such list (and completely unrelated to any kind of kernel development) misposted on linux-kernel. A separate list dedicated to this kind of self-gratification would hopefully * reduce the gag reflex among the l-k readers * provide a forum where such activity ...
May 21, 1:34 am 2008
Andrew Morton
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
On Wed, 21 May 2008 23:08:29 +0200 Well you should. One person makes a mistake and gets horridly treated in public and this will make others fear the consequences of any mistake they might make. This could have been handled better, don't you think? --
May 21, 2:12 pm 2008
David Miller
Re: CFD: linux-wanking@vger.kernel.org
From: Andrew Morton <akpm@linux-foundation.org> You can't have your cake and eat it too Andrew. It's only a half-story to talk about future contributors when current trends on this list are making things bad for existing folks doing useful work. You make it sound like it's this one sided story where we have to be all nicey nicey to everybody so that new contributors aren't discouraged, and that's where it ends. But we're currently encouraging a society of bottom feeders. And bottom ...
May 21, 12:49 pm 2008
Stefan Richter
Re: CFD: linux-wanking@vger.kernel.org
People fix bugs when they realize that nobody else is going to do it for them. -- Stefan Richter -=====-==--- -=-= =-=-= http://arcgraph.de/sr/ --
May 21, 2:44 pm 2008
Christoph Hellwig
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
But I'd like to second the opinion. This is getting a little too far. We should rather try to at least enforce very basic standards a lot of the crap shoved in doesn't follow instead of wanking around about exact placement of whitespaces. --
May 21, 3:32 am 2008
Andrew Morton
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
Oh, what a marvellous way to encourage new contributors that was. Thank you so much. For the record: Al speaks only for himself and a lack of expressed disagrement from others should not be taken as agreement. Sheesh. --
May 21, 1:50 am 2008
Andrew Morton
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
On Wed, 21 May 2008 23:45:22 +0400 Yes, a general GettingStarted document would probably be useful. It would hopefully have more what-to-do content than what-not-to-do. --
May 21, 12:54 pm 2008
Jiri Slaby
Re: [PATCH] Standard indentation of arguments
I think, there is no "standard" on this. I personally do prefer indentation by tabs. --
May 21, 12:19 am 2008
Johannes Weiner
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
Hi, How about the following? --- From: Johannes Weiner <hannes@saeurebad.de> Subject: [PATCH] CodingStyle: no more trivial coding style fixes, please Add a note to CodingStyle that style cleanups should only be done if the code is really offending and violating the kernel conventions heavily. But no more oneliners fixing indentation and the like. Signed-off-by: Johannes Weiner <hannes@saeurebad.de> --- Documentation/CodingStyle | 12 ++++++++++++ 1 file changed, 12 ...
May 21, 12:42 pm 2008
Andrew Morton
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
Guys, get a clue. It doesn't matter what that person did. It is the effect upon *all* other potential developers which is so damaging here. Not upon this individual. --
May 21, 10:46 am 2008
Rene Herman
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
Do note that in the above I did not suggest that the problem isn't real. I'm just suggesting that it's not the _kernel's_ problem. The openness adds significant value to the kernel. I'd say more value then would be brought in by developers who now shy away from the process. And yes, it's general openness. Noone is being ripped apart when they The actual case in point was a little odd though. I do not for a minute believe that any serious developer is going to shy away from submitting ...
May 21, 2:08 pm 2008
Adrian Bunk
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
We are drowning in new code, and our biggest problem is to get it properly integrated. We don't have any shortage in the sheer number of people, and it doesn't seem we'll ever have. And we have many newbies who come and find themselves areas for useful cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. ...
May 21, 4:55 pm 2008
Theodore Tso
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
The real question is whether people who are wanking about whitespace and spelling fixes in comments will graduate to writing real, useful patches. If they won't, there's no point to encouraging them. - Ted --
May 21, 5:09 am 2008
David Miller
Re: CFD: linux-wanking@vger.kernel.org
From: Andrew Morton <akpm@linux-foundation.org> Indeed. A lot of the time I see new people, or people making suggestions to them, so fixated on wanting to implement new features. To me that is absolutely the wrong way to go about this. It's so much more useful, for both the community and the individual, to fix bugs. Fixing a bug forces you to learn how the kernel works at least on some level, and fixing a bug always makes Linux better. Implementing a new feature does not necessarily ...
May 21, 1:10 pm 2008
Rene Herman
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
Yes. Their company's problem. I must say I'm getting rather sick of this hiding behind culture. Does anyone think it's good for _anyone_ from any culture to be publicly called upon their mistakes? Public is simply what this development is and what makes it different from other types. People who can't deal with it either grow up, go away or better still, try their damndest to minimise mistakes to avoid the experience in the first place. That last one in fact is one of the fundamental ...
May 21, 1:38 pm 2008
Adrian Bunk
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
Let's look at it from another angle: We should not aim at being good at this. What do we need more in the kernel: - people testing development kernels - people fixing bugs - people maintaining code - people reviewing code What do we already have more than enough: - people developing new bugs^Wfeatures If someone wants to do a project that's OK. And if some kernel developer wants to assist him that's OK. But in my opinion stuff like "I need a project for university" requests are ...
May 21, 4:01 pm 2008
Andrew Morton
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
On Wed, 21 May 2008 22:57:25 +0400 There are a lot of people out there who would like to try their hands at kernel.org development but who just aren't sure how to start, nor where to start. One could understand a developer deciding to write a do-nothing whitespace patch as a general throat-clearing exercise, but when asked, I recommend against that. I generally recommend that people just download and test the latest -rc, linux-next and -mm kernels and build and run them. Because they ...
May 21, 12:31 pm 2008
David Newall
Re: [PATCH] Standard indentation of arguments
So do I, but that pales compared to how annoying I find patches that can best be described as anal-retentive. Let the person who writes the code decide how to lay it out. --
May 21, 4:35 am 2008
Al Viro
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
*blink* OK, I give up; how was it supposed to be parsed? I can't come up with any way of reading that sentence that would not be an obvious glaring idiocy and I don't see any obvious typos or word omissions that could have created that. Surely you are not saying that we are not really looking for more people doing useful work? And doing that without "getting involved"... could any resident Zen master enlighten me? I seem to be unable to figure out how the hell one could pull off such a ...
May 21, 4:35 pm 2008
Jesper Juhl May 21, 4:46 pm 2008
Cyrill Gorcunov
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
[Andrew Morton - Wed, May 21, 2008 at 10:46:44AM -0700] | On Wed, 21 May 2008 08:09:39 -0400 Theodore Tso <tytso@mit.edu> wrote: | | > On Wed, May 21, 2008 at 06:32:06AM -0400, Christoph Hellwig wrote: | > > On Wed, May 21, 2008 at 01:50:37AM -0700, Andrew Morton wrote: | > > > Oh, what a marvellous way to encourage new contributors that was. Thank | > > > you so much. | > > > | > > > For the record: Al speaks only for himself and a lack of expressed | > > > disagrement from others should not ...
May 21, 11:57 am 2008
Rene Herman
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
I myself tend be rather apprehensive about making an ass of myself in public as well but the only thing I'm taking away from this particular thread is that not everyone is going to appreciate argument alignment patches. So I'll not submit those. Maybe I'll go to work on rewriting I'm not sure. Triggered myself into this thread mostly due to recent pussy-footing around another culturally biased developer in a thread I was in and the most definite impression I got there was that if it had ...
May 21, 2:32 pm 2008
Andrew Morton
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
On Wed, 21 May 2008 22:38:04 +0200 Sigh. There are kernel contributions which have not been submitted partly because their developers are apprehensive about the way in which they will be treated. This is not theory. It is not a guess. It is not speculation. It is empirical observation. We have a bad reputation. I think it is largely undeserved nowadays, because things have got a lot better. But once a reputation has stuck, it is hard to get it unstuck. When I am on the podium ...
May 21, 1:50 pm 2008
Randy Dunlap
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
I did a talk on Linux "social engineering" at {OSCON, IEEE NW something, and SCALE}. All about what (not) to do, how to do it, etc. Slides for it are available in http://www.xenotime.net/linux/mentor/ . --- ~Randy --
May 21, 12:33 pm 2008
Cyrill Gorcunov
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
[Randy Dunlap - Wed, May 21, 2008 at 12:33:55PM -0700] | On Wed, 21 May 2008 22:57:25 +0400 Cyrill Gorcunov wrote: | | > [Andrew Morton - Wed, May 21, 2008 at 10:46:44AM -0700] | > | On Wed, 21 May 2008 08:09:39 -0400 Theodore Tso <tytso@mit.edu> wrote: | > | | > | > On Wed, May 21, 2008 at 06:32:06AM -0400, Christoph Hellwig wrote: | > | > > On Wed, May 21, 2008 at 01:50:37AM -0700, Andrew Morton wrote: | > | > > > Oh, what a marvellous way to encourage new contributors that was. Thank | > | ...
May 21, 12:45 pm 2008
Jesper Juhl
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
I'm in the process of trying to write an initial draft of just such a document right now. I'll post it once I'm a bit more done (gimme an hour or two). -- Jesper Juhl <jesper.juhl@gmail.com> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html --
May 21, 1:06 pm 2008
Rene Herman
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
There is the question of exactly how long you'd like this project to survive though (in a vibrant form). Remarked elsewhere recently that a downside of the new development model seems to be missing opportunity for new editions of books with "all new! covers 2.8!" blurps on the cover. That is, not seeing quality documentation emerge, not seeing mentoring from experienced developers... -- where and how do you want the new developers to come from? If only from business linux as a ...
May 21, 4:17 pm 2008
Al Viro
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
Of course I speak for myself. And I am absolutely open about my belief that such _contribution_s_ need to be discouraged. Actively. Hell, a month ago I mentioned right-justifying text in comments as "we'll never reach _that_" kind of pointless idiocy. And there we are, much closer to that than I ever expected. I have nothing against contributors. I *DO* have a lot against a very specific class of contributions. Exactly because they actively prevent people from moving on to saner stuff. ...
May 21, 2:41 am 2008
Theodore Tso
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
It probably did make things marginally worse from that standpoint, but the code style weanies also make things worse, so at least IMHO it's a wash. I'd suggest that the more aggressive public code reviews and the perception that it is highly painful, time-consuming, and expensive to get code merged up. But of course we need that to maintain quality. Even if we eliminated all code style weanies slapdowns, if a Asian Engineer submits a patchset, and it gets (rightly) ripped to pieces ...
May 21, 12:45 pm 2008
Willy Tarreau
Re: CFD: linux-wanking@vger.kernel.org
I think that they are often young and want to get their name associated Not that much for newbies. Linux is thought^Wknown to be bug-free. People don't get a name by claiming everywhere "hey, I found bug X which I could trigger by doing stupid thing Y, and I could fix it, I've contributed". On the opposite, they have the ability to say "hey friends, now you can buy webcam XX, I have implemented support for it" (often meaning "I send a PCI ID update"). This is a lot more rewarding for ...
May 21, 2:25 pm 2008
Willy Tarreau
Re: CFD: linux-wanking@vger.kernel.org
That's partly true. But we don't need people to fix all bugs by themselves, otherwise we might take more time trying to fix their own fixes. We most of all need them to *work* on bugs, which is not the same. Actively participating to tests and bug hunting is a very important activity. Let's get the original code author propose a fix once the bug is pointed to. Willy --
May 21, 2:56 pm 2008
Al Viro
Re: CFD: linux-wanking@vger.kernel.org
Sigh... <mode=Andrew> Let me make it clear that Davem is not speaking for me </mode>. It's NOT about personalities of people submitting patches. I don't know them and I absolutely do not believe that either personality per se or expected future behaviour can be derived from the fact of having sent this kind of junk. So "bottom-feeders" is IMO uncalled for - it presumes far more personal and permanent features that simply are not in evidence. Moreover, I'm less concerned about ...
May 21, 3:03 pm 2008
Jianjun Kong
[PATCH] Standard indentation of arguments
Standard indentation of arguments. I use right blank space to displace the last table, in order to make the arguments alining. For example: old: extern void test_fun(struct list_head *new, struct list_head *prev, struct list_head *next); new: extern void test_fun(struct list_head *new, struct list_head *prev, struct list_head *next); Signed-off-by: Jianjun Kong <kongjianjun@gmail.com> --- include/linux/list.h | 27 ++++++++++++++------------- 1 files changed, 14 ...
May 20, 10:58 pm 2008
Andrew Morton
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
There are good ways in which to communicate that and there are bad ways. Look. This has absolutely nothing to do with that patch. Don't care, doesn't matter, irrelevant, not even going to discuss it in this context. I have spoken with engineers both individual and within companies who have developed and who plan to develop substantial kernel features. I'm forever explaining to people why they should work to get that code merged up. One reason for their not yet having done so which comes ...
May 21, 10:44 am 2008
Valdis.Kletnieks
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
Some of us never manage to escape from that level. I dug around, and I've been playing the "What did -mm break on me *this* time?" since 2.5.55-mm1. :)
May 21, 2:08 pm 2008
Cyrill Gorcunov
Re: CFD: linux-wanking@vger.kernel.org (was [PATCH] Stan ...
[Johannes Weiner - Wed, May 21, 2008 at 09:42:32PM +0200] | Hi, | | Cyrill Gorcunov <gorcunov@gmail.com> writes: | | > [Andrew Morton - Wed, May 21, 2008 at 10:46:44AM -0700] | > | On Wed, 21 May 2008 08:09:39 -0400 Theodore Tso <tytso@mit.edu> wrote: | > | | > | > On Wed, May 21, 2008 at 06:32:06AM -0400, Christoph Hellwig wrote: | > | > > On Wed, May 21, 2008 at 01:50:37AM -0700, Andrew Morton wrote: | > | > > > Oh, what a marvellous way to encourage new contributors that was. Thank | > ...
May 21, 12:47 pm 2008
Steven Rostedt
2.6.24.7-rt9
We are pleased to announce the 2.6.24.7-rt9 tree, which can be downloaded from the location: http://rt.et.redhat.com/download/ Information on the RT patch can be found at: http://rt.wiki.kernel.org/index.php/Main_Page Changes since 2.6.24.7-rt8 - RT downgrade_write (Steven Rostedt) - fix RT rwlocks typecasts (Steven Rostedt) - default sched_nr_migrate to 8 (Steven Rostedt) - ftrace task comm fix (Steven Rostedt) - ARM compile fix (Remy Bohmer) to build a ...
May 20, 9:32 pm 2008
Justin Mattock
completely lost as to what to do, or where to look.
Hello; I'm lost as to where to look in the kernel, as to why I'm receiving a black screen with startx DRI seems to be fine, I'm noticing a sema_init but am not sure if this is the cause of the blackness. any direction as to where I might look would be helpful. regards; -- Justin P. Mattock --
May 20, 9:10 pm 2008
Lee Revell
Re: completely lost as to what to do, or where to look.
Yes, the whole problem was that he was trying to use an incompatible kernel with the closed source ATI driver. Lee --
May 21, 1:31 pm 2008
Andrew Morton
Re: completely lost as to what to do, or where to look.
Kernel version? A git-bisect should get you down the the offending commit within an hour or three. http://www.kernel.org/doc/local/git-quick.html has some instructions. But if you're on 2.6.26-rcX, be sure to use the very latest - a pile of bad DRI code got reverted recently. This morning, I think. --
May 20, 10:34 pm 2008
Justin Mattock
Re: completely lost as to what to do, or where to look.
On Wed, May 21, 2008 at 5:34 AM, Andrew Morton Thanks for the help, From what I can remember I noticed this around 2.6.26-rc1. It could be an issue with DRI, but then again it could be something else. With running some more tests I'm noticing a conflict with libdri.so, not recognizing the module or the module not recognizing libdri.so. As for the latest git I'll have to pull, and see if it makes a difference. If not then I'll have to sit and keep working this problem until I can figure what ...
May 20, 11:51 pm 2008
Justin Mattock
Re: completely lost as to what to do, or where to look.
Just so I can have suspend working properly, now the next question is seeing if radeohd can wakeup from suspend That way I don't have to be confined to using one module But for the time being I need a nice cold beer from this headache.. : - ) regards; -- Justin P. Mattock --
May 21, 1:40 pm 2008
Ray Lee
Re: completely lost as to what to do, or where to look.
First, you really need to try the latest kernel from the git repository (or latest nightly snapshot). The DRI 'mechanisms' you're asking about were broken in 2.6.26-rc1. They got fixed very, very recently (past 24 hours). So if you haven't tried the latest kernel from -git yet, then, respectfully, you're not going to get very far. Please try the latest kernel first, and then let us know what happens -- given your description there's a good chance the problem is already fixed. Also, please ...
May 21, 7:48 am 2008
Justin Mattock
Re: completely lost as to what to do, or where to look.
O.K. I've got my 8-balls back, from what I could tell there was three areas that needed attention to: 1) add nopage back into the kernel 2) The DRI needed to be reverted back to it's original state, or modified due to some issue. 3) find_task_by_pid( pid) on the module side needed to be changed to find_task_by_vpid( pid) or else you'll have an issue with init_pid_ns I did have the latest DRI updates yesterday, but should have been using nopage to build the module instead of fault. so three ...
May 21, 1:03 pm 2008
Oliver Pinter
Re: completely lost as to what to do, or where to look.
you use ati or nvidia binary driver? -- Thanks, Oliver --
May 21, 7:51 am 2008
Justin Mattock
Re: completely lost as to what to do, or where to look.
Alright: I'm using 2.6.26-rc3-00122-g748bf99, I pulled if I can remember Monday night and I did notice drmP.h and the rest of the drm files, but, will try and pull again to see if it makes a difference. As for the question about what video card nvidia or ati, I'm stuck with ati, went into apple yesterday to see if that would be easy to change out, but unfortunately I would have to get a new laptop. To bad apple didn't use an intel graphics card, that linux already has a module for. As for ...
May 21, 10:04 am 2008
Ray Lee
Re: completely lost as to what to do, or where to look.
Well, I for one am still confused. Is there an issue with the latest kernel.org kernel and Xorg opensource drivers that need to be addressed? In other words, are other people going to hit the problem you had? If so, a patch, or more technical description of what's going on would benefit others that would otherwise have to do everything you just did. Or are you using the closed-source nvidia drivers? (No judgement from me if you are, but it would really help clear up what the heck is going ...
May 21, 1:09 pm 2008
Adrian Bunk
Re: completely lost as to what to do, or where to look.
Which X video driver are you using? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed --
May 21, 12:59 am 2008
Justin Mattock
Re: completely lost as to what to do, or where to look.
Hello; thanks for the feedback, from previous posts, you know what module I'm talking about, So with that in mind I'm going to go to the next question: From error messages "there isn't" the only leeway or light at the end of the tunnel I see is with libdri.so i.g. If I boot the system up with out messing with anything I will receive a black screen after issueing startx, (from looking at what I see, the screen will flash one time then black, it should flash or blink two times before giving me ...
May 21, 7:33 am 2008
XiongJia Le
How to filter the Block I/O in 2.6 kernel?
How to filter the Block I/O in 2.6 kernel? I have looked some in blktrace. blktrace can trace the block device I/O info. But that can't filter/change this I/O. Is the Linux kernel have any way to filter/change a block i/o before it write to hard disk? I don't want to change kernel code and re-build. Is Kernel already have any I/O filter interface? Thanks, Xiongjia Le --
May 20, 9:05 pm 2008
David Miller
Re: pull request: wireless-2.6 2008-05-20
From: "John W. Linville" <linville@tuxdriver.com> Pulled and pushed back out to net-2.6, thanks John! --
May 20, 8:41 pm 2008
John W. Linville
pull request: wireless-2.6 2008-05-20
Dave, Another round of fixes intended for 2.6.26...one of these ("ath5k: Fix loop variable initializations") is already queued in net-next-2.6, but it fixes the following bugzilla: http://bugzilla.kernel.org/show_bug.cgi?id=10605 Also included is "mac80211: fix NULL pointer dereference in ieee80211_compatible_rates", which fixes another bugzilla: http://bugzilla.kernel.org/show_bug.cgi?id=10755 Let me know if there are problems! Thanks, John --- Individual patches are ...
May 20, 7:57 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 17/39] aufs policies to sele ...
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit when creating/removing an entry and there are multiple writable branches specified in aufs, aufs has to decide which branch is the target. aufs has several policies for that such as, round-robin, most-free-space and so on. Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/wbr_policy.c | 685 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 685 insertions(+), 0 deletions(-) create mode 100644 ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 03/39] aufs configuration an ...
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit aufs configuration and Makefile Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/Kconfig | 174 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/Makefile | 39 ++++++++++++ 2 files changed, 213 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/Kconfig create mode 100644 fs/aufs/Makefile diff --git a/fs/aufs/Kconfig b/fs/aufs/Kconfig new file mode 100644 index ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 38/39] aufs global header file
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit aufs global header file Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- include/linux/aufs_type.h | 111 +++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 111 insertions(+), 0 deletions(-) create mode 100644 include/linux/aufs_type.h diff --git a/include/linux/aufs_type.h b/include/linux/aufs_type.h new file mode 100644 index 0000000..f69fb16 --- /dev/null +++ b/include/linux/aufs_type.h @@ -0,0 ...
May 20, 8:23 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 16/39] aufs pseudo-link
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit pseudo-link is a logical hardlink over branches or different filesystems. Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/plink.c | 344 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 344 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/plink.c diff --git a/fs/aufs/plink.c b/fs/aufs/plink.c new file mode 100644 index 0000000..7197d7c --- /dev/null +++ ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 29/39] aufs lower inode and ...
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit handles inodes on lower/branch filesystem, including internal inotify-watch Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/hinode.h | 184 +++++++++ fs/aufs/hinotify.c | 1059 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 1243 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/hinode.h create mode 100644 fs/aufs/hinotify.c diff --git a/fs/aufs/hinode.h ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 18/39] aufs dentry (main lookup)
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit dentry operations main lookup operation Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/dentry.c | 959 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 959 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/dentry.c diff --git a/fs/aufs/dentry.c b/fs/aufs/dentry.c new file mode 100644 index 0000000..1e16848 --- /dev/null +++ b/fs/aufs/dentry.c @@ -0,0 +1,959 @@ +/* + * ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 00/39] AUFS: merging/stackin ...
From: Junjiro Okajima <hooanon05@yahoo.co.jp> I have posted some of ideas, design or approaches which are implemented in AUFS stackable filesystem about a month before. While I have a plan to implement some more features still, the current AUFS status is better and used many people for years. Since I have received requests to submit AUFS into the mainline more than once, Now I'd ask you to include AUFS into mainline. After last posts last week, I received several review comments and ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 08/39] aufs branch filesyste ...
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit br_fuse.c special handling for inode attributes on FUSE branch br_nfs.c lookup functions for NFS branch br_xfs.c special handling inode attributes on XFS branch Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/br_fuse.c | 107 ++++++++++++++++ fs/aufs/br_nfs.c | 347 +++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/br_xfs.c | 67 ++++++++++ 3 files changed, 521 insertions(+), 0 deletions(-) ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 01/39] aufs documents
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit aufs documents Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- Documentation/filesystems/aufs/Design | 311 +++++++++++++++++++++++++++++++++ Documentation/filesystems/aufs/README | 152 ++++++++++++++++ 2 files changed, 463 insertions(+), 0 deletions(-) create mode 100644 Documentation/filesystems/aufs/Design create mode 100644 Documentation/filesystems/aufs/README diff --git ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 09/39] aufs object lifetime ...
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit some aufs objects have a corresponding entry under sysfs, so the lifetime will be managed by struct kref even if CONFIG_SYSFS is disabled. This file is compiled unconditionally. Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/sysaufs.c | 102 +++++++++++++++++++++++++++++++++++++++ fs/aufs/sysaufs.h | 137 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 239 insertions(+), 0 ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 07/39] aufs xino
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit external inode number translation table and bitmap Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/xino.c | 1212 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 1212 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/xino.c diff --git a/fs/aufs/xino.c b/fs/aufs/xino.c new file mode 100644 index 0000000..eb5bdff --- /dev/null +++ b/fs/aufs/xino.c @@ -0,0 +1,1212 @@ +/* + ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 39/39] merge aufs
From: Junjiro Okajima <hooanon05@yahoo.co.jp> - incorporate fs/aufs - export __lookup_hash() - make lockdep deeper for debugging locks in a stackble fs Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/Kconfig | 2 ++ fs/Makefile | 1 + fs/namei.c | 2 +- include/linux/lockdep.h | 4 ++++ include/linux/namei.h | 1 + 5 files changed, 9 insertions(+), 1 deletions(-) diff --git a/fs/Kconfig b/fs/Kconfig index ...
May 20, 8:23 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 14/39] aufs copy-up
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit internal copy-up functions see wbr_policy.c for copy-down Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/cpup.c | 1021 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/cpup.h | 80 +++++ 2 files changed, 1101 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/cpup.c create mode 100644 fs/aufs/cpup.h diff --git a/fs/aufs/cpup.c b/fs/aufs/cpup.c new file mode 100644 index ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 36/39] aufs debug print and ...
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit debug print functions and magic sysrq handler Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/debug.c | 466 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/debug.h | 208 +++++++++++++++++++++++++ fs/aufs/sysrq.c | 101 ++++++++++++ 3 files changed, 775 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/debug.c create mode 100644 fs/aufs/debug.h create mode 100644 ...
May 20, 8:23 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 37/39] aufs mount/umount helpers
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit they will be written all in C in the future. mount.aufs mount helper script auplink pseudo-link helper script aulchown.c pseudo-link helper for symlink umount.aufs umount helper script Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- Documentation/filesystems/aufs/aulchown.c | 28 ++++ Documentation/filesystems/aufs/auplink | 168 +++++++++++++++++++++++ Documentation/filesystems/aufs/mount.aufs | 203 ...
May 20, 8:23 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 11/39] aufs workqueue
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit workqueue for asynchronous, super-io or delegated operations. they are used in various places such as, - handling 'opaque' directory and whiteout - lookup and copy-up/down with credential - create/remove files and file i/o by delegation - internal xino file i/o Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/wkq.c | 294 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/wkq.h | 158 ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 19/39] aufs dentry (except lookup)
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit dentry operations and private data Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/dentry.h | 381 ++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/dinfo.c | 409 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 790 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/dentry.h create mode 100644 fs/aufs/dinfo.c diff --git a/fs/aufs/dentry.h b/fs/aufs/dentry.h new ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 10/39] aufs mount options/flags
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit handling mount options/flags Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/opts.c | 1492 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/opts.h | 243 +++++++++ 2 files changed, 1735 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/opts.c create mode 100644 fs/aufs/opts.h diff --git a/fs/aufs/opts.c b/fs/aufs/opts.c new file mode 100644 index 0000000..ca897a8 --- ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 33/39] aufs robr-mode
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit aufs as a readonly branch of another aufs Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/robr.c | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 109 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/robr.c diff --git a/fs/aufs/robr.c b/fs/aufs/robr.c new file mode 100644 index 0000000..64ec128 --- /dev/null +++ b/fs/aufs/robr.c @@ -0,0 +1,109 @@ +/* + * ...
May 20, 8:23 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 28/39] aufs inode other operations
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit inode other operations (permission/lookup/setattr/readlink/follow_link/put_link) Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/i_op.c | 728 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 728 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/i_op.c diff --git a/fs/aufs/i_op.c b/fs/aufs/i_op.c new file mode 100644 index 0000000..deb25d8 --- /dev/null +++ ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 31/39] aufs lower inode and ...
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit common functions to internal inotify and delegate-mode Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/hin_or_dlgt.c | 705 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 705 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/hin_or_dlgt.c diff --git a/fs/aufs/hin_or_dlgt.c b/fs/aufs/hin_or_dlgt.c new file mode 100644 index 0000000..362d66d --- /dev/null +++ ...
May 20, 8:23 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 12/39] aufs sub-VFS
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit sub-routines or simple wrappers for VFS Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/vfsub.c | 633 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/vfsub.h | 472 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 1105 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/vfsub.c create mode 100644 fs/aufs/vfsub.h diff --git a/fs/aufs/vfsub.c b/fs/aufs/vfsub.c new file mode ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 30/39] aufs delegate mode
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit 'delegate' is a special mode for people who don't want their application to access branches through aufs or to be traced strictly by task I/O accounting. Also it will be helpful for LSM users, because the internal access from aufs to branches may be detected, reported or prohibited by LSM. in 'delegate' mode, aufs passes the internal access to the aufs kernel thread. Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- ...
May 20, 8:23 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 06/39] aufs branch directory ...
From: Junjiro Okajima <hooanon05@yahoo.co.jp> branch management Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/branch.c | 912 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/branch.h | 352 +++++++++++++++++++++ 2 files changed, 1264 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/branch.c create mode 100644 fs/aufs/branch.h diff --git a/fs/aufs/branch.c b/fs/aufs/branch.c new file mode 100644 index 0000000..88b6258 --- /dev/null +++ ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 15/39] aufs whiteout
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit whiteout for logical deletion and opaque directory Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/whout.c | 1026 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/whout.h | 138 ++++++++ 2 files changed, 1164 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/whout.c create mode 100644 fs/aufs/whout.h diff --git a/fs/aufs/whout.c b/fs/aufs/whout.c new file mode 100644 index ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 21/39] aufs file (vm op)
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit file operations and vm operations Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/f_op.c | 645 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 645 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/f_op.c diff --git a/fs/aufs/f_op.c b/fs/aufs/f_op.c new file mode 100644 index 0000000..cf48f45 --- /dev/null +++ b/fs/aufs/f_op.c @@ -0,0 +1,645 @@ +/* + * Copyright (C) ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 26/39] aufs inode del operations
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit inode del operations (unlink/rmdir) Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/i_op_del.c | 562 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 562 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/i_op_del.c diff --git a/fs/aufs/i_op_del.c b/fs/aufs/i_op_del.c new file mode 100644 index 0000000..66eab04 --- /dev/null +++ b/fs/aufs/i_op_del.c @@ -0,0 +1,562 @@ +/* + ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 05/39] aufs super_block
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit super_block operations and private data Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/sbinfo.c | 261 +++++++++++++++++ fs/aufs/super.c | 835 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/super.h | 405 ++++++++++++++++++++++++++ 3 files changed, 1501 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/sbinfo.c create mode 100644 fs/aufs/super.c create mode 100644 ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 24/39] aufs inode
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit inode functions and private data Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/iinfo.c | 275 ++++++++++++++++++++++++++++++++++++++ fs/aufs/inode.c | 400 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/inode.h | 334 ++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 1009 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/iinfo.c create mode 100644 fs/aufs/inode.c ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 27/39] aufs inode rename operation
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit inode rename operation Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/i_op_ren.c | 788 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 788 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/i_op_ren.c diff --git a/fs/aufs/i_op_ren.c b/fs/aufs/i_op_ren.c new file mode 100644 index 0000000..b61d4cb --- /dev/null +++ b/fs/aufs/i_op_ren.c @@ -0,0 +1,788 @@ +/* + * Copyright ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 35/39] aufs misc functions
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit misc functions Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/misc.c | 266 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/misc.h | 201 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 467 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/misc.c create mode 100644 fs/aufs/misc.h diff --git a/fs/aufs/misc.c b/fs/aufs/misc.c new file mode 100644 index ...
May 20, 8:23 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 02/39] aufs manual
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit aufs manual Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- Documentation/filesystems/aufs/aufs.5 | 1609 +++++++++++++++++++++++++++++++++ 1 files changed, 1609 insertions(+), 0 deletions(-) create mode 100644 Documentation/filesystems/aufs/aufs.5 diff --git a/Documentation/filesystems/aufs/aufs.5 b/Documentation/filesystems/aufs/aufs.5 new file mode 100644 index 0000000..42aabc6 --- /dev/null +++ ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 13/39] aufs sub-dcache
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit sub-routines or simple wrappers for dentry cache Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/dcsub.c | 244 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/dcsub.h | 52 ++++++++++++ 2 files changed, 296 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/dcsub.c create mode 100644 fs/aufs/dcsub.h diff --git a/fs/aufs/dcsub.c b/fs/aufs/dcsub.c new file mode 100644 index ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 25/39] aufs inode add operations
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit inode add operations (mknod/creat/link/mkdir) Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/i_op_add.c | 765 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 765 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/i_op_add.c diff --git a/fs/aufs/i_op_add.c b/fs/aufs/i_op_add.c new file mode 100644 index 0000000..471a31f --- /dev/null +++ b/fs/aufs/i_op_add.c @@ -0,0 +1,765 ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 20/39] aufs file
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit file private data and address_space operations Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/file.c | 747 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/file.h | 223 +++++++++++++++++ fs/aufs/finfo.c | 182 ++++++++++++++ 3 files changed, 1152 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/file.c create mode 100644 fs/aufs/file.h create mode 100644 ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 32/39] aufs export via NFS
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit NFS exporting Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/export.c | 578 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 578 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/export.c diff --git a/fs/aufs/export.c b/fs/aufs/export.c new file mode 100644 index 0000000..13b7b67 --- /dev/null +++ b/fs/aufs/export.c @@ -0,0 +1,578 @@ +/* + * Copyright (C) 2007-2008 ...
May 20, 8:23 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 23/39] aufs virtual or verti ...
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit main readdir function Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/vdir.c | 928 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 928 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/vdir.c diff --git a/fs/aufs/vdir.c b/fs/aufs/vdir.c new file mode 100644 index 0000000..6371160 --- /dev/null +++ b/fs/aufs/vdir.c @@ -0,0 +1,928 @@ +/* + * Copyright (C) 2005-2008 ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 22/39] aufs direcotry
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit directory operations Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/dir.c | 548 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/dir.h | 145 +++++++++++++++ 2 files changed, 693 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/dir.c create mode 100644 fs/aufs/dir.h diff --git a/fs/aufs/dir.c b/fs/aufs/dir.c new file mode 100644 index 0000000..c4e328d --- /dev/null +++ ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 04/39] aufs module global
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit main header file module initialization and module global vars Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/aufs.h | 52 ++++++++++++++++++ fs/aufs/module.c | 153 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/module.h | 72 +++++++++++++++++++++++++ 3 files changed, 277 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/aufs.h create mode 100644 fs/aufs/module.c create ...
May 20, 8:22 pm 2008
hooanon05
[AUFS PATCH v2.6.26-rc2-mm1 34/39] aufs sysfs entries
From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit sysfs entries, compiled only when CONFIG_SYSFS is enabled Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/sysfs.c | 353 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 353 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/sysfs.c diff --git a/fs/aufs/sysfs.c b/fs/aufs/sysfs.c new file mode 100644 index 0000000..63cffe7 --- /dev/null +++ b/fs/aufs/sysfs.c @@ -0,0 +1,353 ...
May 20, 8:23 pm 2008
Robert Hancock
Re: [PATCH] ata: fix sleep-while-holding-spinlock in sata_nv
Now it can, for no reason. Under the conditions it was used before, it More than slightly buggy, I think.. It seems like it is going to be bouncing block layer accesses to devices with 32-bit DMA masks through the 16MB ZONE_DMA. If that's what's actually going on, I'm surprised there haven't been more regression reports. The fact that the function now sleeps when it didn't before is the least of the problems here.. --
May 21, 7:31 am 2008
Robert Hancock
Re: [PATCH] ata: fix sleep-while-holding-spinlock in sata_nv
I'm not certain this is safe to do it quite this way. It would be better to keep that spinlock held so that no operations could be in progress on either port while these operations are happening. It would be better to fix the regression from 419c434c35614609fd0c79d335c134bf4b88b30b in block/blk_settings.c that resulted in the blk_queue_bounce_limit allocation wrongly allocating emergency ISA pages in the first place as a 32-bit DMA mask does not need them. --
May 20, 7:17 pm 2008
Arjan van de Ven
Re: [PATCH] ata: fix sleep-while-holding-spinlock in sata_nv
On Tue, 20 May 2008 20:17:08 -0600 the condition under which it sleeps might be slightly buggy on your exact x86 machine... but that doesn't mean that that is guaranteed to be so forever going forward.... it's still a sleeping function. --
May 20, 9:43 pm 2008
Arjan van de Ven
Re: [PATCH] ata: fix sleep-while-holding-spinlock in sata_nv
On Wed, 21 May 2008 08:31:26 -0600 "never" is.. a dangerous assumption. It depends on the details of what GFP_DMA exactly means and how the exact zoning in the system is set up. All of that is undergoing flux (Andi Kleen has been hacking on that for example) But yes, on the existing VM layout on a 32 bit X86 system it wouldn't you're absolutely right that the current implementation has a bug. But the sleepy-ness part isn't really part of that bug. When we get pools to fill for other masks ...
May 21, 8:16 am 2008
Johannes Weiner
[RFC 3/3] mm: Remove node_boot_start from bootmem_data_t
Drop node_boot_start and convert users to node_min_pfn which is what they really mean. Signed-off-by: Johannes Weiner <hannes@saeurebad.de> CC: Richard Henderson <rth@twiddle.net> CC: Russell King <rmk@arm.linux.org.uk> CC: Haavard Skinnemoen <hskinnemoen@atmel.com> CC: Tony Luck <tony.luck@intel.com> CC: Hirokazu Takata <takata@linux-m32r.org> CC: David Howells <dhowells@redhat.com> CC: Paul Mundt <lethal@linux-sh.org> CC: Ingo Molnar <mingo@elte.hu> --- arch/alpha/mm/numa.c | 2 ...
May 20, 6:37 pm 2008
Johannes Weiner
[RFC 2/3] mm: Reimplement bootmem
This is a complete overhaul of the bootmem allocator. alloc_bootmem() will more likely respect the requested goal as the old logic tried allocation on the first node in the system and dropped the goal immediately if it not happened to reside on that node. Now we try the first allocation on the node holding the goal and then fall back. free_bootmem() and reserve_bootmem() have become more strict. Users have to make sure that the PFNS of the range are contiguous. __alloc_bootmem_node_low() ...
May 20, 6:37 pm 2008
Johannes Weiner
[RFC 1/3] mm: Move bootmem descriptors to a single place
There are a lot of places that define either a single bootmem descriptor or an array of them. Use only one central array with MAX_NUMNODES items instead. Signed-off-by: Johannes Weiner <hannes@saeurebad.de> Acked-by: Ralf Baechle <ralf@linux-mips.org> CC: Andrew Morton <akpm@linux-foundation.org> CC: Ingo Molnar <mingo@elte.hu> CC: Richard Henderson <rth@twiddle.net> CC: Russell King <rmk@arm.linux.org.uk> CC: Tony Luck <tony.luck@intel.com> CC: Hirokazu Takata <takata@linux-m32r.org> CC: ...
May 20, 6:37 pm 2008
Andrew Morton
Re: [RFC 0/3] bootmem rewrite
On Wed, 21 May 2008 03:37:35 +0200 Oh gee. bootmem is an area where large numbers of people have done hit-and-run jobs over a lot of years. Nobody owns it and I'm sure that you are now the world's expert. We just need to push ahead with this, I guess. I expect there will be problems - so many architectures which do such different things, and all the configuration options churning things around. So how to move ahead with this? - I think I'd prefer not to drop ...
May 21, 4:57 pm 2008
Johannes Weiner
[RFC 0/3] bootmem rewrite
Hi, This is a complete overhaul of the bootmem allocator while preserving its original functionality, excluding bugs. free_bootmem and reserve_bootmem become a bit stricter than they are right now, callsites have to make sure that the PFN range is contiguous but it might go across node boundaries. alloc_bootmem satisfying the allocation goal is more likely as the routines will try to allocate on the node holding the goal first before falling back as opposed to the original behaviour ...
May 20, 6:37 pm 2008
Divy Le Ray
[PATCH 3/3 2.6.27] cxgb3 - Add LRO support
From: Divy Le Ray <divy@chelsio.com> Add LRO support. Signed-off-by: Divy Le Ray <divy@chelsio.com> --- drivers/net/Kconfig | 1 drivers/net/cxgb3/adapter.h | 14 ++ drivers/net/cxgb3/common.h | 1 drivers/net/cxgb3/cxgb3_ioctl.h | 1 drivers/net/cxgb3/cxgb3_main.c | 19 +++ drivers/net/cxgb3/sge.c | 235 +++++++++++++++++++++++++++++++++++++-- drivers/net/cxgb3/t3_cpl.h | 11 ++ 7 files changed, 269 insertions(+), 13 ...
May 20, 6:57 pm 2008
Divy Le Ray
[PATCH 2/3 2.6.27] cxgb3 - Add page support to jumbo fra ...
From: Divy Le Ray <divy@chelsio.com> Add page support to Jumbo frame Rx queues. Signed-off-by: Divy Le Ray <divy@chelsio.com> --- drivers/net/cxgb3/adapter.h | 4 + drivers/net/cxgb3/sge.c | 118 ++++++++++++++++++++++++++++++------------- 2 files changed, 86 insertions(+), 36 deletions(-) diff --git a/drivers/net/cxgb3/adapter.h b/drivers/net/cxgb3/adapter.h index acebe43..263e4fa 100644 --- a/drivers/net/cxgb3/adapter.h +++ b/drivers/net/cxgb3/adapter.h @@ -92,6 +92,7 @@ ...
May 20, 6:57 pm 2008
Divy Le Ray
[PATCH 1/3 2.6.27] cxgb3 - Fix dma mapping error path
From: Divy Le Ray <divy@chelsio.com> Take potential dma mapping errors in account. Signed-off-by: Divy Le Ray <divy@chelsio.com> --- drivers/net/cxgb3/sge.c | 53 ++++++++++++++++++++++++++++++++++++----------- 1 files changed, 41 insertions(+), 12 deletions(-) diff --git a/drivers/net/cxgb3/sge.c b/drivers/net/cxgb3/sge.c index 796eb30..0741deb 100644 --- a/drivers/net/cxgb3/sge.c +++ b/drivers/net/cxgb3/sge.c @@ -376,13 +376,16 @@ static void free_rx_bufs(struct pci_dev *pdev, ...
May 20, 6:57 pm 2008
Divy Le Ray
[PATCH 0/3 2.6.27] cxgb3 - driver updates
Hi Jeff, I'm submitting 3 update patches against netdev-2.6#upstream for inclusion in 2.6.27. Here is a brief description of the patch series: - Check pci mapping errors - Feed the Jumbo frame Rx queue with pages - Add support for LRO Cheers, Divy --
May 20, 6:57 pm 2008
Al Viro
[PATCH] MODULE_LICENSE expects "GPL v2", not "GPLv2"
Content-Length: 4235 Lines: 110 ... and we have few enough places using the latter to make it simpler to do search and replace... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- arch/sh/drivers/heartbeat.c | 2 +- drivers/input/keyboard/aaed2000_kbd.c | 2 +- drivers/input/keyboard/corgikbd.c | 2 +- drivers/input/keyboard/jornada680_kbd.c | 2 +- drivers/input/keyboard/jornada720_kbd.c | 2 +- drivers/input/keyboard/spitzkbd.c | ...
May 20, 6:13 pm 2008
Al Viro
[PATCH] HTC_EGPIO is ARM-only
Content-Length: 638 Lines: 22 driver uses symbols defined only on ARM Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/mfd/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 072b683..d83b50f 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -25,7 +25,7 @@ config MFD_ASIC3 config HTC_EGPIO bool "HTC EGPIO support" - depends on GENERIC_HARDIRQS && HAVE_GPIO_LIB + depends on ...
May 20, 6:12 pm 2008
Adrian Bunk
-ffreestanding or not -ffreestanding
Can we try to get this sorted out properly instead of constantly fiddling with it? Currently we use -ffreestanding on some architectures and fix breakages on the other architectures when they arise. The options I see for getting this fixed properly are: - use -ffreestanding on all architectures or - don't use -ffreestanding on any architecture and move the string functions (and perhaps other functions if required) out-of-line I'd prefer the first option, but I know that not everyone ...
May 21, 12:52 am 2008
Al Viro
Re: [PATCH] provide out-of-line strcat() for m68k
Here it replaced strncat() with call of strcat() (gcc 4.0.1, FWIW). And yes, I can show you init/main.s with jbsr strcat | in it generated on kernel in b0rken range... --
May 20, 10:30 pm 2008
Roman Zippel
Re: [PATCH] provide out-of-line strcat() for m68k
Hi, Please use a more recent compiler, 4.0 created too many problems on m68k, which we only got under control with 4.1, so at least on m68k 4.0 is not really supported. bye, Roman --
May 21, 3:53 am 2008
Al Viro
[PATCH] provide out-of-line strcat() for m68k
Content-Length: 788 Lines: 30 Whether we sidestep it in init/main.c or not, such situations will arise again; compiler does generate calls of strcat() on optimizations, so we really ought to have an out-of-line version... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- arch/m68k/lib/string.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/m68k/lib/string.c b/arch/m68k/lib/string.c index 891e134..4253f87 100644 --- a/arch/m68k/lib/string.c +++ ...
May 20, 6:12 pm 2008
Roman Zippel
Re: [PATCH] provide out-of-line strcat() for m68k
Hi, It actually was strlen that was generated and not strcat. bye, Roman --
May 20, 8:34 pm 2008
Al Viro
Re: [PATCH] provide out-of-line strcat() for m68k
Then it's worth mentioning in Documentation/Changes, IMO... Anyway, updating m68k toolchain is not a problem; I'll get around to it tonight. I still think that out-of-line implementation is a good idea, if nothing else it would prevent future crap of the same kind if some later version decides that strlen(a) + strlen(b) can be proven to be less than size argument of strncat(), etc. Technically we _are_ in nasal daemon country with redefining str*, unless we pass -ffreestanding; m68k doesn't, ...
May 21, 4:09 am 2008
Roman Zippel
Re: -ffreestanding or not -ffreestanding
Hi, This won't help completely unless you also clean up all archs to use the same mappings to the builtin functions. The main problem I had with -ffreestanding is that it's awkward to map a library function to the builtin function and also provide the fallback from lib/string.c. If you look at asm-m68k/string.h I once tried this with the mem* functions and I still have the duplicated memcmp in arch/m68k/lib/string.c. (You could argue that it would be easier to just remove the define ...
May 21, 4:44 am 2008
Al Viro
[PATCH] caiaq endianness fix
Content-Length: 800 Lines: 23 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- sound/usb/caiaq/caiaq-device.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/usb/caiaq/caiaq-device.c b/sound/usb/caiaq/caiaq-device.c index e97d8b2..a972f77 100644 --- a/sound/usb/caiaq/caiaq-device.c +++ b/sound/usb/caiaq/caiaq-device.c @@ -351,8 +351,8 @@ static struct snd_card* create_card(struct usb_device* usb_dev) dev = caiaqdev(card); dev->chip.dev = ...
May 20, 6:11 pm 2008
Al Viro
[PATCH] msnd_* is ISA-only
Content-Length: 1025 Lines: 30 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- sound/oss/Kconfig | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/oss/Kconfig b/sound/oss/Kconfig index 857008b..3be2dc1 100644 --- a/sound/oss/Kconfig +++ b/sound/oss/Kconfig @@ -79,7 +79,7 @@ config SOUND_TRIDENT config SOUND_MSNDCLAS tristate "Support for Turtle Beach MultiSound Classic, Tahiti, Monterey" - depends on SOUND_PRIME && (m || !STANDALONE) + depends ...
May 20, 6:11 pm 2008
Al Viro
[PATCH] missing dependencies on HAS_DMA
Content-Length: 2430 Lines: 75 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/video/Kconfig | 2 +- drivers/mmc/host/Kconfig | 2 +- drivers/net/Kconfig | 2 +- drivers/net/wireless/b43/Kconfig | 2 +- drivers/net/wireless/b43legacy/Kconfig | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 89d8d37..3b26fbd 100644 --- ...
May 20, 6:07 pm 2008
Al Viro
[PATCH] ocfs2 endianness fixes
Content-Length: 1027 Lines: 30 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- fs/ocfs2/alloc.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/ocfs2/alloc.c b/fs/ocfs2/alloc.c index 41f84c9..10bfb46 100644 --- a/fs/ocfs2/alloc.c +++ b/fs/ocfs2/alloc.c @@ -2788,7 +2788,7 @@ static int ocfs2_merge_rec_right(struct inode *inode, BUG_ON(index >= le16_to_cpu(el->l_next_free_rec)); left_rec = &el->l_recs[index]; - if (index == ...
May 20, 6:07 pm 2008
Al Viro
[PATCH] irda-usb endianness annotations and fixes
Content-Length: 1257 Lines: 40 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/net/irda/irda-usb.c | 2 +- drivers/net/irda/irda-usb.h | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/irda/irda-usb.c b/drivers/net/irda/irda-usb.c index 9081234..6f50ed7 100644 --- a/drivers/net/irda/irda-usb.c +++ b/drivers/net/irda/irda-usb.c @@ -1120,7 +1120,7 @@ static int stir421x_patch_device(struct irda_usb_cb *self) } ...
May 20, 6:06 pm 2008
Al Viro
[PATCH] sbus bpp: instances missed in s/dev_name/bpp_dev_name/
Content-Length: 1164 Lines: 39 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/sbus/char/bpp.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/sbus/char/bpp.c b/drivers/sbus/char/bpp.c index b87037e..03c9660 100644 --- a/drivers/sbus/char/bpp.c +++ b/drivers/sbus/char/bpp.c @@ -869,7 +869,7 @@ static void probeLptPort(unsigned idx) instances[idx].mode = COMPATIBILITY; instances[idx].run_length = 0; ...
May 20, 6:06 pm 2008
Al Viro
[PATCH] ecryptfs fixes
Content-Length: 2206 Lines: 71 memcpy() from userland pointer is a Bad Thing(tm) Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- fs/ecryptfs/miscdev.c | 26 ++++++++++++-------------- 1 files changed, 12 insertions(+), 14 deletions(-) diff --git a/fs/ecryptfs/miscdev.c b/fs/ecryptfs/miscdev.c index 6560da1..50c994a 100644 --- a/fs/ecryptfs/miscdev.c +++ b/fs/ecryptfs/miscdev.c @@ -243,7 +243,6 @@ ecryptfs_miscdev_read(struct file *file, char __user *buf, size_t count, struct ...
May 20, 6:06 pm 2008
Al Viro
[PATCH 6/6][uml] thanks to net/mac80211 we need to pull ...
Content-Length: 454 Lines: 21 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- arch/um/Kconfig | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/um/Kconfig b/arch/um/Kconfig index dba8e05..6976812 100644 --- a/arch/um/Kconfig +++ b/arch/um/Kconfig @@ -259,6 +259,8 @@ if BROKEN source "drivers/mtd/Kconfig" endif +source "drivers/leds/Kconfig" + #This is just to shut up some Kconfig warnings, so no prompt. config INPUT bool -- ...
May 20, 5:49 pm 2008
Al Viro
[PATCH 5/6][uml] missing export of csum_partial() on uml/amd64
Content-Length: 596 Lines: 22 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- arch/um/sys-x86_64/ksyms.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/um/sys-x86_64/ksyms.c b/arch/um/sys-x86_64/ksyms.c index 4d7d1a8..6604673 100644 --- a/arch/um/sys-x86_64/ksyms.c +++ b/arch/um/sys-x86_64/ksyms.c @@ -1,5 +1,7 @@ -#include "linux/module.h" -#include "asm/string.h" +#include <linux/module.h> +#include <asm/string.h> +#include <asm/checksum.h> ...
May 20, 5:48 pm 2008
Al Viro
[PATCH 4/6][uml] uml: add missing exports for UML_RANDOM=m
Content-Length: 581 Lines: 24 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- arch/um/kernel/ksyms.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/um/kernel/ksyms.c b/arch/um/kernel/ksyms.c index 66e2a30..ccc02a6 100644 --- a/arch/um/kernel/ksyms.c +++ b/arch/um/kernel/ksyms.c @@ -60,6 +60,11 @@ EXPORT_SYMBOL(os_rcv_fd); EXPORT_SYMBOL(run_helper); EXPORT_SYMBOL(start_thread); ...
May 20, 5:48 pm 2008
Al Viro
[PATCH 3/6][uml] fix hppfs Makefile breakage
Fallout from commit 46d7b522ebf486edbd096965d534cc6465e9e309 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Acked-by: Jeff Dike <jdike@addtoit.com> --- fs/hppfs/Makefile | 5 +---- 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/fs/hppfs/Makefile b/fs/hppfs/Makefile index 8a1f503..3a982bd 100644 --- a/fs/hppfs/Makefile +++ b/fs/hppfs/Makefile @@ -3,7 +3,4 @@ # Licensed under the GPL # -hppfs-objs := hppfs.o - -obj-y = -obj-$(CONFIG_HPPFS) += ...
May 20, 5:48 pm 2008
Al Viro
[PATCH 2/6][uml] fix include order in sys-i386/registers.c
We want sys/ptrace.h before any includes of linux/ptrace.h and asm/user.h pulls the latter. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Acked-by: Jeff Dike <jdike@addtoit.com> --- arch/um/os-Linux/sys-i386/registers.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/um/os-Linux/sys-i386/registers.c b/arch/um/os-Linux/sys-i386/registers.c index c6183e7..b487cbe 100644 --- a/arch/um/os-Linux/sys-i386/registers.c +++ ...
May 20, 5:48 pm 2008
Al Viro
[PATCH 1/6][uml] missed kmalloc() in pcap_user.c
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Acked-by: Jeff Dike <jdike@addtoit.com> --- arch/um/drivers/pcap_user.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/um/drivers/pcap_user.c b/arch/um/drivers/pcap_user.c index e980935..5f90358 100644 --- a/arch/um/drivers/pcap_user.c +++ b/arch/um/drivers/pcap_user.c @@ -50,7 +50,7 @@ static int pcap_open(void *data) return -EIO; } - pri->compiled = kmalloc(sizeof(struct ...
May 20, 5:48 pm 2008
Al Viro
[PATCHES] uml fixes
first 3 patches resent, the rest is new... --
May 20, 5:48 pm 2008
Al Viro
Re: [PATCH] misc drivers/net endianness noise
Do not grow API too much. Mental savings on recognizing what's done are offset by need to remember more helper functions... --
May 20, 5:55 pm 2008
Harvey Harrison
Re: [PATCH] misc drivers/net endianness noise
Fair point, I was hoping to get the following family: get_le16 put_le16 get_unaligned_le16 put_unaligned_le16 And get rid of the le16_to_cpup api. Then the it's explicit when alignment is an issue, and the endianess is also explicit. That and I think it just looks nicer than the existing *p versions. Just a thought, Harvey --
May 20, 5:58 pm 2008
Harvey Harrison
Re: [PATCH] misc drivers/net endianness noise
I was contemplating an api like: void put_le16(u16 val, __le16 *ptr) { *ptr = cpu_to_le16(val); } which would allow the above to become: if (catc->is_f5u011) put_be16(skb->len, tx_buf); else put_le16(skb->len, tx_buf); Thoughts? Harvey --
May 20, 5:48 pm 2008
Al Viro
[PATCH] misc drivers/net endianness noise
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/net/3c509.c | 15 +++++++-------- drivers/net/atlx/atl1.c | 2 +- drivers/net/usb/catc.c | 5 ++++- drivers/net/usb/rndis_host.c | 4 ++-- drivers/net/wireless/zd1211rw/zd_mac.c | 2 +- drivers/net/wireless/zd1211rw/zd_usb.c | 2 +- 6 files changed, 16 insertions(+), 14 deletions(-) diff --git a/drivers/net/3c509.c b/drivers/net/3c509.c index ...
May 20, 5:34 pm 2008
Al Viro
Re: [PATCH] or51132.c: unaligned
... and the point of that would be? FWIW, I really don't like the ...p() forms - they are hard to distinguish from normal ones visually and any possible performance benefit is too small for most of the uses. IOW, it's mostly redundant API. --
May 20, 5:45 pm 2008
Al Viro
[PATCH] or51132.c: unaligned
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/dvb/frontends/or51132.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/dvb/frontends/or51132.c b/drivers/media/dvb/frontends/or51132.c index c7b5785..5ed3254 100644 --- a/drivers/media/dvb/frontends/or51132.c +++ b/drivers/media/dvb/frontends/or51132.c @@ -126,7 +126,7 @@ static int or51132_readreg(struct or51132_state *state, u8 reg) reg, err); return -EREMOTEIO; ...
May 20, 5:33 pm 2008
Linus Torvalds
Re: [PATCH] or51132.c: unaligned
Perhaps better code generation? I didn't look what buf[0] | (buf[1] << 8) generates, but on x86, get_unaligned_le16() should just boil down to *(unsigned short *)buf which is certainly going to mostly generate better code (smaller, faster) than at least the most likely and straigthforward of the former. (Just checked. Gcc is not smart enough to make those two loads plus a shift be one word load. At least not my version) Linus --
May 20, 5:55 pm 2008
Al Viro
Re: [PATCH] or51132.c: unaligned
Thus the "mostly" part - on hot paths the microoptimization is worth the trouble. None of the places in question is on such paths... --
May 20, 5:56 pm 2008
Linus Torvalds
Re: [PATCH] or51132.c: unaligned
It would almost certainly help on x86. The cost of an unaligned integer access that doesn't cross a cache-fetch boundary (8 bytes on older CPU's, 16 or 32 bytes on newer ones) is zero, last I saw. IOW, there are misaligned cases that have a higher cost, but they are pretty rare, and especially so with small data and modern CPU's. So no disadvantage for 95% of all cases, and the advantage of doing just a single instruction, rather than four (2 zero-extending loads, a shift and an ...
May 20, 7:02 pm 2008
Al Viro
Re: [PATCH] or51132.c: unaligned
FWIW, I wonder how they really compare on misaligned and whether it would make sense for gcc to try and generate a single load on targets that are known to allow that... Hell knows; I still find explicit variant more readable in this case and AFAICS it's not a critical path... --
May 20, 6:18 pm 2008
Harvey Harrison
Re: [PATCH] or51132.c: unaligned
firmwareBsize = le32_to_cpup((__le32 *)(fw->data + 4)); Cheers, Harvey --
May 20, 5:41 pm 2008
Harvey Harrison
Re: [PATCH] or51132.c: unaligned
I sent a patchset getting rid of the p variants earlier today, Dave Miller made a good point that some arches have well optimized versions of these as they have specific machine instructions they can use. Agreed that I don't much like them either, was thinking of adding a u32 get_le32(__le32 *ptr) type api and get rid of the le32_to_cpup api. Cheers, Harvey --
May 20, 5:51 pm 2008
Harvey Harrison
Re: [PATCH] dvb-usb: unaligned
Just curious, is gcc smart enough to just turn this into a 2-byte load on x86 (little-endian with no particular alignment constraints). Otherwise it would have a better chance at doing this using the helper function. You're right though, it is a small consideration. Harvey --
May 20, 5:53 pm 2008
Harvey Harrison
Re: [PATCH] dvb-usb: unaligned
hx->addr = get_unaligned_le16(&b[1]); Cheers, Harvey --
May 20, 5:42 pm 2008
Al Viro
Re: [PATCH] dvb-usb: unaligned
Again, what's the benefit? Having a function doesn't mean that we need to use it religiously - if it doesn't make things more clear... --
May 20, 5:47 pm 2008
Al Viro
[PATCH] dvb-usb: unaligned
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/dvb/dvb-usb/dvb-usb-firmware.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-firmware.c b/drivers/media/dvb/dvb-usb/dvb-usb-firmware.c index e1112e3..733a7ff 100644 --- a/drivers/media/dvb/dvb-usb/dvb-usb-firmware.c +++ b/drivers/media/dvb/dvb-usb/dvb-usb-firmware.c @@ -127,7 +127,7 @@ int dvb_usb_get_hexline(const struct firmware *fw, struct hexline *hx, if ...
May 20, 5:33 pm 2008
Al Viro
[PATCH] media/video: mix trivial endianness annotations
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/video/em28xx/em28xx-video.c | 8 ++++---- drivers/media/video/usbvideo/quickcam_messenger.c | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/media/video/em28xx/em28xx-video.c b/drivers/media/video/em28xx/em28xx-video.c index 8996175..fb163ec 100644 --- a/drivers/media/video/em28xx/em28xx-video.c +++ b/drivers/media/video/em28xx/em28xx-video.c @@ -1166,13 +1166,13 @@ static int ...
May 20, 5:32 pm 2008
Al Viro
[PATCH] m920x: unaligned access
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/dvb/dvb-usb/m920x.c | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/media/dvb/dvb-usb/m920x.c b/drivers/media/dvb/dvb-usb/m920x.c index a12e6f7..54626a0 100644 --- a/drivers/media/dvb/dvb-usb/m920x.c +++ b/drivers/media/dvb/dvb-usb/m920x.c @@ -16,6 +16,7 @@ #include "qt1010.h" #include "tda1004x.h" #include "tda827x.h" +#include <asm/unaligned.h> /* debug */ static int ...
May 20, 5:32 pm 2008
Al Viro
[PATCH] zoran: endianness annotations
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/video/zoran.h | 4 ++-- drivers/media/video/zoran_device.c | 2 +- drivers/media/video/zoran_driver.c | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/media/video/zoran.h b/drivers/media/video/zoran.h index 81cc3b0..46b7ad4 100644 --- a/drivers/media/video/zoran.h +++ b/drivers/media/video/zoran.h @@ -285,7 +285,7 @@ struct zoran_mapping { struct zoran_jpg_buffer { ...
May 20, 5:32 pm 2008
Harvey Harrison May 20, 5:38 pm 2008
Al Viro
[PATCH] bt8xx: unaligned access
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/video/bt8xx/bttv-cards.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/bt8xx/bttv-cards.c b/drivers/media/video/bt8xx/bttv-cards.c index f20a01c..8ef0424 100644 --- a/drivers/media/video/bt8xx/bttv-cards.c +++ b/drivers/media/video/bt8xx/bttv-cards.c @@ -34,6 +34,7 @@ #include <linux/firmware.h> #include <net/checksum.h> +#include <asm/unaligned.h> #include ...
May 20, 5:32 pm 2008
Harvey Harrison
Re: [PATCH] bt8xx: unaligned access
You want me to patch the unaligned guys to take typed pointers and follow it through? Or do you mind? Cheers, Harvey --
May 20, 5:45 pm 2008
Al Viro
Re: [PATCH] bt8xx: unaligned access
I'd rather have them explicit *and* make get_unaligned_* take the pointer of right type, so that it'd eat things like void * and __be16 *, but warn on int * et.al. One too many brainos seen in that area... --
May 20, 5:43 pm 2008
Al Viro
[PATCH] cx18: direct dereferencing of iomem
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/video/cx18/cx18-irq.c | 10 ++++++---- 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/media/video/cx18/cx18-irq.c b/drivers/media/video/cx18/cx18-irq.c index 0590d71..25114a5 100644 --- a/drivers/media/video/cx18/cx18-irq.c +++ b/drivers/media/video/cx18/cx18-irq.c @@ -161,13 +161,15 @@ irqreturn_t cx18_irq_handler(int irq, void *dev_id) */ if (sw2) { - if (sw2 & (cx->scb->cpu2hpu_irq_ack ...
May 20, 5:32 pm 2008
Al Viro
[PATCH] cx18 iomem annotations
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/video/cx18/cx18-driver.c | 2 +- drivers/media/video/cx18/cx18-driver.h | 2 +- drivers/media/video/cx18/cx18-fileops.c | 3 ++- drivers/media/video/cx18/cx18-irq.c | 2 +- drivers/media/video/cx18/cx18-mailbox.c | 8 ++++---- drivers/media/video/cx18/cx18-streams.c | 8 ++++---- 6 files changed, 13 insertions(+), 12 deletions(-) diff --git a/drivers/media/video/cx18/cx18-driver.c ...
May 20, 5:32 pm 2008
Al Viro
[PATCH] annotate bcx_riscmem
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/video/bt8xx/bttv-risc.c | 8 +++++--- drivers/media/video/btcx-risc.c | 2 +- drivers/media/video/btcx-risc.h | 4 ++-- drivers/media/video/cx23885/cx23885-core.c | 8 ++++---- drivers/media/video/cx88/cx88-core.c | 8 ++++---- 5 files changed, 16 insertions(+), 14 deletions(-) diff --git a/drivers/media/video/bt8xx/bttv-risc.c b/drivers/media/video/bt8xx/bttv-risc.c index ...
May 20, 5:31 pm 2008
Al Viro
[PATCH] ivtv: trivial annotations
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/video/ivtv/ivtv-driver.h | 10 ++++++++-- drivers/media/video/ivtv/ivtv-fileops.c | 2 +- drivers/media/video/ivtv/ivtv-irq.c | 8 ++++---- drivers/media/video/ivtv/ivtv-queue.c | 2 +- drivers/media/video/ivtv/ivtv-yuv.c | 2 +- drivers/media/video/ivtv/ivtv-yuv.h | 2 +- 6 files changed, 16 insertions(+), 10 deletions(-) diff --git a/drivers/media/video/ivtv/ivtv-driver.h ...
May 20, 5:31 pm 2008
Al Viro
[PATCH] ttusb endianness annotations and fixes
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c | 2 +- drivers/media/dvb/ttusb-dec/ttusb_dec.c | 25 +++++++++++---------- drivers/media/dvb/ttusb-dec/ttusbdecfe.c | 10 ++++---- 3 files changed, 19 insertions(+), 18 deletions(-) diff --git a/drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c b/drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c index 732ce4d..5d2d81a 100644 --- ...
May 20, 5:31 pm 2008
Al Viro
[PATCH] fix endianness bug in dib0700_devices.c
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/dvb/dvb-usb/dib0700_devices.c | 21 +++++++++++---------- 1 files changed, 11 insertions(+), 10 deletions(-) diff --git a/drivers/media/dvb/dvb-usb/dib0700_devices.c b/drivers/media/dvb/dvb-usb/dib0700_devices.c index 3462238..c4d40fe 100644 --- a/drivers/media/dvb/dvb-usb/dib0700_devices.c +++ b/drivers/media/dvb/dvb-usb/dib0700_devices.c @@ -111,8 +111,8 @@ static int bristol_tuner_attach(struct dvb_usb_adapter *adap) ...
May 20, 5:31 pm 2008
Al Viro
[PATCH] dvb_net: endianness annotations
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/dvb/dvb-core/dvb_net.c | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/media/dvb/dvb-core/dvb_net.c b/drivers/media/dvb/dvb-core/dvb_net.c index 56d871c..c2334ae 100644 --- a/drivers/media/dvb/dvb-core/dvb_net.c +++ b/drivers/media/dvb/dvb-core/dvb_net.c @@ -168,7 +168,7 @@ struct dvb_net_priv { * stolen from eth.c out of the linux kernel, hacked for dvb-device * by Michael ...
May 20, 5:31 pm 2008
Al Viro
[PATCH] endianness fix in flexcop-usb.c
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/dvb/b2c2/flexcop-usb.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/dvb/b2c2/flexcop-usb.c b/drivers/media/dvb/b2c2/flexcop-usb.c index 449fb5c..ae0d76a 100644 --- a/drivers/media/dvb/b2c2/flexcop-usb.c +++ b/drivers/media/dvb/b2c2/flexcop-usb.c @@ -379,7 +379,7 @@ static void flexcop_usb_transfer_exit(struct flexcop_usb *fc_usb) static int flexcop_usb_transfer_init(struct ...
May 20, 5:31 pm 2008
Al Viro
[PATCH] fix unaligned access in av7110.c
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/dvb/ttpci/av7110.c | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/media/dvb/ttpci/av7110.c b/drivers/media/dvb/ttpci/av7110.c index 747e7f1..f05d43d 100644 --- a/drivers/media/dvb/ttpci/av7110.c +++ b/drivers/media/dvb/ttpci/av7110.c @@ -51,6 +51,7 @@ #include <linux/crc32.h> #include <linux/i2c.h> #include <linux/kthread.h> +#include <asm/unaligned.h> #include ...
May 20, 5:30 pm 2008
Al Viro
[PATCH] fix the roothole in av7110_av.c
direct dereferencing from user-supplied address Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/dvb/ttpci/av7110_av.c | 34 +++++++++++++++++++++++++++------- 1 files changed, 27 insertions(+), 7 deletions(-) diff --git a/drivers/media/dvb/ttpci/av7110_av.c b/drivers/media/dvb/ttpci/av7110_av.c index 3e6b650..ec55a96 100644 --- a/drivers/media/dvb/ttpci/av7110_av.c +++ b/drivers/media/dvb/ttpci/av7110_av.c @@ -965,8 +965,9 @@ static u8 iframe_header[] = { 0x00, 0x00, ...
May 20, 5:30 pm 2008
Al Viro
[PATCH] cinergyT2: endianness annotations, endianness an ...
Endianness annotations and fixes + fixing the handling of ->uncorrected_block_count Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/dvb/cinergyT2/cinergyT2.c | 46 ++++++++++++++++--------------- 1 files changed, 24 insertions(+), 22 deletions(-) diff --git a/drivers/media/dvb/cinergyT2/cinergyT2.c b/drivers/media/dvb/cinergyT2/cinergyT2.c index f5010e8..a824f37 100644 --- a/drivers/media/dvb/cinergyT2/cinergyT2.c +++ b/drivers/media/dvb/cinergyT2/cinergyT2.c @@ ...
May 20, 5:30 pm 2008
Peter Zijlstra
Re: kswapd busy but not swapping
It could have been busy reclaiming pagecache. kswapd is the generic reclaim thread - paging anonymous memory to the swap is but one form thereof. --
May 21, 2:13 am 2008
Christian Kujau
Re: kswapd busy but not swapping
Hm, OK, so it's "OK" I guess. It stopped after a few hours anyway, I think it was related to the disk IO (dd if=/dev/hdd of=/dev/null).... Thanks for replying, Christian. -- BOFH excuse #75: There isn't any problem --
May 21, 11:42 am 2008
Michael Halcrow
[PATCH] eCryptfs: Remove useless lock
Nobody can get a reference to req so long as &ecryptfs_kthread_ctl.mux is held. Remove lock of req->mux for newly created req. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> --- fs/ecryptfs/kthread.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/fs/ecryptfs/kthread.c b/fs/ecryptfs/kthread.c index dba7c67..3d34327 100644 --- a/fs/ecryptfs/kthread.c +++ b/fs/ecryptfs/kthread.c @@ -158,7 +158,6 @@ int ecryptfs_privileged_open(struct file **lower_file, ...
May 21, 8:39 am 2008
Michael Halcrow
Re: [PATCH] eCryptfs: Privileged kthread for lower file opens
Nobody else actually has a reference to req at this point, so the unlock is not really necessary. It might not be a bad idea to jump to --
May 21, 8:14 am 2008
Andrew Morton
Re: [PATCH] eCryptfs: Privileged kthread for lower file opens
On Tue, 20 May 2008 16:46:10 -0500 I think this guy can be made static too. As a result of which, entire data structure definitions could possibly be pushed down into A plain old `return 0;' will suffice here, and is more typical. I'm eh? We attach a local variable to a global list and then return? That This looks racy to me. I assume we're waiting for ecryptfs_kthread to wake us up. But that thread could have sent us its wakeup _before_ we did the ...
May 21, 3:59 pm 2008
Jiri Slaby
Re: VM: killing process - How to identify the problem
Caused by out of memory, a page fault couldn't be serviced due to memory exhaustion. See arch/mips/mm/fault.c. --
May 21, 12:44 am 2008
Mudeem Siddiqui
RE: VM: killing process - How to identify the problem
>Just curious, is is a typo? Can this condition arise due to some other reason other than memory leak. E.g the way the paging is being done etc because the application calls malloc only once when it starts. I have been struggling with this for quite a while, how would you recommend I should try to solve this? Thanks --
May 21, 12:30 pm 2008
Steven Rostedt
Re: Compile warning rtmutex code on 2.6.24.7-rt8 (CC:LKM ...
If you feel brave, take a crack at the DYNAMIC_FTRACE. It's been done for x86 (both 32 and 64 bit), PPC (also both 32 and 64 bit) as well as Sparc64. The dynamic ftrace is self modifying code, that will start off having mcount simply call a nop. Then later it will change that to call a "record_ip" function. A daemon is kicked off to change all the IPs that are called into NOPs. When tracing is enabled, all the NOPs are converted into calls to the trace function. Dynamic ftrace also adds ...
May 21, 12:14 pm 2008
Remy Bohmer
Re: Compile warning rtmutex code on 2.6.24.7-rt8 (CC:LKM ...
Yes, this helps. Looks a little weird to add bitmasks to pointers, but I understand why it has been done here. BTW: I notice that you already has put it in -rt9. And some other positive news: 2.6.24.7-rt9 compiles and boots perfectly on ARM at91sam9261. (There are still a few other warnings, but these are not RT related) Now I understood your hint in some other mail, and I am going to take a look at ftrace for ARM. Just for the fun of it... I hope it is not too intrusive for these ARM ...
May 21, 11:35 am 2008
Benjamin Herrenschmidt
Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
There have been long discussions about that. The end result was that being too weakly ordered is just asking for trouble because the majority of drivers are written & tested on x86 which is in order. If you look at our accessors, minus that gcc problem you found, the barriers in there should pretty much guarantee ordering in the cases that matter, which are basically MMIO read followed by memory accesses and memory writes followed by MMIO. In fact, MMIO read are fully Ok, so there is a ...
May 21, 1:41 pm 2008
Benjamin Herrenschmidt
Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
I don't have time for that now. Can you dig into the archives ? The whole thing has been discussed at lenght already. Ben. --
May 21, 7:01 am 2008
Benjamin Herrenschmidt
Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
If that's the case, there is a bug. Ignoring gcc possible optimisations, the accessors contain the necessary memory barriers for things to work the way you describe above. If the use of volatile and clobber in our macros isn't enough to also prevent optimisations, then we have a bug The linus kernel -cannot- be compiled with strict aliasing rules. This is one of the many areas where those are violated. Frankly, this strict aliasing stuff is just a total nightmare turning a pefectly nice ...
May 21, 7:00 am 2008
Andreas Schwab
Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
Use the %y modifier when substituting the operand. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." --
May 21, 1:03 am 2008
Trent Piepho
Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
Someone should update memory-barriers.txt, because it doesn't say that, and No, it's compiled with a normal kernel build, which includes -fno-strict-aliasing. --
May 21, 12:44 pm 2008
Trent Piepho
Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
Of course, the undocumented y modifier! "Print AltiVec or SPE memory operand" Why didn't I think of that? That appears to work. I can get gcc to to emit 0,reg and reg,reg but not disp(reg). It won't try to use an "update" address either, though it will with an "m" constraint. But, gcc 4.0.2 can't handle the 'Z' constraint. It looks like it's not supported. Other than this, I can build a kernel with 4.0.2 that appears to work. Is it ok to break compatibility with 4.0.2, or should I put ...
May 21, 1:25 pm 2008
Hugh Dickins
Re: 2.6.26-rcX: Problem with mem config > 4GB ; fore2000 ...
It's worth now trying 2.6.26-rc3-git2 or later: there was indeed a problem introduced in 2.6.26-rc2-git<I-haven't-looked-which> which caused segfaults in various things when CONFIG_HIGHMEM64G. (See http://lkml.org/lkml/2008/5/19/446 for what I'm talking about; Sorry, I've not looked into that at all: Cc'ed ATM maintainer. Hugh --
May 21, 11:41 am 2008
Paul Mackerras
Re: [PATCH 1/2] Remove all users of cpu_to_{le|be}{16|32|64}p
Please don't do this, because it means we don't get to use the byte-reversing loads and stores on powerpc, and end up using several instructions instead of one. Paul. --
May 20, 6:13 pm 2008
Michael S. Tsirkin May 20, 10:47 pm 2008
Patrick McHardy
Re: include/linux/netfilter.h after make headers_install ...
I didn't notice the ifdef around the include statement, this makes sense of course. I'll fix it up, thanks Sam. --
May 21, 3:31 am 2008
Sam Ravnborg
Re: include/linux/netfilter.h after make headers_install ...
Everything inside #ifdef __KERNEL__ ... #endif are stripped. From netfilter.h: #ifdef __KERNEL__ #include <linux/init.h> #include <linux/types.h> #include <linux/skbuff.h> #include <linux/net.h> #include <linux/netdevice.h> #include <linux/if.h> #include <linux/in.h> #include <linux/in6.h> #include <linux/wait.h> #include <linux/list.h> #include <net/net_namespace.h> #endif Include of types.h should be outside the #ifdef block. Sam --
May 21, 3:04 am 2008
Patrick McHardy
Re: include/linux/netfilter.h after make headers_install ...
These types are used by countless header files. I don't know why types.h is stripped, I guess this question can be best answered by whoever maintains the header-install stuff (Sam? I don't know). --
May 21, 2:56 am 2008
mark
Re: fork: Resource temporarily unavailable / cant start ...
No. There is no new message added after kernel boot messages --
May 21, 2:27 pm 2008
Randy Dunlap
Re: fork: Resource temporarily unavailable / cant start ...
I made a small patch to a vanilla kernel.org 2.6.25.3 kernel tree. Hopefully it applies cleanly to that fc9 kernel source, but check/verify that first before going any further. After building and booting with this patch, there will be kernel messages whenever fork's "copy_process" function fails with -EAGAIN (-11), which is reported to userspace as errno = 11 (Resource temporarily unavailable). Hopefully this will identify which test is failing, but there's a chance that something else is ...
May 21, 4:35 pm 2008
Randy Dunlap
Re: fork: Resource temporarily unavailable / cant start ...
Hi, The only place that fork() returns EAGAIN is for number of processes being >= its limit. Does this user already have >= 1024 processes? --- ~Randy --
May 21, 1:28 pm 2008
Randy Dunlap
Re: fork: Resource temporarily unavailable / cant start ...
Well, my comment was wrong anyway. There are several other tests just below number of user processes that also return EAGAIN, like: - total number of threads being too large - error on grabbing a module reference count (?) -- ~Randy --
May 21, 1:50 pm 2008
Jesper Juhl
Re: fork: Resource temporarily unavailable / cant start ...
2008/5/21 mark <markkicks@gmail.com>: What about if you run 'dmesg'? are there any clues in that output? any kernel stack traces? error messages? warnings? anything out of the ordinary? -- Jesper Juhl <jesper.juhl@gmail.com> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html --
May 21, 2:15 pm 2008
Randy Dunlap
Re: fork: Resource temporarily unavailable / cant start ...
1.56 0.58 0.27 2/203 28500 It's the number following the '/', e.g., 203 on my desktop system. max_threads allowed is a sysctl, so you can tune it if needed. 32624 I can send you some debug patches that will print out the specific problem area. Do you want to do that? Can you rebuild and install --- ~Randy --
May 21, 2:32 pm 2008
mark
Re: fork: Resource temporarily unavailable / cant start ...
cat /proc/loadavg 0.39 0.45 0.57 1/1412 12032 cat /proc/sys/kernel/threads-max 274432 Is it possible to get this debug messages by turning on some flags? If not yes, pl. send debug patches. its a live box and I will try to do it! This is my system / kernel info: uname -a Linux XXX 2.6.25.3-18.fc9.x86_64 #1 SMP Tue May 13 04:54:47 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux thanks a lot!!!! --
May 21, 3:51 pm 2008
mark
Re: fork: Resource temporarily unavailable / cant start ...
as a user how do i identify what is wrong, and fix this? for total number of threads -> is there anyway i can find out if this is causing the problem? my system is running around 80 multi-threaded python web Yes. i get this error when i restart the web server. if i kill all other apps, and then start it again it starts fine. this is the complete error message, 2008/05/21 08:02:19 [emerg] 30558#0: setuid(500) failed (11: Resource temporarily unavailable) 2008/05/21 08:02:19 [alert] ...
May 21, 2:08 pm 2008
Johannes Weiner May 21, 1:39 pm 2008
mark
Re: fork: Resource temporarily unavailable / cant start ...
No, it is around 400 ps ax | wc -l 417 I also I increased max process to unlimited, and I still get the error randomly.. ulimit -u unlimited my webserver is now throwing this error: setuid(500) failed (11: Resource temporarily unavailable) cat /etc/passwd | grep mark mark:x:500:500::/home/mark:/bin/bash I also increased this, but still the same error kernel.pid_max = 65536 --
May 21, 1:39 pm 2008
David Brownell
Re: [patch] provide rtc_cmos platform device
Well, "regression" is the wrong phrase. You've switched drivers (from the legacy RTC to the new one), so this is not the thing which worked for you before. Nonetheless, this should get fixed soonish; it just happens to be something nobody reported before. See two comments about patch brokenness below, though ... If I had realized there was a "pnpacpi=off" option, I'd have sent in my patch addressing this problem way back when the rtc-cmos code merged! I was deluded into thinking this ...
May 21, 4:05 pm 2008
Andrew Morton
Re: [patch] provide rtc_cmos platform device
On Tue, 20 May 2008 22:25:56 +0400 Albeit a fairly obscure one. I tagged the patch for backporting, let I suppose that on this basis: arch/x86/kernel/rtc.c | 31 +++++++++++++++++++++++++++++++ drivers/rtc/rtc-cmos.c | 26 +++++++++----------------- include/asm-x86/rtc.h | 4 ++++ it should be considered an x86 patch. I shall treat it as such. Thanks. --
May 21, 3:32 pm 2008
Peter Zijlstra
Re: /proc/lock_stat "stuck"
Did you get lockdep warnings? Those disable all lock debugging, including lockstat. --
May 21, 2:16 am 2008
Peter Zijlstra
Re: /proc/lock_stat "stuck"
You might like to 'test' these two patches :-) Subject: lockstat: warn about disabled lock debugging From: Peter Zijlstra <a.p.zijlstra@chello.nl> Avoid confusion and clearly state lock debugging got disabled. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> --- kernel/lockdep_proc.c | 4 ++++ 1 file changed, 4 insertions(+) Index: linux-2.6/kernel/lockdep_proc.c =================================================================== --- ...
May 21, 4:29 am 2008
Alan D. Brunelle
Re: /proc/lock_stat "stuck"
Hi Peter - Yesterday, during boots I /was/ getting a problem with NVIDIA ck804xrom registration problems - "Unable to register resource" - it did produce a stack trace w/ lock calls in the stack. Since then I've cut /way/ back on my .config, and I don't see that problem anymore, and the lock stats seem to be updating correctly with this new .config. [If I have time later today, I'll go back to the old .config and try to track down the ck804xrom issue.] Thanks for the hint about watching ...
May 21, 4:09 am 2008
Peter Zijlstra
Re: [RFC][PATCH 0/3] configfs: Make nested default group ...
Why doesn't sysfs have this problem? - the code says configfs was derived from sysfs. Also, do you really need to hold all locks when removing something? sound like a bit overdone. Also realise there is a maximum number of held locks - various people have already requested it to be increased or made dynamic. We're reluctant in doing so because we feel lock chains should not be of unlimited length. The deeper the chains the bigger the PI overhead etc.. As to modifying lockdep - it currently ...
May 21, 3:59 am 2008
Peter Zijlstra May 21, 2:23 am 2008
Louis Rilling
Re: [RFC][PATCH 0/3] configfs: Make nested default group ...
Perhaps because sysfs is driven from the kernel, where behaviors can be I did not write configfs, so I can only observe that a whole inode tree is locked when removing a directory hierarchy. I suspect that this is intended to provide userspace and client sub-systems with some atomic That was my guess. -- Dr Louis Rilling Kerlabs Skype: louis.rilling Batiment Germanium Phone: (+33|0) 6 80 89 08 23 80 avenue des Buttes de Coesmes http://www.kerlabs.com/ 35700 Rennes --
May 21, 5:54 am 2008
Louis Rilling
Re: [RFC][PATCH 0/3] configfs: Make nested default group ...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks for pointing this out. Yes this could solve part of the issue, at the price of duplicating the inode mutex class. However, this still does not solve the issue when deleting config_groups, since in that case all nodes of the tree are locked. Thinking about adding lockdep support for concurrent locking of the direct children of a node in a tree... Louis - -- Dr Louis Rilling Kerlabs Skype: louis.rilling Batiment ...
May 21, 3:25 am 2008
Peter Zijlstra
Re: [RFC][PATCH 0/3] configfs: Make nested default group ...
Also bear in mind that the lock_class_key structure must be in static storage. --
May 21, 2:20 am 2008
Louis Rilling
Re: [RFC][PATCH 0/3] configfs: Make nested default group ...
Sorry for answering late, it seems that we are working in very different timezones :) The former approach limits the level of recursion, but also the total number of default groups (whole tree) under a created config_group. I Note that I keep lockdep on for the first level of recursion, which lets I can do this. However, the original approach should be modified since I_MUTEX_CHILD + 1 == I_MUTEX_XATTR and I_MUTEX_CHILD + 2 == I_MUTEX_QUOTA. For instance we could redefine ...
May 21, 1:13 am 2008
Joel Becker
Re: [RFC][PATCH 0/3] configfs: Make nested default group ...
sysfs objects are created from kernel code. Things register kobjects one at a time, so it has the usual parent->child dentry relationships. This is handled by I_MUTEX_PARENT/CHILD just fine. configfs item creation is triggered from userspace. mkdir(2) creates an item in a group. If that item is a group itself, it can have child groups that automatically exist ("default_groups"). All of the default_groups must appear before the userspace-invoked mkdir(2) returns. Worse, rmdir(2) must ...
May 21, 3:09 pm 2008
Ingo Molnar
Re: [patch] fix build error in drivers/media/video/cx238 ...
thanks, this too solves the build problem. Tested-by: Ingo Molnar <mingo@elte.hu> Ingo --
May 20, 11:29 pm 2008
Arjan van de Ven
Re: [PATCH] [2/11] Add unlocked_fasync
On Wed, 21 May 2008 01:35:21 +0200 yes exactly --
May 20, 9:47 pm 2008
Clemens Ladisch
Re: [PATCH] [9/11] Convert hpet to unlocked_fasync
Acked-by: Clemens Ladisch <clemens@ladisch.de> --
May 21, 2:01 am 2008
Dave Airlie
Re: [PATCH] [7/11] Convert DRM to unlocked_fasync
Acked-by: Dave Airlie <airlied@linux.ie> unless you want me to take it via my tree. --
May 20, 11:36 pm 2008
Pavel Machek
i8259.c: remove #ifdefs around includes
Remove #ifdefs around includes; including too much should be always safe. Signed-off-by: Pavel Machek <pavel@suse.cz> --- commit 06f12eb6da33da70dbdccbee5a687d5353782e1d tree 62b9b1a785bbc5a9daa22512ec95601d54aa004d parent 44b4ec2247971ba1a1906752208182146fc5974c author Pavel <pavel@amd.ucw.cz> Wed, 21 May 2008 11:46:46 +0200 committer Pavel <pavel@amd.ucw.cz> Wed, 21 May 2008 11:46:46 +0200 arch/x86/kernel/i8259.c | 11 ----------- 1 files changed, 0 insertions(+), 11 ...
May 21, 2:47 am 2008
Pavel Machek
Automatical unification of i8259.c
Make conversion of i8259 very mechanical -- i8259 was generated by diff -D, with too different parts left in i8259_32 and i8259_64.c. Only "by hand" changes were removal of #ifdef from middle of the comment (prevented compilation) and removal of one static to allow splitting into files. Of course, it will need some cleanups now, and those will follow. Signed-of-by: Pavel Machek <pavel@suse.cz> diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile index 5e618c3..f71a76e ...
May 21, 2:44 am 2008
Pavel Machek
i8259.c: remove trivial ifdefs
Remove #ifdefs where the only difference is formatting of comments. Signed-off-by: Pavel Machek <pavel@suse.cz> --- commit 800e1add46a2686995af98432a7971150318676d tree 5daa71306ceb60b0fb7e5707ec4d9701c06197de parent 06f12eb6da33da70dbdccbee5a687d5353782e1d author Pavel <pavel@amd.ucw.cz> Wed, 21 May 2008 11:52:11 +0200 committer Pavel <pavel@amd.ucw.cz> Wed, 21 May 2008 11:52:11 +0200 arch/x86/kernel/i8259.c | 20 +++----------------- 1 files changed, 3 insertions(+), 17 ...
May 21, 2:52 am 2008
Pavel Machek
i8259: cleanup codingstyle
i8259: trivial codingstyle cleanup. Signed-off-by: Pavel Machek <pavel@suse.cz> --- commit 3333c67ab415a0debec8e178c563e81b49f73bf9 tree 9f868e4422e7d58bfe398541335b8574ea4c11ee parent 800e1add46a2686995af98432a7971150318676d author Pavel <pavel@amd.ucw.cz> Wed, 21 May 2008 11:57:12 +0200 committer Pavel <pavel@amd.ucw.cz> Wed, 21 May 2008 11:57:12 +0200 arch/x86/kernel/i8259.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/i8259.c ...
May 21, 2:57 am 2008
Michael Kerrisk
Re: [PATCH 1/8] Scaling msgmni to the amount of lowmem
Nadia, I think for the moment it might be best to revert that change, since there's no actual need to change things. I've updated the man page to say that this value is in kibibytes. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html --
May 21, 3:47 am 2008
Yinghai Lu
Re: aperture_64: use symbolic constants
can you change the titile? YH --
May 20, 6:59 pm 2008
Andi Kleen
Re: aperture_64: use symbolic constants
That's actually not needed. The IOMMU code was carefully written to not require AGP. The only requirement it has is that if AGP is enabled it has to be built in. -Andi --
May 20, 6:23 pm 2008
Maciej W. Rozycki
Re: RTC subsystem and 11 min rtc update
See the recent discussion around my proposal: http://www.ussg.iu.edu/hypermail/linux/kernel/0805.1/1772.html I am about to update some of the architecture bits in arch/mips/sibyte, but otherwise the patchset is ready to go. Feel free to join the discussion and/or update your platform to make use of the generic rtc_read_persistent_clock() and rtc_update_persistent_clock() functions. Testing is always welcome too. Maciej --
May 21, 3:18 pm 2008
Philippe De Muyter
RTC subsystem and 11 min rtc update
Hello everybody, I have linux-2.6.25-rc6 running on a board with an i2c rtc chip, and synchronized to a ntp server. When my board starts, the current time is correctly read from the rtc chip, but ... I noticed that my rtc chip does not get updated by the kernel every 11 min, on my powerpc board, just like it would be on all other architectures. Paul Mackerras told me that that is now supposed to be done by the code inside #ifdef CONFIG_GENERIC_CMOS_UPDATE in kernel/time/ntp.c. I agree ...
May 21, 2:57 pm 2008
Andrew Morton
Re: [PATCH] serial: fix enable_irq_wake/disable_irq_wake ...
On Mon, 19 May 2008 20:11:41 -0700 erp, is that the easiest way of going from a uart_driver* to a device*? Doing a lookup each time is a bit unusual. --
May 21, 2:53 pm 2008
gshan
Re: PIIX4 DMA Timeout
Maciej, thank you very much for your reply. I don't think this was caused by interrupt routing. I added lots of "printk" before following output, and saw interrupts could be triggered correctly. hdc: 195371568 sectors (100030 MB) w/7539KiB Cache, CHS=16383/255/63, UDMA(33) LynxOS has been run successfully on this board, and we want port it to Linux recently. I'm not sure which resource (I/O or Memory space) should be used for DMA operation because all memory resources haven't been set (the ...
May 20, 6:08 pm 2008
Maciej W. Rozycki
Re: PIIX4 DMA Timeout
As I wrote, that was a restriction that did not affect PIO operation. IIRC, you had to wire IDE interrupt lines to motherboard interrupt (MIRQ) lines of the south-bridge rather than regular IRQ14/15 lines and then route them to IRQ14/15 inputs of the embedded slave 8259A core via some internal interrupt routing register for DMA to work correctly. PIO worked just fine either way, because the interrupts were delivered to the CPU after all, but some internal logic of the IDE adapter used them ...
May 20, 7:37 pm 2008
Tom Spink
Re: UML fails to locate address space
Hi Jeff, Here is the revised version - I cheered Dijkstra up by getting rid of that goto. -- Tom -- From: Tom Spink <tspink@gmail.com> Date: Wed, 21 May 2008 00:53:54 +0100 Subject: [PATCH] Locate the bottom of the address space This patch makes os_get_task_size locate the bottom of the address space, as well as the top. This is for systems which put a lower limit on mmap addresses. It works by manually scanning pages from zero onwards until a valid page is found. Because the ...
May 21, 5:02 am 2008
Tom Spink
Re: UML fails to locate address space
Oh No! I forgot to get rid of those nasty includes.... Take 2.... -- Tom -- From: Tom Spink <tspink@gmail.com> Date: Wed, 21 May 2008 00:53:54 +0100 Subject: [PATCH] Locate the bottom of the address space This patch makes os_get_task_size locate the bottom of the address space, as well as the top. This is for systems which put a lower limit on mmap addresses. It works by manually scanning pages from zero onwards until a valid page is found. Because the bottom of the address space ...
May 21, 5:04 am 2008
Jeff Dike
Re: UML fails to locate address space
Actually, since the search for the lowest valid page needs to be there anyway, I think we should just always use it, and not bother with /proc/sys/vm/mmap_min_addr at all. Less code, and the new code is more heavily exercised this way. Jeff -- Work email - jdike at linux dot intel dot com --
May 20, 6:58 pm 2008
Tom Spink
Re: UML fails to locate address space
Awesome! Thanks for your help, Jeff. -- Tom Spink --
May 21, 12:01 pm 2008
Jeff Dike
Re: UML fails to locate address space
You don't seem to have followed the thread. For UML, the address isn't a hint - it's a requirement. Tossing random numbers into your code until a particular test works isn't really the way to go. In this case, we are looking at mmap_min_addr being set at 0x10000, but which may be set to 0x20000 someplace else. Jeff -- Work email - jdike at linux dot intel dot com --
May 20, 7:15 pm 2008
Jeff Dike
Re: UML fails to locate address space
This is actually supposed to return the address space top, not the size, so I changed the name and return value accordingly. Other than that, this is fine. The final result is below... Jeff -- Work email - jdike at linux dot intel dot com From: Tom Spink <tspink@gmail.com> This patch makes os_get_task_size locate the bottom of the address space, as well as the top. This is for systems which put a lower limit on mmap addresses. It works by manually scanning pages ...
May 21, 10:58 am 2008
Yasunori Goto
Re: [PATCH] memory hotplug: fix early allocation handling
Looks good to me. Thanks. -- Yasunori Goto --
May 21, 12:29 am 2008
Uwe
Re: [PATCH 00/03][RFC] Reusable UIO Platform Driver
I would prefer the latter, because my patch already has acks and is complete as such. Moreover your suggestion needs the irq_enable patch. Best regards Uwe -- Uwe Kleine-König, Software Engineer Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962 --
May 21, 5:09 am 2008
Paul Mundt
Re: [PATCH 00/03][RFC] Reusable UIO Platform Driver
Physically contiguous memory is a real requirement, especially for DMA. I'm not sure what's confusing about that? --
May 21, 12:49 am 2008
Magnus Damm
Re: [PATCH 01/03] uio: Add enable_irq() callback
We can most likely use a single uio platform driver if this patch is acceptable. Any NAKs? Thanks, / magnus --
May 21, 4:58 am 2008
Uwe
Re: [PATCH 00/03][RFC] Reusable UIO Platform Driver
... if both info->handler and info->prep_read_poll are NULL and I'm not sure that solving that problem in uio_pdrv is the right approach. Other uio drivers might have the same problem, so better allow the userspace driver to allocate some memory in a more generic Assume your irq is stuck at its active level. Normally the irq is then disabled after some time. You can handle that in your userspace driver, but with acking in kernel space and returning IRQ_NONE or IRQ_HANDLED you get it for free. ...
May 21, 4:04 am 2008
Magnus Damm
Re: [PATCH 00/03][RFC] Reusable UIO Platform Driver
Hi Uwe! Thanks for your email. On Wed, May 21, 2008 at 3:49 PM, Uwe Kleine-König Most UIO kernel drivers today contain hardware device specific code to acknowledge interrupts. In other words, most UIO interrupt handlers touches some device specific bits so the interrupt gets deasserted. My uio_platform driver handles interrupts in a different way. The kernel UIO driver is not aware of the hardware device specific method to acknowledge the interrupt, instead it simply disables the ...
May 21, 1:09 am 2008
Magnus Damm
Re: [PATCH 00/03][RFC] Reusable UIO Platform Driver
On Wed, May 21, 2008 at 8:04 PM, Uwe Kleine-König I don't think there is any generic way for a user space driver to allocate physically contiguous memory. If such way exists then we Ok, so normally if the irq is stuck as asserted then it gets disabled after some time. In my case it gets disabled directly so see it as a feature. =) Would you like to fold in the irq_handler and irq_enable function in your patch, or would you like me to make a patch that fits on top of your latest ...
May 21, 4:56 am 2008
Magnus Damm
Re: [PATCH 00/03][RFC] Reusable UIO Platform Driver
Hi Hans! The uio_pdrv driver doesn't do what I need at this point, though I may be able to extend it with the following: - Interrupt enable/disable code - Physically contiguous memory support The interrupt code may be placed in the board/cpu code, but I need to share that code between multiple UIO driver instances. We want to use the same UIO driver for many different processor models and hardware blocks. Extending uio_pdrv driver with a chunk of physically contiguous memory isn't a big ...
May 20, 8:31 pm 2008
Uwe
Re: [PATCH 00/03][RFC] Reusable UIO Platform Driver
Hello, Yes it does. I thought the physical address is stored in internal_addr and the virtual in addr, but it's the other way round. Thanks. Best regards Uwe -- Uwe Kleine-König, Software Engineer Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962 --
May 21, 1:50 am 2008
Uwe
Re: [PATCH 00/03][RFC] Reusable UIO Platform Driver
Hello Magnus, What about adding uio_platform_handler (with a different name) to uio_pdrv.c? OTOH I don't see why you want to disable the irq. Can you describe the I wonder how you use that memory. Isn't it just some kind of shared memory? If so, why not use normal shared memory? Do you really need That alone doesn't help. You need a struct device to register a uio In my eyes this isn't completly correct. Just the way you specify your handler is a bit different. You can pass a handler ...
May 20, 11:49 pm 2008
Magnus Damm
Re: [PATCH 00/03][RFC] Reusable UIO Platform Driver
On Wed, May 21, 2008 at 5:05 PM, Uwe Kleine-K=F6nig [Added Matsubara-san as CC] Sure, here is a little test program. Have a look at "uio_mem". The "address" member contains the physical address that can be used for bus mastering DMA. Compare that to "iomem" which is the pointer to the virtual memory area in user space. Hope this helps! / magnus
May 21, 1:22 am 2008
Uwe
Re: [PATCH 00/03][RFC] Reusable UIO Platform Driver
I got that, yes. The problem is I don't see how you can use it for DMA. The physical address is stored in info->mem[$last].internal_addr and if there is a way to access that variable from user space, I don't see it and would appretiate a hint. Sorry for not expressing my concern more clear at the first go. I hope it's understandable now. @Magnus: Maybe you can provide the userspace part of the driver? How is that mapping used there? Best regards Uwe -- Uwe Kleine-König, Software ...
May 21, 1:05 am 2008
Uwe
Re: [PATCH 00/03][RFC] Reusable UIO Platform Driver
Just add irq_disabled to struct uio_platdata and define irqreturn_t uio_pdrv_disirq(int irq, struct uio_info *dev_info) { struct uio_platdata *pdata = container_of(dev_info, struct uio_platdata, uio_info); disable_irq(irq); pdata->irq_disabled = 1; return IRQ_HANDLED; } EXPORT_SYMBOL(uio_pdrv_disirq); void uio_pdrv_enirq(struct uio_info *dev_info) { ... } EXPORT_SYMBOL(uio_pdrv_enirq); and then you can do info->handler = uio_pdrv_disirq; info->enable_irq = ...
May 21, 2:25 am 2008
Magnus Damm
Re: [PATCH 00/03][RFC] Reusable UIO Platform Driver
On Wed, May 21, 2008 at 6:25 PM, Uwe Kleine-König I understand now. Thanks for the clear description. What about letting the uio_pdrv code override info->handler and info->enable_irq with the above functions if info->handler is NULL? That would be one step closer to a shared driver in my opinion. And it would remove the need for symbol exports and solve the static-compile-only issue. The physically contiguous memory issue still needs to be solved somehow though. What about using struct ...
May 21, 3:50 am 2008
Henrique de Moraes H ...
Re: Accelerometer, Gyros and ADC's etc within the kernel.
Agreed. I have put some thought on it in the past, and while the input subsystem is the only thing even remotely usable for this *right now*, a new subsystem for data acquisition would be the best way forward. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --
May 21, 7:09 am 2008
Jonathan Cameron
Re: [spi-devel-general] Accelerometer, Gyros and ADC's e ...
That's certainly interesting and I guess one of the easiest ways of getting data from spi to a desktop machine. I'll admit my interest is more with embedded Yes, and that means we would use the delights of platform data and the generic gpio subsystem. Although I believe generic gpio isn't available on every platform as yet, it is getting there and is certainly in place for ARM (and Yes, the intention would not be to generalize the hardware comms, but rather the interface on the user side. ...
May 21, 2:40 am 2008
Dmitry Torokhov
Re: Accelerometer, Gyros and ADC's etc within the kernel.
I don't think that input subsystem woudl be the best choice. While we do support the event-driven mechanism for delivering information to userspace input is mostly oriented for human interface devices, not general data acquisition. If anything input_dev is too fat. Another thing is that input layer anonymizes input devices, makes them capability-oriented. I.e. we dont really care what model of joystick we have, we want something that reports ABS_X, ABS_Y, BTN_FIRE and userpsace can use it ...
May 21, 6:49 am 2008
Jean Delvare
Re: Accelerometer, Gyros and ADC's etc within the kernel.
Note that hardware monitoring chips can include ADCs and DACs: the former to monitor system voltages, and the later to control fans (most chips use PWM for that but a few use DACs.) ADCs and DACs are, much like GPIOs, usable for a variety of different purposes. I doubt that there would be any benefit in abstracting DACs and ADCs the way we did for GPIOs, but the important point here is that we really want to group the drivers according to their functionality and not technical implementation ...
May 21, 6:20 am 2008
Jonathan Cameron
Re: Accelerometer, Gyros and ADC's etc within the kernel.
Hi Hans and Jean, Hmm.. Going to be interesting coming up with a name! Guess that can come at a Definitely agreed that it makes sense to put DACs and ADCs in the same general place It would indeed by stretching the point to make drivers in that subsystem have more performance critical drivers! We seem to have a consensus that neither hwmon or Although I don't know much about the input subsystem it doesn't seem likely that all the devices we are considering would share all that much ...
May 21, 3:04 am 2008
Greg KH
Re: [PATCH 2/3][-mm] reclassify the sg_sysfs_class mutex
I do not know, there might be in the future. thanks, greg k-h --
May 20, 9:37 pm 2008
Dave Young
Re: [PATCH 2/3][-mm] reclassify the sg_sysfs_class mutex
I don't think it necessary to do this for every class, because only class_interface_* calls could cause the issue, and the class_interface_* are only used by pcmcia & scsi, do you think there --
May 20, 6:25 pm 2008
Dave Young
Re: [PATCH 1/3][-mm] add class_reclassify macro
On Wed, May 21, 2008 at 3:23 AM, Andrew Morton --
May 20, 7:05 pm 2008
Jan Engelhardt
Re: [PATCH] [.gitignore] match ncscope.out
Unless you know there is acscope, bcscope, etc. I'd rather add just ncscope.* instead of the catches-more *cscope.*. --
May 21, 1:47 pm 2008
Jianjun Kong
Re: [PATCH] [.gitignore] match ncscope.out
Yes, there is also another two files, ncscope.in.out and ncscope.po.out kongove@ubuntu:~/git/linux-2.6$ git commit -a # On branch master # Untracked files: # (use "git add <file>..." to include in what will be committed) # # ncscope.in.out # ncscope.po.out -- | Feel Earthquake, Feel Fright! | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | Jianjun Kong | www.kongove.cn | Xi'an Institute of Post & Telecommunications --
May 20, 11:29 pm 2008
Rami Rosen
Re: [PATCH net-2.6] [NET] The world is not perfect patch.
Hi, Unless there will be any objection here, I suggest consider the following patch which simply removes the code for the -DI_WISH_WORLD_WERE_PERFECT in the three methods which use it. The compilation errors we get when using -DI_WISH_WORLD_WERE_PERFECT show that this code was not built and not used for really a long time. Regards, Rami Rosen Signed-off-by: Rami Rosen <ramirose@gmail.com>
May 21, 12:33 am 2008
Hirokazu Takahashi
Re: [RFC][PATCH 2/3] memcg:: seq_ops support for cgroup
I also hope it! Now I'm working on dm-ioband --- I/O bandwidth controller --- and making it be able to work under cgroups. I realized it is quite hard to set some specific value to each block device because each machine has various number of devices and then some of them are hot-added or hot-removed. So I hope CGROUP will support some method to handle hot-pluggable --
May 21, 6:08 am 2008
KAMEZAWA Hiroyuki
Re: [RFC][PATCH 2/3] memcg:: seq_ops support for cgroup
On Tue, 20 May 2008 11:46:46 -0700 With current interface, my concern is hotplug. File-per-node method requires delete/add files at hotplug. A file for all nodes with _maps_ method cannot be used because maps file says == The key/value pairs (and their ordering) should not * change between reboots. == And (*read) method isn't useful ;) Can we add new stat file dynamically ? Thanks, -Kame --
May 20, 5:28 pm 2008
KAMEZAWA Hiroyuki
Re: [RFC][PATCH 2/3] memcg:: seq_ops support for cgroup
On Tue, 20 May 2008 22:06:48 -0700 For making the kernel simple, one-file-per-entity(cpu/node...) is better. For making the applications simple, one big file is better. I think recent interfaces uses one-file-per-entity method. So I vote for it for this numastat. One concern is size of cpu/node. It can be 1024...4096 depends on environment. open/close 4096 files took some amount of cpu time. (And that's why 'ps' command is slow on big system.) Thanks, -Kame --
May 20, 11:06 pm 2008
Paul Menage
Re: [RFC][PATCH 2/3] memcg:: seq_ops support for cgroup
On Tue, May 20, 2008 at 5:28 PM, KAMEZAWA Hiroyuki OK, so we may need to extend the interface ... The main reason for that restriction (not allowing the set of keys to change) was to simplify and speed up userspace parsing and make any future binary API simpler. But if it's not going to work, we can maybe Yes, there's no reason we can't do that. Right now it's not possible to remove a control file without deleting the cgroup, but I have a patch that supports removal. The question is ...
May 20, 10:06 pm 2008
Mike Galbraith May 20, 10:19 pm 2008
Zhang, Yanmin
Re: hackbench regression with 2.6.26-rc2 on tulsa machine
Yes. CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_USER_SCHED=y I reran the test for dozeons of times. 1) Background processes have impact on the result and cause result to fluctuate with 8~9 seconds; 2) After turning off most services (background processes), the result looks stable; 3) I tested both 2.6.26-rc1 and 2.6.26-rc2 with CONFIG_GROUP_SCHED=n. the first one's result is about 30 seconds and the second one's result is about 31 seconds. So ...
May 20, 9:54 pm 2008
Andrew Morton
Re: + pcmcia-add-support-the-cf-pcmcia-driver-for-blackf ...
On Tue, 20 May 2008 20:41:13 -0400 Well I made that change, but this all has a rather untested feeling to it. --
May 21, 4:11 pm 2008
Mike Frysinger
Re: + pcmcia-add-support-the-cf-pcmcia-driver-for-blackf ...
both will work with Blackfin toolchains, the latter form is obviously preferred -mike --
May 21, 4:23 pm 2008
Mike Frysinger
Re: + pcmcia-add-support-the-cf-pcmcia-driver-for-blackf ...
On Tue, May 20, 2008 at 4:02 AM, Andrew Morton it should be defined(__bfin__) at least. perhaps i should add that check to checkpatch.pl as well ... -mike --
May 20, 5:41 pm 2008
Mike Frysinger
Re: + pcmcia-add-support-the-cf-pcmcia-driver-for-blackf ...
please add a common statement that tells you the module name if the u_int forms are weird ... i'd wonder why we have these variations i dont think that MAX_BLACKFIN_GPIOS check is needed. the we dont call gpio_free() here or in the fail0 case below. -mike --
May 21, 4:34 pm 2008
Bryan Wu
Re: b4aa54d951d38d7a989d6b6385494ef5ea7371d7 breaks some ...
IMO, we need to revert this 8250 irq patch. Can we fix this just in Blackfin code? I found it was specific for our arch not for others. --
May 20, 11:38 pm 2008
Javier Herrero
Re: b4aa54d951d38d7a989d6b6385494ef5ea7371d7 breaks some ...
Perhaps then, at least for now, in order to quickly restore the functionality of the driver with other platforms and to continue having the 8250 support in the blackfin, would be to apply this patch, that is a bit ugly but at least only affects to blackfin platforms using 8250-class uarts :) Regards, Javier -- ------------------------------------------------------------------------ Javier Herrero EMAIL: jherrero@hvsistemas.com HV Sistemas S.L. ...
May 20, 10:45 pm 2008
Mike Galbraith
Re: 2.6.24.7-rt8
Ahem. Attach the data _before_ poking xmit.
May 20, 11:27 pm 2008
Mike Galbraith
Re: 2.6.24.7-rt8
Hi Steven, I ran mysql+oltp (ro) on 2.6.24.7-rt7 and 2.6.25-rt2 to compare throughput to their parent trees, and ended up with strange (and verified) looking performance curves for both trees. The changes in 2.6.24.7-rt8 and 2.6.25.4-rt3 cured the primary oddities. (it looks to me like there may be a little load-balancing issue, peak throughput isn't where it should be for my Q6600 box) -Mike --
May 20, 11:25 pm 2008
Steven Rostedt
Re: 2.6.24.7-rt8
The difference between 24-rt7 and 24-rt8 as well as with 25-rt2 and 25-rt3 is the deserialization of rwlocks. The rt patch as always serialized readers to allow for priority inheritance with rwlocks. I wrote a patch to break that and allow for multiple readers and still keep the priority inheritance. Your test probably had a bottle neck on a rwlock (same for rwsems) somewhere that the new code solved. -- Steve --
May 21, 5:47 am 2008
Rene Herman
Re: [X86] Add a boot parameter to force-enable PAT
It doesn't even apply for me. Moreover though -- __early_param() still seems to be too late for validate_pat_support() so this isn't going to work. __setup() is even later than that. I guess this just wants to set a flag Rene. --
May 20, 6:10 pm 2008
H. Peter Anvin
Re: [X86] Add recent Centaur CPUs to PAT whitelist
Question: are there any VIA CPUs that display the PAT CPUID flag that aren't covered by the above? -hpa --
May 21, 4:56 pm 2008
H. Peter Anvin
Re: [X86] Remove unnecessary code in 64bit CPU identification.
Hi Dave, I was going to pull this into -tip, but I need a Signed-off-by: line in order to do so. Could you resend this so we can add it to -tip? -hpa --
May 21, 4:55 pm 2008
Luca Tettamanti
Re: [BISECTED] pata_jmicron: no drives found on post 2.6 ...
T24gV2VkLCBNYXkgMjEsIDIwMDggYXQgMTA6NTggQU0sIFNoYW9odWEgTGkgPHNoYW9odWEubGlA aW50ZWwuY29tPiB3cm90ZToKPiBPbiBUdWUsIDIwMDgtMDUtMjAgYXQgMTk6MDkgKzAzMDAsIFBs YW1lbiBQZXRyb3Ygd3JvdGU6Cj4+IFNoYW9odWEgTGkg0L3QsNC/0LjRgdCwOgo+Pgo+PiA+IE9u IFR1ZSwgMjAwOC0wNS0yMCBhdCAwMTozNyArMDMwMCwgUGxhbWVuIFBldHJvdiB3cm90ZToKPj4g Pj4gSGVsbG8sIGZvbGtzIQo+PiA+Pgo+PiA+PiBBZnRlciAyLjYuMjYgbWVyZ2Ugd2luZG93IG9w ZW5lZCwgdGhlIG9wdGljYWwgZHJpdmVzIGluIG15Cj4+ID4+IGNvbXB1dGVyLCBoYW5naW5nIG9m ZiBhIEpNaWNyb24gY29udHJvbGVyIHdlcmUgbm90 ...
May 21, 12:45 pm 2008
Plamen Petrov
Re: [BISECTED] pata_jmicron: no drives found on post 2.6 ...
With the provided patch applied on top of latest git tree, the optical drive connected to the JMicron controller WORKS with CONFIG_PCIEASPM=y. Just in case - this is on a Gigabyte GA-P35-DS3R v2.1 motherboard, BIOS F11. Thanks! Plamen Petrov, network & system administrator Filial - Silistra RU "Angel Kantchev" http://fs.ru.acad.bg/ -------------------------------- this message is UTF8 encoded _ ___ _____ ------------------------------------------ This message was sent by ...
May 21, 8:49 am 2008
Shaohua Li
Re: [BISECTED] pata_jmicron: no drives found on post 2.6 ...
Can you please try below patch? The Slot 03:00.* of JMicron controller has two functions, but one is PCIE endpoint the other isn't PCIE device, very strange. PCIE spec defines all functions should have the same config for ASPM, so disable ASPM for the whole slot in this case. Signed-off-by: Shaohua Li <shaohua.li@intel.com> Index: linux/drivers/pci/pcie/aspm.c =================================================================== --- linux.orig/drivers/pci/pcie/aspm.c 2008-05-21 ...
May 21, 1:58 am 2008
Jan Engelhardt
Re: Modern 2.6 kernels - Notification for changing hostn ...
Then these should be resolved. Sometimes, even setting just the time with ntpdate makes X go blank for a few seconds, or even exit. --
May 21, 2:38 am 2008
Soumyadip Das Mahapatra
Re: [PATCH 1/2] bitreversal program
Sorry to disturb you again. But i tested my code against Akinobu's one and the test result shows my code takes less cpu time than that of Akinobu's. Here is the code i used to determine performance -- #include<stdio.h> #include<time.h> int main() { int i = 100000000; printf("%ld\n", (long)clock()); for(; i>0; i--) { bitrev32(0x00face32); } printf("%ld", (long)clock()); } -- OUTPUT: [using Akinobu's bitrev32()] 0 6010000 [using my bitrev32()] 0 3990000 And ...
May 21, 1:54 am 2008
Rene Herman
Re: [PATCH 1/2] bitreversal program
The unfortunate thing about these kinds of changes is that they're not all that easily tested. Straightforwardness would suggest that obviously the current table driven method will be faster due to needing fewer code cycles. Cache considerations add to that in the sense of instruction cache and can (!) detract from it in the sense of data cache; sometimes dramaticaly detract due to cache misses basically dwarving most anything else. However, in this case the table is a tiny 256-byte one ...
May 21, 4:11 am 2008
Benoit Boissinot
Re: [PATCH 1/2] bitreversal program
I'm using a core duo 1.2GHz, if you want to play with the code, I'm attaching a tarball (it's hackish, just change the #include at the top of bitrev.h to switch implementation). I'm using gcc -Wall -O3 to compile with gcc 4.2.3. regards, Benoit
May 21, 2:11 am 2008
Tilman Schmidt
Re: [PATCH 1/2] bitreversal program
bitrev8() is used on every transferred byte for certain types of ISDN connections, ie. with a steady rate of 8000 bytes/sec. Depending on the driver, it will be called for individual data bytes or possibly a small number of bytes at a time, typically not more than 64, and typically in interrupt context. I'd expect the table driven version to perform better in those circumstances. Thanks, Tilman --=20 Tilman Schmidt E-Mail: tilman@imap.cc Bonn, Germany Diese ...
May 21, 9:52 am 2008
Andrew Morton
Re: [PATCH] Fixups to ATA ACPI hotplug
On Tue, 20 May 2008 15:58:30 +0200 Looks odd. I guess this: --- a/drivers/ata/libata-acpi.c~ata-acpi-hotplug-handle-bay-devices-in-dock-stations-cleanup +++ a/drivers/ata/libata-acpi.c @@ -128,7 +128,7 @@ static void ata_acpi_detach_device(struc ata_port_for_each_link(tlink, ap) ata_link_for_each_dev(tdev, tlink) - tdev->flags |= ATA_DFLAG_DETACH; + tdev->flags |= ATA_DFLAG_DETACH; } ata_port_freeze(ap); _ The old code was less odd ;) --
May 21, 3:26 pm 2008
Rusty Russell
Re: [PATCH 18/57] iTCO: unlocked_ioctl, coding style and ...
Well, it got some commentry on lkml, mainly from Christoph H. He was the one OK, I'll send a patch now. Thanks, Rusty. --
May 20, 9:58 pm 2008
Alan Cox
Re: [PATCH 18/57] iTCO: unlocked_ioctl, coding style and ...
The watchdog drivers all got the semaphores removed in the patch set I --
May 21, 2:29 am 2008
Andrew Morton
Re: [PATCH 18/57] iTCO: unlocked_ioctl, coding style and ...
Well, a simple patch which does /* * comment goes here */ static inline int __must_check down_nowait(struct semaphore *sem) { return !down_trylock(sem); } and which does not deprecate down_trylock() could go into mainline right now, (assuming that the overall concept doesn't get shot down in review - did it get reviewed?) Then you can start trickling stuff out to people straight away. --
May 20, 9:36 pm 2008
Rusty Russell
Re: [PATCH 18/57] iTCO: unlocked_ioctl, coding style and ...
I've been pulling out s/down_trylock/down_nowait/ patches which effect others' changes. Those patches get moved to the end of my queue, and I'll revisit them before an actual merge with Linus. As down_trylock still works (but marked deprecated) with my patches, they're fine to drop. Just tell me which ones... Hope that helps, Rusty. --
May 20, 9:26 pm 2008
Andrew Morton
Re: [ANNOUNCE] util-linux-ng 2.14-rc3
I think it would be useful to have a util-linux mention in the kernel's ./MAINTAINERS. We're rather joined-at-the-hip and you guys are a bit hard to find. If agreeable, please send a patch. Have you considered adding collectl to util-linux? If so, what was the outcome? Thanks. --
May 20, 7:17 pm 2008
Karel Zak
Re: [ANNOUNCE] util-linux-ng 2.14-rc3
The util-linux is a very basic system package and I'd like to avoid dependences on things like Perl. I don't see a problem to distribute collectl as a separate package. It seems that Mark is maintaining the package very successfully on sf.net. Karel -- Karel Zak <kzak@redhat.com> --
May 21, 2:05 am 2008
Maciej W. Rozycki
Re: [ANNOUNCE] util-linux-ng 2.14-rc3
Does collectl require Perl for building? If it has a run-time dependency only, then it does not really differ from chkdupexe and it is up to whoever makes a distribution to partition binary packages in a sensible way. Maciej --
May 21, 2:11 am 2008
Tom Spink
Re: [RFC PATCH] Introduce filesystem type tracking
Ready for another? <g> Here's another try, with Matthews suggestion of moving the mutex outside the spinlock. Again, I've used a wee stress test that tries to mount a toy filesystem many times, with random pauses in the init routines. It seems to pass this (and again I've seen quite a few interleavings of the calls), and a mental scan of the code paths leads me to believe the locking is correct. Thanks for putting up with me, guys! -- Tom -- From: Tom Spink ...
May 21, 7:49 am 2008
Jan Engelhardt
Re: [RFC PATCH] Introduce filesystem type tracking
The filesystem may want to have the superblock passed. Well, will see once a filesystem has the need for it. --
May 21, 2:42 am 2008
Peter Zijlstra
Re: [PATCH] consolidate all within() implementations
might be my braindamage, but I'd have written it like: static inline int addr_within_len(const void *addr, const void *start, size_t len) { return (unsigned long)addr - (unsigned long)start < len; } static inline int addr_within(const void *add, const void *start, const void *end) { return addr_within_len(addr, start, (unsigned long)end - (unsigned long)start); } --
May 21, 3:04 am 2008
Peter Zijlstra
Re: [PATCH] consolidate all within() implementations
peter@lappy:~/tmp$ cat cmp.c int within_len1(const void *addr, const void *start, unsigned long len) { return (unsigned long)addr - (unsigned long)start < len; } int within1(const void *addr, const void *start, const void *end) { return within_len1(addr, start, (unsigned long)end - (unsigned long)start); } peter@lappy:~/tmp$ cat cmp2.c int within_len2(const void *addr, const void *start, unsigned long len) { return ((unsigned long) addr ...
May 21, 3:48 am 2008
Peter 1 Oberparleiter
Re: [PATCH] consolidate all within() implementations
Yeah, but! [oberpar@local cmp]$ gcc -c -O2 cmp*.c [oberpar@local cmp]$ ls -la cmp*.o -rw-r--r-- 1 oberpar oberpar 1352 May 21 15:40 cmp2.o It really boils down to the question whether you want to trade a bit of obviousness for a bit of efficiency/clever programming. Why not plan for the unexpected when it comes at little cost? Regards, Peter --
May 21, 6:50 am 2008
Peter 1 Oberparleiter
Re: [PATCH] consolidate all within() implementations
Definitely another way to put it. In my opinion the intention of the implementation is more easily understood though when spelling it out For empty ranges (start > end), this produces different (less expected) results than the previous version. Regards, Peter --
May 21, 3:33 am 2008
Sergei Shtylyov
Re: [PATCH 4/9] Alchemy: register mmc platform device fo ...
Hello. Shouldn't the IRQ/DMA resources also have their 'end' field set? These 2 separate versions could be converted into single one by using the You don't have to explicitly set 'cd_setup' to NULL... PS: BTW, I've noticed that include/asm-mips/mach-db1x00/db1x00.h defines macros mmc_card_insterted() and mmc_power_on() which no code seems to be using (might have been intended for use by the MMC driver but why no such macros in other board headers?). Care to remove ...
May 21, 5:32 am 2008
Manuel Lauss
Re: [PATCH 4/9] Alchemy: register mmc platform device fo ...
Well, that's what my initial submission did, but it required access to the mmc drivers host structure (moved from au1xmmc.h to au1100_mmc.h) to determine The comment explains what setting to NULL does, so I'd like to keep it (for people implementing this for other boards and wondering what Sure, I'll add another patch to the pile. Thank you! Manuel Lauss --
May 21, 6:10 am 2008
Kamalesh Babulal
[BUG] linux-next: Tree for May 19/20/21 - BUG at arch/x8 ...
Hi Stephen, This kernel panic while booting up is reproducible with the next-20080519, next-20080520 and next-20080521 kernels. -- Thanks & Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. --
May 21, 10:26 am 2008
Henrique de Moraes H ...
Re: [PATCH 09/15] rfkill: add the WWAN radio type
Actually, I have no reason to believe there *isn't* a device with KEY_WIMAX... but we need the WWAN type before we bother with a WiMax type :-) IMO, we should fix the issue by adding a "supertype", i.e., a class. Use that for generic grouping, and let type be more specific when there is a reason for it. Repeat the class as the type to get a "generic" type, when there is no reason to bother with more specific types. Stuff like "WiMax", "802.1a", "EDGE", "GRPS", "802.1bg" would be the type, ...
May 20, 6:12 pm 2008
Henrique de Moraes H ...
Re: [PATCH 15/15] rfkill: document rw rfkill switches an ...
I'll take that as an ACK :-) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --
May 20, 6:44 pm 2008
Henrique de Moraes H ...
Re: [PATCH 09/15] rfkill: add the WWAN radio type
Then here's what you'd have with (class, type): EITHER 1. rfkill-input would manipulate based on class for a given input event. Therefore we would remove KEY_WIMAX from rfkill-input. OR... 2. rfkill-input would be teached to manipulate for classes (all switches in a class), and for (class,type) (hunt down all rfkill switches of that given type and class)... and it does mean KEY_WIMAX would only affect WiMAX switches, while WWAN would affect EDGE, GPRS, *WIMAX*, etc. And if you ...
May 21, 7:07 am 2008
Inaky Perez-Gonzalez
Re: [PATCH 09/15] rfkill: add the WWAN radio type
-EOPERATORISDUMB, sorry; I meant turn one off and the other on. -- Inaky --
May 20, 11:48 pm 2008
Inaky Perez-Gonzalez
Re: [PATCH 09/15] rfkill: add the WWAN radio type
BTW, I just realized this was mistakenly put in your initial patch; How would this apply to the case where I want to use the HW key to switch one off and turn the other one off (say I have both a WiMAX and EDGE cards in my machine); how could we do it to distinguish which key is which? I might be missing something. -- Inaky --
May 20, 8:35 pm 2008
Henrique de Moraes H ...
Re: [PATCH 09/15] rfkill: add the WWAN radio type
I don't understand. Switch one off and turn the other one off? Isn't that the same thing? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --
May 20, 8:42 pm 2008
rae l
Re: [PATCH] net/ipv4/arp.c: Use the exported hex_asc fro ...
From bc47e710a3ebd8a5989404f711a051b6516d01ed Mon Sep 17 00:00:00 2001 From: Denis Cheng <crquan@gmail.com> Date: Wed, 21 May 2008 09:43:32 +0800 Subject: [PATCH] net/ipv4/arp.c: Use common hex_asc helpers Here the local hexbuf is a duplicate of global const char hex_asc from lib/hexdump.c, except the hex letters' cases: const char hexbuf[] = "0123456789ABCDEF"; const char hex_asc[] = "0123456789abcdef"; and here to print HW addresses, the hex cases are not significant. Thanks to ...
May 20, 7:27 pm 2008
Borislav Petkov
Re: [PATCH 14/40] ide-floppy: merge idefloppy_transfer_p ...
... and also probably mv idefloppy_transfer_pc1() to something like idefloppy_start_transfer_pc() and rename idefloppy_transfer_pc2() to something more appropriate like e.g. idefloppy_do_transfer_pc() or similar and do away -- Regards/Gruß, Boris. --
May 20, 10:24 pm 2008
Ingo Molnar
Re: [PATCH] eCryptFS: fix missed mutex_unlock
btw., i didnt do any specific ecryptfs testing - randconfig enabled it and it got booted. So if you dont get the warning during bootup/module-load, you'll have the same test coverage i did. Ingo --
May 21, 1:02 am 2008
Cyrill Gorcunov May 21, 2:33 am 2008
Gabriel C
Re: [Bug #10648] CONFIG_PRINTK_TIME broken on git HEAD ?
Peter thx , it fixes the problem for me. Gabriel --
May 20, 6:10 pm 2008
Gabriel C
Re: [Bug #10648] CONFIG_PRINTK_TIME broken on git HEAD ?
Sorry for the lag , I'm gonna test this now and report back in a bit. Gabriel --
May 20, 5:38 pm 2008
Cyrill Gorcunov
Re: [RFC] x86: merge nmi_32-64 to nmi.c
well, here is a second version of patch attached (i'm in office now so can't use my lovely mutt as usual). Please take a look. Any objections are quite welcome! - Cyrill -
May 21, 12:41 am 2008
Roland McGrath
Re: [PATCH 2/3] signals: introduce SIGQUEUE_CANCELLED
I think to keep things easier to understand, we should say the rule is that touching q->flags is always controlled by siglock when q is on a queue. Before it's queued or after it's been dequeued (i.e. list_empty(&q->list) with siglock held), then the "owner" of the struct sigqueue of course needs noone's siglock. Thanks, Roland --
May 20, 7:24 pm 2008
Roland McGrath
Re: [PATCH 1/3] signals: sigqueue_free: don't free sigqu ...
Removing the entry without fixing the pending set is the bug we're trying to fix. That's what it does now, and it's wrong. Oleg had a patch that marked the sigqueue entry with whether it was on the shared queue or not. The caller in timer_delete knows which thread it is when it's on a thread queue, and whether it's on the shared queue. So it could be the caller's responsibility to know, i.e. its sigqueue_free call matches its send_sigqueue call. Thanks, Roland --
May 21, 12:33 pm 2008
Oleg Nesterov
Re: [PATCH 1/3] signals: sigqueue_free: don't free sigqu ...
Yes, yes, I meant doesn't change the behaviour in a sense that the OK, will do tomorrow, but... Oh well. I just realized SIGQUEUE_CANCELLED breaks sys_sigpending() ? Oleg. --
May 21, 4:54 am 2008
Roland McGrath
Re: [PATCH 1/3] signals: sigqueue_free: don't free sigqu ...
The timer_delete/sigqueue_free behavior predates my involvement with the code. I think it is fine to leave pending signals queued. (POSIX makes it unspecified for deleted timers. A robust application cannot even assume that they will or won't be removed consistently on one running system.) What I think everyone agrees is wrong in the abstract is the status quo, where (effectively) signals stay queued but with zeroed siginfo_t values. (This violates POSIX.) If there is a signal, its siginfo_t ...
May 21, 4:01 pm 2008
Linus Torvalds
Re: [PATCH 1/3] signals: sigqueue_free: don't free sigqu ...
I thought we didn't even know which queue it was pending on if it was already on a thread-local queue. So we could remove the entry, but I always objected to the games with the pending bit. Just removing the entry I'm ok with, it was the (pointless and misleading) use of recalc_sigpending() that started the whole discussion. The fact that we then also have that "which signal is pending" bit in front of the queue was something that came up later. Linus --
May 21, 11:49 am 2008
Linus Torvalds
Re: [PATCH 1/3] signals: sigqueue_free: don't free sigqu ...
Well, I think we could/should look at the bigger picture. The whole (and only!) reason for this problem in the first place is that the generic signal-handling code is simply not designed for signals going away. Because they simply don't. This whole sys_timer_delete() thing is purely based on that problem. So we have a few options here, I think. One is the approach that Oleg has taken, which is to try to remove the signals. Quite frankly, I don't much like it, because it's against ...
May 21, 1:07 pm 2008
Roland McGrath
Re: [PATCH 1/3] signals: sigqueue_free: don't free sigqu ...
> Oh well. I just realized SIGQUEUE_CANCELLED breaks sys_sigpending() ? Yes, it does. Well, POSIX says after timer_delete "the disposition of pending signals for the deleted timer is unspecified". So perhaps one can say that "unspecified" here can include sigpending() says it's pending but it will disappear when delivered or accepted (means sigwait()). But it's a bit of a stretch. Just properly removing the sigqueue entry and fixing the pending set is looking pretty good. Why was it we ...
May 21, 11:42 am 2008
Roland McGrath
Re: [PATCH 1/3] signals: sigqueue_free: don't free sigqu ...
To clarify, this certainly does change the behavior. There are two changes. Firstly, a pending timer-firing signal currently gets its siginfo_t zeroed out synchronously by timer_delete and now will have its info preserved. That change alone is a potential problem for userland, so it should not go in without the following changes to prevent userland from seeing the signal at all. (Currently userland may see a spurious signal, but its si_code and si_value don't indicate a timer ...
May 20, 7:20 pm 2008
Roland McGrath
Re: [PATCH 3/3] posix timers: use SIGQUEUE_CANCELLED whe ...
Just make it: spin_lock_irqsave(lock, flags); q->flags |= SIGQUEUE_CANCELLED; q->flags &= ~SIGQUEUE_PREALLOC; and we needn't wax philosophical about the meaning of locking rules. That patch would have my ACK, but I concur with Linus about the undesireability of the plain = version. Thanks, Roland --
May 20, 7:27 pm 2008
Roland McGrath
Re: [PATCH 2/2] signals: collect_signal: simplify the "s ...
> Factor out sigdelset() calls and remove the "still_pending" variable. Acked-by: Roland McGrath <roland@redhat.com> --
May 20, 5:58 pm 2008
Roland McGrath
Re: [PATCH 1/2] signals: collect_signal: remove the unne ...
The only use of ->notifier/notifier_mask is for block_all_signals. Its only user in the tree is drm_lock(), but it is exported too. drm_lock is using block_all_signals to catch all the stop signals for a purpose that is not immediately clear to me. Thanks, Roland --
May 20, 5:56 pm 2008
Oleg Nesterov
Re: [PATCH 1/2] signals: collect_signal: remove the unne ...
Suppose that the task has the pending SIG which is "blocked" by DRM. dequeue_signal() calls ->notifier(), it nacks the signal, we clear TIF_SIGPENDING. Then dequeue_signal() does recalc_sigpending() and sets TIF_SIGPENDING again. We return 0 to get_signal_to_deliver(), and then return to user-space with TIF_SIGPENDING. Endless loop ? Even if it works somehow... "blocking" SIG means that in fact we and of course this can't work for multithread programs, another thread can dequeue SIGTSTP ...
May 21, 5:20 am 2008
Linus Torvalds
Re: [PATCH 1/2] signals: collect_signal: remove the unne ...
It's basically the equivalent of a "spin_lock_irq()" for DRM, where signals are the "interrupts" that need to be blocked while holding the lock. In order for the user-level direct-rendering code to be able to do a lock that is safe in the presense of signals, the locking code needs to have some way to basically disable signals. And it could disable/re-enable them all the time, but that would be very expensive and defeat the whole purpose (which is that you can get the lock cheaply ...
May 20, 7:14 pm 2008
Roland McGrath
Re: [PATCH 1/2] signals: collect_signal: remove the unne ...
Well, sure, that makes sense. But that's not what it does. I can see what it does, I just can't tell why it really makes any sense. Despite the name, block_all_signals() in fact blocks no signals. What it does is install notifier/notifier_mask, which makes the hook get called for those particular signals and it can decide to delay the signal (in a kooky fashion that's not really reliable). drm_lock uses a mask containing only the stop signals (SIGSTOP, SIGTSTP, SIGTTOU, SIGTTIN). So for ...
May 20, 7:56 pm 2008
John W. Linville
Re: [RFC] make wext wireless bits optional and deprecate them
I think this is going to fall under the "userland ABI" category. We can make it a configurable option, but I don't think we are free to remove it completely since there is at least existing versions of HAL that use it. John -- John W. Linville linville@tuxdriver.com --
May 21, 2:03 pm 2008
Johannes Berg
Re: [RFC] make wext wireless bits optional and deprecate them
Well, yes, I gave it a year in the feature removal schedule since I thought nobody was actually using it. But if you look at how hal/sysfs are always dependent on new versions of each other *anyway*, I think we can get away with removing this in maybe two years time, and distributors can unset the option if they know their hal is new enough? johannes
May 21, 2:37 pm 2008
Mike Frysinger
Re: [PATCH 0/2] MUSB: 2 patches to fix some bug found on ...
unfortunately, that is the case. the BF527 EZKit is ~$900 while the BF548 EZKit is ~$1000. i'm hoping us software guys keep complaining enough for the hardware guys to put out a bare bone kit at a reasonable price (sub $300). -mike --
May 21, 1:10 pm 2008
Tony Lindgren
Re: [PATCH 0/2] MUSB: 2 patches to fix some bug found on ...
Maybe we should get the musb code to USB tree before that? It's been out of the scope for linux-omap tree for quite a while now. Tony --
May 21, 8:50 am 2008
David Brownell
Re: [PATCH 0/2] MUSB: 2 patches to fix some bug found on ...
I'm all for getting the musb_hdrc driver into the 2.6.27 queue... I presume there are still some infrastructure changes in usbcore that block that merge? It'd be nice if we could merge musb_hdrc without those changes (OTG related) and then update that stuff separately. - Dave --
May 21, 10:14 am 2008
David Brownell
Re: [PATCH 0/2] MUSB: 2 patches to fix some bug found on ...
When it's a USB patch, please post to linux-usb. Most of the relevant reviewers won't be on Linux-OMAP. ;) That said, I'm looking forward to seeing the www.beagleboard.org hardware [1] become more generally available. That will make some musb_hdrc hardware available in a more developer-friendly rig than, say, an N810 tablet. And it might well get more folk in a position where they can use that driver! (I think some Blackfin devboards are available already, but they're more pricey.) - ...
May 21, 1:04 pm 2008
Felipe Balbi
Re: [PATCH 0/2] MUSB: 2 patches to fix some bug found on ...
On Wed, 21 May 2008 10:14:44 -0700, David Brownell <david-b@pacbell.net> Ok then, I'll prepare the patches during the next week and post here on l-o so people can comment. Any otg related stuff will come later. -- Best Regards, Felipe Balbi http://felipebalbi.com me@felipebalbi.com --
May 21, 12:06 pm 2008
Atsushi Nemoto
Re: [PATCH] RTC: M41T80: Century Bit support
OK, it would be the best way to handle the century bit. I'll test your patch (if my board is still alive at the time ;-)) --- Atsushi Nemoto --
May 20, 5:56 pm 2008
Bruno
Re: Input+S3: extra keycodes forgotten after suspend
Hi Dmitry, When running 2.6.25.4 without the two dritek patches it does not redetect the keyboard (but obviously the extra keys don't work at all) Attached is the log for a suspend session without the dritek patches. I hope you can find a useful difference between both cases with the input debug messages so it's possible to get it working properly with dritek extensions... Seems to look like reset on suspend path does not reset everything... Tomorrow I will also try with acerhk ...
May 21, 1:08 pm 2008
Dmitry Torokhov
Re: Input+S3: extra keycodes forgotten after suspend
Hi Bruno, Question - does the problem happen if you dont have dritek extension enabled (i.e. on unpatched kernel)? -- Dmitry --
May 21, 10:55 am 2008
Dmitry Torokhov
Re: Input+S3: extra keycodes forgotten after suspend
Ah, ok, great.. I think we simply need to move dritek out of the place where you put it in so it does not interfere with our efforts to resume keyboard and mouse ;) I will see what I can do there.. -- Dmitry --
May 21, 1:38 pm 2008
Grant Likely
Re: [PATCH 3/4] spi: Add OF binding support for SPI busses
On Wed, May 21, 2008 at 1:11 PM, Segher Boessenkool For SPI the CS # *is* the address. :-) Unlike I2C, SPI doesn't impose any protocol on the data. It is all anonymous data out, anonymous data in, a clock and a chip select. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. --
May 21, 12:33 pm 2008
Segher Boessenkool
Re: [PATCH 3/4] spi: Add OF binding support for SPI busses
It would be best to handle all these things that are specific to a certain SPI controller (like how CSs work) in the binding for that SPI controller, and not try to shoehorn all of this into some artificial generic framework. If you can have identical addresses on the SPI bus going to different devices based on which CS is asserted, you'll have to make the CS part of the "reg". Example: spi-controller { #address-cells = 2; #size-cells = 0; some-device@0,f000 { reg = < 0 f000 >; } // ...
May 21, 12:11 pm 2008
Anton Vorontsov
Re: [PATCH 3/4] spi: Add OF binding support for SPI busses
[...] -- Anton Vorontsov email: cbouatmailru@gmail.com irc://irc.freenode.net/bd2 --
May 21, 8:19 am 2008
Andrew Morton
Re: [PATCH] ATA over Ethernet: Convert emsgs_sema in a c ...
That's fine - the normal way of handling that is for the user's fd to hold a reference against the module itself. --
May 21, 11:38 am 2008
Ed L. Cashin
Re: [PATCH] ATA over Ethernet: Convert emsgs_sema in a c ...
I plan to answer this question soon. Right now I am quite busy. This emsgs_sema part of the aoe driver has never caused any problems for users but has caused many problems for me, because it is tricky to think about, to talk about, and for others to patch. I hope that there is a more straightforward way to get the current read-from-the-file-forever behavior using an existing kernel facility. A user currently can do, cat /dev/etherd/err ... and have it block, waiting until there is ...
May 21, 7:49 am 2008
Andrew Morton
Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
It is 20%? I recall 30% from a few years ago, but that's vague and it might have changed. Has much quantitative testing been done recently? I might have missed it. If we do make this change I think it should be accompanied by noisy printks so that as many people as possible know about the decision which we just made for them. afaik there is no need to enable this feature if the machine (actually the disks) are on a UPS, yes? --
May 21, 11:03 am 2008
Jamie Lokier
Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
My work here is done ;-) -- Jamie --
May 21, 12:43 pm 2008
Theodore Tso
Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
It is for me; I think we have to enable barriers for ext3/4, and then work to improve the overhead in ext4/jbd2. It's probably true that the vast majority of systems don't run under conditions similar to what Chris used to demonstrate the problem, but the default has to be filesystem safety. People who are sure they are extremely unlikely to run into this problem can turn barriers off (and I suspect they won't see that much difference in the most common workloads anyway). ...
May 21, 5:32 am 2008
Chris Mason May 21, 12:40 pm 2008
Jamie Lokier
Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
I favour saying barrier=1 in /proc/mounts, even though it will become the new default. At least for a while. -- Jamie --
May 21, 12:54 pm 2008
Andrew Morton
Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
That won't cause corruption, will it? The problem is purely one of Well. The product of two very small numbers is... --
May 21, 11:49 am 2008
Greg Smith
Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
As far as I know that made its way first into MySQL 4.1.9 (2005-01), then into SQLite (2005-02), then into PostgreSQL (2005-04), so the database coders all picked that up around the same time and have been using it for years now. http://www.mail-archive.com/sqlite-users@sqlite.org/msg06502.html shows part of that timeline, and even includes some useful comments on the underlying Darwin implementation from that mailing list. That suggests one reason Apple is able to make this work is ...
May 21, 1:25 pm 2008
Jens Axboe
Re: [PATCH 4/4] ext4: call blkdev_issue_flush on fsync
It may not mention flushing explicitly, but it does not have to since the flushing is one way to implement what the above describes. Note how it says that request must have made it to physical medium before allowing others to continue? That means you have to either write through Yeah, that is precisely what it is and why it does not mention flushing Right, that is what ordered tags give you. But if you have write back caching enabled, then you get a completion event before the data ...
May 21, 12:30 am 2008
Eric Sandeen
Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
As long as your power supply (or your UPS) doesn't go boom, I suppose so. It is too bad that there is no way to determine no-barrier safety from software. (maybe apcupsd could do something... ;) I guess it's levels of confidence. I agree that a user education campaign is probably in order... maybe if this thread is long enough to make LWN it'll raise some awareness. :) -Eric --
May 21, 11:15 am 2008
Jamie Lokier
Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
Can a kernel lockup cause this kind of corruption? Will a system reboot wipe the disk's write cache? I had imagined only power loss would prevent the disk from writing it's cache eventually; is that wrong? -- Jamie --
May 21, 12:36 pm 2008
Theodore Tso
Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
Yes, as long as you're confident that there won't be a kernel bug/regression causing a lockup while the server is under severe memory pressure while doing lots of fsync's, file creations, renames, etc. And as long as your 100% confident that UPS's will never fail, janitors will never accidentally hit the Emergency Power Office switch, and so on. - Ted --
May 21, 11:29 am 2008
Daniel Phillips
Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
Nice, htree as a canary for disk corruption. This makes sense since directory data is the only verifiable structure at the logical data level and htree offers the only large scale, verifiable structure. Thanks for the lovely test methodology example. Let me additionally offer this tool: http://code.google.com/p/zumastor/source/browse/trunk/ddsnap/tests/devspam.c?r=1564 devspam The idea is to write an efficiently verifiable pattern across a range of a file, including a mix of ...
May 21, 3:30 pm 2008
Pavel Machek
Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
Ok, Andrew, is this enough to get barrier patch applied and stop corrupting data in default config, or do you want some more testing? I guess 20% benchmark regression is bad, but seldom and impossible to debug data corruption is worse... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --
May 21, 4:22 am 2008
Jamie Lokier
Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
Another unquantified very small number. You have a UPS, but the first time you discover it's not wired up properly is when it fails. This happened recently in a customer's office... The UPS power wiring melted, leaving a big stinking hole, and all the servers went down - quickly. Another is misconfiguring the UPS daemon so it continues writing to disk for 30 minutes until the battery runs down... Like the chance of two disks going wrong in a RAID at the same time... that would ...
May 21, 12:42 pm 2008
Anton Vorontsov
[PATCH 2/2] mmc_spi: add support for card-detection polling
If platform_data lacks init() callback (solely used to request card-detect interrupt), we mark the host as MMC_CAP_NEEDS_POLL. get_cd() host operation provided to optimize polling. p.s. Since mmc_host_ops no longer the same for every instance of mmc_spi, struct mmc_host_ops can't be const and should be allocated dynamically. Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> --- drivers/mmc/host/mmc_spi.c | 31 +++++++++++++++++++++---------- include/linux/spi/mmc_spi.h | 6 ...
May 21, 11:47 am 2008
Anton Vorontsov
Re: [PATCH 3/4] [MMC] mmc_spi: add polling support for t ...
Calling get_cd() for every request smells like overhead, especially given that that get_cd() could ask for GPIO status via relatively slow bus (like I2C GPIO expanders). So, polling seems most reasonable solution here, no need to call it very often. How about these patches? Tested with and without get_cd() optimization. -- Anton Vorontsov email: cbouatmailru@gmail.com irc://irc.freenode.net/bd2 --
May 21, 11:47 am 2008
Anton Vorontsov
[PATCH 1/2] mmc: add support for card-detection polling
Some hosts (and boards that use mmc_spi) do not use interrupts on the CD line, so they can't trigger mmc_detect_change. We want to poll the card and see if there was a change. 1 second poll interval seems resonable. This patch also implements .get_cd() host operation, that could be used by the hosts that are able to report card-detect status without need to talk MMC. Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> --- drivers/mmc/core/core.c | 19 ++++++++++++++++--- ...
May 21, 11:47 am 2008
Pierre Ossman
Re: [PATCH 3/4] [MMC] mmc_spi: add polling support for t ...
On Wed, 21 May 2008 22:47:13 +0400 Fair enough. You should probably add a comment about this somewhere so that people do not call get_cd() in the core request function and similar places. Place it so that both get_cd() and get_ro() are covered I'm always nervous when it comes to adding more callbacks, but I This should only be done when there is no bus handler. Since we are polling, we might actually miss the user removing and reinserting the card. The only way to check for that is to ...
May 21, 12:28 pm 2008
Clemens Ladisch
Re: [PATCH] x86: Get irq for hpet timer
HPET interrupts can be either edge or level triggered. Probably we should modify it according to the type of the interrupt line we're An edge-triggered HPET interrupt line is not shared (we set IRQF_SHARED I don't have much of a clue about that "somehow", but this sound like a good idea. ;-) I think hpet_reserve_platform_timers() might be the place for this. It gets called from hpet_late_init(), which is a fs_initcall, so I think we should be careful not to grab some unsharable ...
May 21, 1:28 am 2008
Cornelia Huck
Re: [PATCH] driver core: Suppress sysfs warnings for dev ...
On Tue, 20 May 2008 15:52:44 -0700, Here it is again, respun against today's git: driver core: Suppress sysfs warnings for device_rename(). Renaming network devices to an already existing name is not something we want sysfs to print a scary warning for, since the callers can deal with this correctly. So let's introduce sysfs_create_link_nowarn() which gets rid of the common warning. Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Cornelia Huck ...
May 21, 1:05 am 2008
Pavel Machek May 21, 3:41 am 2008
Mike Frysinger
Re: [PATCH 1/3, RFC] misc char dev BKL pushdown
the lock is to protect one thing: coreb_status. we lock around any access to it, so it not being grabbed in the irq handler or any other function where coreb_status is not utilized is irrelevant. that means the BKL is not needed in the driver. the rest of your comments are more or less on target, but again irrelevant to the topic of the BKL. i'll keep them in mind when i rewrite the driver, thanks. -mike --
May 21, 9:22 am 2008
Mathieu Desnoyers
Re: [PATCH] Fix immediate asm constraint for gcc 3 x86_64
Hrm, you are right. Let's see a simple toy case which generates the problem : struct test_struct { int a; int b; int c; }; static struct test_struct testa; int main() { asm ( ".quad %c0\n\t" : : "i" (&testa.c)); return 0; } gcc 4.1 generates : .quad testa+8 and doesn't complain. However, gcc-3.4 stops with : compudj@amd64:~/test$ gcc-3.4 -S -o oldgcc.S oldgcc.c oldgcc.c: In function `main': oldgcc.c:11: ...
May 21, 6:31 am 2008
Takashi Sato
Re: [RFC PATCH 1/3] Implement generic freeze feature
Hi, Sounds good. I will send new patch-set which is rebased to 2.6.26-rc3 and includes this fix, in this weekend. Cheers, Takashi --
May 20, 6:23 pm 2008
Hidehiro Kawai
Re: [PATCH 4/4] jbd: fix error handling for checkpoint i ...
Hi, A checkpointing failure is a bit special. If the journal is aborted by journal_commit_transaction(), the integrity of the filesystem is ensured although the latest changes will be lost. However, if the journal is aborted by log_do_checkpoint() and the replay also failed, the filesystem may be corrupted because some of the metadata blocks are in old states. In this case, the user will have to recover the filesystem manually and carefully. So I think printing the special I can ...
May 20, 6:34 pm 2008
Hidehiro Kawai
Re: [PATCH 3/4] jbd: abort when failed to log metadata ...
Hi, I see. I'll move the aborting point to just before journal_write_commit_record() in the next version. Thanks, -- Hidehiro Kawai Hitachi, Systems Development Laboratory Linux Technology Center --
May 20, 6:33 pm 2008
Cliff Wickman
[BUG] hotplug cpus on ia64
Gentlemen, I built an ia64 kernel from Andrew's tree (2.6.26-rc2-mm1) and get a very predictable hotplug cpu problem. billberry1:/tmp/cpw # ./dis disabled cpu 17 enabled cpu 17 billberry1:/tmp/cpw # ./dis disabled cpu 17 enabled cpu 17 billberry1:/tmp/cpw # ./dis The script that disables the cpu always hangs (unkillable) on the 3rd attempt. I haven't spent any debugging time on it yet. Just wondering if you've seen it? It doesn't seem to happen x86_64. -Cliff ...
May 21, 7:48 am 2008
Heiko Carstens
Re: [BUG] cpu hotplug vs scheduler
Ah no. I thought "x86: fix crash on cpu hotplug on pat-incapable machines" would have fixed the cpu hotplug bug for you. I was actually talking of the pick_next_task_fair incarnation of one of the cpu hotplug bugs. s390 backtrace on 2.6.25 looks like this. <1>Unable to handle kernel pointer dereference at virtual kernel address 00000200000db000 <4>Oops: 003b [#1] PREEMPT SMP <4>Modules linked in: dm_multipath sunrpc qeth_l2 dm_mod cu3088 qeth ccwgroup <4>CPU: 0 Not ...
May 21, 5:55 am 2008
Heiko Carstens
Re: [BUG] cpu hotplug vs scheduler
Hi Avi, I think you fixed this specific bug. Does cpu hotplug stresstest now work for you? --
May 21, 5:31 am 2008
Avi Kivity
Re: [BUG] cpu hotplug vs scheduler
Which bug, the order-2 allocs? I certainly didn't fix it. Last I tried, cpu hotplug still failed, but it was some time ago as patches flow. -- error compiling committee.c: too many arguments to function --
May 21, 5:42 am 2008
Avi Kivity
Re: [BUG] cpu hotplug vs scheduler
No, that only fixes an immediate oops when running in a virtual machine Seems to be the same bug, yes. -- error compiling committee.c: too many arguments to function --
May 21, 6:03 am 2008
Pavel Machek
Re: [PATCH] x86: fix app crashes after SMP resume
ACK. Perhaps you should send it to Andrew for a merge? Or maybe Rafael wants to add it to his patch queue? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --
May 21, 4:16 am 2008
Jesse Barnes
Re: [PATCH] PCI: boot parameter to avoid expansion ROM m ...
Great, thanks. I'll push it to Linus in the next merge window. Jesse --
May 21, 10:40 am 2008
Gary Hade
Re: [PATCH] PCI: boot parameter to avoid expansion ROM m ...
Jesse, I just tried 2.6.26-rc3-next-20080521 on one of those systems and the pci=norom option worked as expected. Thanks, Gary -- Gary Hade System x Enablement IBM Linux Technology Center 503-578-4503 IBM T/L: 775-4503 garyhade@us.ibm.com http://www.ibm.com/linux/ltc --
May 21, 10:29 am 2008
Pavel Machek
Re: Tracking and crediting bug reporters
I believe we have enough tags already. Plus, if the reporter really works with the developer till the end, there's already accepter Tested-by: flag, right? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --
May 21, 3:41 am 2008
Pekka Enberg
Re: Tracking and crediting bug reporters
Tested-by is really helpful for identifying potential testers when you change some part of the kernel. I use git history to identify people who are able/willing to test NUMA changes to the slab allocators that require a big ass NUMA box to trigger a bug, for example. Also, in some cases, testing a bug fix is not trivial and might require a lot of work that we should give credit for. --
May 21, 6:46 am 2008
Johannes Weiner
Re: Tracking and crediting bug reporters
Hi, I would more argue to remove Tested-by completely because it does not tell much. Code is not bugfree just because someone compiled and ran it. And if it breaks on some other systems later on, what does it help if you know someone tested it? It still breaks. And you can not even blame the tester because of his luck of a working configuration. While a Reported-by in this case credits a person reporting a bug. Just that. And perhaps that the report was good enough to make a ...
May 21, 6:34 am 2008
Pavel Machek
Re: better msleep for drivers
Okay, I was a bit confused. Actually, both can delay for longer... msleep() in case of scheduling load, mdelay() in case of interrupt load... But the above was about hrtimer_nano*sleep*(), so that "how much latency we can tolarate" parameter would still be good. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --
May 21, 12:01 pm 2008
Pavel Machek
Re: better msleep for drivers
While you are at it... it would be cool to have 'mdelay(2500 msec), but it is okay to wait 100msec more' -- type interface, so we could use that for nohz benefit. Currently, mdelay is 'it is okay to wait 10msec more' interface, and it would be nice to have that explicit. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) ...
May 21, 3:41 am 2008
Jeff Garzik
Re: better msleep for drivers
eh, I think you transposed mdelay with msleep? msleep() is the "it is okay to wait longer than I said" interface, not mdelay(). mdelay() has always been non-sleeping and exact (as much as the delay loop allows) Jeff --
May 21, 8:24 am 2008
Yinghai Lu
[PATCH] x86: move e820_mark_nosave_regions to e820.c
and make e820_mark_nosave_regions to take limit_pfn to use max_low_pfn for 32bit and end_pfn for 64bit Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Index: linux-2.6/arch/x86/kernel/e820.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/e820.c +++ linux-2.6/arch/x86/kernel/e820.c @@ -18,6 +18,7 @@ #include <linux/module.h> #include <linux/mm.h> #include <linux/pfn.h> +#include <linux/suspend.h> #include <asm/pgtable.h> ...
May 20, 8:10 pm 2008
Evgeniy Polyakov
Re: iput() in reclaim context
Hi Hugh. If we are talking about the same things, its waiting for pages to be synced (wither written back or truncated) when inode is about to be destroyed. Thus reclaim can sleep wating for pages to be synced, which it is about to move somewhere itself. Deadlock. The same for writepage - if we drop inode there it can wait for pages to be synced, which inturn requires writeback, where we are sleeping already... -- Evgeniy Polyakov --
May 21, 10:58 am 2008
Andrew Morton
Re: [patch 10/21] buffer heads: Support slab defrag
Well, we _can_, but doing so within the present constraints is delicate. An implementation which locked all the to-be-written pages up front and then wrote them out and which was careful not to touch the inode or address_space after the last page is unlocked could work. Or perhaps add a new lock to the inode and then in reclaim a) lock a page on the LRU, thus pinning the address_space and inode. b) take some new sleeping lock in the inode c) unlock that page and now proceed to do ...
May 20, 11:24 pm 2008
Christoph Lameter
Re: [patch 10/21] buffer heads: Support slab defrag
Well that is what Dave wants. I'd rather go the safe route for now and defer this until later. I think you are much more an expert on the filesystems and I/O paths than I am. So I'd rather take my hands of as soon as possible. --
May 20, 6:56 pm 2008
Evgeniy Polyakov
Re: [patch 10/21] buffer heads: Support slab defrag
Which basically means we can not do direct writeback at reclaim time?.. -- Evgeniy Polyakov --
May 20, 11:15 pm 2008
Evgeniy Polyakov
Re: [patch 10/21] buffer heads: Support slab defrag
Cool, I did not know that, probably because it is not exported :) -- Evgeniy Polyakov --
May 20, 11:20 pm 2008
Hugh Dickins
iput() in reclaim context
I happened to notice your remark in the buffer heads defrag thread. Do you remember what that limitation was about? Because just a few months ago I discovered a shmem race which I fixed by doing igrab+iput in shmem_writepage, in the reclaim context. Feeling guilty now: I'd better investigate, but would welcome a starting pointer. (If I'm lucky, it'll be that the generic code in vmscan.c cannot use iput, but particular filesystems might themselves be safe to.) Thanks, Hugh --
May 21, 10:52 am 2008
Andrew Morton
Re: iput() in reclaim context
Ages and ages ago. I expect it was a deadlock thing. iput_final() can end up calling things like write_inode() which can want to do things like opening a transaction against filesystem A while already having one open against filesystem B. Which is both deadlockable and BUGable. Yes, it was specific to the direct-reclaim calling context. --
May 21, 11:12 am 2008
Jason Wessel
Re: kgdb test suite failure
I duplicated the problem by trying the kernel out with the CONFIG_DEBUG_RODATA, which appears to only be implemented on the x86 architecture. I am not exactly certain what the right level of fix should be in this case, or if it should be fixed at all. It seems that the probe_kernel_write should have a force option to force writing to a read-only memory page (meaning it will be unprotected/re-protected), or there should be another function to deal with writes that are deemed to be critical ...
May 21, 9:27 am 2008
Jean Delvare
Re: [PATCH 1/3] i2c : use class_for_each_device
Too late for this time, but for next time, you can emulate an i2c device using the i2c-stub driver, that's very convenient when you want to test a change that affects i2c and don't have any physical device to test it. -- Jean Delvare --
May 20, 11:00 pm 2008
Dave Young May 20, 6:30 pm 2008
Dave Young
Re: [PATCH 1/3] i2c : use class_for_each_device
Thanks for review, It's only boot-tested with i2c part as built-in by Glad to see that, thanks. Regards dave --
May 20, 6:29 pm 2008
Max Krasnyanskiy
Re: Reverting per-cpuset "system" (IRQ affinity) patch
Yeah, unfortunately we did not make much progress. Partly because of disagreements and party because I was on a longish vacation and did not get a chance to push things forward. Now I'm back. At this point I want to make a step back and redo some of the original patches without using cpusets. At least for now while we do not have clear agreement on how cpuset integration should look like it seems to make sense to simply extend existing interfaces. For the irqs specifically I'm just ...
May 20, 5:46 pm 2008
Steve French (smfltc)
Re: Re: [PATCH] usb-storage: don't call utsname()
The version number (of the OS not just of the SMB/CIFS implementation, both of which are exchanged by client and server) has sometimes been useful in debugging problems that I and others and the Samba team look at (you can see it in wireshark/tcpdump traces, and it can be logged easily on either end as well). If containers are crazy enough to change the version number, not just the hostname, why don't we simply define a three line macro for retrieving this which is safe and put it in ...
May 21, 2:01 pm 2008
Christoph Hellwig
Re: [2.6 patch] unexport uts_sem
Just a debug printk. Note sure why this particular one needs to print the version, but if it really wants to do it it should rather use This one is quite fishy. Not sure what it needs the name for but the kernel utsname is probably a bad choise. And yes, this one actually random.c is always built-in and utsname is called during the Yes, this one is racy. Should probably be fixed by starting lockd with CLONE_NEWUTS so that it never changed during it's lifetime. It's probably not a good ...
May 21, 5:37 am 2008
Christoph Hellwig
Re: [PATCH] usb-storage: don't call utsname()
Because thanks to the container patches it utsname fields other than hostname can actually change at runtime now and you'll get races looking at them. And probably not the output you want if someone in your container changes the kernel version to trick applications. --
May 21, 11:52 am 2008
Steve French (smfltc)
Re: Re: [2.6 patch] unexport uts_sem
CIFS in fs/cifs/sess.c uses utsname()->version because the cifs protocol requires that the server and client report their native operating system version during session setup (not just their "network operating system" or network file system version). The other uses of utsname()->version in connect.c will be removed (they are used in an older implementation of session_setup which is disabled by default). CIFS in fs/cifs/connect.c uses utsname()->nodename to get the default hostname ...
May 21, 7:48 am 2008
Alan Stern
[PATCH] usb-storage: don't call utsname()
This patch (as1100) replaces the core-kernel function call to utsname() in usb-storage with the UTS_RELEASE macro. It's used only for warning about extra unusual_devs entries. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> --- Index: usb-2.6/drivers/usb/storage/usb.c =================================================================== --- usb-2.6.orig/drivers/usb/storage/usb.c +++ usb-2.6/drivers/usb/storage/usb.c @@ -53,7 +53,7 @@ #include <linux/slab.h> #include ...
May 21, 10:51 am 2008
Greg KH
Re: [PATCH] usb-storage: don't call utsname()
Why? With this change, if you change the version number, the file will have to be rebuilt. Without the change, the file will not need to be rebuilt, right? I thought that was why this change was made a while ago, to prevent things from having to be rebuilt that didn't need to be. thanks, greg k-h --
May 21, 11:09 am 2008
Steve French (smfltc)
Re: Re: [PATCH] usb-storage: don't call utsname()
I agree - what was wrong with utsname->release ... it seems odd to statically build the kernel's version number into a module - it should be something we should be able to query (and it shouldn't change without reboot so accessing it is not racy). Access to other fields in the structure (nodename, domainname etc.) might need to be included in a macro but I didn't see one in utsname.h for this. --
May 21, 11:19 am 2008
Greg KH
Re: [PATCH] usb-storage: don't call utsname()
So, do we now go and rip out all usages of utsname()->release and put back the #define just because of the loonacy of containers? No kernel should have to change it's version number to trick an application, why would an application care about the version number to start with? In the "enterprise kernel" world, version numbers have little to no relevance on the functionality or features of the kernel, so any check of something like this is sure to be wrong to start with. thanks, greg ...
May 21, 12:35 pm 2008
H. Peter Anvin
Re: [RFC] Kernel naming convention in the merge phase
It'll probably make some of them work and break others. It's pretty hard-coded in most of them that the flow is from 2.6.25 -> 2.6.26-{pre,rc}*; whether or not they permit a zero probably depends on if they know what is available or not (ketchup wouldn't be able to, for example, but the kernel.org incdiff robot *might* "just work".) -hpa --
May 21, 9:02 am 2008
Pavel Machek
Re: [RFC] Kernel naming convention in the merge phase
Well, unfortunately its not there in the makefile, so you can't tell 2.6.25 from 2.6.26-rc0... Would 'rc0' make robots happy? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --
May 21, 4:16 am 2008
Randy Dunlap
Re: [patch 1/3] dynamic_printk: core
and depends on DEBUG_FS ?? We shouldn't advertise this option unless the kernel can actually --- ~Randy --
May 21, 1:35 pm 2008
Andres Salomon
Re: Additional kconfig targets (cloneconfig, nonint_oldc ...
On Fri, 2 May 2008 21:09:49 +0200 Since this is aconf (automated), if we run 'make K=foo defconfig' and 'foo' doesn't contain one of the necessary values.. the build will fail, right? I'm not sure I see the point of #3. --
May 21, 1:47 pm 2008
Andres Salomon
Re: Additional kconfig targets (cloneconfig, nonint_oldc ...
On Wed, 21 May 2008 17:11:39 -0400 Ah, I see. My process has always been: cp arch/x86/configs/foo_defconfig .config make oldconfig make obvious decisions about new symbols, choose defaults if unknown diff -u arch/x86/configs/foo_defconfig .config figure out if any decisions or defaults are incorrect, change accordingly make oldconfig (more decisions if there are new symbols exposed) My build has broken again, which is why I'm inquiring about the status of this; I'm not going to bother ...
May 21, 2:38 pm 2008
Sam Ravnborg
Re: Additional kconfig targets (cloneconfig, nonint_oldc ...
Been busy and got sidetracked after my first version proved broken. Will try to look at it in the weekend. Sam --
May 21, 2:47 pm 2008
Dave Jones
Re: Additional kconfig targets (cloneconfig, nonint_oldc ...
On Wed, May 21, 2008 at 04:47:03PM -0400, Andres Salomon wrote: > > 3) Implement newsymbolsconfig (any better name?) > > Shall list all new symbols and shall not write > > any config > > I'm not sure I see the point of #3. It's something we've had in Fedora kernels forever, because when rebasing to a new upstream version the process becomes make newsymbolsconfig take list of symbols, and make decisions on them make oldconfig without it, the process would be.. make ...
May 21, 2:11 pm 2008
Pierre Ossman
Re: tifm_7xx1: SD card is ignored
On Wed, 7 May 2008 18:50:54 +0200 I missed the start of this, but I assume it is just the one card that What can I say, the card thinks it's an SDIO card. :) The question is why. Might be some shoddy wiring between the card and the controller that causes some unlucky misinterpretations. Might also be that the card needs some increased delay to function correctly. Try adding: msleep(500); to mmc_rescan() in drivers/mmc/core/core.c. Put it right after mmc_power_up(). Rgds Pierre
May 21, 5:21 am 2008
Benjamin Herrenschmidt
Re: [PATCH 1/2] Add thread_info_cache_init() to all archs
Back to this old subject... I'm having reports that this is not working... gcc is seeing the empty weak function and is optimizing it out before it gets a chance to link to the arch provided one. This would affect that and the other one next to it.. That seems pretty bad... it causes nasty crashes as we end up having no idea what the compiler decided to generate... I suppose we could keep the weak stubs out of the file where they are called but that sucks. ie. This is some form of ...
May 21, 10:56 am 2008
Sam Ravnborg
Re: [PATCH 1/2] Add thread_info_cache_init() to all archs
It was discussed to add some run-time checks for this issue. But the examples given were a bit fluffy so I never integrated anything i kbuild to detect this. As this is only a bug for const weak functions they could be made non-const if they are seldomly used? Sam --
May 21, 12:06 pm 2008
Andrew Morton
Re: [PATCH 1/2] Add thread_info_cache_init() to all archs
On Wed, 21 May 2008 15:44:41 -0400 istr that sticking an asm(""); in the weak function was a reliable workaround. If we are going to to that it should be via /* comment goes here */ #define gcc_screws_up_weak_stuff() asm("") but that approach didn't seem very popular. It's a _bit_ fragile I guess, but it's pretty easy to grep for missed workarounds. --
May 21, 1:52 pm 2008
Benjamin Herrenschmidt
Re: [PATCH 1/2] Add thread_info_cache_init() to all archs
With the asm("") trick ? I suppose, but I'm also happy to just reject the bad gcc... It shouldn't be too hard to do a test case made of 2 files. test_foo.c int foo(void) { printf("good\n"); } test_bar.c int foo(void) __weak { } int main(void) { foo(); return 0; } And check for "good" in the output of said program.. Can somebody test that ? Luke, you have a broken compiler, can you make up some test that could be integrated in the kernel build system easily ...
May 21, 1:38 pm 2008
Andrew Morton
Re: [PATCH 1/2] Add thread_info_cache_init() to all archs
yup, gcc bug. Discussed recently on lkml, "Subject: Re: huge gcc 4.1.{0,1} __weak problem". I don't think anything ended up happening about it though. --
May 21, 11:41 am 2008
Benjamin Herrenschmidt
Re: [PATCH 1/2] Add thread_info_cache_init() to all archs
Hrm... do you think we should work around ? ie. move the stubs to a separate .c file ? Ben. --
May 21, 12:44 pm 2008
Eric W. Biederman
Re: [PATCH] kill_something_info: don't take tasklist_loc ...
No because of this from fork.c:copy_process() /* * Process group and session signals need to be delivered to just the * parent before the fork or both the parent and the child after the * fork. Restart if a signal comes in before we add the new process to * it's process group. * A fatal signal pending means that current will exit, so the new * thread can't slip out of an OOM kill (or normal SIGKILL). */ ...
May 20, 7:53 pm 2008
Eric W. Biederman
Re: [PATCH] kill_something_info: don't take tasklist_loc ...
Sorry for the very delayed response. I have been moving and overwhelmed with everything. Call me paranoid but I don't think there is any guarantee without a lock that we will hit the -ERESTARTNOITR check for new processes. I think we have a slight race where the fork process may not have received the signal (because it is near the tail of the list) but the new process would be Actually we do sent the signal to init but we shouldn't, if we want our semantics straight. And we drop ...
May 20, 8:47 pm 2008
Atsushi Tsuji
Re: [PATCH] kill_something_info: don't take tasklist_loc ...
Sorry for late reply and thank you for your comment. I understood the mechanism that kill(-1, SIGKILL) can miss the tasks forked by init (and the thread group of the current process, because we don't also send the signal to them). If kill(-1, SIGKILL) finish before the forking init process does list_add_tail_rcu(p->tasks) in copy_process(), the process forked by init appears on the ->tasks list after that. Is that right? If so, I think this problem can happen without my patch. Because even ...
May 20, 6:48 pm 2008
Michael Kerrisk
Re: [RFC] correct flags to f_mode conversion in __dentry_open
Late follow-up to this thread (http://thread.gmane.org/gmane.linux.kernel/653123): I propose to add the following text to the open(2) man page. Unlike the other values that can be specified in flags, the access mode values O_RDONLY, O_WRONLY, and O_RDWR, do not specify individual bits. Rather, they define the low order two bits of flags, and are defined respectively as 0, 1, and 2. In other words, the combination O_RDONLY | O_WRONLY is a ...
May 21, 10:54 am 2008
Paul Jackson
Re: IRQ affinities
I suspect that something like you're proposing to do here will answer your needs, to "tell the kernel to not route IRQs to certain CPUs." I suspect that other folks will have some additional needs, that perhaps my idea of May 9, 2008: How about this. We add two files to each cpuset: irq_affinity_include # IRQs to direct to CPUs in this cpuset irq_affinity_exclude # IRQs -not- to direct to these CPUs where irq_affinity_exclude overrides ...
May 20, 11:34 pm 2008
Max Krasnyanskiy
Re: IRQ affinities
Looks like we arrived at the same conclusion. See my prev reply. There is actually no duplication as far as I can see because IRQ layer already This would be an overkill imho. Max --
May 20, 6:21 pm 2008
Arjan van de Ven
Re: IRQ affinities
On Tue, 20 May 2008 18:14:58 -0700 \\ why don't you tell irqbalance instead? it'll make sure the irq stays out of the wind... --
May 20, 9:45 pm 2008
Max Krasnyanskiy
Re: IRQ affinities
Hi Paul, I saw your earlier email with that proposal. Just had to digest it a bit :) That would work. But wouldn't it be hard for the users to debug things ? I mean if you have a complex cpuset hierarchy it may be hard to figure out why a certain irq is not getting to cpuX and vice versa. btw How would we represent "all irqs", are you implying that those files contain masks ? We'll also need to handle conflicts like "irq excluded from all cpusets", etc. I still prefer "irq as a task" ...
May 21, 10:58 am 2008
Max Krasnyanskiy
Re: IRQ affinities
That will be too late. By the time irqbalance sees that IRQ it may have already fired (possibly several times) on the "wrong" processor. Max --
May 21, 9:18 am 2008
Max Krasnyanskiy
Re: IRQ affinities
As Peter explained I'm focusing on the "CPU isolation" aspect. ie Shielding a CPU (or a set of CPUs) from various kernel activities (load balancing, soft and hard irq handling, workqueues, etc). For the IRQs specifically all I need is to be able to tell the kernel to not route IRQs to certain CPUs. That's mostly works already via /proc/irq/N/smp_affinity, the problem is dynamically allocated irqs because /proc/irq/N directory does not exist until those IRQs are ...
May 20, 6:14 pm 2008
Mingming
Re: [PATCH-v2] JBD: Fix race between free buffer and com ...
I was worried about the case when we call try_to_free_buffers() again, it races with the current transaction commit again. Is it possible? I guess the question is whether it is possible to have buffers on the same page attached to different transaction. If so, I think we need to keep the journal state lock while retry try_to_free_buffers(), so that the For try_to_release_page(),we should wait only when (__GFP_WAIT & Thanks, patch v3 to follow. Mingming --
May 21, 10:14 am 2008
Mingming
[PATCH 1/2][TAKE3] JBD: Fix race between free buffer and ...
Changes since take 2: - fix a bug pointed by Jan, and updated the comments journal_try_to_free_buffers() could race with jbd commit transaction when the later is holding the buffer reference while waiting for the data buffer to flush to disk. If the caller of journal_try_to_free_buffers() request tries hard to release the buffers, it will treat the failure as error and return back to the caller. We have seen the directo IO failed due to this race. Some of the caller of releasepage() also ...
May 21, 4:38 pm 2008
Mingming
[PATCH 2/2][TAKE3] JBD2: Fix race between free buffer an ...
journal_try_to_free_buffers() could race with jbd commit transaction when the later is holding the buffer reference while waiting for the data buffer to flush to disk. If the caller of journal_try_to_free_buffers() request tries hard to release the buffers, it will treat the failure as error and return back to the caller. We have seen the directo IO failed due to this race. Some of the caller of releasepage() also expecting the buffer to be dropped when passed with GFP_KERNEL mask to the ...
May 21, 4:39 pm 2008
Sergei Shtylyov
Re: [PATCH 04/22] ide: add ide_deprecated_find_port() helper
Hello. I wonder whether ide_register_hw() was much good at all since it didn't actually permit to register chips using MMIO: you couldn't pass that info via 'hw' and it set 'hwif->noprobe' to 0, thus giving you no chance to skip probing which wouldn't work anyway; for the same reason it was no good for DMA capable chips since you had not time to install ide_dma_check() and other DMA methods. Am I right here? MBR, Sergei --
May 21, 7:29 am 2008
previous daytodaynext day
May 20, 2008May 21, 2008May 22, 2008