I ran into this problem while trying to resize a mounted file-system after growing/shrinking the size of the underlying block device (in this case, a fibre-channel LUN). The kernel recognizes the device size change when revalidate_disk() is called, but the bdev->bd_inode->i_size will not be updated for any new openers if there are already openers of the device. In my case I was using LVM thusly: 1. Create a volume group with a physical volume on something that can be resized (us...

Oh, and this would not be complete without giving Andrew Pinski complete credit for telling me it wasn't a gcc bug but a bug in the toplevel asm code in the kernel. ;-) -- Steve --

This is a resend of the patch set Cedric had sent earlier. I ported the patch set to 2.6.25-rc8-mm1 and tested on x86 and x86_64. --- We have run out of the 32 bits in clone_flags ! This patchset introduces 2 new system calls which support 64bit clone-flags. long sys_clone64(unsigned long flags_high, unsigned long flags_low, unsigned long newsp); long sys_unshare64(unsigned long flags_high, unsigned long flags_low); The current version of clone64() does not support CLONE_PARE...

Can you explain why are you adding it for 64-bit arches too? unsigned long is there already 64-bit, and both sys_clone and sys_unshare have unsigned long flags, rather than unsigned int. Jakub --

From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject: [lxc-dev] [patch -lxc 1/3] change clone_flags type to u64 This is a preliminary patch changing the clone_flags type to 64bits for all the routines called by do_fork(). It prepares ground for the next patch which introduces an enhanced version of clone() supporting 64bits flags. This is work in progress. All conversions might not be done yet. Signed-off-by: Cedric Le Goater <clg@fr.ibm.com> Signed-off-by: Sukadev Bhattiprol...

Can we please just merge that syntax and make a single function like alloc_intr_gate(RESCHEDULE_VECTOR, reschedule_interrupt); instead? Linus --

From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Shared memory users probably don't think the shared memory is swapped out. But actually shared memory could be swapped out under memory pressure. Linux has SHM_LOCK feature for prevent shared memory swapping, and it can be used by shmctl() after create the shared memory. There are some needs that SHM_LOCK is default behavior. This patch adds shm_locked sysctl to turn SHM_LOCK on when creating. kernel.shm_locked = 0, is default and the beh...

$ DEV=/dev/sda $ GEOM="`/sbin/hdparm -g $DEV | awk '{print $3}'`" $ echo $GEOM 19457/255/63 $ --

Unfortunatelly there is also bios' view of the geometry, which is especially a problem for boot loaders. Just another hint: # lilo -T geom bios=0x00, cylinders=80, heads=2, sectors=18 ( 1.44Mb 2,880 sectors) C:H:S supported (PC bios) BIOS reports 2 hard drives bios=0x80, cylinders=527, heads=255, sectors=63 vol-ID: 2C731DD1 ( 4.33Gb 8,467,199 sectors) LBA32 supported (EDD bios) bios=0x81, cylinders=527, heads=255, sectors=63 ...

Hi all, When running smartctl to get the attributes readout libata seems to get really confused on my system. After a timeout it recovers without apparent ill-effect, but the reported values are complete rubbish. Unfortunately I don't remember if this is a regression or it was always like this.. I have attached some data below, but if more is needed just shout! Regards, Tvrtko root@sol:~# uname -a Linux sol 2.6.24.3 #4 SMP PREEMPT Sat Mar 8 12:57:56 GMT 2008 x86_64 GNU/Linux root@sol...

This adds to the already default CONFIG_E1000=y in these files. Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com> --- arch/x86/configs/i386_defconfig | 1 + arch/x86/configs/x86_64_defconfig | 1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig index 3df340b..35f6308 100644 --- a/arch/x86/configs/i386_defconfig +++ b/arch/x86/configs/i386_defconfig @@ -814,6 +814,7 @@ CONFIG_NETDEV_1000=y CONFI...

Jeff Roberson discovered a race when using kaio eventfd based notifications. This patch fixes the race by moving the notification inside the spinlocked section of kaio. The operation is safe since eventfd spinlock and kaio one are unrelated. Signed-off-by: Davide Libenzi <davidel@xmailserver.org> - Davide --- fs/aio.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) Index: linux-2.6.mod/fs/aio.c ====================================================...

This was described in the original email. I posted a patch back then (waiting for Jeff test feedback - that never came), but then I forgot about it till now: This was the intended behaviour. No event was actually *ready*, so no need to signal completion of an event. - Davide --

* proc_reports_siimage() is now only called by init_chipset_siimage() so inline it there. * Use array instead of switch statement for reporting clock modes. There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> --- drivers/ide/pci/siimage.c | 33 ++++++++------------------------- 1 file changed, 8 insertions(+), 25 deletions(-) Index: b/drivers/ide/pci/siimage.c ===================================================...

Do clocking register posting earlier in setup_mmio_siimage() to match code in init_chipset_siimage(). This is a preparation for the next patch which merges PCI and MMIO code paths together. Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> --- drivers/ide/pci/siimage.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Index: b/drivers/ide/pci/siimage.c =================================================================== --- a/drivers/ide/pci/siimage.c +++ b/dr...

Missed a few includes when moving some files around, this makes it actually compile. Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- Applies on top of the unaligned access revamp, missed when moving files around. include/linux/unaligned/generic_be.h | 2 +- include/linux/unaligned/generic_le.h | 2 +- include/linux/unaligned/no_builtin_memcpy.h | 1 + 3 files changed, 3 insertions(+), 2 deletions(-) diff --git a/include/linux/unaligned/generic_be....

From: "John W. Linville" <linville@tuxdriver.com> Pulled and pushed out to net-2.6, thanks! --

after fixing that, got arch/x86/kernel/smpboot.c:143: error: 'TRAMPOLINE_BASE' undeclared here (not in a function) arch/x86/kernel/smpboot.c: In function 'do_boot_cpu': arch/x86/kernel/smpboot.c:908: warning: assignment makes pointer from integer without a cast make[1]: *** [arch/x86/kernel/smpboot.o] Error 1 make: *** [arch/x86/kernel] Error 2 YH

Is there something I could do to pull this? Lu, could you post the patch to fix the first problem you hit? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

did you get the patch i sent to you earlier today? That is the patch that i included in x86.git mistakenly. Ingo --

Fix add_preferred_console() and update_console_cmdline() not to to read beyond the terminating zero of their name argument. Signed-off-by: Markus Armbruster <armbru@redhat.com> --- kernel/printk.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/printk.c b/kernel/printk.c index c46a20a..52526df 100644 --- a/kernel/printk.c +++ b/kernel/printk.c @@ -865,7 +865,7 @@ int add_preferred_console(char *name, int idx, char *options) return -E2BIG; selecte...

Any reason to keep carrying this completely misleading comment chunk still? -hpa --

WRONG! Using =r for single-byte values is incorrect for 32-bit code -- that would permit %spl, %bpl, %sil, %dil which are illegal in 32-bit mode. That is not the incorrect bit, it's the description that is confused. -hpa --

This comment explains why I use the =q constraint for the 1 bytes immediate value. It makes sure we use an instruction with 1-byte opcode, without REX.R prefix, on x86_64. That's required for the NMI-safe version of the immediate values, which uses a breakpoint, but not for this version based on stop_machine_run(). However, to minimize the amount of changes between the two versions, I left the =q constraint, which is more restrictive. Is it worth it to use =r instead ? It will typically let the c...

-Updating immediate values, cannot rely on smp_call_function() b/c synchronizing cpus using IPIs leads to deadlocks. Process A held a read lock on tasklist_lock, then process B called apply_imv_update(). Process A received the IPI and begins executing ipi_busy_loop(). Then process C takes a write lock irq on the task list lock, before receiving the IPI. Thus, process A holds up process C, and C can't get an IPI b/c interrupts are disabled. Solve this problem by using a new 'ALL_CPUS' parame...