linux-kernel - Re: [mm-patch] bluetooth: use GFP_ATOMIC in *_sock_create's sk

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]

Date:	Fri, 28 Jul 2006 14:36:25 +0200
From:	Frederik Deweerdt <deweerdt@...e.fr>
To:	Marcel Holtmann <marcel@...tmann.org>
Cc:	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
	jet@...e.org
Subject: Re: [mm-patch] bluetooth: use GFP_ATOMIC in *_sock_create's sk_alloc

On Fri, Jul 28, 2006 at 11:00:09AM +0200, Marcel Holtmann wrote:
> Hi Frederik,
> 
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
> > > 
> > 
> > I think that the bluetooth-guard-bt_proto-with-rwlock.patch introduced the following
> > BUG:
> > [   43.232000] BUG: sleeping function called from invalid context at mm/slab.c:2903
> > [   43.232000] in_atomic():1, irqs_disabled():0
> > [   43.232000]  [<c0104114>] show_trace_log_lvl+0x197/0x1ba
> > [   43.232000]  [<c010415e>] show_trace+0x27/0x29
> > [   43.232000]  [<c010426e>] dump_stack+0x26/0x28
> > [   43.232000]  [<c011ad1c>] __might_sleep+0xa2/0xaa
> > [   43.232000]  [<c0173085>] __kmalloc+0x9c/0xb3
> > [   43.232000]  [<c02f9295>] sk_alloc+0x1bc/0x1de
> > [   43.232000]  [<c036d689>] hci_sock_create+0x42/0x8a
> > [   43.236000]  [<c0366f40>] bt_sock_create+0xb5/0x154
> > [   43.236000]  [<c02f69dc>] __sock_create+0x131/0x356
> > [   43.236000]  [<c02f6c2f>] sock_create+0x2e/0x30
> > [   43.236000]  [<c02f6c88>] sys_socket+0x27/0x53
> > [   43.240000]  [<c02f7db5>] sys_socketcall+0xa9/0x277
> > [   43.240000]  [<c0103131>] sysenter_past_esp+0x56/0x8d
> > [   43.240000]  [<b7f38410>] 0xb7f38410
> 
> the comment from Max Krasnyansky (the original author) I got was this:
> 
>   As far as I remember there was some upper level locking that ensured
>   that protected registration stuff. But it's been awhile so I may be
>   completely wrong.
> 
> And Masatake YAMATO mentioned:
> 
>   It seems that lock_kernel/unlock_kernel was used in sys_init_module.
>   However, now it is gone.
> 
> I haven't looked at the new module loading code to verify if we really
> need to protect our socket registration or not.
> 
I'm really not an expert here, but from what I read, the only obvious
locking done in sys_init_module is involves 'module_mutex'. And that
mutex is released at the time 'mod->init()' is called.

Regards,
Frederik
-
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/