Hello Linus,
could you please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git for_linus
The pull contains three fixes for the fanotify use after free problems guys
were reporting. I have ended up with different lifetime rules for struct
fanotify_event_info
Hello Linus,
could you please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git for_linus
The pull contains three fixes for the fanotify use after free problems guys
were reporting. I have ended up with different lifetime rules for struct
fanotify_event_info
On Tue, Jan 28, 2014 at 03:53:27PM +0100, Jan Kara wrote:
> On Tue 28-01-14 12:07:51, Jiri Kosina wrote:
> > On Tue, 28 Jan 2014, Jan Kara wrote:
> >
> > > > 2b:* 4d 8b 64 c6 08 mov0x8(%r14,%rax,8),%r12 <--
> > > > trapping instruction
> > > >
> > > > R14 is
On Tue 28-01-14 12:07:51, Jiri Kosina wrote:
> On Tue, 28 Jan 2014, Jan Kara wrote:
>
> > > 2b:*4d 8b 64 c6 08 mov0x8(%r14,%rax,8),%r12 <--
> > > trapping instruction
> > >
> > > R14 is 0x6b6b6b6b6b6b6c03, which looks like a use-after-free.
> > Yup. But I'm somewhat
On Tue, 28 Jan 2014, Jan Kara wrote:
> > 2b:* 4d 8b 64 c6 08 mov0x8(%r14,%rax,8),%r12 <--
> > trapping instruction
> >
> > R14 is 0x6b6b6b6b6b6b6c03, which looks like a use-after-free.
> Yup. But I'm somewhat puzzled by the trace. We crash when calling
>
On Tue, 28 Jan 2014, Jan Kara wrote:
> Hum, still no luck with reproduction (either on physical machine or with
> KVM). Anyway, I've looked at the code again and the previous patch had a
> stupid bug (passing different pointer to fsnotify_destroy_event() than we
> should have), plus also the
On Tue 28-01-14 01:10:37, Dave Jones wrote:
> On Tue, Jan 28, 2014 at 12:40:17AM +0100, Jan Kara wrote:
> > On Fri 24-01-14 08:26:45, Jiri Kosina wrote:
> > > On Fri, 24 Jan 2014, Jan Kara wrote:
> > >
> > > > Strange. I've installed systemd system (openSUSE 13.1) and it boots
> > > >
On Tue 28-01-14 01:10:37, Dave Jones wrote:
On Tue, Jan 28, 2014 at 12:40:17AM +0100, Jan Kara wrote:
On Fri 24-01-14 08:26:45, Jiri Kosina wrote:
On Fri, 24 Jan 2014, Jan Kara wrote:
Strange. I've installed systemd system (openSUSE 13.1) and it boots
with the latest
On Tue, 28 Jan 2014, Jan Kara wrote:
Hum, still no luck with reproduction (either on physical machine or with
KVM). Anyway, I've looked at the code again and the previous patch had a
stupid bug (passing different pointer to fsnotify_destroy_event() than we
should have), plus also the
On Tue, 28 Jan 2014, Jan Kara wrote:
2b:* 4d 8b 64 c6 08 mov0x8(%r14,%rax,8),%r12 --
trapping instruction
R14 is 0x6b6b6b6b6b6b6c03, which looks like a use-after-free.
Yup. But I'm somewhat puzzled by the trace. We crash when calling
fsnotify_destroy_event()
On Tue 28-01-14 12:07:51, Jiri Kosina wrote:
On Tue, 28 Jan 2014, Jan Kara wrote:
2b:*4d 8b 64 c6 08 mov0x8(%r14,%rax,8),%r12 --
trapping instruction
R14 is 0x6b6b6b6b6b6b6c03, which looks like a use-after-free.
Yup. But I'm somewhat puzzled by the
On Tue, Jan 28, 2014 at 03:53:27PM +0100, Jan Kara wrote:
On Tue 28-01-14 12:07:51, Jiri Kosina wrote:
On Tue, 28 Jan 2014, Jan Kara wrote:
2b:* 4d 8b 64 c6 08 mov0x8(%r14,%rax,8),%r12 --
trapping instruction
R14 is 0x6b6b6b6b6b6b6c03, which looks
On Tue, Jan 28, 2014 at 12:40:17AM +0100, Jan Kara wrote:
> On Fri 24-01-14 08:26:45, Jiri Kosina wrote:
> > On Fri, 24 Jan 2014, Jan Kara wrote:
> >
> > > Strange. I've installed systemd system (openSUSE 13.1) and it boots
> > > with the latest Linus' kernel just fine (and I have at
On Fri 24-01-14 08:26:45, Jiri Kosina wrote:
> On Fri, 24 Jan 2014, Jan Kara wrote:
>
> > Strange. I've installed systemd system (openSUSE 13.1) and it boots
> > with the latest Linus' kernel just fine (and I have at least FANOTIFY
> > and SLAB debugging set the same way as you). But it was
On Fri 24-01-14 08:26:45, Jiri Kosina wrote:
On Fri, 24 Jan 2014, Jan Kara wrote:
Strange. I've installed systemd system (openSUSE 13.1) and it boots
with the latest Linus' kernel just fine (and I have at least FANOTIFY
and SLAB debugging set the same way as you). But it was only a
On Tue, Jan 28, 2014 at 12:40:17AM +0100, Jan Kara wrote:
On Fri 24-01-14 08:26:45, Jiri Kosina wrote:
On Fri, 24 Jan 2014, Jan Kara wrote:
Strange. I've installed systemd system (openSUSE 13.1) and it boots
with the latest Linus' kernel just fine (and I have at least FANOTIFY
On Fri, 24 Jan 2014, Jan Kara wrote:
> Strange. I've installed systemd system (openSUSE 13.1) and it boots
> with the latest Linus' kernel just fine (and I have at least FANOTIFY
> and SLAB debugging set the same way as you). But it was only a KVM
> guest. I'll try tomorrow with a physical
On Thu 23-01-14 16:07:45, Jiri Kosina wrote:
> On Thu, 23 Jan 2014, Jan Kara wrote:
>
> > > > > But refcounting seems like an overkill for this - there is exactly one
> > > > > fanotify_response_event structure iff it is a permission event. So
> > > > > something like the (completely untested)
On Thu, 23 Jan 2014, Jan Kara wrote:
> > > > But refcounting seems like an overkill for this - there is exactly one
> > > > fanotify_response_event structure iff it is a permission event. So
> > > > something like the (completely untested) attached patch should fix the
> > > > problem. But I
On Thu 23-01-14 11:23:53, Jiri Kosina wrote:
> On Wed, 22 Jan 2014, Linus Torvalds wrote:
>
> > > But refcounting seems like an overkill for this - there is exactly one
> > > fanotify_response_event structure iff it is a permission event. So
> > > something like the (completely untested) attached
On Wed 22-01-14 19:32:40, Dave Jones wrote:
> On Wed, Jan 22, 2014 at 04:08:52PM -0800, Linus Torvalds wrote:
> > On Wed, Jan 22, 2014 at 3:36 PM, Jan Kara wrote:
> > >
> > > But refcounting seems like an overkill for this - there is exactly one
> > > fanotify_response_event structure iff it
On Wed, 22 Jan 2014, Linus Torvalds wrote:
> > But refcounting seems like an overkill for this - there is exactly one
> > fanotify_response_event structure iff it is a permission event. So
> > something like the (completely untested) attached patch should fix the
> > problem. But I agree it's a
On Wed, 22 Jan 2014, Linus Torvalds wrote:
But refcounting seems like an overkill for this - there is exactly one
fanotify_response_event structure iff it is a permission event. So
something like the (completely untested) attached patch should fix the
problem. But I agree it's a bit ugly
On Wed 22-01-14 19:32:40, Dave Jones wrote:
On Wed, Jan 22, 2014 at 04:08:52PM -0800, Linus Torvalds wrote:
On Wed, Jan 22, 2014 at 3:36 PM, Jan Kara j...@suse.cz wrote:
But refcounting seems like an overkill for this - there is exactly one
fanotify_response_event structure iff it
On Thu 23-01-14 11:23:53, Jiri Kosina wrote:
On Wed, 22 Jan 2014, Linus Torvalds wrote:
But refcounting seems like an overkill for this - there is exactly one
fanotify_response_event structure iff it is a permission event. So
something like the (completely untested) attached patch
On Thu, 23 Jan 2014, Jan Kara wrote:
But refcounting seems like an overkill for this - there is exactly one
fanotify_response_event structure iff it is a permission event. So
something like the (completely untested) attached patch should fix the
problem. But I agree it's a bit
On Thu 23-01-14 16:07:45, Jiri Kosina wrote:
On Thu, 23 Jan 2014, Jan Kara wrote:
But refcounting seems like an overkill for this - there is exactly one
fanotify_response_event structure iff it is a permission event. So
something like the (completely untested) attached patch
On Fri, 24 Jan 2014, Jan Kara wrote:
Strange. I've installed systemd system (openSUSE 13.1) and it boots
with the latest Linus' kernel just fine (and I have at least FANOTIFY
and SLAB debugging set the same way as you). But it was only a KVM
guest. I'll try tomorrow with a physical
On Wed, Jan 22, 2014 at 04:08:52PM -0800, Linus Torvalds wrote:
> On Wed, Jan 22, 2014 at 3:36 PM, Jan Kara wrote:
> >
> > But refcounting seems like an overkill for this - there is exactly one
> > fanotify_response_event structure iff it is a permission event. So
> > something like the
On Wed, Jan 22, 2014 at 3:36 PM, Jan Kara wrote:
>
> But refcounting seems like an overkill for this - there is exactly one
> fanotify_response_event structure iff it is a permission event. So
> something like the (completely untested) attached patch should fix the
> problem. But I agree it's a
On Wed 22-01-14 10:20:01, Linus Torvalds wrote:
> On Tue, Jan 21, 2014 at 10:27 PM, Dave Jones wrote:
> >
> > BUG fanotify_event_info (Not tainted): Poison overwritten
>
> Looking at the poison data, it seems that is is the
>
> u32 response;
>
> field that has been overwritten (with
On Tue, Jan 21, 2014 at 10:27 PM, Dave Jones wrote:
>
> BUG fanotify_event_info (Not tainted): Poison overwritten
Looking at the poison data, it seems that is is the
u32 response;
field that has been overwritten (with all zero).
That doesn't really help me guess where the bug is,
On Wed, Jan 22, 2014 at 01:27:30AM -0500, Dave Jones wrote:
> Jan,
>
> since yesterdays changes, on boot I see a flood of messages from slub debug
> during boot..
>
> =
> BUG fanotify_event_info (Not tainted):
On Wed, Jan 22, 2014 at 01:27:30AM -0500, Dave Jones wrote:
Jan,
since yesterdays changes, on boot I see a flood of messages from slub debug
during boot..
=
BUG fanotify_event_info (Not tainted): Poison
On Tue, Jan 21, 2014 at 10:27 PM, Dave Jones da...@redhat.com wrote:
BUG fanotify_event_info (Not tainted): Poison overwritten
Looking at the poison data, it seems that is is the
u32 response;
field that has been overwritten (with all zero).
That doesn't really help me guess where
On Wed 22-01-14 10:20:01, Linus Torvalds wrote:
On Tue, Jan 21, 2014 at 10:27 PM, Dave Jones da...@redhat.com wrote:
BUG fanotify_event_info (Not tainted): Poison overwritten
Looking at the poison data, it seems that is is the
u32 response;
field that has been overwritten
On Wed, Jan 22, 2014 at 3:36 PM, Jan Kara j...@suse.cz wrote:
But refcounting seems like an overkill for this - there is exactly one
fanotify_response_event structure iff it is a permission event. So
something like the (completely untested) attached patch should fix the
problem. But I agree
On Wed, Jan 22, 2014 at 04:08:52PM -0800, Linus Torvalds wrote:
On Wed, Jan 22, 2014 at 3:36 PM, Jan Kara j...@suse.cz wrote:
But refcounting seems like an overkill for this - there is exactly one
fanotify_response_event structure iff it is a permission event. So
something like the
Jan,
since yesterdays changes, on boot I see a flood of messages from slub debug
during boot..
=
BUG fanotify_event_info (Not tainted): Poison overwritten
Jan,
since yesterdays changes, on boot I see a flood of messages from slub debug
during boot..
=
BUG fanotify_event_info (Not tainted): Poison overwritten
40 matches
Mail list logo
