Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- include/asm-x86/xen/hypercall.h | 6 ++ include/asm-x86/xen/interface.h | 4 + include/xen/interface/callback.h | 102 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 112 insertions(+) diff --git a/include/asm-x86/xen/hypercall.h b/include/asm-x86/xen/hypercall.h --- a/include/asm-x86/xen/hypercall.h +++ b/include/asm-x86/xen/hypercall.h @@ -161,6 +161,12 @@ return _hypercall4(int, set_callbacks, ...

The sysenter path tries to enable interrupts immediately. Unfortunately this doesn't work in a paravirt environment, because not enough kernel state has been set up at that point (namely, pointing %fs to the kernel percpu data segment). To fix this, defer ENABLE_INTERRUPTS until after the kernel state has been set up. Unfortunately this means that we're running with interrupts disabled for a while without calling the IRQ tracing code, but that can't be called without setting up %fs ...

pte_t always contains a "pte" field for the whole pte value, so make use of it. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/xen/mmu.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -216,12 +216,10 @@ pteval_t xen_pte_val(pte_t pte) { - pteval_t ret = 0; + pteval_t ret = pte.pte; - if (pte.pte_low) ...

retrigger_dynirq() was incomplete, and didn't properly set the event to be pending again. It doesn't seem to actually get used. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/xen/events.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/x86/xen/events.c b/arch/x86/xen/events.c --- a/arch/x86/xen/events.c +++ b/arch/x86/xen/events.c @@ -601,10 +601,16 @@ static int retrigger_dynirq(unsigned int irq) { int evtchn = ...

Hi Ingo, This is a great big pile of x86 unification and Xen bugfix patches. They build and boot for me on 64-bit and 32-bit (PAE and non-PAE). Patches are based on x86.git#testing as of this morning. The overview: - a couple of Xen bugfixes, which are 2.6.24 and 2.6.25 material - a bunch of x86 cleanups and unifications, mostly around pgalloc - some Xen fixes and improvements: - unify PAE/non-PAE pagetable handling - implement sysenter where applicable Thanks, J --

xen_irq_enable_direct and xen_sysexit were using "andw $0x00ff, XEN_vcpu_info_pending(vcpu)" to unmask events and test for pending ones in one instuction. Unfortunately, the pending flag must be modified with a locked operation since it can be set by another CPU, and the unlocked form of this operation was causing the pending flag to get lost, allowing the processor to return to usermode with pending events and ultimately deadlock. The simple fix would be to make it a locked operation, but ...

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/mm/pageattr.c | 2 -- include/asm-x86/pgalloc.h | 10 ++++++++++ include/asm-x86/pgalloc_32.h | 10 ---------- 3 files changed, 10 insertions(+), 12 deletions(-) diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c --- a/arch/x86/mm/pageattr.c +++ b/arch/x86/mm/pageattr.c @@ -479,9 +479,7 @@ goto out_unlock; pbase = (pte_t *)page_address(base); -#ifdef CONFIG_X86_32 ...

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/mm/init_64.c | 5 ---- arch/x86/mm/pgtable.c | 7 +++++ include/asm-x86/pgalloc.h | 52 +++++++++++++++++++++++++++++++++++++----- include/asm-x86/pgalloc_32.h | 24 ------------------- include/asm-x86/pgalloc_64.h | 29 ----------------------- 5 files changed, 53 insertions(+), 64 deletions(-) diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c --- ...

64-bit Xen supports sysenter for 32-bit guests, so support its use. (sysenter is faster than int $0x80 in 32-on-64.) sysexit is still not supported, so we fake it up using iret. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/kernel/entry_32.S | 18 +++++++++++++- arch/x86/xen/enlighten.c | 3 -- arch/x86/xen/setup.c | 21 ++++++++++++++++ arch/x86/xen/smp.c | 1 arch/x86/xen/xen-asm.S | 56 ...

Common definitions for 3-level pagetable functions. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/mm/init_64.c | 5 ----- arch/x86/mm/pgtable.c | 8 ++++++++ arch/x86/mm/pgtable_32.c | 10 ---------- include/asm-x86/pgalloc.h | 33 +++++++++++++++++++++++++++++++++ include/asm-x86/pgalloc_32.h | 32 -------------------------------- include/asm-x86/pgalloc_64.h | 24 ------------------------ 6 files changed, 41 ...

Make KERNEL_PGD_PTRS common, as previously it was only being defined for 32-bit. There are a couple of follow-on changes from this: - KERNEL_PGD_PTRS was being defined in terms of USER_PGD_PTRS. The definition of USER_PGD_PTRS doesn't really make much sense on x86-64, since it can have two different user address-space configurations. I renamed USER_PGD_PTRS to KERNEL_PGD_BOUNDARY, which is meaningful for all of 32/32, 32/64 and 64/64 process configurations. - USER_PTRS_PER_PGD ...

Xen's pte operations on mfns can be unified like the kernel's pfn operations. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- include/xen/page.h | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/include/xen/page.h b/include/xen/page.h --- a/include/xen/page.h +++ b/include/xen/page.h @@ -125,37 +125,37 @@ #define virt_to_mfn(v) (pfn_to_mfn(PFN_DOWN(__pa(v)))) #define mfn_to_virt(m) (__va(mfn_to_pfn(m) << ...

Add a common arch/x86/mm/pgtable.c file for common pagetable functions. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/mm/Makefile | 2 arch/x86/mm/pgtable.c | 239 ++++++++++++++++++++++++++++++++++++++++++ arch/x86/mm/pgtable_32.c | 187 -------------------------------- include/asm-x86/pgalloc.h | 18 +++ include/asm-x86/pgalloc_32.h | 11 - include/asm-x86/pgalloc_64.h | 67 ----------- 6 files changed, 258 insertions(+), ...

We need to set up the shared_info pointer once we've mapped the real shared_info into its fixmap slot. That needs to happen once the general pagetable setup has been done. Previously, the UP shared_info was set up one in xen_start_kernel, but that was left pointing to the dummy shared info. Unfortunately there's no really good place to do a later setup of the shared_info in UP, so just do it once the pagetable setup has been done. [ Stable: needed in 2.6.24.x ] Signed-off-by: Jeremy ...

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/kernel/paravirt.c | 2 ++ arch/x86/mm/pgtable.c | 1 + include/asm-x86/paravirt.h | 11 +++++++++++ include/asm-x86/pgalloc.h | 3 +++ 4 files changed, 17 insertions(+) diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c --- a/arch/x86/kernel/paravirt.c +++ b/arch/x86/kernel/paravirt.c @@ -385,8 +385,10 @@ .alloc_pte = paravirt_nop, .alloc_pmd = paravirt_nop, ...

Use jmp rather than call for the iret fixup, so its consistent with the sysexit fixup, and it simplifies the stack (which is already complex). Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/kernel/entry_32.S | 3 +-- arch/x86/xen/xen-asm.S | 22 +++++++++------------- 2 files changed, 10 insertions(+), 15 deletions(-) diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S --- a/arch/x86/kernel/entry_32.S +++ ...

[Empty message]

This has nothing to do with /dev/stdout. Your terminal simply does not allow access by anyone except user root or group tty. You need to open it up first, or mount /dev/pts with broader permissions (which is a bad idea however). 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." --

Just something like this? Completely untested as I've not the hardware anymore. Googling for an old lspci, I had a revision 0x63, and Lev has a revision 0x65. The VT6212(L) should be 0x60+ it seems. The "CC:" should be a "Tested-by:" if that's actually the case. But yes, as he also asked, should this be the fix at all? Rene.

Missing update to Documentation/sysrq.txt. Patch description, diffstat, & sob should come before the patch. And I propose that we reserve sysrq-j for extending sysrq keys in the --- ~Randy --

While looking at the generic semaphore patch, I came to wonder what the remaining semaphore users in the kernel were actually doing. After a quick grep for down_interruptible(), smackfs remained at the bottom of my screen. It seems like a straightforward mutex case - low-hanging fruit. So here's a conversion patch; compile-tested only, but what could go wrong? jon Convert smackfs from a semaphore to a mutex Signed-off-by: Jonathan Corbet <corbet@lwn.net> diff --git ...

new version about boundary check.

Ack-ed by: Eric Paris <eparis@redhat.com> --

ITYM Acked-by :-) -- James Morris <jmorris@namei.org> --

From: Miklos Szeredi <mszeredi@suse.cz> On mount propagation, let the owner of the clone be inherited from the parent into which it has been propagated. If the parent has the "nosuid" flag, set this flag for the child as well. This is needed for the suid-less namespace (use case #2 in the first patch header), where all mounts are owned by the user and have the nosuid flag set. In this case the propagated mount needs to have nosuid, otherwise a suid executable may be misused by the ...

From: Miklos Szeredi <mszeredi@suse.cz> Allow bind mounts to unprivileged users if the following conditions are met: - mountpoint is not a symlink - parent mount is owned by the user - the number of user mounts is below the maximum Unprivileged mounts imply MS_SETUSER, and will also have the "nosuid" and "nodev" mount flags set. In particular, if mounting process doesn't have CAP_SETUID capability, then the "nosuid" flag will be added, and if it doesn't have CAP_MKNOD capability, ...

From: Miklos Szeredi <mszeredi@suse.cz> Add sysctl variables for accounting and limiting the number of user mounts. The maximum number of user mounts is set to 1024 by default. This won't in itself enable user mounts, setting a mount to be owned by a user is first needed. [akpm] - don't use enumerated sysctls Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> Acked-by: Serge Hallyn <serue@us.ibm.com> --- Documentation/filesystems/proc.txt | 9 ++++ fs/namespace.c ...

Andrew, Al, Please consider adding this series to your trees. I've been using these patches for a while on my laptop to mount fuse filesystems as user, without any suid-root helpers. The setup is as follows: - link /proc/mounts to /etc/mtab - patch util-linux-ng with http://lkml.org/lkml/2008/1/16/103 - remove suid from mount, umount and fusermount - add a line to /etc/fstab to bind mount ~/mnt onto itself owned by the user - add 'fs.types.fuse.usermount_safe = 1' to ...

From: Miklos Szeredi <mszeredi@suse.cz> This patchset adds support for keeping mount ownership information in the kernel, and allow unprivileged mount(2) and umount(2) in certain cases. The mount owner has the following privileges: - unmount the owned mount - create a submount under the owned mount The sysadmin can set the owner explicitly on mount and remount. When an unprivileged user creates a mount, then the owner is automatically set to the user. The following use cases are ...

From: Miklos Szeredi <mszeredi@suse.cz> Add the following: /proc/sys/fs/types/${FS_TYPE}/usermount_safe Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> Acked-by: Serge Hallyn <serue@us.ibm.com> --- Documentation/filesystems/proc.txt | 31 +++++++++++++++++++ fs/filesystems.c | 60 +++++++++++++++++++++++++++++++++++++ include/linux/fs.h | 1 3 files changed, 92 insertions(+) Index: ...

Built-in code can't use functions in a modular ACPI dock driver. This patch fixes the following build error reported by Thomas Meyer: <-- snip --> ... LD .tmp_vmlinux1 drivers/built-in.o: In function `ata_acpi_associate': (.text+0x7106a): undefined reference to `register_hotplug_dock_device' drivers/built-in.o: In function `ata_acpi_associate': (.text+0x710bd): undefined reference to `register_hotplug_dock_device' make: *** [.tmp_vmlinux1] Fehler 1 <-- snip ...

-ENODOTCONFIG 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 --

Looks like I added a bogus target (no dts file for the board yet) and didn't match correctly the init code for the other two. Please try this: --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -253,7 +253,6 @@ image-$(CONFIG_TQM8540) += cuImage.tqm85 image-$(CONFIG_TQM8541) += cuImage.tqm8541 image-$(CONFIG_TQM8555) += cuImage.tqm8555 image-$(CONFIG_TQM8560) += ...

It doesn't fix the build, and adds sbc8560_defconfig to the list of non-compiling defconfigs: <-- snip --> ... WRAP arch/powerpc/boot/cuImage.sbc8560 DTC: dts->dtb on file "/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/dts/sbc8560.dts" powerpc64-linux-ld: arch/powerpc/boot/cuboot-sbc8560.o: No such file: No such file or directory make[2]: *** [arch/powerpc/boot/cuImage.sbc8560] Error 1 cu Adrian -- "Is there not promise of rain?" Ling Tan asked ...

On Mon, Mar 17, 2008 at 4:46 PM, Paul Gortmaker Heh; oops. I looked but somehow missed them. I guess I didn't look hard enough. Acked-by: Grant Likely <grant.likely@secretlab.ca> Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. --

On Mon, Mar 17, 2008 at 2:07 PM, Paul Gortmaker No, the suffix in the cuImage targets has a 1:1 relationship with dts files in arch/powerpc/boot/dts/. If a file doesn't exist there, then the target cannot be built. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. --

James, Sure I will send more details. Thanks. Bo Yang -----Original Message----- From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com] Sent: Monday, March 17, 2008 4:55 PM To: Yang, Bo Cc: linux-scsi@vger.kernel.org; akpm@osdl.org; linux-kernel@vger.kernel.org; Patro, Sumant; Kolli, Neela Subject: Re: [PATCH 4/4] scsi: megaraid_sas - Update the Version andChangelog It would be nice if the git change log were this detailed, as well Where did this change come ...

Add the new Controller (ID: 007C) support to driver. Signed-off-by Bo Yang<bo.yang@lsi.com> --- drivers/scsi/megaraid/megaraid_sas.c | 7 +++++-- drivers/scsi/megaraid/megaraid_sas.h | 1 + 2 files changed, 6 insertions(+), 2 deletions(-) diff -rupN linux-2.6.24_orig/drivers/scsi/megaraid/megaraid_sas.c linux-2.6.24_new/drivers/scsi/megaraid/megaraid_sas.c --- linux-2.6.24_orig/drivers/scsi/megaraid/megaraid_sas.c 2008-03-17 13:53:49.000000000 -0400 +++ ...

It would be nice if the git change log were this detailed, as well Where did this change come from? It's not in any of this change set that I can see. James --

From: Nick Piggin <npiggin@suse.de> Introduce fuse_perform_write. With fusexmp (a passthrough filesystem), large (1MB) writes into a backing tmpfs filesystem are sped up by almost 4 times (256MB/s vs 71MB/s). [mszeredi@suse.cz]: - split into smaller functions - testing - duplicate generic_file_aio_write(), so that there's no need to add a new ->perform_write() a_op. Comment from hch. Signed-off-by: Nick Piggin <npiggin@suse.de> Signed-off-by: Miklos Szeredi ...

From: Miklos Szeredi <mszeredi@suse.cz> Quoting Linus (3 years ago, FUSE inclusion discussions): "User-space filesystems are hard to get right. I'd claim that they are almost impossible, unless you limit them somehow (shared writable mappings are the nastiest part - if you don't have those, you can reasonably limit your problems by limiting the number of dirty pages you accept through normal "write()" calls)." Instead of attempting the impossible, I've just waited for the ...

From: Miklos Szeredi <mszeredi@suse.cz> Fuse will use temporary buffers to write back dirty data from memory mappings (normal writes are done synchronously). This is needed, because there cannot be any guarantee about the time in which a write will complete. By using temporary buffers, from the MM's point if view the page is written back immediately. If the writeout was due to memory pressure, this effectively migrates data from a full zone to a less full zone. This patch adds a new ...

From: Miklos Szeredi <mszeredi@suse.cz> Fuse needs this for writable mmap support. Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> --- include/linux/backing-dev.h | 2 ++ mm/page-writeback.c | 10 ++++++++++ 2 files changed, 12 insertions(+) Index: linux/include/linux/backing-dev.h =================================================================== --- linux.orig/include/linux/backing-dev.h 2008-03-17 18:24:13.000000000 +0100 +++ ...

ecryptfs_d_release() is doing a mntput before doing the dput. This patch moves the dput before the mntput. Thanks to Rajouri Jammu for reporting this. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> --- diff --git a/fs/ecryptfs/dentry.c b/fs/ecryptfs/dentry.c index 841a032..5e59658 100644 --- a/fs/ecryptfs/dentry.c +++ b/fs/ecryptfs/dentry.c @@ -80,8 +80,8 @@ static void ecryptfs_d_release(struct dentry *dentry) { if (ecryptfs_dentry_to_private(dentry)) { if ...

Implement a cgroup to track and enforce open and mknod restrictions on device files. A device cgroup associates a device access whitelist with each cgroup. A whitelist entry has 4 fields. 'type' is a (all), c (char), or b (block). 'all' means it applies to all types and all major and minor numbers. Major and minor are either an integer or * for all. Access is a composition of r (read), w (write), and m (mknod). The root device cgroup starts with rwm to 'all'. A child devcg gets a copy of ...

On Mon, Mar 17, 2008 at 11:36 AM, Stephen Neuendorffer Acked-by: Grant Likely <grant.likely@secretlab.ca> -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. --

On Mon, Mar 17, 2008 at 11:36 AM, Stephen Neuendorffer Looks good to me -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. --

The following sequence of patches makes the icap driver more robust, by making better use of the status information from the cores. In addition, Lanana has assigned Major 259 for FPGA configuration interfaces, so we now use it, rather than dynamically finding a major number. Grant: please pick these up for 2.6.26. Do you think it's worth patching virtex_devices.c at this point, or just punt on ARCH=ppc? Steve --

It appears that in some cases, the sync word might not be recognized by the hardware correctly. If this happens, then attempting to read from the port results in an unrecoverable error because of the design of the FPGA core. This patch updates the code to check the status of the device before reading the IDCODE, in order to avoid entering this unrecoverable state. This patch also adds additional NOOP commands into the sychronization sequence, which appears to be necessary to avoid the ...

With kernel version 2.6.24.3, I sometimes get an unexpected SIGTRAP signal during the evaluation of a function call on the gdb command line. This problem does not occur with kernel version 2.6.23.12 running on the same machine. Both gdb-6.4.90 and gdb-6.7.1 exhibit this behavior. I can reproduce the problem as follows: $ cat > bug.c int x; int foo(void) { return 42; } int main(int argc, char* argv[]) { x++; return 0; } ^D $ cat > bug.gdb b main r s p foo() p foo() ^D $ ...

On Mon, 17 Mar 2008 11:43:28 -0500 Different issue. I can hijack a connection. Imagine I have a server bound to *.5000, and someone is about to connect. If on the server box I am able to bind and issue a connect outwards matching the inbound connection I will get the connection not the server. --

Signed-off-by: Alan D. Brunelle <alan.brunelle@hp.com> --- arch/ia64/kernel/smp.c | 8 ++++++-- arch/x86/kernel/smp_32.c | 8 ++++++-- arch/x86/kernel/smp_64.c | 8 ++++++-- include/linux/smp.h | 1 + kernel/smp.c | 34 ++++++++++++++++++++-------------- 5 files changed, 39 insertions(+), 20 deletions(-) diff --git a/arch/ia64/kernel/smp.c b/arch/ia64/kernel/smp.c index 04ba9f8..52225bb 100644 --- a/arch/ia64/kernel/smp.c +++ b/arch/ia64/kernel/smp.c @@ ...

I agree with doing it this way, re-checking and doing another run (or more). However I think we can improve it a bit so we don't always have to grab the dst lock at least twice - it should be safe enough to include the lock only inside the first loop, doing an smp_mb() before the list_empty() check and again at the bottom before looping around and doing the list_empty() check again. I've rolled a new patch series ...

This is included in the later series. -- Jens Axboe --

This is starting to look pretty good! Thanks a lot for these results, and the ->activated optimizations. I had a feeling the unstable results were something like this, missing ipi's. -- Jens Axboe --

After a discussion with the autor of the original patch adding support for Apple's new aluminium keyboards (a45d82d19a6c2a717bcc33cff243199b77fa0082), Michel Dänzer, we decided that some changes should be done. Please push this patch into 2.6.25 before it's released. Changing the key codes later might confuse users. Signed-off-by: Michael Hanselmann <linux-kernel@hansmi.ch> --- --- linux-2.6.25-rc6.orig/drivers/hid/hid-input.c 2008-03-17 15:46:52.000000000 +0100 +++ ...

It indeed does. I will queue it in my tree, thanks a lot. --=20 Jiri Kosina SUSE Labs

Could we have this patch or something similar in 2.6.25, please? It's broken doing a test_bit() on an int since the result is random whenever sizeof(int) != sizeof(long). It might also lead to exceptions if an architecture requires a sizeof(long) alignment for test_bit(). --

VL is vesa local ... it was an ISA like graphics bus that was fast and It will definitely work for EISA and VL bus. I think if you analyse the placement of kernel data segments for compiled in drivers, it might also work for ISA too, since I think the pfn will be low enough. It should fail as a module not just because the area will be out of range for ISA, but also because the module data segment is in vmalloc space, so the virt_to_bus assumptions of contiguity could be ...

It will work compiled in, and probably users of such cards if any don't have > 16MB. I doubt anyone is using the driver however. Alan --

Error handling here, I'm afraid; dma_alloc_coherent can return NULL. Other than that, looks great. James --

No ... ISA definitely requires it. James --

Two things I'm trying to solve with my fc hardware. How do I enable these for IP networking, and how do I offer say lvm logical volumes behind Linux as a SAN? I'd like nodes to be bootable and offer specific volumes as their disks. I'm using 2.6.28 As for networking, I vaguely remember setting up IPv4 on fibre channel some time ago. So far I have two hosts connected to a Compaq Storage Works FC arbitrated loop. Each host has Online for /sys/class/fc_host/hostN/port_state. I can't ...

The task_struct->tgid field is about to become deprecated, due to pid namespaces make tasks have many pids, not one. There is one place using it left to fix in infiniband - the make_cm_node(). This function uses the task tgid just to generate a session id, so it's perfectly safe to use appropriate wrapper - task_tgid_nr(). Signed-off-by: Pavel Emelyanov <xemul@openvz.org> --- drivers/infiniband/hw/nes/nes_cm.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git ...

The task_struct->tgid field is about to become deprecated, due to pid namespaces make tasks have many pids, not one. The infiniband driver is one of the code, that still uses it in some places. First make struct ehca_pd use a struct pid pointer and consolidate owners check into one call (saves space). Signed-off-by: Pavel Emelyanov <xemul@openvz.org> --- drivers/infiniband/hw/ehca/ehca_av.c | 18 +++--------------- drivers/infiniband/hw/ehca/ehca_classes.h | 2 +- ...

hm, this broke the build, the attached (common) config fails with: LD .tmp_vmlinux1 drivers/built-in.o: In function `ata_acpi_associate': (.text+0xc3984): undefined reference to `register_hotplug_dock_device' drivers/built-in.o: In function `ata_acpi_associate': (.text+0xc39d1): undefined reference to `register_hotplug_dock_device' make: *** [.tmp_vmlinux1] Error 1 Ingo

Notes: * the devres change is included here because the ahci fix needs it Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git upstream-linus to receive the following updates: drivers/ata/ahci.c | 72 ++++++++++++++++++++++----------- drivers/ata/libata-acpi.c | 96 ++++++++++++++++++++++++++++++++------------- drivers/ata/pata_ali.c | 2 +- include/linux/pci.h | 2 + lib/devres.c | 25 ...

Notes: 1) This includes a drivers/atm patch from Al (I don't usually take drivers/atm patches, but it came straight to me) 2) the drivers/sn change came from the maintainer, so it seemed fine to push it this way, along with the drivers/net/ioc3-eth changes 3) the forcedeth change is a critical fix Please pull from 'upstream-davem' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-davem to receive the following updates: drivers/atm/fore200e.c ...

You won the sum of

> % ./hackbench 130 process 500 I'd like to reproduce your results so I can make a new version of the ptc.g patch that doesn't have this regression. I found this version (that claims to be the latest) of hackbench.c http://people.redhat.com/mingo/cfs-scheduler/tools/hackbench.c Is this the one you used? What was the configuration of your machine (how many cpus, how much memory)? Thanks -Tony --

Thank you very much for your testing, and for isolating the How long does hackbench take to complete on 2.6.25-rc5? I'll revert it while I investigate the cause of this Me too! -Tony --

cpu: Itanium2 x8 mem: 8GB(4GB x2 node) Thanks. --

Hello, Can any one tell me why ip_rcv, ip_output is not exported in 2.6 kernel. If I have to use this function in kernel module what should be the approach. Do I need to export it, in kernel code or there is any other alternative. Thanks Murtuja Bharmal Meet people who discuss and share your passions. Go to http://in.promos.yahoo.com/groups --

In case we're accounting from a sub-namespace, the tgids reported will not refer to the right namespace. Save the pid_namespace we're accounting in on the acct_glbs and use it in do_acct_process. Two less :) places using the task_struct.tgid member. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> --- kernel/acct.c | 21 +++++++++++++++------ 1 files changed, 15 insertions(+), 6 deletions(-) diff --git a/kernel/acct.c b/kernel/acct.c index 7ff5339..91e1cfd 100644 --- ...

Although the "select" that started this thread was certainly erroneous, this doesn't look right either. THERMAL should not depend on or select HWMON. Instead, part of its code that is there for the benefit of HWMON should depend on HWMON. Based on Jean's last message, that code should probably get its own sub-config option, CONFIG_THERMAL_HWMON that is default N for the benefit of old libraries. Similarly, ACPI_THERMAL should not depend on THERMAL, instead the code that registers with ...

From: Heiko Carstens <heiko.carstens@de.ibm.com> git commit 3152fb9f11cdd2fd8688c2c5cb805e5c09b53dd9 "thermal: fix generic thermal I/F for hwmon" adds a select HWMON to THERMAL. This causes HWMON to be selected regardless of its other dependencies. In this case depends on HAS_IOMEM gets ignored which causes this build error on s390: drivers/hwmon/w83627hf.c: In function 'superio_outb': drivers/hwmon/w83627hf.c:117: error: implicit declaration of function 'outb' Change the select to a ...

zlc_setup(): handle jiffies wraparound (10ed273f5016c582413dfbc468dd084957d847e1) changes tab with spaces CC: Lee Schermerhorn <Lee.Schermerhorn@hp.com> CC: Paul Jackson <pj@sgi.com> Cc: Andrew Morton <akpm@linux-foundation.org> --- mm/page_alloc.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 402a504..363c948 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -1284,7 +1284,7 @@ static nodemask_t *zlc_setup(struct ...

The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values. So following patch implements usage of the time_after() macro, defined at linux/jiffies.h, which deals with wrapping correctly Cc: linux-wireless@vger.kernel.org Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: S.Çağlar Onur <caglar@pardus.org.tr> --- net/mac80211/rc80211_simple.c | 3 ++- net/mac80211/rx.c | 3 ++- 2 files ...

On Mon, 17 Mar 2008 11:36:26 +0200 S.=C3=87a=C4=9Flar Onur <caglar@pardus.o= Acked-by: Stephen Rothwell <sfr@canb.auug.org.au> --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/

The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values. So following patch implements usage of the time_after() macro, defined at linux/jiffies.h, which deals with wrapping correctly Cc: netdev@vger.kernel.org Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: S.Çağlar Onur <caglar@pardus.org.tr> --- drivers/net/tokenring/3c359.c | 21 +++++++++++---------- 1 files changed, 11 insertions(+), 10 ...

Hi, On Mon, Mar 17, 2008 at 11:36:25AM +0200, S.?a??lar Onur wrote: I prefer the idea of using printk_ratelimit. I've committed a patch that does this to git and credited you with pointing it out. --

The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values. So following patch implements usage of the time_after() macro, defined at linux/jiffies.h, which deals with wrapping correctly Cc: Richard Henderson <rth@twiddle.net> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: S.Çağlar Onur <caglar@pardus.org.tr> --- arch/alpha/kernel/traps.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff ...

The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values. So following patch implements usage of the time_after() macro, defined at linux/jiffies.h, which deals with wrapping correctly Cc: linuxppc-dev@ozlabs.org Cc: Paul Mackerras <paulus@samba.org> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: S.Çağlar Onur <caglar@pardus.org.tr> --- arch/powerpc/platforms/iseries/pci.c | 3 ++- 1 files changed, 2 ...

Use force_sig in handle_vm86_trap like other machine traps do. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/x86/kernel/vm86_32.c | 9 +-------- 1 files changed, 1 insertions(+), 8 deletions(-) diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c index 738c210..fddb998 100644 --- a/arch/x86/kernel/vm86_32.c +++ b/arch/x86/kernel/vm86_32.c @@ -553,16 +553,9 @@ int handle_vm86_trap(struct kernel_vm86_regs * regs, long error_code, int trapno } if (trapno ...

--

As a side effect, remove unused idetape_kfree_stage() and idetape_abort_pipeline() Signed-off-by: Borislav Petkov <petkovbb@gmail.com> --- drivers/ide/ide-tape.c | 83 ------------------------------------------------ 1 files changed, 0 insertions(+), 83 deletions(-) diff --git a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c index 7e0f4fa..3eeb5c0 100644 --- a/drivers/ide/ide-tape.c +++ b/drivers/ide/ide-tape.c @@ -686,37 +686,6 @@ static void __idetape_kfree_stage(idetape_stage_t ...

idetape_queue_pc_tail() is a wrapper for its __idetape_queue_pc_tail() counterpart and has no other functionality. Remove it and call the "wrapped" function directly. Signed-off-by: Borislav Petkov <petkovbb@gmail.com> --- drivers/ide/ide-tape.c | 11 +++-------- 1 files changed, 3 insertions(+), 8 deletions(-) diff --git a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c index 3eeb5c0..a85866a 100644 --- a/drivers/ide/ide-tape.c +++ b/drivers/ide/ide-tape.c @@ -1631,7 +1631,7 @@ static ...

Signed-off-by: Borislav Petkov <petkovbb@gmail.com> --- drivers/ide/ide-tape.c | 34 +++++----------------------------- 1 files changed, 5 insertions(+), 29 deletions(-) diff --git a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c index 5535356..1464383 100644 --- a/drivers/ide/ide-tape.c +++ b/drivers/ide/ide-tape.c @@ -204,19 +204,15 @@ enum { /* 0 When the tape position is unknown */ IDETAPE_FLAG_ADDRESS_VALID = (1 << 1), /* Device already opened */ - IDETAPE_FLAG_BUSY = (1 ...

Signed-off-by: Borislav Petkov <petkovbb@gmail.com> --- drivers/ide/ide-tape.c | 40 ++++------------------------------------ 1 files changed, 4 insertions(+), 36 deletions(-) diff --git a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c index c612c8c..0056a26 100644 --- a/drivers/ide/ide-tape.c +++ b/drivers/ide/ide-tape.c @@ -2690,11 +2690,10 @@ static inline void idetape_add_settings(ide_drive_t *drive) { ; } */ static void idetape_setup(ide_drive_t *drive, idetape_tape_t *tape, int ...

Signed-off-by: Borislav Petkov <petkovbb@gmail.com> --- Documentation/ide/ide-tape.txt | 132 ++++++++++++++++++++-------------------- 1 files changed, 65 insertions(+), 67 deletions(-) diff --git a/Documentation/ide/ide-tape.txt b/Documentation/ide/ide-tape.txt index 51f596b..3f348a0 100644 --- a/Documentation/ide/ide-tape.txt +++ b/Documentation/ide/ide-tape.txt @@ -1,67 +1,65 @@ -/* - * IDE ATAPI streaming tape driver. - * - * This driver is a part of the Linux ide driver. - * - * ...

Signed-off-by: Borislav Petkov <petkovbb@gmail.com> --- Documentation/ide/ide-tape.txt | 79 ---------------------------------------- 1 files changed, 0 insertions(+), 79 deletions(-) diff --git a/Documentation/ide/ide-tape.txt b/Documentation/ide/ide-tape.txt index 658f271..51f596b 100644 --- a/Documentation/ide/ide-tape.txt +++ b/Documentation/ide/ide-tape.txt @@ -8,8 +8,6 @@ * interface, on the other hand, creates new requests, adds them * to the request-list of the block device, ...

Signed-off-by: Borislav Petkov <petkovbb@gmail.com> --- drivers/ide/ide-tape.c | 22 +++------------------- 1 files changed, 3 insertions(+), 19 deletions(-) diff --git a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c index 9ae42c3..a4caf2b 100644 --- a/drivers/ide/ide-tape.c +++ b/drivers/ide/ide-tape.c @@ -265,9 +265,7 @@ typedef struct ide_tape_obj { * While polling for DSC we use postponed_rq to postpone the current * request so that ide.c will be able to service pending ...

Signed-off-by: Borislav Petkov <petkovbb@gmail.com> --- drivers/ide/ide-tape.c | 11 ++++------- 1 files changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c index 86be926..b931547 100644 --- a/drivers/ide/ide-tape.c +++ b/drivers/ide/ide-tape.c @@ -1619,7 +1619,7 @@ static int idetape_copy_stage_from_user(idetape_tape_t *tape, } static int idetape_copy_stage_to_user(idetape_tape_t *tape, char __user *buf, - idetape_stage_t *stage, ...

Signed-off-by: Borislav Petkov <petkovbb@gmail.com> --- drivers/ide/ide-tape.c | 79 ++++------------------------------------------- 1 files changed, 7 insertions(+), 72 deletions(-) diff --git a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c index 1464383..9ae42c3 100644 --- a/drivers/ide/ide-tape.c +++ b/drivers/ide/ide-tape.c @@ -307,12 +307,8 @@ typedef struct ide_tape_obj { * At most, there is only one ide-tape originated data transfer request * in the device request queue. ...

The PT_DTRACE flag is meaningless and obsolete. Don't touch it. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/powerpc/kernel/process.c | 5 ----- arch/powerpc/kernel/sys_ppc32.c | 5 ----- 2 files changed, 0 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c index 4846bf5..7c8e3da 100644 --- a/arch/powerpc/kernel/process.c +++ b/arch/powerpc/kernel/process.c @@ -862,11 +862,6 @@ int sys_execve(unsigned long a0, ...

When we're stopped at syscall entry tracing, ptrace can change the %rax value from -ENOSYS to something else. If no system call is actually made because the syscall number (now in orig_rax) is bad, then we now always reset %rax to -ENOSYS again. This changes it to leave the return value alone after entry tracing. That way, the %rax value set by ptrace is there to be seen in user mode (or in syscall exit tracing). This is consistent with what the 32-bit kernel does. Signed-off-by: Roland ...

Hi if revert following patch [IA64] Multiple outstanding ptc.g instruction support then this problem doesn't reproduce. I attached that revert patch.

致贵公司（厂）财务部协议书 尊贵的先生（小姐）您好！ 推出此项业务是双方公司的利益，是一项双赢的业务，本公司每月都有发票剩余，因此愿为有需要的客户代理开具发票。 本公司有增值税专用发票、普通发票，还可提供多家公司及不同性质的发票、海关进口增值、建筑业、广告业、运输业、服务业等。点数优惠、发票真实有效可验证后付款。 若有不明，欢迎来电洽谈，若有打搅、敬请谅解！本公司将真诚与您长期合作！ 顺祝商祺！ 联系电话：0512-67138515 王小姐( 苏州广达新公司) MSN:sale-account2008@hotmail.com QQ:954661604 建议您保留本邮件

Ok - good plan. Do you know offhand what would be the correct HW list for hugepages and hugepagesz? -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.940.382.4214 --

That one and Add basic support for more than one hstate in hugetlbfs and partly Add support to have individual hstates for each hugetlbfs mount It all builds on each other. Ideally look at the end result of the whole series. -Andi --

Add an hugepagesz=... option similar to IA64, PPC etc. to x86-64. This finally allows to select GB pages for hugetlbfs in x86 now that all the infrastructure is in place. Signed-off-by: Andi Kleen <ak@suse.de> --- Documentation/kernel-parameters.txt | 11 +++++++++-- arch/x86/mm/hugetlbpage.c | 17 +++++++++++++++++ include/asm-x86/page.h | 2 ++ 3 files changed, 28 insertions(+), 2 deletions(-) Index: ...

Signed-off-by: Andi Kleen <ak@suse.de> --- arch/x86/mm/hugetlbpage.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) Index: linux/arch/x86/mm/hugetlbpage.c =================================================================== --- linux.orig/arch/x86/mm/hugetlbpage.c +++ linux/arch/x86/mm/hugetlbpage.c @@ -133,9 +133,14 @@ pte_t *huge_pte_alloc(struct mm_struct * pgd = pgd_offset(mm, addr); pud = pud_alloc(mm, pgd, addr); if (pud) { - if ...

I chose to just report the numbers in a row, in the hope to minimze breakage of existing software. The "compat" page size is always the first number. Signed-off-by: Andi Kleen <ak@suse.de> --- mm/hugetlb.c | 59 +++++++++++++++++++++++++++++++++++++++-------------------- 1 file changed, 39 insertions(+), 20 deletions(-) Index: linux/mm/hugetlb.c =================================================================== --- linux.orig/mm/hugetlb.c +++ linux/mm/hugetlb.c @@ -683,37 +683,56 ...

Andi, Are all the "interesting" cpuset related changes in patch: [PATCH] [1/18] Convert hugeltlb.c over to pass global state around in a structure ? -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.940.382.4214 --

Fixed thanks. Indeed description went wrong on 4/18 2/ was the correct one. -Andi --

i = ALIGN(i+offset, incr) - offset; also the one in fail_block... only happen when align is large than alignment of node_boot_start. YH --

This patchkit supports GB pages for hugetlb on x86-64 in addition to 2MB pages. This is the sucessor of an earlier much simpler patchkit that allowed to set the hugepagesz globally at boot to 1GB pages. The advantage of this more complex patchkit is that it allows 2MB page users and 1GB page users to coexist (although not on the same hugetlbfs mount points) It first adds some straight-forward infrastructure to hugetlbfs to support multiple page sizes. Then it uses that infrastructure ...

This was against 2.6.25-rc4 -Andi --

Well, from what I can see, Ken Chen wrote the code that deals with constraints on hugetlb allocation. So I'll copy him on this reply, along with the other two subject matter experts I know of in this area, Christoph Lameter and Adam Litke. The following is the only cpuset related change I saw in this patchset. It looks pretty obvious to me ... just changing the code to adapt to Andi's new 'struct hstate' for holding what had been global hugetlb state. @@ -1228,18 +1252,18 @@ static int ...

No the later patch only supports GB and MB. If you want KB you have to do it yourself. If there was a reason I forgot it. Doesn't really matter much either way. -Andi --

I didn't see anything fundamentally wrong with this... In fact it is looking really nice notwithstanding the minor nits below. Could you define a macro for (1 << huge_page_order(h))? It is used at least 4 times. How about something like pages_per_huge_page(h) or something? I think that would convey the meaning more clearly. Whitespace? Whitespace? -- Adam Litke - (agl at us.ibm.com) IBM Linux Technology Center --

- Add a new pagesize= option to the hugetlbfs mount that allows setting the page size - Set up pointers to a suitable hstate for the set page size option to the super block and the inode and the vma. - Change the hstate accessors to use this information - Add code to the hstate init function to set parsed_hstate for command line processing - Handle duplicated hstate registrations to the make command line user proof Signed-off-by: Andi Kleen <ak@suse.de> --- fs/hugetlbfs/inode.c | ...

With this patch you will call try_to_free_low on all registered page sizes. As written, when a user reduces the number of one page size, all page sizes could be affected. I don't think that's what you want to do. Perhaps just call do_try_to_free_low() on the hstate in question. -- Adam Litke - (agl at us.ibm.com) IBM Linux Technology Center --

No offset is not enough because it is still relative to the zone start. I'm preparing an updated patch. -Andi --

Andi wrote: + hugepages= [HW,X86-32,IA-64] HugeTLB pages to allocate at boot. + hugepagesz= [HW,IA-64,PPC,X86-64] The size of the HugeTLB pages. + On x86 this option can be specified multiple times + interleaved with hugepages= to reserve huge pages + of different sizes. Valid pages sizes on x86-64 + are 2M (when the CPU supports "pse") and 1G (when the + CPU supports the "pdpe1gb" cpuinfo flag) + Note that 1GB pages can only be allocated at boot time + using hugepages= and not ...

how about create local node_boot_start and node_bootmem_map that make sure node_boot_start has bigger alignment than align input. YH --

hugetlb will need to get compound pages from bootmem to handle the case of them being larger than MAX_ORDER. Export the constructor function needed for this. Signed-off-by: Andi Kleen <ak@suse.de> --- mm/internal.h | 2 ++ mm/page_alloc.c | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) Index: linux/mm/internal.h =================================================================== --- linux.orig/mm/internal.h +++ linux/mm/internal.h @@ -13,6 +13,8 @@ #include ...

Needed to avoid code duplication in follow up patches. This happens to fix a minor bug. When alloc_bootmem_node returns a fallback node on a different node than passed the old code would have put it into the free lists of the wrong node. Now it would end up in the freelist of the correct node. Signed-off-by: Andi Kleen <ak@suse.de> --- mm/hugetlb.c | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) Index: ...

I just updated to 2.6.25-rc6 base on ftp://firstfloor.org/pub/ak/gbpages/patches/ and gave it a quick test. So you can use that one too. It only had a single easy reject. -Andi --

Signed-off-by: Andi Kleen <ak@suse.de> --- include/linux/hugetlb.h | 1 + mm/hugetlb.c | 23 ++++++++++++++++++----- 2 files changed, 19 insertions(+), 5 deletions(-) Index: linux/mm/hugetlb.c =================================================================== --- linux.orig/mm/hugetlb.c +++ linux/mm/hugetlb.c @@ -552,19 +552,23 @@ static int __init hugetlb_init_hstate(st { unsigned long i; - for (i = 0; i < MAX_NUMNODES; ...

Signed-off-by: Andi Kleen <ak@suse.de> --- mm/hugetlb.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) Index: linux/mm/hugetlb.c =================================================================== --- linux.orig/mm/hugetlb.c +++ linux/mm/hugetlb.c @@ -550,26 +550,33 @@ static unsigned int cpuset_mems_nr(unsig #ifdef CONFIG_SYSCTL #ifdef CONFIG_HIGHMEM -static void try_to_free_low(unsigned long count) +static void do_try_to_free_low(struct hstate *h, ...

when node_boot_start is 512M alignment, and align is 1024M, offset could be 512M. it seems i = ALIGN(i, incr) need to do sth with offset... YH --

- Convert hstates to an array - Add a first default entry covering the standard huge page size - Add functions for architectures to register new hstates - Add basic iterators over hstates Signed-off-by: Andi Kleen <ak@suse.de> --- include/linux/hugetlb.h | 10 +++++++++- mm/hugetlb.c | 46 +++++++++++++++++++++++++++++++++++++--------- 2 files changed, 46 insertions(+), 10 deletions(-) Index: ...

Hello! In the process of writing up the mechanical proof of correctness for the dynticks/preemptable-RCU interface, I noticed misplaced memory barriers in rcu_enter_nohz() and rcu_exit_nohz(). This patch puts them in the right place and adds a comment. The key thing to keep in mind is that rcu_enter_nohz() is -exiting- the mode that can legally execute RCU read-side critical sections. The memory barrier must be between any potential RCU read-side critical sections and the increment of the ...

If you mean that the rcu_needs_cpu() executes before the cpu_set() in the code fragment above, while the rcu_start_batch() executes on some other CPU? Hmmm.... Can't see why this wouldn't be a problem, right off-hand, though I cannot claim to be an s390 expert. Heiko, thoughts? --

Can't see why not, now that you mention it. Steve, anything Nick and I are missing here? (See updated patch below.) Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> --- rcupreempt.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff -urpNa -X dontdiff linux-2.6.25-rc6/include/linux/rcupreempt.h linux-2.6.25-rc6-rcu_nohz-fix/include/linux/rcupreempt.h --- linux-2.6.25-rc6/include/linux/rcupreempt.h 2008-03-16 17:45:16.000000000 -0700 +++ ...

(to clarify: my question is completely offtopic to this patch) No, but it is very possible I missed something. What if rcu_needs_cpu(cpu) is executed before cpu_set(cpu, nohz_cpu_mask)? It can miss rcu_start_batch() -> rcp->cur++ and return false, but at the same time rcu_start_batch() may see nohz_cpu_mask without this CPU. No? Oleg. --

Hi Linus, Please pull the 'drm-fixes' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes Sorry this is so late, but a number of things cropped up in the last week I thought were urgent enough to get into 2.6.25 final. The PCI GART changes should fix '2.6.25-rc3 + RS690 + DRM + xf86-video-ati hang' The VIA fixes are for a number of upstream bugs, along with the pci ids fixups so we work properly on a new series of ATI cards. Dave. ...

That commit broke lmsensros here ( found by bisect ). ... Can't access procfs/sysfs file Kernel interface access error For 2.6 kernels, make sure you have mounted sysfs and libsensors was compiled with sysfs support! ... Of course proc and sysfs is mounted and the lib has that support :) Here the bisect result : git-bisect start # bad: [a978b30af3bab0dd9af9350eeda25e76123fa28e] Linux 2.6.25-rc6 git-bisect bad a978b30af3bab0dd9af9350eeda25e76123fa28e # good: ...

I completely agree that it shouldn't have been included that late in the release cycle, in particular when it obviously received no testing at all (it breaks all versions of lm-sensors.) The reason why it was merged is that some people feared that application authors would add support for the new thermal zone interface (/sys/class/thermal) quickly instead of waiting for the same information to be exported through the standard hwmon interface (/sys/class/hwmon) which libsensors supports. This ...

No, I have not the lightest clue whats going on. Thanks, tglx --

Thanks, I updated the entry. Rafael --

Rafael J. Wysocki wrote: Thomas do you want me to bisect ? Or do you have any patches I could try ( really does not matter how experimental they are ) ? Rafael the bug report is saying x86-64 Component while my box is 32bit :) Could you please correct this ? Best Regards Gabriel --

I'm sorry for the spaces in the second patch, here's a clean one with tabs. --- From: Stefan Bauer <stefan.bauer@cs.tu-chemnitz.de> Since 4c7ffe0b9f7f40bd818fe3af51342f64c483908e ("fbdev: prevent drivers that have hardware cursors from calling software cursor code") every call of i810fb_cursor fails with -ENXIO because of a incorrect "!". This hasn't striked until eaa0ff15c30dc9799eb4d12660edb73aeb6d32c5 ("fix ! versus & precedence in various places") surrounded the expression with ...

Would it? Other than the basic cgroup boilerplate, the only real duplication that I could see would be that there'd need to be an additional per-mm pointer back to the cgroup. (Which could be avoided if we added a single per-mm pointer back to the "owning" task, which would generally be the mm's thread group leader, so that you could go quickly from an mm to a set of cgroup subsystems). And the advantage would that you'd be able to more easily pick/choose which bits of control you use (and ...

Not really. Virtual limits are more gentle than an OOM kill that can occur if the cgroup runs out of memory. Please also see Yes, a disk I/O and swap I/O controller are being developed (not by us, but others in the community). How does one restrict swap space for a particular application? I can think of RLIMIT_AS for a process and something similar to what I've posted for cgroups. Not enabling swap is an option, but not very practical IMHO. -- Warm Regards, Balbir Singh Linux ...

Yes, but we don't have mm->owner, which is what I was proposing - mm->owner would be a pointer typically to the mm's thread group leader. It would remove the need to have to have pointers for the various different cgroup subsystems that need to act on an mm rather than a task_struct, since then you could use mm->owner->cgroups[subsys_id]. But this is kind of orthogonal to whether virtual address space limits should be a separate cgroup subsystem. Paul --

So? What prevents us from using these hooks? :) --

I'm a counter-example to your suspicion :-) Trying to control virtual address space is a complete nightmare in the presence of anything that uses large sparsely-populated mappings (mmaps of large files, or large sparse heaps such as the JVM uses.) If we want to control the effect of swapping, the right way to do it is to control disk I/O, and ensure that the swapping is accounted to that. Or simply just not give apps much swap space. Paul --

I understand the per-mm pointer overhead back to the cgroup. I don't understand the part about adding a per-mm pointer back to the "owning" task. We already have task->mm. BTW, the reason by we directly add the mm_struct to mem_cgroup mapping is that there are contexts from where only the mm_struct is known (when we charge/uncharge). Assuming that current->mm's mem_cgorup is the one we want I am not sure I understand your proposal fully. But, if it can help provide the flexibility you are ...

I am not sure I understand your proposal. Without manually placing these hooks how do we track 1. When the vm size has increased/decreased 2. In case due to some reason, the call following these hooks fail, how do we Not sure I understand -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL --

We still have two of them even placing hooks in each place manually. Besides, putting the mem_cgroup_(un)charge_as() in these vm hooks will 1. save the number of places to patch 2. help keeping memcgroup consistent in case someone adds more places that expand tasks vm (arches, drivers) - in case we have our hooks This is a good point against. But, wrt my previous comment, can we handle this somehow? --

I thought about it and almost used may_expand_vm(), but there is a slight catch there. With cap_vm_enough_memory() or security_vm_enough_memory(), they are called after total_vm has been calculated. In our case we need to keep the cgroups equivalent of total_vm up to date, and we do this in mem_cgorup_update_as. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL --

No, please, no. Let's make two calls - mem_cgroup_charge_as and mem_cgroup_uncharge_as. Why not use existintg cap_vm_enough_memory and co? [snip] --

Agreed. It was either killed, or exited. The exit code provides enough info. Thanks, I'll resend this patch. Oleg. --

On Mon, Mar 17, 2008 at 7:19 AM, Ananth N Mavinakayanahalli I see your point. This can be prevented by saving and restoring regs->ip around the post_handler() call, no ? Current code is beautiful. Saving and restoring regs->ip would make this place look ugly. Otoh, if the post_handler() wants to crash the kernel, it can do it in thousand ways, not just by trashing regs->ip, no ? Yakov --

resume_execution() exists not just for the program counter fixups after out-of-line singlestepping, but is also as an insurance to put the program counter back to the correct address in case the user's post_handler() mucks around with it. That isn't possible with this change :-( Ananth --

applied --

OK, i'll pass it along. ty --

Applied, thanks. --

Below is the same patch with another kluge, which cuts down the requested sleep by 10% in hopes of getting the actual sleep closer to what's wanted. This is unusable in anything resembling mainline, but I'd like to see how your various systems react to it. I'm getting very close to the sleeps I asked for (with slight undersleeping, which is a bug). Jeff -- Work email - jdike at linux dot intel dot com Index: ...

OK. Tests on host with clocksource pit: bash-3.2# bin/select-sleep 5 Slept for 5 seconds. bash-3.2# bin/select-sleep 10 Slept for 11 seconds. bash-3.2# bin/select-sleep 30 Slept for 31 seconds. bash-3.2# bin/select-sleep 60 Slept for 61 seconds. ... so much better than the 4x error without this patch. Tests on host with clocksource tsc: bash-3.2# bin/select-sleep 5 Slept for 5 seconds. bash-3.2# bin/select-sleep 10 Slept for 10 seconds. bash-3.2# bin/select-sleep 30 Slept ...

Hi Peter, Indeed. I have some other candidates. - list_single - list_has_one - list_one Could you tell me which or some other name you recommend? Thanks, -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division e-mail: mhiramat@redhat.com --

Rename list_singleton to list_is_singular. Signed-off-by: Masami Hiramatsu <mhiramat@redhat.com> --- OK, I picked up list_is_singular(). Thanks, include/linux/list.h | 4 ++-- kernel/kprobes.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) Index: 2.6.25-rc5-mm1/include/linux/list.h =================================================================== --- 2.6.25-rc5-mm1.orig/include/linux/list.h +++ 2.6.25-rc5-mm1/include/linux/list.h @@ -212,10 +212,10 @@ ...

They do generally mutually exclude each other. I think that the problem is just that dirty old "select PARAVIRT" in config KVM_CLOCK. PARAVIRT depends on !(X86_VISWS || X86_VOYAGER), but "select" doesn't care^W honor that. As Documentation/kbuild/kconfig-language.txt says: "In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies. That will limit the usefulness but on the other hand avoid the illegal configurations all over. ...

It looks reasonable to me. If you can send a tested patch with a good description to linux-audit@redhat.com I can work it into mainline. -Eric --

Looks great, all the more so I created very similar patch. David, can we have this in mainline some day? Thanks, --

Sure. Thanks. -- ~Randy --

If the problem is in the splice part of relay, then the problem will likely go away if you add the -s parameter to blktrace. Might be handy to know if you are experimenting. -- Jens Axboe --

0.01%, so 1 time every 10 000 tests. That seems pretty excessive. If the 9 999 tests which were taken correctly each saved only 0.1 cycle due to the likely annotation, then that would be implying the same likely annotation adds 1 000 cycles to the cost of the branch when taken that way. In practice, I'd say it is probably just going to cost an extra icache miss, another jump, and maybe a cycle here or there... 100 cycles at worst. And the benefit might also be larger than 0.1 cycle because ...

By complete security model, I don't mean it has to be MAC+DAC +privileges. Just that it does in fact implement a well formed security model, not just an ad hoc set of stupid security tricks. Smack and "One of the explicit requirements to get LSM into the kernel was to have the ability to make capabilities be a module. This allows the embedded people to completely remove capabilities, as they really want this. I don't think we can ignore this, no matter how much of a pain in the butt it ...

I don't expect to put in any additional hooks points, although it's safe to bet that someone will want to pretty quickly. What I see as the big concern is our old friend the granularity question. I can pretty well predict that we'll have quite a bruhaha over whether each hook point should have it's own hook or if they should be shared based on the privilege supported. For example, in namei.c the function generic_permission() currently calls capable(CAP_DAC_OVERRIDE). The privilege supported ...

Yes, MOVABLE is for things which are very easily moved out, whether that is migrated to another page, or paged out to swap, or trivially freed as it can be re-read from somewhere such as text from a binary; generally this is things on the LRU. RECLAIMABLE, is things which are harder to get rid of, but for which there is some hope of evicting their contents; as you say things like -apw --

Yes, this can be nasty when triggered (Busy inodes after umount) and the patch is safe. Honza -- Jan Kara <jack@suse.cz> SUSE Labs, CR --

I'm mainly afraid to break some implicit assumptions potentially made somewhere that the memory clobber is there (as e.g. implicitly The fact that a char array may be of a size that is not a multiple of the word size used by bt{,c,r,s}, i.e. you may either touch memory outside of the actual bit field (problematic if what follows is an atomic variable, and the bit operation used is not an atomic one, or if the bit array is Apparently not, as you can see from the example I gave that ...

REFILL means refilling the per cpu objects from the freelist of the per cpu slab page. That could be bad because it requires taking the slab Hmmm... I was hoping that add/remove partial numbers would come down. Ok lets forget about the patch. Increasing min_objects does the trick. --

I collected more data on 16-p tigerton to try to find the possible relationship between slub_min_objects and processor number. Kernel is 2.6.25-rc5. Command\slub_min_objects | slub_min_objects=8 | 16 | 32 | 64 ------------------------------------------------------------------------------------- ./hackbench 100 process 2000 | 250second | 23 | 18.6 | 17.5 ./hackbench 200 process 2000 | 532 | 44 | 35.6 | 33.5 The first ...

Initially I wanted to do so, but oprofile data showed both 2.6.24 and 2.6.25-rc aren't good with hachbench on tigerton. The slub_min_objects boot parameter could boost performance largely. So I think --

No. It is indeed constrained by the amount of virtual memory space the kernel has. So it could use in practice probably only around 700-800MB for buffercache. --

I've tripped over this recently aswell. It would for sure be useful to add a sumbolic O_FOO constant for this magic value '3' and document it in the manpage. --

Sorry for that. I've realized I forgot to add "quota:" only after I've sent Not really serious. Nobody complained so far (i.e., for the time quota exists) and the limits will just wrap when you try to set them over 4TB now. So the patch can wait... Honza -- Jan Kara <jack@suse.cz> SUSE Labs, CR --

Hi, You ignore the fact that there are structures and pointers in C :) One and the same object may be referenced from different structure objects. For example you have an object foo saved in a cpu-local variable and this object references another object bar (foo.bar), you might do whatever you want to do with foo. But if bar is a structure you might still have to lock when you want to change the fields of it to prevent races if this bar object can be referenced from another point like ...

Perhaps we can go organize a fundraiser for SuSE so they can go out and buy an ISAPnP soundcard. I have a few I can sell. I promise I won't overcharge Did look, but decided there wasn't much more specifically to add. It's something more fundamental about the flow of things and while the comment above is obviously cynical I did grow a bit tired of a series of patches that just transported the OOPS two lines down again each time, so I held out for Bjorn as well. Still availabe for ...

Thanks for the confirmation.--b. --

Have you looked at the patches you are replying to? :-) -- Jens Axboe --

It's the BUG() which the new s/g API change added. I don't know exactly what caused it. It's possible that block layer is buggy by itself. Or perhaps hald sens a packet command and the conversion to the new API is not complete. In the old API drivers had to adjust the request, but in the new one the right way seems to pass the byte count into the __blk_end_request. I don't have a specific guidance regarding it, and the conversion of ub was hurried apparently. Try this, please: --- ...

Hi Mark, Yes, this patch does revert back to previously working 2.6.24 behavior and fixes the problem for me. --

Oh and even on servers, when your anti-virus proxy reaches a load of 800, you're happy no to have too large a time-slice so that you regularly get a chance of being allowed to type in commands over SSH. Large time-slices are needed only in HPC environments IMHO, where only one task runs. --

Yeah, and firefox scrolling is in the class of workloads where they adaptively reduce CPU consumption as they get less quota (ie. because they just start skipping). Still, for desktop workloads you shouldn't have to deal with lots of CPU hog processes on the runqueue, so I don't see why this is needed? I don't mind having the timeslice smallish, but it shouldn't be Yeah, thanks for looking at that. Wow, scheduler patches sure make it upstream a lot quicker than when I used to work on the ...

here's a performance comparison between 2.6.21 and -rc6, on a 8-socket/16-core system: http://redhat.com/~mingo/misc/sysbench-rc6.jpg [transactions/sec, higher is better] 2.6.21 2.6.25-rc5 2.6.25-rc6 ------------------------------------------------------- 1: 383.26 270.47 269.69 2: 741.02 527.67 560.52 4: 1880.79 1049.59 ...

Secondary issues like the actual cost of context switch, but they are Linux desktops shouldn't run with massive loads anyway. Tuning the scheduler to "work" well in an X session when you have a make -j100 in the background is retarded. But sure, if the scheduler doesn't properly prioritize non-CPU bound tasks versus CPU bound ones, then it should be fixed to do so. --

It's not about what *ssh* uses but about what *others* use. Except by renicing SSH or marking it real-time, it has no way to say "give the CPU to me right now, I have something very short to do". So it will have to wait for the 100 other tasks to eat their 10ms, waiting 1 second to consume 5ms of CPU (and I was speaking about 800 and not 100). It is one of the situations where I prefer to shorten timeslices when load increases because it will not slow down the service too much, but will still ...

There's a new patchset against 2.6.25-rc6 at: http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.25-rc6/patches/ It contains some more patches, specifically the "legacy PM removal" series, the fixed "PM: make wakeup flags available whenever CONFIG_PM is set" series posted recently by Alan (the second patch rebased by me), the Johannes' apm-emulation patch and the patches introducing the new suspend/hibernation callbacks I sent yesterday. Also, patches 05-06 are upstream (in the ...

applied this, and the devres function --

I recommend that you make a new proposal for 2.6.26 that applies on top of Linus' top-of-tree and that we include lkml in hashing it out rather than just linux-acpi. thanks, -Len --

Actually looks like the semaphore thing again, its a spinlock inside of Looks like another of the semaphore thingies.. Does this go away once you apply the semaphore lockdep fixup from here: http://lkml.org/lkml/2008/3/12/63 --

[Empty message]

m. The userspace failure described there is indeed the same as mine: Postfix' sendmail command tries to open "/proc/net/if_inet6" which fails with EACCES. But I have never installed grsecurity on this machine, and the problem appeared for me only with kernel 2.6.25-rc5-mm1, not when running kernel 2.6.25-rc5 on the same machine, so I guess the cause must be something different. What's also strange is that I can "cat /proc/net/if_inet6" from the command line as the same non-root user with ...

For a Linux distro to ship DSDT override images, they'd have to have some licensing & support arrangement with the OEM who actually owns that BIOS code. While this wouldn't defy any laws of physics, it doesn't look compatible with current industry business practices. OEMs are more likely to simply ship a BIOS update ISO. -Len --

I still cannot *believe* this bug, but i just checked out the latest kernel and did a make distclean and a make (with mr. bunks patch applied) and there it is again: $ dmesg (cut) [ 464.852986] ohci1394: fw-host0: physical posted write error [ 464.852991] ohci1394: fw-host0: respTxComplete: dma prg stopped [ 464.852997] ohci1394: fw-host0: SelfID received outside of bus reset sequence [ 464.853002] ohci1394: fw-host0: Unhandled interrupt(s) 0xfc7cfe0c [ 464.896722] ohci1394: ...

At Mon, 17 Mar 2008 22:32:29 +0900 (JST), Done. thanks, Takashi --

Yes, please. Thank you. --- Atsushi Nemoto --

So we've all noticed Alan --

You are twisting words. I may have said that replication provides a point-in-time copy of a volume, which is exactly what it does, no more, A big buffer cache does not provide a guarantee that the dirty cache data saved to disk when line power is lost. If you would like to add that feature to the Linux buffer cache, then please do it, or make whichever other contribution you wish to make. If you just want to explain to me one more time that Linux, batteries, whatever, cannot be relied on, ...

by the way, the only way to get this much bandwideth between two machines is to directly connect PCI-e/16 card slots togeather. this is definantly not commodity hardware anymore (if it's even possible, PCI-e has some very short distance limitations) David Lang --

if you are depending on replication over the network you have just limited your throughput to your network speed and latency. on an enterprise level machine the network can frequently be significantly slower than the disk array that you are so frantic to avoid waiting for. David Lang --

your network will do less then 1 Gbit/sec, so to mirror in real-time (what you claim is trivial) you would need at least 24 network connections in parallel. that's a LOT harder to setup then a high performance disk array. David Lang --

Just a point of information, most of the mid-tier and above disk arrays can do replication/mirroring behind the scene (i.e., you write to one array and it takes care of replicating your write to one or more other arrays). This behind the scene replication can be over various types of connections - IP or fibre channel probably are the two most common paths. That will still leave you with the normal latency for a small write to an array which is (when you hit cache) order of 1-2 ...

> You did not explain how your proposal will avoid dropping the transaction Here is a simple but high physical storage using approach (but hey disks are cheap) You walk across the ram dirty table writing out chunks to backing store 0. At some point in time you want a consistent snapshot so you pick the next write barrier point after this time and begin committing blocks dirtied after that moment to store 1 (with blocks before that moment being written to both). You don't permit more than ...

so just mirror to a local disk array then. a local disk array has more write bandwidth than a network connection to a remote machine, so if you can mirror to a remote machine you can mirror to if by traditionalists you mean everyone who makes a living keeping systems running you are right. we want sane failure modes as much as we want performance. there will be times when we decide to go for speed at the expense of safety, but we want to do it knowingly, not when someone is ...

At Fri, 14 Mar 2008 21:18:19 -0400, I vaguely remember about the patch... The patch below was on my local tree but never pushed because of lack of testing. Does it work for Maybe the problem is in a different place, then... thanks, Takashi --- diff -r 82e6201fc907 sound/isa/es18xx.c --- a/sound/isa/es18xx.c Mon Mar 17 14:36:24 2008 +0100 +++ b/sound/isa/es18xx.c Mon Mar 17 17:32:59 2008 +0100 @@ -765,9 +765,10 @@ static irqreturn_t snd_es18xx_interrupt( /* Read Interrupt ...

Okay, thought I'd stare at this thing a bit -- there's no specific 1888 documentation available it seems but I did notice something in the 1878 datasheet which might mean something. The docs says that bits 0-1 are don't care for DMA but don't for IRQ, so could it possibly be as simple as the attached? 1878 sheet doesn't document register 0x7f, it seems... Assuming it's not just this, this thing is going to require quite a bit of trial and error and without the hardware this will be ...

Tested-by: Christian Lamparter <chunkeey@web.de> Well, the dm-crypt regressions seems to be gone. :) Thanks for your work & time! Regards, Christian --

Hi Olof, In the future please copy Maciej as one of "the DMA guys" as he has taken over ioatdma for me. Beyond that, one little picky comment Is the number of channels defaulting to 2 or 4? sln --

What's the command you're using to build? What happens if you build the kernel normally? J --

Seems some people are still concerned about this benchmark. OK I tried with Linux 2.6.25-rc6 (just because it's what I've got on this system). Versus FreeBSD 7.0. Unfortunately, I don't think FreeBSD supports binding a process to a CPU, and on either system when the scheduler is allowed to choose what happens, results are more variable than you would like. That being said, I found that Linux often outscored FreeBSD in all 3 tests of pipe_v3. FreeBSD does appear like it can get a slightly ...

The bisect ends up pointing at IDE bits everytime, plus it's io There's no data to back any such conclusion up, that would be extremely hand wavy (at best). Ingo hit a hang in one boot out of hundreds to thousands. Anders can reproduce easily, should be easy enough to narrow down. -- Jens Axboe --

Blame VIA for that one. Notice how their descriptions of the fields in that register don't even mention a MAC. :) But the relevant bit is the "sleep time" and that's described in the EHCI specification. It basically means how long it waits, after noticing a "no work for me" async schedule ring, before scanning that schedule again. It seems your system had that set to just 1 usec, meaning it would hardly give anything else a chance to get onto the PCI bus. That's probably why the ...

Hi Oleg, I tried your patches on vanila kernel 2.6.25-rc3 (ia64). Then, I got the NULL pointer dereference at task_session_nr(t) in check_kill_permission(). That is why t->signal->__session is accessed after t->signal was released. It is reproducible by sending many SIGCONT signals to exiting processes. The trace is as follows: Pid: 7807, CPU 9, comm: kill_sigcont psr : 00001210085a6010 ifs : 800000000000030a ip : [<a0000001000ab441>] Not tainted (2.6.25-rc3-debug) ip ...

... you're not accessing EHCI devices at all. Is HAL or something else polling them too often? Or are you maybe That watchdog is a bit messy, but it's got two basic tasks: (a) Take work off the async ring ... bulk and control transfers will leave an empty QH there for a few milliseconds before taking it off, to avoid wasting effort in the common case where another transfer quickly follows the first one. In the extreme case, when there's no more work, that ring ...

I'm okay with switching away from the file-based refcounts to a refcount embedded in the kvm structures, though I'm not particularly thrilled by it. Any reason not to use krefs for this? -- error compiling committee.c: too many arguments to function --

Hi Aron, We have two WDWD1500ADFD and a MSI motherboard which is not exactly the same as what you have. I have tested your case two weeks ago, and do it with copy-compare test program but I find nothing as you describe. Could you give me your experimental directory to let me try again?? BTW, what is your FW version? The latest FW version is v1.44. Please check it out, -----Original Message----- From: Aron Stansvik [mailto:elvstone@gmail.com] Sent: Saturday, March 15, 2008 1:26 AM To: ...

Just upgraded my laptop to 2.6.25-rc6 and I see the same. A little instrumentation shows that there is no socket to connect to aka the server side process (whatever that is) didn't start. --

More info... The Oops seems to be caused by a size mismatch that causes memset to write over other variables in the stack... The following debug hack moved oops to another point in the v4l1-compact code.. So memset(&tun2,0,sizeof(tun2)) seems to be overwriting btv->lock->wait_list: --- drivers/media/video/v4l1-compat.c~ 2007-11-13 10:25:52.000000000 +0200 +++ drivers/media/video/v4l1-compat.c 2008-03-17 23:17:38.000000000 +0200 @@ -688,7 +688,7 @@ { struct ...

It is not an new ABI, its an extension as per the way it was documented The problem is the "bad" ABI has existed in that form since somewhere around 2.6.15 and it is therefore too late to drop things from it or rearrange it. The ABI described additions being allowed so we're taking advantage of that to gain something which should have really been there originally. Short term there is some complexity with some limits but they're going away so there is no problem. The whole point of the ...

Hi all, just a reminder, the server is now running 2.6.24 and the leak is still there. I noticed there is a slab leak debug option and turned it on, results should be visible in a few days I guess. Offenders: Slabs TCPv6, size_2048 and size_512 grow over time. I also noticed that the machine stops responding to pings after some time, which seems to coincide with a slight increase in leak speed. Interstingly IPv4 pings give out first, IPv6 pings continue to work a bit longer, but ...