Re: [PATCH v2] pstore: pass allocated memory region back to caller

[Kees Cook]

On Thu, Nov 17, 2011 at 1:22 AM, Chen Gong <gong.chen@xxxxxxxxxxxxxxx> wrote:
> ä 2011/11/17 5:13, Kees Cook åé:
>>
>> The buf_lock cannot be held while populating the inodes, so make the
>> backend
>> pass forward an allocated and filled buffer instead. This solves the
>> following
>> backtrace. The effect is that "buf" is only ever used to notify the
>> backends
>> that something was written to it, and shouldn't be used in the read path.
>>
>> To replace the buf_lock during the read path, isolate the open/read/close
>> loop with a separate mutex to maintain serialized access to the backend.
>>
>> [ Â 59.691019] BUG: sleeping function called from invalid context at
>> .../mm/slub.c:847
>> [ Â 59.691019] in_atomic(): 0, irqs_disabled(): 1, pid: 1819, name: mount
>> [ Â 59.691019] Pid: 1819, comm: mount Not tainted 3.0.8 #1
>> [ Â 59.691019] Call Trace:
>> [ Â 59.691019] Â[<810252d5>] __might_sleep+0xc3/0xca
>> [ Â 59.691019] Â[<810a26e6>] kmem_cache_alloc+0x32/0xf3
>> [ Â 59.691019] Â[<810b53ac>] ? __d_lookup_rcu+0x6f/0xf4
>> [ Â 59.691019] Â[<810b68b1>] alloc_inode+0x2a/0x64
>> [ Â 59.691019] Â[<810b6903>] new_inode+0x18/0x43
>> [ Â 59.691019] Â[<81142447>] pstore_get_inode.isra.1+0x11/0x98
>> [ Â 59.691019] Â[<81142623>] pstore_mkfile+0xae/0x26f
>> [ Â 59.691019] Â[<810a2a66>] ? kmem_cache_free+0x19/0xb1
>> [ Â 59.691019] Â[<8116c821>] ? ida_get_new_above+0x140/0x158
>> [ Â 59.691019] Â[<811708ea>] ? __init_rwsem+0x1e/0x2c
>> [ Â 59.691019] Â[<810b67e8>] ? inode_init_always+0x111/0x1b0
>> [ Â 59.691019] Â[<8102127e>] ? should_resched+0xd/0x27
>> [ Â 59.691019] Â[<8137977f>] ? _cond_resched+0xd/0x21
>> [ Â 59.691019] Â[<81142abf>] pstore_get_records+0x52/0xa7
>> [ Â 59.691019] Â[<8114254b>] pstore_fill_super+0x7d/0x91
>> [ Â 59.691019] Â[<810a7ff5>] mount_single+0x46/0x82
>> [ Â 59.691019] Â[<8114231a>] pstore_mount+0x15/0x17
>> [ Â 59.691019] Â[<811424ce>] ? pstore_get_inode.isra.1+0x98/0x98
>> [ Â 59.691019] Â[<810a8199>] mount_fs+0x5a/0x12d
>> [ Â 59.691019] Â[<810b9174>] ? alloc_vfsmnt+0xa4/0x14a
>> [ Â 59.691019] Â[<810b9474>] vfs_kern_mount+0x4f/0x7d
>> [ Â 59.691019] Â[<810b9d7e>] do_kern_mount+0x34/0xb2
>> [ Â 59.691019] Â[<810bb15f>] do_mount+0x5fc/0x64a
>> [ Â 59.691019] Â[<810912fb>] ? strndup_user+0x2e/0x3f
>> [ Â 59.691019] Â[<810bb3cb>] sys_mount+0x66/0x99
>> [ Â 59.691019] Â[<8137b537>] sysenter_do_call+0x12/0x26
>>
>
> Would you please tell me how do you construct such a scenario to
> get above call trace?

Yeah, I just mounted pstore. :)

I enjoyed the irony of generating an oops while trying to review the
stored oopses.

-Kees

-- 
Kees Cook
ChromeOS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/