Re: 2.6.24-rc3-mm2 - Build Failure on powerpc timerfd() undeclared

Re: 2.6.24-rc3-mm2 - Build Failure on powerpc timerfd() undeclared

[Kamalesh Babulal]

Hi Andrew,

Kernel build fails, with build error

  CC      arch/powerpc/platforms/cell/spu_callbacks.o
In file included from arch/powerpc/platforms/cell/spu_callbacks.c:49:
include/asm/systbl.h:312: error: ‘sys_timerfd’ undeclared here (not in a function)
make[2]: *** [arch/powerpc/platforms/cell/spu_callbacks.o] Error 1
make[1]: *** [arch/powerpc/platforms/cell] Error 2
make: *** [arch/powerpc/platforms] Error 2

-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.

Re: 2.6.24-rc3-mm2 - Build Failure on powerpc timerfd() undeclared

[Arnd Bergmann]

On Wednesday 28 November 2007, Kamalesh Babulal wrote:
> Kernel build fails, with build error
>=20
> =C2=A0 CC =C2=A0 =C2=A0 =C2=A0arch/powerpc/platforms/cell/spu_callbacks.o
> In file included from arch/powerpc/platforms/cell/spu_callbacks.c:49:
> include/asm/systbl.h:312: error: =E2=80=98sys_timerfd=E2=80=99 undeclared=
 here (not in a function)
> make[2]: *** [arch/powerpc/platforms/cell/spu_callbacks.o] Error 1
> make[1]: *** [arch/powerpc/platforms/cell] Error 2
> make: *** [arch/powerpc/platforms] Error 2
>=20

I guess all architectures except x86 are currently broken because they
reference the old sys_timerfd function. This patch should add the missing
bits to powerpc.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

=2D--

Disclaimer: Not tested at all, just applied common sense.
Disclaimer2: conflicts with the sys_indirect kernel implementation
sent by paulus last week.

diff --git a/include/asm-powerpc/systbl.h b/include/asm-powerpc/systbl.h
index 11d5383..b029368 100644
=2D-- a/include/asm-powerpc/systbl.h
+++ b/include/asm-powerpc/systbl.h
@@ -309,7 +309,9 @@ SYSCALL_SPU(getcpu)
 COMPAT_SYS(epoll_pwait)
 COMPAT_SYS_SPU(utimensat)
 COMPAT_SYS_SPU(signalfd)
=2DCOMPAT_SYS_SPU(timerfd)
+COMPAT_SYS_SPU(timerfd_create)
 SYSCALL_SPU(eventfd)
 COMPAT_SYS_SPU(sync_file_range2)
 COMPAT_SYS(fallocate)
+COMPAT_SYS_SPU(sys_timerfd_settime)
+COMPAT_SYS_SPU(sys_timerfd_gettime)
diff --git a/include/asm-powerpc/unistd.h b/include/asm-powerpc/unistd.h
index 97d82b6..4ba2d20 100644
=2D-- a/include/asm-powerpc/unistd.h
+++ b/include/asm-powerpc/unistd.h
@@ -328,14 +328,16 @@
 #define __NR_epoll_pwait	303
 #define __NR_utimensat		304
 #define __NR_signalfd		305
=2D#define __NR_timerfd		306
+#define __NR_timerfd_create	306
 #define __NR_eventfd		307
 #define __NR_sync_file_range2	308
 #define __NR_fallocate		309
+#define __NR_sys_timerfd_settime 310
+#define __NR_sys_timerfd_gettime 311
=20
 #ifdef __KERNEL__
=20
=2D#define __NR_syscalls		310
+#define __NR_syscalls		312
=20
 #define __NR__exit __NR_exit
 #define NR_syscalls	__NR_syscalls

Re: 2.6.24-rc3-mm2 - Build Failure on powerpc timerfd() undeclared

[Andrew Morton]

On Wed, 28 Nov 2007 14:32:07 +0100 Arnd Bergmann <arnd@arndb.de> wrote:

> On Wednesday 28 November 2007, Kamalesh Babulal wrote:
> > Kernel build fails, with build error
> > 
> >   CC      arch/powerpc/platforms/cell/spu_callbacks.o
> > In file included from arch/powerpc/platforms/cell/spu_callbacks.c:49:
> > include/asm/systbl.h:312: error: ‘sys_timerfd’ undeclared here (not in a function)
> > make[2]: *** [arch/powerpc/platforms/cell/spu_callbacks.o] Error 1
> > make[1]: *** [arch/powerpc/platforms/cell] Error 2
> > make: *** [arch/powerpc/platforms] Error 2
> > 
> 
> I guess all architectures except x86 are currently broken because they
> reference the old sys_timerfd function.

None of them were broken in my testing and I'm unsure why powerpc broke
here.

> This patch should add the missing
> bits to powerpc.
> 

Because the patches in -mm left the stubs in place in sys_ni.c and powerpc
_should_ have (incorrectly) picked those up.

Odd.

> 
> ---
> 
> Disclaimer: Not tested at all, just applied common sense.
> Disclaimer2: conflicts with the sys_indirect kernel implementation
> sent by paulus last week.
> 
> diff --git a/include/asm-powerpc/systbl.h b/include/asm-powerpc/systbl.h
> index 11d5383..b029368 100644
> --- a/include/asm-powerpc/systbl.h
> +++ b/include/asm-powerpc/systbl.h
> @@ -309,7 +309,9 @@ SYSCALL_SPU(getcpu)
>  COMPAT_SYS(epoll_pwait)
>  COMPAT_SYS_SPU(utimensat)
>  COMPAT_SYS_SPU(signalfd)
> -COMPAT_SYS_SPU(timerfd)
> +COMPAT_SYS_SPU(timerfd_create)
>  SYSCALL_SPU(eventfd)
>  COMPAT_SYS_SPU(sync_file_range2)
>  COMPAT_SYS(fallocate)
> +COMPAT_SYS_SPU(sys_timerfd_settime)
> +COMPAT_SYS_SPU(sys_timerfd_gettime)
> diff --git a/include/asm-powerpc/unistd.h b/include/asm-powerpc/unistd.h
> index 97d82b6..4ba2d20 100644
> --- a/include/asm-powerpc/unistd.h
> +++ b/include/asm-powerpc/unistd.h
> @@ -328,14 +328,16 @@
>  #define __NR_epoll_pwait	303
>  #define __NR_utimensat		304
>  #define __NR_signalfd		305
> -#define __NR_timerfd		306
> +#define __NR_timerfd_create	306
>  #define __NR_eventfd		307
>  #define __NR_sync_file_range2	308
>  #define __NR_fallocate		309
> +#define __NR_sys_timerfd_settime 310
> +#define __NR_sys_timerfd_gettime 311
>  
>  #ifdef __KERNEL__
>  
> -#define __NR_syscalls		310
> +#define __NR_syscalls		312
>  
>  #define __NR__exit __NR_exit
>  #define NR_syscalls	__NR_syscalls

Re: 2.6.24-rc3-mm2 - Build Failure on powerpc timerfd() undeclared

[Davide Libenzi]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1248 bytes --]

On Wed, 28 Nov 2007, Andrew Morton wrote:

> On Wed, 28 Nov 2007 14:32:07 +0100 Arnd Bergmann <arnd@arndb.de> wrote:
> 
> > On Wednesday 28 November 2007, Kamalesh Babulal wrote:
> > > Kernel build fails, with build error
> > > 
> > >   CC      arch/powerpc/platforms/cell/spu_callbacks.o
> > > In file included from arch/powerpc/platforms/cell/spu_callbacks.c:49:
> > > include/asm/systbl.h:312: error: ‘sys_timerfd’ undeclared here (not in a function)
> > > make[2]: *** [arch/powerpc/platforms/cell/spu_callbacks.o] Error 1
> > > make[1]: *** [arch/powerpc/platforms/cell] Error 2
> > > make: *** [arch/powerpc/platforms] Error 2
> > > 
> > 
> > I guess all architectures except x86 are currently broken because they
> > reference the old sys_timerfd function.
> 
> None of them were broken in my testing and I'm unsure why powerpc broke
> here.
> 
> > This patch should add the missing
> > bits to powerpc.
> > 
> 
> Because the patches in -mm left the stubs in place in sys_ni.c and powerpc
> _should_ have (incorrectly) picked those up.

My fault. I forgot to update sys_ni.c with the new functions (and with the
sys_timerfd->sys_timerfd_create name change).
Do you want a patch Andrew?



- Davide

Re: 2.6.24-rc3-mm2 - Build Failure on powerpc timerfd() undeclared

[Arnd Bergmann]

On Wednesday 28 November 2007 19:43:45 Andrew Morton wrote:
> > I guess all architectures except x86 are currently broken because they
> > reference the old sys_timerfd function.
>
> None of them were broken in my testing and I'm unsure why powerpc broke
> here.

PowerPC is unique in that it actually relies on the declarations
in include/{linux,asm}/syscalls.h to be present, because the
spu_syscall_table is generated from C code, not from assembly.
One reason why I did this was to be sure to find this exact
type of problem at compile-time, not at link time.

	Arnd <><

[BUG] 2.6.24-rc3-mm2 soft lockup while running tbench

[Kamalesh Babulal]

Hi Andrew,

while running tbench on the powerpc with 2.6.24-rc3-mm2 softlock up occurs

BUG: soft lockup - CPU#0 stuck for 11s! [tbench:12183]
NIP: c0000000000ac978 LR: c0000000000acff0 CTR: c00000000005c648
REGS: C00000076F0F3200 TRAP: 0901   Not tainted  (2.6.24-rc3-mm2-autotest)
MSR: 8000000000009032 <EE,ME,IR,DR>  CR: 44000482  XER: 00000000
TASK = C00000076F4BC000[12183] 'tbench' THREAD: C00000076F0F0000 CPU: 0
NIP [c0000000000ac978] .get_page_from_freelist+0x1cc/0x754
LR [c0000000000acff0] .__alloc_pages+0xb0/0x3a8
Call Trace:
[c00000076f0f3480] [c00000076f0f3560] 0xc00000076f0f3560 (unreliable)
[c00000076f0f3590] [c0000000000acff0] .__alloc_pages+0xb0/0x3a8
[c00000076f0f3680] [c0000000000ce2e4] .alloc_pages_current+0xa8/0xc8
[c00000076f0f3710] [c0000000000ac6ec] .__get_free_pages+0x20/0x70
[c00000076f0f3790] [c0000000000d75c8] .__kmalloc_node_track_caller+0x60/0x148
[c00000076f0f3840] [c0000000002c22b0] .__alloc_skb+0x98/0x184
[c00000076f0f38f0] [c000000000306cd8] .tcp_sendmsg+0x1fc/0xe24
[c00000076f0f3a10] [c0000000002b963c] .sock_sendmsg+0xe4/0x128
[c00000076f0f3c10] [c0000000002ba4ec] .sys_sendto+0xd4/0x120
[c00000076f0f3d90] [c0000000002df2f8] .compat_sys_socketcall+0x148/0x214
[c00000076f0f3e30] [c00000000000872c] syscall_exit+0x0/0x40
Instruction dump:
720b0001 eb970000 40820070 72000002 4182000c e8bc0000 48000018 72080004 
4182000c e8bc0008 48000008 e8bc0010 <e8c10078> 7f83e378 7de407b4 7e078378 

-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.

Re: [BUG] 2.6.24-rc3-mm2 soft lockup while running tbench

[Andrew Morton]

On Wed, 28 Nov 2007 20:03:22 +0530
Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:

> Hi Andrew,
> 
> while running tbench on the powerpc with 2.6.24-rc3-mm2 softlock up occurs
> 
> BUG: soft lockup - CPU#0 stuck for 11s! [tbench:12183]
> NIP: c0000000000ac978 LR: c0000000000acff0 CTR: c00000000005c648
> REGS: C00000076F0F3200 TRAP: 0901   Not tainted  (2.6.24-rc3-mm2-autotest)
> MSR: 8000000000009032 <EE,ME,IR,DR>  CR: 44000482  XER: 00000000
> TASK = C00000076F4BC000[12183] 'tbench' THREAD: C00000076F0F0000 CPU: 0
> NIP [c0000000000ac978] .get_page_from_freelist+0x1cc/0x754
> LR [c0000000000acff0] .__alloc_pages+0xb0/0x3a8
> Call Trace:
> [c00000076f0f3480] [c00000076f0f3560] 0xc00000076f0f3560 (unreliable)
> [c00000076f0f3590] [c0000000000acff0] .__alloc_pages+0xb0/0x3a8
> [c00000076f0f3680] [c0000000000ce2e4] .alloc_pages_current+0xa8/0xc8
> [c00000076f0f3710] [c0000000000ac6ec] .__get_free_pages+0x20/0x70
> [c00000076f0f3790] [c0000000000d75c8] .__kmalloc_node_track_caller+0x60/0x148
> [c00000076f0f3840] [c0000000002c22b0] .__alloc_skb+0x98/0x184
> [c00000076f0f38f0] [c000000000306cd8] .tcp_sendmsg+0x1fc/0xe24
> [c00000076f0f3a10] [c0000000002b963c] .sock_sendmsg+0xe4/0x128
> [c00000076f0f3c10] [c0000000002ba4ec] .sys_sendto+0xd4/0x120
> [c00000076f0f3d90] [c0000000002df2f8] .compat_sys_socketcall+0x148/0x214
> [c00000076f0f3e30] [c00000000000872c] syscall_exit+0x0/0x40
> Instruction dump:
> 720b0001 eb970000 40820070 72000002 4182000c e8bc0000 48000018 72080004 
> 4182000c e8bc0008 48000008 e8bc0010 <e8c10078> 7f83e378 7de407b4 7e078378 
> 

hm.  Beats me.  Does the machine recover OK?

Re: [BUG] 2.6.24-rc3-mm2 soft lockup while running tbench

[Kamalesh Babulal]

Andrew Morton wrote:
> On Wed, 28 Nov 2007 20:03:22 +0530
> Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> 
>> Hi Andrew,
>>
>> while running tbench on the powerpc with 2.6.24-rc3-mm2 softlock up occurs
>>
>> BUG: soft lockup - CPU#0 stuck for 11s! [tbench:12183]
>> NIP: c0000000000ac978 LR: c0000000000acff0 CTR: c00000000005c648
>> REGS: C00000076F0F3200 TRAP: 0901   Not tainted  (2.6.24-rc3-mm2-autotest)
>> MSR: 8000000000009032 <EE,ME,IR,DR>  CR: 44000482  XER: 00000000
>> TASK = C00000076F4BC000[12183] 'tbench' THREAD: C00000076F0F0000 CPU: 0
>> NIP [c0000000000ac978] .get_page_from_freelist+0x1cc/0x754
>> LR [c0000000000acff0] .__alloc_pages+0xb0/0x3a8
>> Call Trace:
>> [c00000076f0f3480] [c00000076f0f3560] 0xc00000076f0f3560 (unreliable)
>> [c00000076f0f3590] [c0000000000acff0] .__alloc_pages+0xb0/0x3a8
>> [c00000076f0f3680] [c0000000000ce2e4] .alloc_pages_current+0xa8/0xc8
>> [c00000076f0f3710] [c0000000000ac6ec] .__get_free_pages+0x20/0x70
>> [c00000076f0f3790] [c0000000000d75c8] .__kmalloc_node_track_caller+0x60/0x148
>> [c00000076f0f3840] [c0000000002c22b0] .__alloc_skb+0x98/0x184
>> [c00000076f0f38f0] [c000000000306cd8] .tcp_sendmsg+0x1fc/0xe24
>> [c00000076f0f3a10] [c0000000002b963c] .sock_sendmsg+0xe4/0x128
>> [c00000076f0f3c10] [c0000000002ba4ec] .sys_sendto+0xd4/0x120
>> [c00000076f0f3d90] [c0000000002df2f8] .compat_sys_socketcall+0x148/0x214
>> [c00000076f0f3e30] [c00000000000872c] syscall_exit+0x0/0x40
>> Instruction dump:
>> 720b0001 eb970000 40820070 72000002 4182000c e8bc0000 48000018 72080004 
>> 4182000c e8bc0008 48000008 e8bc0010 <e8c10078> 7f83e378 7de407b4 7e078378 
>>
> 
> hm.  Beats me.  Does the machine recover OK?
> -
Hi Andrew,

In the set of test cases ran serially, the softlockup in seen in tbench,
then the remaining test cases get to run successfully after the softlockup.

-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.

[BUG] 2.6.24-rc3-mm2 kernel bug on nfs & cifs mounted partitions

[Kamalesh Babulal]

Hi Andrew,

While running file system stress on nfs and cifs mounted partitions, the machine
drops to xmon

1:mon> e
cpu 0x1: Vector: 300 (Data Access) at [c000000080a9f880]
    pc: c0000000001392c8: .inotify_inode_queue_event+0x50/0x158
    lr: c0000000001074d0: .vfs_link+0x204/0x298
    sp: c000000080a9fb00
   msr: 8000000000009032
   dar: 280 
 dsisr: 40010000
  current = 0xc0000000c8e6f670
  paca    = 0xc000000000512c00
    pid   = 2848, comm = fsstress
1:mon> t
[c000000080a9fbd0] c0000000001074d0 .vfs_link+0x204/0x298
[c000000080a9fc70] c00000000010b6e0 .sys_linkat+0x134/0x1b4
[c000000080a9fe30] c00000000000872c syscall_exit+0x0/0x40
--- Exception: c00 (System Call) at 000000000ff1bdfc
SP (ffeaed10) is in userspace
1:mon> r
R00 = c0000000001074d0   R16 = 0000000000000000
R01 = c000000080a9fb00   R17 = 0000000000000000
R02 = c00000000060c380   R18 = 0000000000000000
R03 = 0000000000000000   R19 = 0000000000000000
R04 = 0000000000000004   R20 = 0000000000000000
R05 = 0000000000000000   R21 = 0000000000000000
R06 = 0000000000000000   R22 = 0000000000000000
R07 = 0000000000000000   R23 = 0000000000000004
R08 = 0000000000000000   R24 = 0000000000000280
R09 = 0000000000000000   R25 = fffffffffffff000
R10 = 0000000000000001   R26 = c000000082827790
R11 = c0000000003963e8   R27 = c0000000828275a0
R12 = d000000000deec78   R28 = 0000000000000000
R13 = c000000000512c00   R29 = c00000007b18fcf0
R14 = 0000000000000000   R30 = c0000000005bc088
R15 = 0000000000000000   R31 = 0000000000000000
pc  = c0000000001392c8 .inotify_inode_queue_event+0x50/0x158
lr  = c0000000001074d0 .vfs_link+0x204/0x298
msr = 8000000000009032   cr  = 24000882
ctr = c0000000003963e8   xer = 0000000000000000   trap =  300 
dar = 0000000000000280   dsisr = 40010000


The gdb output shows 

0xc0000000001076d4 is in vfs_symlink (include/linux/fsnotify.h:108).
103      * fsnotify_create - 'name' was linked in
104      */  
105     static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
106     {   
107             inode_dir_notify(inode, DN_CREATE);
108             inotify_inode_queue_event(inode, IN_CREATE, 0, dentry->d_name.name,
109                                       dentry->d_inode);
110             audit_inode_child(dentry->d_name.name, dentry, inode);
111     }   
112



-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.

Re: [BUG] 2.6.24-rc3-mm2 kernel bug on nfs & cifs mounted partitions

[Andrew Morton]

On Thu, 29 Nov 2007 14:30:14 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:

> Hi Andrew,
> 
> While running file system stress on nfs and cifs mounted partitions, the machine
> drops to xmon
> 
> 1:mon> e
> cpu 0x1: Vector: 300 (Data Access) at [c000000080a9f880]
>     pc: c0000000001392c8: .inotify_inode_queue_event+0x50/0x158
>     lr: c0000000001074d0: .vfs_link+0x204/0x298
>     sp: c000000080a9fb00
>    msr: 8000000000009032
>    dar: 280 
>  dsisr: 40010000
>   current = 0xc0000000c8e6f670
>   paca    = 0xc000000000512c00
>     pid   = 2848, comm = fsstress
> 1:mon> t
> [c000000080a9fbd0] c0000000001074d0 .vfs_link+0x204/0x298
> [c000000080a9fc70] c00000000010b6e0 .sys_linkat+0x134/0x1b4
> [c000000080a9fe30] c00000000000872c syscall_exit+0x0/0x40
> --- Exception: c00 (System Call) at 000000000ff1bdfc
> SP (ffeaed10) is in userspace
> 1:mon> r
> R00 = c0000000001074d0   R16 = 0000000000000000
> R01 = c000000080a9fb00   R17 = 0000000000000000
> R02 = c00000000060c380   R18 = 0000000000000000
> R03 = 0000000000000000   R19 = 0000000000000000
> R04 = 0000000000000004   R20 = 0000000000000000
> R05 = 0000000000000000   R21 = 0000000000000000
> R06 = 0000000000000000   R22 = 0000000000000000
> R07 = 0000000000000000   R23 = 0000000000000004
> R08 = 0000000000000000   R24 = 0000000000000280
> R09 = 0000000000000000   R25 = fffffffffffff000
> R10 = 0000000000000001   R26 = c000000082827790
> R11 = c0000000003963e8   R27 = c0000000828275a0
> R12 = d000000000deec78   R28 = 0000000000000000
> R13 = c000000000512c00   R29 = c00000007b18fcf0
> R14 = 0000000000000000   R30 = c0000000005bc088
> R15 = 0000000000000000   R31 = 0000000000000000
> pc  = c0000000001392c8 .inotify_inode_queue_event+0x50/0x158
> lr  = c0000000001074d0 .vfs_link+0x204/0x298
> msr = 8000000000009032   cr  = 24000882
> ctr = c0000000003963e8   xer = 0000000000000000   trap =  300 
> dar = 0000000000000280   dsisr = 40010000
> 
> 
> The gdb output shows 
> 
> 0xc0000000001076d4 is in vfs_symlink (include/linux/fsnotify.h:108).
> 103      * fsnotify_create - 'name' was linked in
> 104      */  
> 105     static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
> 106     {   
> 107             inode_dir_notify(inode, DN_CREATE);
> 108             inotify_inode_queue_event(inode, IN_CREATE, 0, dentry->d_name.name,
> 109                                       dentry->d_inode);
> 110             audit_inode_child(dentry->d_name.name, dentry, inode);
> 111     }   
> 112
> 

If it is reproducible can you please try reverting
inotify-send-in_attrib-events-when-link-count-changes.patch?

Re: [BUG] 2.6.24-rc3-mm2 kernel bug on nfs & cifs mounted partitions

[Kamalesh Babulal]

Andrew Morton wrote:
> On Thu, 29 Nov 2007 14:30:14 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> 
>> Hi Andrew,
>>
>> While running file system stress on nfs and cifs mounted partitions, the machine
>> drops to xmon
>>
>> 1:mon> e
>> cpu 0x1: Vector: 300 (Data Access) at [c000000080a9f880]
>>     pc: c0000000001392c8: .inotify_inode_queue_event+0x50/0x158
>>     lr: c0000000001074d0: .vfs_link+0x204/0x298
>>     sp: c000000080a9fb00
>>    msr: 8000000000009032
>>    dar: 280 
>>  dsisr: 40010000
>>   current = 0xc0000000c8e6f670
>>   paca    = 0xc000000000512c00
>>     pid   = 2848, comm = fsstress
>> 1:mon> t
>> [c000000080a9fbd0] c0000000001074d0 .vfs_link+0x204/0x298
>> [c000000080a9fc70] c00000000010b6e0 .sys_linkat+0x134/0x1b4
>> [c000000080a9fe30] c00000000000872c syscall_exit+0x0/0x40
>> --- Exception: c00 (System Call) at 000000000ff1bdfc
>> SP (ffeaed10) is in userspace
>> 1:mon> r
>> R00 = c0000000001074d0   R16 = 0000000000000000
>> R01 = c000000080a9fb00   R17 = 0000000000000000
>> R02 = c00000000060c380   R18 = 0000000000000000
>> R03 = 0000000000000000   R19 = 0000000000000000
>> R04 = 0000000000000004   R20 = 0000000000000000
>> R05 = 0000000000000000   R21 = 0000000000000000
>> R06 = 0000000000000000   R22 = 0000000000000000
>> R07 = 0000000000000000   R23 = 0000000000000004
>> R08 = 0000000000000000   R24 = 0000000000000280
>> R09 = 0000000000000000   R25 = fffffffffffff000
>> R10 = 0000000000000001   R26 = c000000082827790
>> R11 = c0000000003963e8   R27 = c0000000828275a0
>> R12 = d000000000deec78   R28 = 0000000000000000
>> R13 = c000000000512c00   R29 = c00000007b18fcf0
>> R14 = 0000000000000000   R30 = c0000000005bc088
>> R15 = 0000000000000000   R31 = 0000000000000000
>> pc  = c0000000001392c8 .inotify_inode_queue_event+0x50/0x158
>> lr  = c0000000001074d0 .vfs_link+0x204/0x298
>> msr = 8000000000009032   cr  = 24000882
>> ctr = c0000000003963e8   xer = 0000000000000000   trap =  300 
>> dar = 0000000000000280   dsisr = 40010000
>>
>>
>> The gdb output shows 
>>
>> 0xc0000000001076d4 is in vfs_symlink (include/linux/fsnotify.h:108).
>> 103      * fsnotify_create - 'name' was linked in
>> 104      */  
>> 105     static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
>> 106     {   
>> 107             inode_dir_notify(inode, DN_CREATE);
>> 108             inotify_inode_queue_event(inode, IN_CREATE, 0, dentry->d_name.name,
>> 109                                       dentry->d_inode);
>> 110             audit_inode_child(dentry->d_name.name, dentry, inode);
>> 111     }   
>> 112
>>
> 
> If it is reproducible can you please try reverting
> inotify-send-in_attrib-events-when-link-count-changes.patch?

Hi Andrew,

reverting the patch inotify-send-in_attrib-events-when-link-count-changes.patch, the 
bug is not reproduced.

-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.

Re: [BUG] 2.6.24-rc3-mm2 kernel bug on nfs & cifs mounted partitions

[Jan Kara]

On Thu 29-11-07 17:27:08, Kamalesh Babulal wrote:
> Andrew Morton wrote:
> > On Thu, 29 Nov 2007 14:30:14 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> > 
> >> Hi Andrew,
> >>
> >> While running file system stress on nfs and cifs mounted partitions, the machine
> >> drops to xmon
> >>
> >> 1:mon> e
> >> cpu 0x1: Vector: 300 (Data Access) at [c000000080a9f880]
> >>     pc: c0000000001392c8: .inotify_inode_queue_event+0x50/0x158
> >>     lr: c0000000001074d0: .vfs_link+0x204/0x298
> >>     sp: c000000080a9fb00
> >>    msr: 8000000000009032
> >>    dar: 280 
> >>  dsisr: 40010000
> >>   current = 0xc0000000c8e6f670
> >>   paca    = 0xc000000000512c00
> >>     pid   = 2848, comm = fsstress
> >> 1:mon> t
> >> [c000000080a9fbd0] c0000000001074d0 .vfs_link+0x204/0x298
> >> [c000000080a9fc70] c00000000010b6e0 .sys_linkat+0x134/0x1b4
> >> [c000000080a9fe30] c00000000000872c syscall_exit+0x0/0x40
> >> --- Exception: c00 (System Call) at 000000000ff1bdfc
> >> SP (ffeaed10) is in userspace
> >> 1:mon> r
> >> R00 = c0000000001074d0   R16 = 0000000000000000
> >> R01 = c000000080a9fb00   R17 = 0000000000000000
> >> R02 = c00000000060c380   R18 = 0000000000000000
> >> R03 = 0000000000000000   R19 = 0000000000000000
> >> R04 = 0000000000000004   R20 = 0000000000000000
> >> R05 = 0000000000000000   R21 = 0000000000000000
> >> R06 = 0000000000000000   R22 = 0000000000000000
> >> R07 = 0000000000000000   R23 = 0000000000000004
> >> R08 = 0000000000000000   R24 = 0000000000000280
> >> R09 = 0000000000000000   R25 = fffffffffffff000
> >> R10 = 0000000000000001   R26 = c000000082827790
> >> R11 = c0000000003963e8   R27 = c0000000828275a0
> >> R12 = d000000000deec78   R28 = 0000000000000000
> >> R13 = c000000000512c00   R29 = c00000007b18fcf0
> >> R14 = 0000000000000000   R30 = c0000000005bc088
> >> R15 = 0000000000000000   R31 = 0000000000000000
> >> pc  = c0000000001392c8 .inotify_inode_queue_event+0x50/0x158
> >> lr  = c0000000001074d0 .vfs_link+0x204/0x298
> >> msr = 8000000000009032   cr  = 24000882
> >> ctr = c0000000003963e8   xer = 0000000000000000   trap =  300 
> >> dar = 0000000000000280   dsisr = 40010000
> >>
> >>
> >> The gdb output shows 
> >>
> >> 0xc0000000001076d4 is in vfs_symlink (include/linux/fsnotify.h:108).
> >> 103      * fsnotify_create - 'name' was linked in
> >> 104      */  
> >> 105     static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
> >> 106     {   
> >> 107             inode_dir_notify(inode, DN_CREATE);
> >> 108             inotify_inode_queue_event(inode, IN_CREATE, 0, dentry->d_name.name,
> >> 109                                       dentry->d_inode);
> >> 110             audit_inode_child(dentry->d_name.name, dentry, inode);
> >> 111     }   
> >> 112
> >>
> > 
> > If it is reproducible can you please try reverting
> > inotify-send-in_attrib-events-when-link-count-changes.patch?
> 
> Hi Andrew,
> 
> reverting the patch inotify-send-in_attrib-events-when-link-count-changes.patch, the 
> bug is not reproduced.
  OK, thanks for testing. I was trying to reproduce the problem locally but
without success so far - I guess it's either NFS or CIFS which makes the
problem appear. I'll investigate more.

									Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

Re: [BUG] 2.6.24-rc3-mm2 kernel bug on nfs & cifs mounted partitions

[Kamalesh Babulal]

Jan Kara wrote:
> On Thu 29-11-07 17:27:08, Kamalesh Babulal wrote:
>> Andrew Morton wrote:
>>> On Thu, 29 Nov 2007 14:30:14 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>>>
>>>> Hi Andrew,
>>>>
>>>> While running file system stress on nfs and cifs mounted partitions, the machine
>>>> drops to xmon
>>>>
>>>> 1:mon> e
>>>> cpu 0x1: Vector: 300 (Data Access) at [c000000080a9f880]
>>>>     pc: c0000000001392c8: .inotify_inode_queue_event+0x50/0x158
>>>>     lr: c0000000001074d0: .vfs_link+0x204/0x298
>>>>     sp: c000000080a9fb00
>>>>    msr: 8000000000009032
>>>>    dar: 280 
>>>>  dsisr: 40010000
>>>>   current = 0xc0000000c8e6f670
>>>>   paca    = 0xc000000000512c00
>>>>     pid   = 2848, comm = fsstress
>>>> 1:mon> t
>>>> [c000000080a9fbd0] c0000000001074d0 .vfs_link+0x204/0x298
>>>> [c000000080a9fc70] c00000000010b6e0 .sys_linkat+0x134/0x1b4
>>>> [c000000080a9fe30] c00000000000872c syscall_exit+0x0/0x40
>>>> --- Exception: c00 (System Call) at 000000000ff1bdfc
>>>> SP (ffeaed10) is in userspace
>>>> 1:mon> r
>>>> R00 = c0000000001074d0   R16 = 0000000000000000
>>>> R01 = c000000080a9fb00   R17 = 0000000000000000
>>>> R02 = c00000000060c380   R18 = 0000000000000000
>>>> R03 = 0000000000000000   R19 = 0000000000000000
>>>> R04 = 0000000000000004   R20 = 0000000000000000
>>>> R05 = 0000000000000000   R21 = 0000000000000000
>>>> R06 = 0000000000000000   R22 = 0000000000000000
>>>> R07 = 0000000000000000   R23 = 0000000000000004
>>>> R08 = 0000000000000000   R24 = 0000000000000280
>>>> R09 = 0000000000000000   R25 = fffffffffffff000
>>>> R10 = 0000000000000001   R26 = c000000082827790
>>>> R11 = c0000000003963e8   R27 = c0000000828275a0
>>>> R12 = d000000000deec78   R28 = 0000000000000000
>>>> R13 = c000000000512c00   R29 = c00000007b18fcf0
>>>> R14 = 0000000000000000   R30 = c0000000005bc088
>>>> R15 = 0000000000000000   R31 = 0000000000000000
>>>> pc  = c0000000001392c8 .inotify_inode_queue_event+0x50/0x158
>>>> lr  = c0000000001074d0 .vfs_link+0x204/0x298
>>>> msr = 8000000000009032   cr  = 24000882
>>>> ctr = c0000000003963e8   xer = 0000000000000000   trap =  300 
>>>> dar = 0000000000000280   dsisr = 40010000
>>>>
>>>>
>>>> The gdb output shows 
>>>>
>>>> 0xc0000000001076d4 is in vfs_symlink (include/linux/fsnotify.h:108).
>>>> 103      * fsnotify_create - 'name' was linked in
>>>> 104      */  
>>>> 105     static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
>>>> 106     {   
>>>> 107             inode_dir_notify(inode, DN_CREATE);
>>>> 108             inotify_inode_queue_event(inode, IN_CREATE, 0, dentry->d_name.name,
>>>> 109                                       dentry->d_inode);
>>>> 110             audit_inode_child(dentry->d_name.name, dentry, inode);
>>>> 111     }   
>>>> 112
>>>>
>>> If it is reproducible can you please try reverting
>>> inotify-send-in_attrib-events-when-link-count-changes.patch?
>> Hi Andrew,
>>
>> reverting the patch inotify-send-in_attrib-events-when-link-count-changes.patch, the 
>> bug is not reproduced.
>   OK, thanks for testing. I was trying to reproduce the problem locally but
> without success so far - I guess it's either NFS or CIFS which makes the
> problem appear. I'll investigate more.
> 
> 									Honza

Hi Jan,

I was running file system stress parallely on NFS and CIFS mounted partitions.
  

-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.

Re: [BUG] 2.6.24-rc3-mm2 kernel bug on nfs & cifs mounted partitions

[Jan Kara]

On Thu 29-11-07 17:27:08, Kamalesh Babulal wrote:
> Andrew Morton wrote:
> > On Thu, 29 Nov 2007 14:30:14 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> > 
> >> Hi Andrew,
> >>
> >> While running file system stress on nfs and cifs mounted partitions, the machine
> >> drops to xmon
> >>
> >> 1:mon> e
> >> cpu 0x1: Vector: 300 (Data Access) at [c000000080a9f880]
> >>     pc: c0000000001392c8: .inotify_inode_queue_event+0x50/0x158
> >>     lr: c0000000001074d0: .vfs_link+0x204/0x298
> >>     sp: c000000080a9fb00
> >>    msr: 8000000000009032
> >>    dar: 280 
> >>  dsisr: 40010000
> >>   current = 0xc0000000c8e6f670
> >>   paca    = 0xc000000000512c00
> >>     pid   = 2848, comm = fsstress
> >> 1:mon> t
> >> [c000000080a9fbd0] c0000000001074d0 .vfs_link+0x204/0x298
> >> [c000000080a9fc70] c00000000010b6e0 .sys_linkat+0x134/0x1b4
> >> [c000000080a9fe30] c00000000000872c syscall_exit+0x0/0x40
> >> --- Exception: c00 (System Call) at 000000000ff1bdfc
> >> SP (ffeaed10) is in userspace
> >> 1:mon> r
> >> R00 = c0000000001074d0   R16 = 0000000000000000
> >> R01 = c000000080a9fb00   R17 = 0000000000000000
> >> R02 = c00000000060c380   R18 = 0000000000000000
> >> R03 = 0000000000000000   R19 = 0000000000000000
> >> R04 = 0000000000000004   R20 = 0000000000000000
> >> R05 = 0000000000000000   R21 = 0000000000000000
> >> R06 = 0000000000000000   R22 = 0000000000000000
> >> R07 = 0000000000000000   R23 = 0000000000000004
> >> R08 = 0000000000000000   R24 = 0000000000000280
> >> R09 = 0000000000000000   R25 = fffffffffffff000
> >> R10 = 0000000000000001   R26 = c000000082827790
> >> R11 = c0000000003963e8   R27 = c0000000828275a0
> >> R12 = d000000000deec78   R28 = 0000000000000000
> >> R13 = c000000000512c00   R29 = c00000007b18fcf0
> >> R14 = 0000000000000000   R30 = c0000000005bc088
> >> R15 = 0000000000000000   R31 = 0000000000000000
> >> pc  = c0000000001392c8 .inotify_inode_queue_event+0x50/0x158
> >> lr  = c0000000001074d0 .vfs_link+0x204/0x298
> >> msr = 8000000000009032   cr  = 24000882
> >> ctr = c0000000003963e8   xer = 0000000000000000   trap =  300 
> >> dar = 0000000000000280   dsisr = 40010000
> >>
> >>
> >> The gdb output shows 
> >>
> >> 0xc0000000001076d4 is in vfs_symlink (include/linux/fsnotify.h:108).
> >> 103      * fsnotify_create - 'name' was linked in
> >> 104      */  
> >> 105     static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
> >> 106     {   
> >> 107             inode_dir_notify(inode, DN_CREATE);
> >> 108             inotify_inode_queue_event(inode, IN_CREATE, 0, dentry->d_name.name,
> >> 109                                       dentry->d_inode);
> >> 110             audit_inode_child(dentry->d_name.name, dentry, inode);
> >> 111     }   
> >> 112
> >>
> > 
> > If it is reproducible can you please try reverting
> > inotify-send-in_attrib-events-when-link-count-changes.patch?
> 
> Hi Andrew,
> 
> reverting the patch inotify-send-in_attrib-events-when-link-count-changes.patch, the 
> bug is not reproduced.
  OK, it's a problem with CIFS. Its cifs_hardlink() function doesn't call
d_instantiate() and thus returns a dentry with d_inode set to NULL. I'm not
sure if such behavior is really correct but anyway, attached is a new
version of the patch which should handle it gracefully. Kamalesh, can you
please give it a try? Thanks.

									Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR
---

  Currently, no notification event has been sent when inode's link count
changed. This is inconvenient for the application in some cases:
  Suppose you have the following directory structure
    foo/test
    bar/

  and you watch test. If someone does "mv foo/test bar/", you get event
IN_MOVE_SELF and you know something has happened with the file "test".
However if someone does "ln foo/test bar/test" and "rm foo/test" you get no
inotify event for the file "test" (only directories "foo" and "bar" receive
events).
  Furthermore it could be argued that link count belongs to file's metadata
and thus IN_ATTRIB should be sent when it changes.
  The following patch implements sending of IN_ATTRIB inotify events when
link count of the inode changes, i.e., when a hardlink to the inode is
created or when it is removed. This event is sent in addition to all the
events sent so far. In particular, when a last link to a file is removed,
IN_ATTRIB event is sent in addition to IN_DELETE_SELF event.

Signed-off-by: Jan Kara <jack@suse.cz>

diff --git a/fs/namei.c b/fs/namei.c
index 3b993db..c1839d1 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2188,6 +2188,7 @@ int vfs_unlink(struct inode *dir, struct dentry *dentry)
 
 	/* We don't d_delete() NFS sillyrenamed files--they still exist. */
 	if (!error && !(dentry->d_flags & DCACHE_NFSFS_RENAMED)) {
+		fsnotify_link_count(dentry->d_inode);
 		d_delete(dentry);
 	}
 
@@ -2360,7 +2361,7 @@ int vfs_link(struct dentry *old_dentry, struct inode *dir, struct dentry *new_de
 	error = dir->i_op->link(old_dentry, dir, new_dentry);
 	mutex_unlock(&old_dentry->d_inode->i_mutex);
 	if (!error)
-		fsnotify_create(dir, new_dentry);
+		fsnotify_link(dir, old_dentry->d_inode, new_dentry);
 	return error;
 }
 
diff --git a/include/linux/fsnotify.h b/include/linux/fsnotify.h
index 2bd31fa..d4b7c4a 100644
--- a/include/linux/fsnotify.h
+++ b/include/linux/fsnotify.h
@@ -92,6 +92,14 @@ static inline void fsnotify_inoderemove(struct inode *inode)
 }
 
 /*
+ * fsnotify_link_count - inode's link count changed
+ */
+static inline void fsnotify_link_count(struct inode *inode)
+{
+	inotify_inode_queue_event(inode, IN_ATTRIB, 0, NULL, NULL);
+}
+
+/*
  * fsnotify_create - 'name' was linked in
  */
 static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
@@ -103,6 +111,20 @@ static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
 }
 
 /*
+ * fsnotify_link - new hardlink in 'inode' directory
+ * Note: We have to pass also the linked inode ptr as some filesystems leave
+ *   new_dentry->d_inode NULL and instantiate inode pointer later
+ */
+static inline void fsnotify_link(struct inode *dir, struct inode *inode, struct dentry *new_dentry)
+{
+	inode_dir_notify(dir, DN_CREATE);
+	inotify_inode_queue_event(dir, IN_CREATE, 0, new_dentry->d_name.name,
+				  inode);
+	fsnotify_link_count(inode);
+	audit_inode_child(new_dentry->d_name.name, new_dentry, dir);
+}
+
+/*
  * fsnotify_mkdir - directory 'name' was created
  */
 static inline void fsnotify_mkdir(struct inode *inode, struct dentry *dentry)

Re: [BUG] 2.6.24-rc3-mm2 kernel bug on nfs & cifs mounted partitions

[Kamalesh Babulal]

Jan Kara wrote:
> On Thu 29-11-07 17:27:08, Kamalesh Babulal wrote:
>> Andrew Morton wrote:
>>> On Thu, 29 Nov 2007 14:30:14 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>>>
>>>> Hi Andrew,
>>>>
>>>> While running file system stress on nfs and cifs mounted partitions, the machine
>>>> drops to xmon
>>>>
>>>> 1:mon> e
>>>> cpu 0x1: Vector: 300 (Data Access) at [c000000080a9f880]
>>>>     pc: c0000000001392c8: .inotify_inode_queue_event+0x50/0x158
>>>>     lr: c0000000001074d0: .vfs_link+0x204/0x298
>>>>     sp: c000000080a9fb00
>>>>    msr: 8000000000009032
>>>>    dar: 280 
>>>>  dsisr: 40010000
>>>>   current = 0xc0000000c8e6f670
>>>>   paca    = 0xc000000000512c00
>>>>     pid   = 2848, comm = fsstress
>>>> 1:mon> t
>>>> [c000000080a9fbd0] c0000000001074d0 .vfs_link+0x204/0x298
>>>> [c000000080a9fc70] c00000000010b6e0 .sys_linkat+0x134/0x1b4
>>>> [c000000080a9fe30] c00000000000872c syscall_exit+0x0/0x40
>>>> --- Exception: c00 (System Call) at 000000000ff1bdfc
>>>> SP (ffeaed10) is in userspace
>>>> 1:mon> r
>>>> R00 = c0000000001074d0   R16 = 0000000000000000
>>>> R01 = c000000080a9fb00   R17 = 0000000000000000
>>>> R02 = c00000000060c380   R18 = 0000000000000000
>>>> R03 = 0000000000000000   R19 = 0000000000000000
>>>> R04 = 0000000000000004   R20 = 0000000000000000
>>>> R05 = 0000000000000000   R21 = 0000000000000000
>>>> R06 = 0000000000000000   R22 = 0000000000000000
>>>> R07 = 0000000000000000   R23 = 0000000000000004
>>>> R08 = 0000000000000000   R24 = 0000000000000280
>>>> R09 = 0000000000000000   R25 = fffffffffffff000
>>>> R10 = 0000000000000001   R26 = c000000082827790
>>>> R11 = c0000000003963e8   R27 = c0000000828275a0
>>>> R12 = d000000000deec78   R28 = 0000000000000000
>>>> R13 = c000000000512c00   R29 = c00000007b18fcf0
>>>> R14 = 0000000000000000   R30 = c0000000005bc088
>>>> R15 = 0000000000000000   R31 = 0000000000000000
>>>> pc  = c0000000001392c8 .inotify_inode_queue_event+0x50/0x158
>>>> lr  = c0000000001074d0 .vfs_link+0x204/0x298
>>>> msr = 8000000000009032   cr  = 24000882
>>>> ctr = c0000000003963e8   xer = 0000000000000000   trap =  300 
>>>> dar = 0000000000000280   dsisr = 40010000
>>>>
>>>>
>>>> The gdb output shows 
>>>>
>>>> 0xc0000000001076d4 is in vfs_symlink (include/linux/fsnotify.h:108).
>>>> 103      * fsnotify_create - 'name' was linked in
>>>> 104      */  
>>>> 105     static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
>>>> 106     {   
>>>> 107             inode_dir_notify(inode, DN_CREATE);
>>>> 108             inotify_inode_queue_event(inode, IN_CREATE, 0, dentry->d_name.name,
>>>> 109                                       dentry->d_inode);
>>>> 110             audit_inode_child(dentry->d_name.name, dentry, inode);
>>>> 111     }   
>>>> 112
>>>>
>>> If it is reproducible can you please try reverting
>>> inotify-send-in_attrib-events-when-link-count-changes.patch?
>> Hi Andrew,
>>
>> reverting the patch inotify-send-in_attrib-events-when-link-count-changes.patch, the 
>> bug is not reproduced.
>   OK, it's a problem with CIFS. Its cifs_hardlink() function doesn't call
> d_instantiate() and thus returns a dentry with d_inode set to NULL. I'm not
> sure if such behavior is really correct but anyway, attached is a new
> version of the patch which should handle it gracefully. Kamalesh, can you
> please give it a try? Thanks.
> 
> 									Honza
Hi Jan,

Thanks, the patch fixes the bug.

-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.