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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGXu5jKaqa+c6dvCPyiXO81EVb67faz7+ht9xHcZpPpke2eStw@mail.gmail.com>
Date:	Thu, 17 Nov 2011 09:51:02 -0800
From:	Kees Cook <keescook@...omium.org>
To:	Chen Gong <gong.chen@...ux.intel.com>
Cc:	linux-kernel@...r.kernel.org, Tony Luck <tony.luck@...el.com>,
	Matthew Garrett <mjg@...hat.com>,
	Huang Ying <ying.huang@...el.com>,
	Mike Waychison <mikew@...gle.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Seiji Aguchi <seiji.aguchi@....com>,
	Don Zickus <dzickus@...hat.com>
Subject: Re: [PATCH v2] pstore: pass allocated memory region back to caller

On Thu, Nov 17, 2011 at 1:22 AM, Chen Gong <gong.chen@...ux.intel.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/