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() an
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 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" allo
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 consid
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
[eventpoll]
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 8
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 s
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 ha
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 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 use
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 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 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 l
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 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 m
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 doesn'
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 th
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 0
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 (sb->s_op
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,
23 matches
Mail list logo
