* [linux-next] BUG triggered in ptraceme
@ 2018-09-19 7:07 Cyrill Gorcunov
2018-09-19 7:10 ` Cyrill Gorcunov
0 siblings, 1 reply; 6+ messages in thread
From: Cyrill Gorcunov @ 2018-09-19 7:07 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: Andrey Vagin, LKML
Hi Oleg! While been testing criu with linux-next we've triggered a BUG.
https://api.travis-ci.org/v3/job/430308998/log.txt
[ 2.461618] BUG: sleeping function called from invalid context at security/apparmor/include/cred.h:154
[ 2.461794] in_atomic(): 1, irqs_disabled(): 1, pid: 152, name: init
[ 2.461890] 1 lock held by init/152:
[ 2.461981] #0: 00000000f30c3fda (tasklist_lock){.+.+}, at: ptrace_traceme+0x1c/0x70
[ 2.462114] irq event stamp: 2524
[ 2.462242] hardirqs last enabled at (2523): [<ffffffff98002922>] do_syscall_64+0x12/0x190
[ 2.462363] hardirqs last disabled at (2524): [<ffffffff98b8b02f>] _raw_write_lock_irq+0xf/0x40
[ 2.462476] softirqs last enabled at (1904): [<ffffffff98ac79ef>] unix_sock_destructor+0x4f/0xc0
[ 2.462586] softirqs last disabled at (1902): [<ffffffff98ac79ef>] unix_sock_destructor+0x4f/0xc0
[ 2.462697] CPU: 1 PID: 152 Comm: init Not tainted 4.19.0-rc4-next-20180918+ #1
Which is due to commit
commit 4b105cbbaf7c06e01c27391957dc3c446328d087
Author: Oleg Nesterov <oleg@redhat.com>
Date: Wed Jun 17 16:27:33 2009 -0700
ptrace: do not use task_lock() for attach
because now after write_lock_irq(&tasklist_lock); apparmor calls for
traceme and
static inline struct aa_label *begin_current_label_crit_section(void)
{
struct aa_label *label = aa_current_raw_label();
--> might_sleep();
Take a look please, once time permit.
Cyrill
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-next] BUG triggered in ptraceme
2018-09-19 7:07 [linux-next] BUG triggered in ptraceme Cyrill Gorcunov
@ 2018-09-19 7:10 ` Cyrill Gorcunov
2018-09-19 14:16 ` Jann Horn
0 siblings, 1 reply; 6+ messages in thread
From: Cyrill Gorcunov @ 2018-09-19 7:10 UTC (permalink / raw)
To: Jann Horn; +Cc: Oleg Nesterov, Andrey Vagin, LKML
On Wed, Sep 19, 2018 at 10:07:37AM +0300, Cyrill Gorcunov wrote:
> Hi Oleg! While been testing criu with linux-next we've triggered a BUG.
> https://api.travis-ci.org/v3/job/430308998/log.txt
>
> [ 2.461618] BUG: sleeping function called from invalid context at security/apparmor/include/cred.h:154
> [ 2.461794] in_atomic(): 1, irqs_disabled(): 1, pid: 152, name: init
> [ 2.461890] 1 lock held by init/152:
> [ 2.461981] #0: 00000000f30c3fda (tasklist_lock){.+.+}, at: ptrace_traceme+0x1c/0x70
> [ 2.462114] irq event stamp: 2524
> [ 2.462242] hardirqs last enabled at (2523): [<ffffffff98002922>] do_syscall_64+0x12/0x190
> [ 2.462363] hardirqs last disabled at (2524): [<ffffffff98b8b02f>] _raw_write_lock_irq+0xf/0x40
> [ 2.462476] softirqs last enabled at (1904): [<ffffffff98ac79ef>] unix_sock_destructor+0x4f/0xc0
> [ 2.462586] softirqs last disabled at (1902): [<ffffffff98ac79ef>] unix_sock_destructor+0x4f/0xc0
> [ 2.462697] CPU: 1 PID: 152 Comm: init Not tainted 4.19.0-rc4-next-20180918+ #1
>
> Which is due to commit
>
> commit 4b105cbbaf7c06e01c27391957dc3c446328d087
> Author: Oleg Nesterov <oleg@redhat.com>
> Date: Wed Jun 17 16:27:33 2009 -0700
>
> ptrace: do not use task_lock() for attach
>
> because now after write_lock_irq(&tasklist_lock); apparmor calls for
> traceme and
>
> static inline struct aa_label *begin_current_label_crit_section(void)
> {
> struct aa_label *label = aa_current_raw_label();
>
> --> might_sleep();
>
> Take a look please, once time permit.
Heh, actually not :) It is due to commit
commit 1f8266ff58840d698a1e96d2274189de1bdf7969
Author: Jann Horn <jannh@google.com>
Date: Thu Sep 13 18:12:09 2018 +0200
which introduced might_sleep. Seems it is bad idea to send bug report
without having a cup of coffee at the morning :)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-next] BUG triggered in ptraceme
2018-09-19 7:10 ` Cyrill Gorcunov
@ 2018-09-19 14:16 ` Jann Horn
2018-09-19 16:13 ` Cyrill Gorcunov
0 siblings, 1 reply; 6+ messages in thread
From: Jann Horn @ 2018-09-19 14:16 UTC (permalink / raw)
To: Cyrill Gorcunov, Alexander Viro, linux-fsdevel, Michal Hocko
Cc: Oleg Nesterov, avagin, kernel list
Adding FS people to figure out whether GFP_KERNEL allocations with
i_rwsem's held for writing are okay.
On Wed, Sep 19, 2018 at 9:10 AM Cyrill Gorcunov <gorcunov@gmail.com> wrote:
> On Wed, Sep 19, 2018 at 10:07:37AM +0300, Cyrill Gorcunov wrote:
> > Hi Oleg! While been testing criu with linux-next we've triggered a BUG.
> > https://api.travis-ci.org/v3/job/430308998/log.txt
> >
> > [ 2.461618] BUG: sleeping function called from invalid context at security/apparmor/include/cred.h:154
> > [ 2.461794] in_atomic(): 1, irqs_disabled(): 1, pid: 152, name: init
> > [ 2.461890] 1 lock held by init/152:
> > [ 2.461981] #0: 00000000f30c3fda (tasklist_lock){.+.+}, at: ptrace_traceme+0x1c/0x70
> > [ 2.462114] irq event stamp: 2524
> > [ 2.462242] hardirqs last enabled at (2523): [<ffffffff98002922>] do_syscall_64+0x12/0x190
> > [ 2.462363] hardirqs last disabled at (2524): [<ffffffff98b8b02f>] _raw_write_lock_irq+0xf/0x40
> > [ 2.462476] softirqs last enabled at (1904): [<ffffffff98ac79ef>] unix_sock_destructor+0x4f/0xc0
> > [ 2.462586] softirqs last disabled at (1902): [<ffffffff98ac79ef>] unix_sock_destructor+0x4f/0xc0
> > [ 2.462697] CPU: 1 PID: 152 Comm: init Not tainted 4.19.0-rc4-next-20180918+ #1
> >
> > Which is due to commit
> >
> > commit 4b105cbbaf7c06e01c27391957dc3c446328d087
> > Author: Oleg Nesterov <oleg@redhat.com>
> > Date: Wed Jun 17 16:27:33 2009 -0700
> >
> > ptrace: do not use task_lock() for attach
> >
> > because now after write_lock_irq(&tasklist_lock); apparmor calls for
> > traceme and
> >
> > static inline struct aa_label *begin_current_label_crit_section(void)
> > {
> > struct aa_label *label = aa_current_raw_label();
> >
> > --> might_sleep();
> >
> > Take a look please, once time permit.
>
> Heh, actually not :) It is due to commit
>
> commit 1f8266ff58840d698a1e96d2274189de1bdf7969
> Author: Jann Horn <jannh@google.com>
> Date: Thu Sep 13 18:12:09 2018 +0200
>
> which introduced might_sleep. Seems it is bad idea to send bug report
> without having a cup of coffee at the morning :)
Yeah, I fixed one sleep-in-atomic bug and figured I'd throw a
might_sleep() in there for good measure... sigh.
I guess now I have to go through all the callers of
begin_current_label_crit_section() to see what else looks wrong...
apparmor_ptrace_traceme() is wrong, as reported...
apparmor_path_link() looks icky, but I'm not sure - from what I can
tell, it's called with an i_rwsem held for writing, and that probably
makes calling back into filesystem context from there a bad idea?
OTOH, it's just the i_rwsem of a newly-created path, so I don't know
whether that's actually an issue...
security_path_rename() is called with two i_rwsem's held, but again,
I'm not sure whether that's a problem.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-next] BUG triggered in ptraceme
2018-09-19 14:16 ` Jann Horn
@ 2018-09-19 16:13 ` Cyrill Gorcunov
2018-09-27 15:35 ` Jann Horn
0 siblings, 1 reply; 6+ messages in thread
From: Cyrill Gorcunov @ 2018-09-19 16:13 UTC (permalink / raw)
To: Jann Horn
Cc: Alexander Viro, linux-fsdevel, Michal Hocko, Oleg Nesterov,
avagin, kernel list
On Wed, Sep 19, 2018 at 04:16:50PM +0200, Jann Horn wrote:
...
> >
> > Heh, actually not :) It is due to commit
> >
> > commit 1f8266ff58840d698a1e96d2274189de1bdf7969
> > Author: Jann Horn <jannh@google.com>
> > Date: Thu Sep 13 18:12:09 2018 +0200
> >
> > which introduced might_sleep. Seems it is bad idea to send bug report
> > without having a cup of coffee at the morning :)
>
> Yeah, I fixed one sleep-in-atomic bug and figured I'd throw a
> might_sleep() in there for good measure... sigh.
> I guess now I have to go through all the callers of
> begin_current_label_crit_section() to see what else looks wrong...
>
Yes, I fear so. Need to check every caller just to be sure.
> apparmor_ptrace_traceme() is wrong, as reported...
>
> apparmor_path_link() looks icky, but I'm not sure - from what I can
> tell, it's called with an i_rwsem held for writing, and that probably
> makes calling back into filesystem context from there a bad idea?
> OTOH, it's just the i_rwsem of a newly-created path, so I don't know
> whether that's actually an issue...
>
> security_path_rename() is called with two i_rwsem's held, but again,
> I'm not sure whether that's a problem.
Lets wait for fs people opinions.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-next] BUG triggered in ptraceme
2018-09-19 16:13 ` Cyrill Gorcunov
@ 2018-09-27 15:35 ` Jann Horn
2018-09-27 15:41 ` Cyrill Gorcunov
0 siblings, 1 reply; 6+ messages in thread
From: Jann Horn @ 2018-09-27 15:35 UTC (permalink / raw)
To: Cyrill Gorcunov
Cc: Al Viro, linux-fsdevel, Michal Hocko, Oleg Nesterov, avagin, kernel list
On Wed, Sep 19, 2018 at 6:13 PM Cyrill Gorcunov <gorcunov@gmail.com> wrote:
>
> On Wed, Sep 19, 2018 at 04:16:50PM +0200, Jann Horn wrote:
> ...
> > >
> > > Heh, actually not :) It is due to commit
> > >
> > > commit 1f8266ff58840d698a1e96d2274189de1bdf7969
> > > Author: Jann Horn <jannh@google.com>
> > > Date: Thu Sep 13 18:12:09 2018 +0200
> > >
> > > which introduced might_sleep. Seems it is bad idea to send bug report
> > > without having a cup of coffee at the morning :)
> >
> > Yeah, I fixed one sleep-in-atomic bug and figured I'd throw a
> > might_sleep() in there for good measure... sigh.
> > I guess now I have to go through all the callers of
> > begin_current_label_crit_section() to see what else looks wrong...
> >
>
> Yes, I fear so. Need to check every caller just to be sure.
>
> > apparmor_ptrace_traceme() is wrong, as reported...
> >
> > apparmor_path_link() looks icky, but I'm not sure - from what I can
> > tell, it's called with an i_rwsem held for writing, and that probably
> > makes calling back into filesystem context from there a bad idea?
> > OTOH, it's just the i_rwsem of a newly-created path, so I don't know
> > whether that's actually an issue...
> >
> > security_path_rename() is called with two i_rwsem's held, but again,
> > I'm not sure whether that's a problem.
>
> Lets wait for fs people opinions.
No reply yet - I guess I should just fix up the traceme case for now.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-next] BUG triggered in ptraceme
2018-09-27 15:35 ` Jann Horn
@ 2018-09-27 15:41 ` Cyrill Gorcunov
0 siblings, 0 replies; 6+ messages in thread
From: Cyrill Gorcunov @ 2018-09-27 15:41 UTC (permalink / raw)
To: Jann Horn
Cc: Al Viro, linux-fsdevel, Michal Hocko, Oleg Nesterov, avagin, kernel list
On Thu, Sep 27, 2018 at 05:35:10PM +0200, Jann Horn wrote:
...
> >
> > Lets wait for fs people opinions.
>
> No reply yet - I guess I should just fix up the traceme case for now.
Yes please.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-09-27 15:41 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-19 7:07 [linux-next] BUG triggered in ptraceme Cyrill Gorcunov
2018-09-19 7:10 ` Cyrill Gorcunov
2018-09-19 14:16 ` Jann Horn
2018-09-19 16:13 ` Cyrill Gorcunov
2018-09-27 15:35 ` Jann Horn
2018-09-27 15:41 ` Cyrill Gorcunov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).