On 03/26/2014 01:53 AM, Dave Jones wrote:
On Tue, Mar 25, 2014 at 10:12:29PM +0100, Jan Kara wrote:
> This fixes an oops triggered by trinity when it tried mounting
> anon_inodefs which overwrote anon_inode_inode pointer while other CPU
> has been in anon_inode_getfile() between ihold()
On 03/26/2014 01:53 AM, Dave Jones wrote:
On Tue, Mar 25, 2014 at 10:12:29PM +0100, Jan Kara wrote:
This fixes an oops triggered by trinity when it tried mounting
anon_inodefs which overwrote anon_inode_inode pointer while other CPU
has been in anon_inode_getfile() between ihold() and
On Tue, Mar 25, 2014 at 10:12:29PM +0100, Jan Kara wrote:
> This fixes an oops triggered by trinity when it tried mounting
> anon_inodefs which overwrote anon_inode_inode pointer while other CPU
> has been in anon_inode_getfile() between ihold() and d_instantiate().
> Thus effectively
On Tue 25-03-14 17:41:59, Linus Torvalds wrote:
> On Tue, Mar 25, 2014 at 2:12 PM, Jan Kara wrote:
> >
> > Can you try whether the following patch fixes the issue for you?
>
> Good catch, Honza.
>
> I hate how fragile that code ends up being and would love to see that
> "anon_inode_inode"
On Tue, Mar 25, 2014 at 2:12 PM, Jan Kara wrote:
>
> Can you try whether the following patch fixes the issue for you?
Good catch, Honza.
I hate how fragile that code ends up being and would love to see that
"anon_inode_inode" allocation and assignment just once in
anon_inode_init(), but
On 03/25/2014 05:12 PM, Jan Kara wrote:
On Tue 25-03-14 13:51:11, Sasha Levin wrote:
On 03/25/2014 01:33 PM, Jan Kara wrote:
On Mon 24-03-14 20:44:14, Sasha Levin wrote:
On 03/24/2014 05:48 PM, Jan Kara wrote:
[ 339.948946] ** 4194304 8805ac03ba38 [eventpoll] 8806ec051fe0
On Tue 25-03-14 13:51:11, Sasha Levin wrote:
> On 03/25/2014 01:33 PM, Jan Kara wrote:
> >On Mon 24-03-14 20:44:14, Sasha Levin wrote:
> >>On 03/24/2014 05:48 PM, Jan Kara wrote:
> >[ 339.948946] ** 4194304 8805ac03ba38 [eventpoll] 8806ec051fe0
> >[eventpoll] 84666040
On 03/25/2014 01:33 PM, Jan Kara wrote:
On Mon 24-03-14 20:44:14, Sasha Levin wrote:
On 03/24/2014 05:48 PM, Jan Kara wrote:
[ 339.948946] ** 4194304 8805ac03ba38 [eventpoll] 8806ec051fe0
[eventpoll] 84666040 88056c73e7b0 (null)
OK, great. So finally we have
On Mon 24-03-14 20:44:14, Sasha Levin wrote:
> On 03/24/2014 05:48 PM, Jan Kara wrote:
> >>>[ 339.948946] ** 4194304 8805ac03ba38 [eventpoll] 8806ec051fe0
> >>>[eventpoll] 84666040 88056c73e7b0 (null)
> > OK, great. So finally we have something useful. We know we
On Mon 24-03-14 20:44:14, Sasha Levin wrote:
On 03/24/2014 05:48 PM, Jan Kara wrote:
[ 339.948946] ** 4194304 8805ac03ba38 [eventpoll] 8806ec051fe0
[eventpoll] 84666040 88056c73e7b0 (null)
OK, great. So finally we have something useful. We know we have
On 03/25/2014 01:33 PM, Jan Kara wrote:
On Mon 24-03-14 20:44:14, Sasha Levin wrote:
On 03/24/2014 05:48 PM, Jan Kara wrote:
[ 339.948946] ** 4194304 8805ac03ba38 [eventpoll] 8806ec051fe0
[eventpoll] 84666040 88056c73e7b0 (null)
OK, great. So finally we have
On Tue 25-03-14 13:51:11, Sasha Levin wrote:
On 03/25/2014 01:33 PM, Jan Kara wrote:
On Mon 24-03-14 20:44:14, Sasha Levin wrote:
On 03/24/2014 05:48 PM, Jan Kara wrote:
[ 339.948946] ** 4194304 8805ac03ba38 [eventpoll] 8806ec051fe0
[eventpoll] 84666040 88056c73e7b0
On 03/25/2014 05:12 PM, Jan Kara wrote:
On Tue 25-03-14 13:51:11, Sasha Levin wrote:
On 03/25/2014 01:33 PM, Jan Kara wrote:
On Mon 24-03-14 20:44:14, Sasha Levin wrote:
On 03/24/2014 05:48 PM, Jan Kara wrote:
[ 339.948946] ** 4194304 8805ac03ba38 [eventpoll] 8806ec051fe0
On Tue, Mar 25, 2014 at 2:12 PM, Jan Kara j...@suse.cz wrote:
Can you try whether the following patch fixes the issue for you?
Good catch, Honza.
I hate how fragile that code ends up being and would love to see that
anon_inode_inode allocation and assignment just once in
anon_inode_init(),
On Tue 25-03-14 17:41:59, Linus Torvalds wrote:
On Tue, Mar 25, 2014 at 2:12 PM, Jan Kara j...@suse.cz wrote:
Can you try whether the following patch fixes the issue for you?
Good catch, Honza.
I hate how fragile that code ends up being and would love to see that
anon_inode_inode
On Tue, Mar 25, 2014 at 10:12:29PM +0100, Jan Kara wrote:
This fixes an oops triggered by trinity when it tried mounting
anon_inodefs which overwrote anon_inode_inode pointer while other CPU
has been in anon_inode_getfile() between ihold() and d_instantiate().
Thus effectively creating
On 03/24/2014 05:48 PM, Jan Kara wrote:
>[ 339.948946] ** 4194304 8805ac03ba38 [eventpoll] 8806ec051fe0
>[eventpoll] 84666040 88056c73e7b0 (null)
OK, great. So finally we have something useful. We know we have problems
with [eventpoll] dentry. That is actually
On Mon 24-03-14 10:42:25, Sasha Levin wrote:
> On 03/10/2014 10:13 AM, Sasha Levin wrote:
> >On 03/10/2014 06:43 AM, Jan Kara wrote:
> >> By garbage, do you mean that it is a poison, completely random data or
> >> does
> >>inode->i_sb look like a valid pointer but just superblock isn't where it
On 03/10/2014 10:13 AM, Sasha Levin wrote:
On 03/10/2014 06:43 AM, Jan Kara wrote:
By garbage, do you mean that it is a poison, completely random data or does
inode->i_sb look like a valid pointer but just superblock isn't where it
points to?
It's poison.
>Any way I could get anything
On 03/10/2014 10:13 AM, Sasha Levin wrote:
On 03/10/2014 06:43 AM, Jan Kara wrote:
By garbage, do you mean that it is a poison, completely random data or does
inode-i_sb look like a valid pointer but just superblock isn't where it
points to?
It's poison.
Any way I could get anything
On Mon 24-03-14 10:42:25, Sasha Levin wrote:
On 03/10/2014 10:13 AM, Sasha Levin wrote:
On 03/10/2014 06:43 AM, Jan Kara wrote:
By garbage, do you mean that it is a poison, completely random data or
does
inode-i_sb look like a valid pointer but just superblock isn't where it
points to?
On 03/24/2014 05:48 PM, Jan Kara wrote:
[ 339.948946] ** 4194304 8805ac03ba38 [eventpoll] 8806ec051fe0
[eventpoll] 84666040 88056c73e7b0 (null)
OK, great. So finally we have something useful. We know we have problems
with [eventpoll] dentry. That is actually a
On 03/10/2014 06:43 AM, Jan Kara wrote:
By garbage, do you mean that it is a poison, completely random data or does
inode->i_sb look like a valid pointer but just superblock isn't where it
points to?
It's poison.
>Any way I could get anything useful any other way?
Hum, can you dump
On Fri 07-03-14 21:14:21, Sasha Levin wrote:
> On 03/06/2014 11:02 AM, Sasha Levin wrote:
> >On 03/05/2014 07:45 AM, Jan Kara wrote:
> >>On Tue 04-03-14 19:00:32, Sasha Levin wrote:
> >>>On 03/03/2014 04:40 PM, Jan Kara wrote:
> On Sat 01-03-14 15:05:21, Sasha Levin wrote:
> >>ping again?
On Fri 07-03-14 21:14:21, Sasha Levin wrote:
On 03/06/2014 11:02 AM, Sasha Levin wrote:
On 03/05/2014 07:45 AM, Jan Kara wrote:
On Tue 04-03-14 19:00:32, Sasha Levin wrote:
On 03/03/2014 04:40 PM, Jan Kara wrote:
On Sat 01-03-14 15:05:21, Sasha Levin wrote:
ping again?
I've been working
On 03/10/2014 06:43 AM, Jan Kara wrote:
By garbage, do you mean that it is a poison, completely random data or does
inode-i_sb look like a valid pointer but just superblock isn't where it
points to?
It's poison.
Any way I could get anything useful any other way?
Hum, can you dump the
On 03/06/2014 11:02 AM, Sasha Levin wrote:
On 03/05/2014 07:45 AM, Jan Kara wrote:
On Tue 04-03-14 19:00:32, Sasha Levin wrote:
On 03/03/2014 04:40 PM, Jan Kara wrote:
On Sat 01-03-14 15:05:21, Sasha Levin wrote:
ping again?
I've been working on it, but don't see an obvious issue.
It does
On 03/06/2014 11:02 AM, Sasha Levin wrote:
On 03/05/2014 07:45 AM, Jan Kara wrote:
On Tue 04-03-14 19:00:32, Sasha Levin wrote:
On 03/03/2014 04:40 PM, Jan Kara wrote:
On Sat 01-03-14 15:05:21, Sasha Levin wrote:
ping again?
I've been working on it, but don't see an obvious issue.
It does
On 03/05/2014 07:45 AM, Jan Kara wrote:
On Tue 04-03-14 19:00:32, Sasha Levin wrote:
On 03/03/2014 04:40 PM, Jan Kara wrote:
On Sat 01-03-14 15:05:21, Sasha Levin wrote:
ping again?
I've been working on it, but don't see an obvious issue.
It does look like an access to invalid memory easily
On 03/05/2014 07:45 AM, Jan Kara wrote:
On Tue 04-03-14 19:00:32, Sasha Levin wrote:
On 03/03/2014 04:40 PM, Jan Kara wrote:
On Sat 01-03-14 15:05:21, Sasha Levin wrote:
ping again?
I've been working on it, but don't see an obvious issue.
It does look like an access to invalid memory easily
On Tue 04-03-14 19:00:32, Sasha Levin wrote:
> On 03/03/2014 04:40 PM, Jan Kara wrote:
> >On Sat 01-03-14 15:05:21, Sasha Levin wrote:
> >>>ping again?
> >>>
> >>>I've been working on it, but don't see an obvious issue.
> >>>
> >>>It does look like an access to invalid memory easily doable from
>
On Tue 04-03-14 19:00:32, Sasha Levin wrote:
On 03/03/2014 04:40 PM, Jan Kara wrote:
On Sat 01-03-14 15:05:21, Sasha Levin wrote:
ping again?
I've been working on it, but don't see an obvious issue.
It does look like an access to invalid memory easily doable from
userspace, so it should
On 03/03/2014 04:40 PM, Jan Kara wrote:
On Sat 01-03-14 15:05:21, Sasha Levin wrote:
>ping again?
>
>I've been working on it, but don't see an obvious issue.
>
>It does look like an access to invalid memory easily doable from
>userspace, so it should probably get fixed soon...
Hum, can you
On 03/03/2014 04:40 PM, Jan Kara wrote:
On Sat 01-03-14 15:05:21, Sasha Levin wrote:
ping again?
I've been working on it, but don't see an obvious issue.
It does look like an access to invalid memory easily doable from
userspace, so it should probably get fixed soon...
Hum, can you maybe
On Sat 01-03-14 15:05:21, Sasha Levin wrote:
> ping again?
>
> I've been working on it, but don't see an obvious issue.
>
> It does look like an access to invalid memory easily doable from
> userspace, so it should probably get fixed soon...
Hum, can you maybe dump the name in dentry passed to
On Sat 01-03-14 15:05:21, Sasha Levin wrote:
ping again?
I've been working on it, but don't see an obvious issue.
It does look like an access to invalid memory easily doable from
userspace, so it should probably get fixed soon...
Hum, can you maybe dump the name in dentry passed to
On 03/01/2014 10:35 PM, Linus Torvalds wrote:
On Sat, Mar 1, 2014 at 2:05 PM, Sasha Levin wrote:
ping again?
I've been working on it, but don't see an obvious issue.
It does look like an access to invalid memory easily doable from userspace,
so it should probably get fixed soon...
It
On 03/01/2014 10:35 PM, Linus Torvalds wrote:
On Sat, Mar 1, 2014 at 2:05 PM, Sasha Levin sasha.le...@oracle.com wrote:
ping again?
I've been working on it, but don't see an obvious issue.
It does look like an access to invalid memory easily doable from userspace,
so it should probably get
On Sat, Mar 1, 2014 at 2:05 PM, Sasha Levin wrote:
> ping again?
>
> I've been working on it, but don't see an obvious issue.
>
> It does look like an access to invalid memory easily doable from userspace,
> so it should probably get fixed soon...
It doesn't happen in mainline? Any possibility
ping again?
I've been working on it, but don't see an obvious issue.
It does look like an access to invalid memory easily doable from userspace, so it should probably
get fixed soon...
Thanks,
Sasha
On 01/08/2014 11:00 AM, Sasha Levin wrote:
ping? still happening in -next.
On 12/18/2013
ping again?
I've been working on it, but don't see an obvious issue.
It does look like an access to invalid memory easily doable from userspace, so it should probably
get fixed soon...
Thanks,
Sasha
On 01/08/2014 11:00 AM, Sasha Levin wrote:
ping? still happening in -next.
On 12/18/2013
On Sat, Mar 1, 2014 at 2:05 PM, Sasha Levin sasha.le...@oracle.com wrote:
ping again?
I've been working on it, but don't see an obvious issue.
It does look like an access to invalid memory easily doable from userspace,
so it should probably get fixed soon...
It doesn't happen in mainline?
ping? still happening in -next.
On 12/18/2013 07:25 PM, Sasha Levin wrote:
Hi all,
While fuzzing with trinity inside a KVM tools guest running latest -next
kernel, I've stumbled on
the following spew.
This happens when sb is dereferenced in __mark_inode_dirty():
if
ping? still happening in -next.
On 12/18/2013 07:25 PM, Sasha Levin wrote:
Hi all,
While fuzzing with trinity inside a KVM tools guest running latest -next
kernel, I've stumbled on
the following spew.
This happens when sb is dereferenced in __mark_inode_dirty():
if
Hi all,
While fuzzing with trinity inside a KVM tools guest running latest -next kernel, I've stumbled on
the following spew.
This happens when sb is dereferenced in __mark_inode_dirty():
if (sb->s_op->dirty_inode) <--- HERE
Hi all,
While fuzzing with trinity inside a KVM tools guest running latest -next kernel, I've stumbled on
the following spew.
This happens when sb is dereferenced in __mark_inode_dirty():
if (sb-s_op-dirty_inode) --- HERE
sb-s_op-dirty_inode(inode,
46 matches
Mail list logo
