commit message 8a5b20aebaa3 refers to non-existing commit ?

commit message 8a5b20aebaa3 refers to non-existing commit ?

[Toralf Förster]

in 
commit 8a5b20aebaa3d0ade5b8381e64d35fb777b7b355
Author: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Date:   Wed Jul 2 15:22:35 2014 -0700

    slub: fix off by one in number of slab tests


you stated:

    Fixes 91cb69620284 ("slub: make dead memcg caches discard free slabs
    immediately").


which I cannot find in main line currently. Pls could you point me to that commit ?

-- 
Toralf

Re: commit message 8a5b20aebaa3 refers to non-existing commit ?

[David Rientjes]

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

On Thu, 3 Jul 2014, Toralf Förster wrote:

> in 
> commit 8a5b20aebaa3d0ade5b8381e64d35fb777b7b355
> Author: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> Date:   Wed Jul 2 15:22:35 2014 -0700
> 
>     slub: fix off by one in number of slab tests
> 
> 
> you stated:
> 
>     Fixes 91cb69620284 ("slub: make dead memcg caches discard free slabs
>     immediately").
> 
> 
> which I cannot find in main line currently. Pls could you point me to that commit ?
> 

It hasn't been pushed to Linus yet, it's still sitting in the -mm tree:
http://ozlabs.org/~akpm/mmotm/broken-out/slub-make-dead-memcg-caches-discard-free-slabs-immediately.patch

Not sure where the SHA1 came from, probably linux-next.  So the fix made 
it to Linus before the offending commit, but the code is still correct.

Re: commit message 8a5b20aebaa3 refers to non-existing commit ?

[Paul Bolle]

On Thu, 2014-07-03 at 14:48 -0700, David Rientjes wrote:
> On Thu, 3 Jul 2014, Toralf Förster wrote:
> 
> > in 
> > commit 8a5b20aebaa3d0ade5b8381e64d35fb777b7b355
> > Author: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> > Date:   Wed Jul 2 15:22:35 2014 -0700
> > 
> >     slub: fix off by one in number of slab tests
> > 
> > 
> > you stated:
> > 
> >     Fixes 91cb69620284 ("slub: make dead memcg caches discard free slabs
> >     immediately").
> > 
> > 
> > which I cannot find in main line currently. Pls could you point me to that commit ?
> > 
> 
> It hasn't been pushed to Linus yet, it's still sitting in the -mm tree:
> http://ozlabs.org/~akpm/mmotm/broken-out/slub-make-dead-memcg-caches-discard-free-slabs-immediately.patch
> 
> Not sure where the SHA1 came from, probably linux-next.

Correct:
$ git tag --contains 91cb69620284f793928045714575cc7f6285c7f1
next-20140620
next-20140623
next-20140624
next-20140625

>   So the fix made 
> it to Linus before the offending commit, but the code is still correct.
Note that in today's linux-next (next-20140703) it appears to have a
different SHA1:
$ git log --no-merges --grep "slub: make dead memcg caches discard free slabs immediately"
commit a879a7e8c64a8d5594acaf665c4135be31ca6570
Author: Vladimir Davydov <vdavydov@parallels.com>
Date:   Thu Jul 3 08:43:12 2014 +1000

    slub: make dead memcg caches discard free slabs immediately
    
    Since [...]

(Both commits appear to introduce identical changes. I have no idea what
those changes actually do.)


Paul Bolle

Re: commit message 8a5b20aebaa3 refers to non-existing commit ?

[Toralf Förster]

On 07/03/2014 11:48 PM, David Rientjes wrote:
> On Thu, 3 Jul 2014, Toralf Förster wrote:
> 
>> in 
>> commit 8a5b20aebaa3d0ade5b8381e64d35fb777b7b355
>> Author: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>> Date:   Wed Jul 2 15:22:35 2014 -0700
>>
>>     slub: fix off by one in number of slab tests
>>
>>
>> you stated:
>>
>>     Fixes 91cb69620284 ("slub: make dead memcg caches discard free slabs
>>     immediately").
>>
>>
>> which I cannot find in main line currently. Pls could you point me to that commit ?
>>
> 
> It hasn't been pushed to Linus yet, it's still sitting in the -mm tree:
> http://ozlabs.org/~akpm/mmotm/broken-out/slub-make-dead-memcg-caches-discard-free-slabs-immediately.patch
> 
> Not sure where the SHA1 came from, probably linux-next.  So the fix made 
> it to Linus before the offending commit, but the code is still correct.
> 
ah thx,

the reason I asked was that I (for a short time) I hoped that this commit would solve an issue at a 32 bit user mode linux (x86), which cored dumps since few weeks/months when fuzz-tested with trinity.
Unfortunately this is not the case. Although with this commit it needs much longer than before till the UML core dump happens (2-3 hours instead of about 30 minutes).

Just for completeness here is the back trace of the UML guest:

$> gdb /home/tfoerste/devel/linux/linux --core=/mnt/ramdisk/core -batch -ex 'thread apply all bt' 

Thread 1 (LWP 18431):
#0  0xb776eaec in __kernel_vsyscall ()
#1  0x08484ca5 in kill () at ../sysdeps/unix/syscall-template.S:81
#2  0x0807253d in uml_abort () at arch/um/os-Linux/util.c:93
#3  0x08072885 in os_dump_core () at arch/um/os-Linux/util.c:148
#4  0x0806241d in panic_exit (self=0x86c95c0 <panic_exit_notifier>, unused1=0, unused2=0x8700980 <buf.19750>) at arch/um/kernel/um_arch.c:240
#5  0x08099706 in notifier_call_chain (nl=0x0, val=1214151512, v=0x6, nr_to_call=-2, nr_calls=0x0) at kernel/notifier.c:93
#6  0x08099863 in __atomic_notifier_call_chain (nr_calls=<optimized out>, nr_to_call=<optimized out>, v=<optimized out>, val=<optimized out>, nh=<optimized out>) at kernel/notifier.c:183
#7  atomic_notifier_call_chain (nh=0x8700944 <panic_notifier_list>, val=0, v=0x8700980 <buf.19750>) at kernel/notifier.c:193
#8  0x084e02b4 in panic (fmt=0x0) at kernel/panic.c:133
#9  0x080cb905 in __delete_from_page_cache (page=0xa786fc0, shadow=0x0) at mm/filemap.c:202
#10 0x080cb9c3 in delete_from_page_cache (page=0xa786fc0) at mm/filemap.c:234
#11 0x080d6d67 in truncate_complete_page (page=<optimized out>, mapping=<optimized out>) at mm/truncate.c:145
#12 truncate_inode_page (mapping=0x487ab3b4, page=0xa786fc0) at mm/truncate.c:180
#13 0x080de257 in shmem_undo_range (inode=0x0, lstart=26983955288, lend=-1, unfalloc=false) at mm/shmem.c:430
#14 0x080de7dd in shmem_truncate_range (inode=0x487ab2fc, lstart=0, lend=5214741036428951552) at mm/shmem.c:527
#15 0x080de892 in shmem_evict_inode (inode=0x487ab2fc) at mm/shmem.c:571
#16 0x0811cebf in evict (inode=0x487ab2fc) at fs/inode.c:550
#17 0x0811d92d in iput_final (inode=<optimized out>) at fs/inode.c:1418
#18 iput (inode=0x487ab2fc) at fs/inode.c:1436
#19 0x08119898 in dentry_iput (dentry=<optimized out>) at fs/dcache.c:292
#20 __dentry_kill (dentry=0x4898d4d0) at fs/dcache.c:477
#21 0x0811a54c in dentry_kill (dentry=<optimized out>) at fs/dcache.c:521
#22 dput (dentry=0x4898d4d0) at fs/dcache.c:617
#23 0x08107265 in __fput (file=0x48664300) at fs/file_table.c:234
#24 0x081072bb in ____fput (work=0x48664300) at fs/file_table.c:252
#25 0x080930e6 in task_work_run () at kernel/task_work.c:123
#26 0x0805f8da in tracehook_notify_resume (regs=<optimized out>) at include/linux/tracehook.h:196
#27 interrupt_end () at arch/um/kernel/process.c:98
#28 0x08074409 in userspace (regs=0x4881c9e4) at arch/um/os-Linux/skas/process.c:459
#29 0x0805f6d0 in fork_handler () at arch/um/kernel/process.c:149
#30 0x00000000 in ?? ()

-- 
Toralf