Have just noticed these in the past few days, now running 2.6.37-rc1+
Seems to be 1 logged per file save when using a text file with gedit over cifs.
unreferenced object 0xffff88022ee08b40 (size 32):
comm "gedit", pid 2524, jiffies 4300160388 (age 2633.655s)
hex dump (first 32 bytes):
5c 2e 67 6f 75 74 70 75 74 73 74 72 65 61 6d 2d \.goutputstream-
35 42 41 53 4c 56 00 de 09 00 00 00 2c 26 78 ee 5BASLV......,&x.
backtrace:
[<ffffffff81504a4d>] kmemleak_alloc+0x2d/0x60
[<ffffffff81136e13>] __kmalloc+0xe3/0x1d0
[<ffffffffa0313db0>] build_path_from_dentry+0xf0/0x230 [cifs]
[<ffffffffa031ae1e>] cifs_setattr+0x9e/0x770 [cifs]
[<ffffffff8115fe90>] notify_change+0x170/0x2e0
[<ffffffff81145ceb>] sys_fchmod+0x10b/0x140
[<ffffffff8100c172>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff88022b469ca0 (size 32):
comm "gedit", pid 2543, jiffies 4300529624 (age 2264.419s)
hex dump (first 32 bytes):
5c 2e 67 6f 75 74 70 75 74 73 74 72 65 61 6d 2d \.goutputstream-
30 38 53 59 4c 56 00 de 01 00 00 00 00 00 00 00 08SYLV..........
backtrace:
[<ffffffff81504a4d>] kmemleak_alloc+0x2d/0x60
[<ffffffff81136e13>] __kmalloc+0xe3/0x1d0
[<ffffffffa0313db0>] build_path_from_dentry+0xf0/0x230 [cifs]
[<ffffffffa031ae1e>] cifs_setattr+0x9e/0x770 [cifs]
[<ffffffff8115fe90>] notify_change+0x170/0x2e0
[<ffffffff811457cf>] chown_common+0x9f/0xc0
[<ffffffff8114588e>] sys_fchown+0x9e/0xc0
[<ffffffff8100c172>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff88022b5f8d20 (size 32):
comm "gedit", pid 1885, jiffies 4294979706 (age 1221.634s)
hex dump (first 32 bytes):
5c 2e 67 6f 75 74 70 75 74 73 74 72 65 61 6d 2d \.goutputstream-
34 38 38 59 4c 56 00 de 02 00 00 00 00 00 00 00 488YLV..........
backtrace:
[<ffffffff81505bad>] kmemleak_alloc+0x2d/0x60
[<ffffffff81136e23>] __kmalloc+0xe3/0x1d0
[<ffffffffa0329b90>] build_path_from_dentry+0xf0/0x230 [cifs]
[<ffffffffa0330abe>] cifs_setattr+0x9e/0x770 [cifs]
[<ffffffff8115fea0>] notify_change+0x170/0x2e0
[<ffffffff81145cfb>] sys_fchmod+0x10b/0x140
[<ffffffff8100c172>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
On Mon, Nov 8, 2010 at 6:13 PM, Andrew Hendry <[email protected]> wrote:
> Have just noticed these in the past few days, now running 2.6.37-rc1+
> Seems to be 1 logged per file save when using a text file with gedit over cifs.
Can you tell the called function in cifs_setattr_unix vs. cifs_setattr_nounix
(the former will usually be called when the server is Samba, the latter
when the server is Windows or NetApp). What is the server type?
> unreferenced object 0xffff88022ee08b40 (size 32):
> ?comm "gedit", pid 2524, jiffies 4300160388 (age 2633.655s)
> ?hex dump (first 32 bytes):
> ? ?5c 2e 67 6f 75 74 70 75 74 73 74 72 65 61 6d 2d ?\.goutputstream-
> ? ?35 42 41 53 4c 56 00 de 09 00 00 00 2c 26 78 ee ?5BASLV......,&x.
> ?backtrace:
> ? ?[<ffffffff81504a4d>] kmemleak_alloc+0x2d/0x60
> ? ?[<ffffffff81136e13>] __kmalloc+0xe3/0x1d0
> ? ?[<ffffffffa0313db0>] build_path_from_dentry+0xf0/0x230 [cifs]
> ? ?[<ffffffffa031ae1e>] cifs_setattr+0x9e/0x770 [cifs]
> ? ?[<ffffffff8115fe90>] notify_change+0x170/0x2e0
> ? ?[<ffffffff81145ceb>] sys_fchmod+0x10b/0x140
> ? ?[<ffffffff8100c172>] system_call_fastpath+0x16/0x1b
> ? ?[<ffffffffffffffff>] 0xffffffffffffffff
Didn't see anything obvious in cifs_setattr_unix on the kmalloc/kfree
of full_path,
but it will help when we know which path we are in. We did make some recent
changes in 2.6.37 in file allocation.
--
Thanks,
Steve
The server is a qnap NAS, running linux 2.6.24
On Tue, Nov 9, 2010 at 3:12 PM, Steve French <[email protected]> wrote:
> On Mon, Nov 8, 2010 at 6:13 PM, Andrew Hendry <[email protected]> wrote:
>> Have just noticed these in the past few days, now running 2.6.37-rc1+
>> Seems to be 1 logged per file save when using a text file with gedit over cifs.
>
> Can you tell the called function in cifs_setattr_unix vs. cifs_setattr_nounix
> (the former will usually be called when the server is Samba, the latter
> when the server is Windows or NetApp). ?What is the server type?
>
>> unreferenced object 0xffff88022ee08b40 (size 32):
>> ?comm "gedit", pid 2524, jiffies 4300160388 (age 2633.655s)
>> ?hex dump (first 32 bytes):
>> ? ?5c 2e 67 6f 75 74 70 75 74 73 74 72 65 61 6d 2d ?\.goutputstream-
>> ? ?35 42 41 53 4c 56 00 de 09 00 00 00 2c 26 78 ee ?5BASLV......,&x.
>> ?backtrace:
>> ? ?[<ffffffff81504a4d>] kmemleak_alloc+0x2d/0x60
>> ? ?[<ffffffff81136e13>] __kmalloc+0xe3/0x1d0
>> ? ?[<ffffffffa0313db0>] build_path_from_dentry+0xf0/0x230 [cifs]
>> ? ?[<ffffffffa031ae1e>] cifs_setattr+0x9e/0x770 [cifs]
>> ? ?[<ffffffff8115fe90>] notify_change+0x170/0x2e0
>> ? ?[<ffffffff81145ceb>] sys_fchmod+0x10b/0x140
>> ? ?[<ffffffff8100c172>] system_call_fastpath+0x16/0x1b
>> ? ?[<ffffffffffffffff>] 0xffffffffffffffff
>
> Didn't see anything obvious in cifs_setattr_unix on the kmalloc/kfree
> of full_path,
> but it will help when we know which path we are in. ?We did make some recent
> changes in 2.6.37 in file allocation.
>
> --
> Thanks,
>
> Steve
>
On 11/09/2010 11:31 AM, Andrew Hendry wrote:
> The server is a qnap NAS, running linux 2.6.24
> On Tue, Nov 9, 2010 at 3:12 PM, Steve French <[email protected]> wrote:
>> On Mon, Nov 8, 2010 at 6:13 PM, Andrew Hendry <[email protected]> wrote:
>>> Have just noticed these in the past few days, now running 2.6.37-rc1+
>>> Seems to be 1 logged per file save when using a text file with gedit over cifs.
>>
>> Can you tell the called function in cifs_setattr_unix vs. cifs_setattr_nounix
>> (the former will usually be called when the server is Samba, the latter
>> when the server is Windows or NetApp). �What is the server type?
>>
>>> unreferenced object 0xffff88022ee08b40 (size 32):
>>> �comm "gedit", pid 2524, jiffies 4300160388 (age 2633.655s)
>>> �hex dump (first 32 bytes):
>>> � �5c 2e 67 6f 75 74 70 75 74 73 74 72 65 61 6d 2d �\.goutputstream-
>>> � �35 42 41 53 4c 56 00 de 09 00 00 00 2c 26 78 ee �5BASLV......,&x.
>>> �backtrace:
>>> � �[<ffffffff81504a4d>] kmemleak_alloc+0x2d/0x60
>>> � �[<ffffffff81136e13>] __kmalloc+0xe3/0x1d0
>>> � �[<ffffffffa0313db0>] build_path_from_dentry+0xf0/0x230 [cifs]
>>> � �[<ffffffffa031ae1e>] cifs_setattr+0x9e/0x770 [cifs]
>>> � �[<ffffffff8115fe90>] notify_change+0x170/0x2e0
>>> � �[<ffffffff81145ceb>] sys_fchmod+0x10b/0x140
>>> � �[<ffffffff8100c172>] system_call_fastpath+0x16/0x1b
>>> � �[<ffffffffffffffff>] 0xffffffffffffffff
>>
Are you using the mount option 'nounix'? I spotted a memleak in the
nounix code path introduced by a recent patch and proposed a fix here:
http://thread.gmane.org/gmane.linux.kernel.cifs/1549
Does this fix the leak for you?
--
Suresh Jayaraman
Yes that fixes the leak, appears fine now thanks.
On Tue, Nov 9, 2010 at 6:05 PM, Suresh Jayaraman <[email protected]> wrote:
> On 11/09/2010 11:31 AM, Andrew Hendry wrote:
>> The server is a qnap NAS, running linux 2.6.24
>
>> On Tue, Nov 9, 2010 at 3:12 PM, Steve French <[email protected]> wrote:
>>> On Mon, Nov 8, 2010 at 6:13 PM, Andrew Hendry <[email protected]> wrote:
>>>> Have just noticed these in the past few days, now running 2.6.37-rc1+
>>>> Seems to be 1 logged per file save when using a text file with gedit over cifs.
>>>
>>> Can you tell the called function in cifs_setattr_unix vs. cifs_setattr_nounix
>>> (the former will usually be called when the server is Samba, the latter
>>> when the server is Windows or NetApp). �What is the server type?
>>>
>>>> unreferenced object 0xffff88022ee08b40 (size 32):
>>>> �comm "gedit", pid 2524, jiffies 4300160388 (age 2633.655s)
>>>> �hex dump (first 32 bytes):
>>>> � �5c 2e 67 6f 75 74 70 75 74 73 74 72 65 61 6d 2d �\.goutputstream-
>>>> � �35 42 41 53 4c 56 00 de 09 00 00 00 2c 26 78 ee �5BASLV......,&x.
>>>> �backtrace:
>>>> � �[<ffffffff81504a4d>] kmemleak_alloc+0x2d/0x60
>>>> � �[<ffffffff81136e13>] __kmalloc+0xe3/0x1d0
>>>> � �[<ffffffffa0313db0>] build_path_from_dentry+0xf0/0x230 [cifs]
>>>> � �[<ffffffffa031ae1e>] cifs_setattr+0x9e/0x770 [cifs]
>>>> � �[<ffffffff8115fe90>] notify_change+0x170/0x2e0
>>>> � �[<ffffffff81145ceb>] sys_fchmod+0x10b/0x140
>>>> � �[<ffffffff8100c172>] system_call_fastpath+0x16/0x1b
>>>> � �[<ffffffffffffffff>] 0xffffffffffffffff
>>>
>
> Are you using the mount option 'nounix'? I spotted a memleak in the
> nounix code path introduced by a recent patch and proposed a fix here:
>
> http://thread.gmane.org/gmane.linux.kernel.cifs/1549
>
> Does this fix the leak for you?
>
>
>
> --
> Suresh Jayaraman
>