On Thu, 1 May 2014, Srivatsa S. Bhat wrote:
>
> I tried to recall the *exact* steps that I had carried out when I first
> hit the bug. I realized that I had actually used kexec to boot the new
> kernel. I had originally booted into a 3.7.7 kernel that happens to be
> on that machine, and then
On Wed, Apr 30, 2014 at 12:16 PM, Srivatsa S. Bhat
wrote:
>
> So I tried the same recipe again (boot into 3.7.7 and kexec into 3.15-rc3+)
> and I got totally random crashes so far, once in sys_kill and two times in
> exit_mmap. So I guess the bug is in 3.7.x and probably 3.15-rc is fine after
>
On 05/01/2014 12:48 AM, Srivatsa S. Bhat wrote:
> On 05/01/2014 12:46 AM, Srivatsa S. Bhat wrote:
>> On 04/29/2014 03:29 PM, Srivatsa S. Bhat wrote:
>>> On 04/29/2014 03:55 AM, Linus Torvalds wrote:
On Mon, Apr 28, 2014 at 3:14 PM, Davidlohr Bueso wrote:
>
> I think that returning
On 05/01/2014 12:46 AM, Srivatsa S. Bhat wrote:
> On 04/29/2014 03:29 PM, Srivatsa S. Bhat wrote:
>> On 04/29/2014 03:55 AM, Linus Torvalds wrote:
>>> On Mon, Apr 28, 2014 at 3:14 PM, Davidlohr Bueso wrote:
I think that returning some stale/bogus vma is causing those segfaults
in
On 05/01/2014 12:46 AM, Srivatsa S. Bhat wrote:
On 04/29/2014 03:29 PM, Srivatsa S. Bhat wrote:
On 04/29/2014 03:55 AM, Linus Torvalds wrote:
On Mon, Apr 28, 2014 at 3:14 PM, Davidlohr Bueso davidl...@hp.com wrote:
I think that returning some stale/bogus vma is causing those segfaults
in
On 05/01/2014 12:48 AM, Srivatsa S. Bhat wrote:
On 05/01/2014 12:46 AM, Srivatsa S. Bhat wrote:
On 04/29/2014 03:29 PM, Srivatsa S. Bhat wrote:
On 04/29/2014 03:55 AM, Linus Torvalds wrote:
On Mon, Apr 28, 2014 at 3:14 PM, Davidlohr Bueso davidl...@hp.com wrote:
I think that returning some
On Wed, Apr 30, 2014 at 12:16 PM, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
So I tried the same recipe again (boot into 3.7.7 and kexec into 3.15-rc3+)
and I got totally random crashes so far, once in sys_kill and two times in
exit_mmap. So I guess the bug is in 3.7.x and
On Thu, 1 May 2014, Srivatsa S. Bhat wrote:
I tried to recall the *exact* steps that I had carried out when I first
hit the bug. I realized that I had actually used kexec to boot the new
kernel. I had originally booted into a 3.7.7 kernel that happens to be
on that machine, and then
On 04/28, Davidlohr Bueso wrote:
>
> @@ -29,6 +30,7 @@ void use_mm(struct mm_struct *mm)
> tsk->active_mm = mm;
> }
> tsk->mm = mm;
> + vmacache_flush(tsk);
But this can't help, we need to do this in unuse_mm(). And we can race
with vmacache_flush_all() which
On 04/29/2014 05:41 AM, Davidlohr Bueso wrote:
> On Mon, 2014-04-28 at 16:57 -0700, Linus Torvalds wrote:
>> On Mon, Apr 28, 2014 at 4:11 PM, Andrew Morton
>> wrote:
>>>
>>> unuse_mm() leaves current->mm at NULL so we'd hear about it pretty
>>> quickly if a user task was running use_mm/unuse_mm.
On 04/29/2014 03:55 AM, Linus Torvalds wrote:
> On Mon, Apr 28, 2014 at 3:14 PM, Davidlohr Bueso wrote:
>>
>> I think that returning some stale/bogus vma is causing those segfaults
>> in udev. It shouldn't occur in a normal scenario. What puzzles me is
>> that it's not always reproducible. This
On 04/29/2014 05:30 AM, Dave Jones wrote:
> On Tue, Apr 29, 2014 at 12:48:14AM +0530, Srivatsa S. Bhat wrote:
> > Hi,
> >
> > I hit this during boot on v3.15-rc3, just once so far.
> > Subsequent reboots went fine, and a few quick runs of multi-
> > threaded ebizzy also didn't recreate the
On 04/29/2014 04:09 AM, Davidlohr Bueso wrote:
> Adding Oleg.
>
> On Mon, 2014-04-28 at 14:55 -0700, Linus Torvalds wrote:
>> On Mon, Apr 28, 2014 at 2:20 PM, Linus Torvalds
>> wrote:
>>>
>>> That said, the bug does seem to be that some path doesn't invalidate
>>> the vmacache sufficiently, or
On 04/29/2014 03:25 AM, Linus Torvalds wrote:
> On Mon, Apr 28, 2014 at 2:20 PM, Linus Torvalds
> wrote:
>>
>> That said, the bug does seem to be that some path doesn't invalidate
>> the vmacache sufficiently, or something inserts a vmacache entry into
>> the current process when looking up a
On 04/29/2014 03:25 AM, Linus Torvalds wrote:
On Mon, Apr 28, 2014 at 2:20 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
That said, the bug does seem to be that some path doesn't invalidate
the vmacache sufficiently, or something inserts a vmacache entry into
the current process
On 04/29/2014 04:09 AM, Davidlohr Bueso wrote:
Adding Oleg.
On Mon, 2014-04-28 at 14:55 -0700, Linus Torvalds wrote:
On Mon, Apr 28, 2014 at 2:20 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
That said, the bug does seem to be that some path doesn't invalidate
the vmacache
On 04/29/2014 05:30 AM, Dave Jones wrote:
On Tue, Apr 29, 2014 at 12:48:14AM +0530, Srivatsa S. Bhat wrote:
Hi,
I hit this during boot on v3.15-rc3, just once so far.
Subsequent reboots went fine, and a few quick runs of multi-
threaded ebizzy also didn't recreate the problem.
On 04/29/2014 03:55 AM, Linus Torvalds wrote:
On Mon, Apr 28, 2014 at 3:14 PM, Davidlohr Bueso davidl...@hp.com wrote:
I think that returning some stale/bogus vma is causing those segfaults
in udev. It shouldn't occur in a normal scenario. What puzzles me is
that it's not always reproducible.
On 04/29/2014 05:41 AM, Davidlohr Bueso wrote:
On Mon, 2014-04-28 at 16:57 -0700, Linus Torvalds wrote:
On Mon, Apr 28, 2014 at 4:11 PM, Andrew Morton
a...@linux-foundation.org wrote:
unuse_mm() leaves current-mm at NULL so we'd hear about it pretty
quickly if a user task was running
On 04/28, Davidlohr Bueso wrote:
@@ -29,6 +30,7 @@ void use_mm(struct mm_struct *mm)
tsk-active_mm = mm;
}
tsk-mm = mm;
+ vmacache_flush(tsk);
But this can't help, we need to do this in unuse_mm(). And we can race
with vmacache_flush_all() which relies
On Mon, 2014-04-28 at 16:57 -0700, Linus Torvalds wrote:
> On Mon, Apr 28, 2014 at 4:11 PM, Andrew Morton
> wrote:
> >
> > unuse_mm() leaves current->mm at NULL so we'd hear about it pretty
> > quickly if a user task was running use_mm/unuse_mm.
>
> Yes.
>
> > I think so. Maybe it's time to
On Tue, Apr 29, 2014 at 12:48:14AM +0530, Srivatsa S. Bhat wrote:
> Hi,
>
> I hit this during boot on v3.15-rc3, just once so far.
> Subsequent reboots went fine, and a few quick runs of multi-
> threaded ebizzy also didn't recreate the problem.
>
> The kernel I was running was v3.15-rc3
On Mon, Apr 28, 2014 at 4:11 PM, Andrew Morton
wrote:
>
> unuse_mm() leaves current->mm at NULL so we'd hear about it pretty
> quickly if a user task was running use_mm/unuse_mm.
Yes.
> I think so. Maybe it's time to cook up a debug patch for Srivatsa to
> use? Dump the vma cache when the bug
On Mon, 28 Apr 2014 15:58:02 -0700 Linus Torvalds
wrote:
> On Mon, Apr 28, 2014 at 3:39 PM, Davidlohr Bueso wrote:
> >
> > Is this perhaps a KVM guest? fwiw I see CONFIG_KVM_ASYNC_PF=y which is a
> > user of use_mm().
>
> So I tried to look through these guys, and that was one of the ones I
On Mon, Apr 28, 2014 at 3:39 PM, Davidlohr Bueso wrote:
>
> Is this perhaps a KVM guest? fwiw I see CONFIG_KVM_ASYNC_PF=y which is a
> user of use_mm().
So I tried to look through these guys, and that was one of the ones I looked at.
It's using use_mm(), but it's only called through
Adding Oleg.
On Mon, 2014-04-28 at 14:55 -0700, Linus Torvalds wrote:
> On Mon, Apr 28, 2014 at 2:20 PM, Linus Torvalds
> wrote:
> >
> > That said, the bug does seem to be that some path doesn't invalidate
> > the vmacache sufficiently, or something inserts a vmacache entry into
> > the current
On Mon, Apr 28, 2014 at 3:14 PM, Davidlohr Bueso wrote:
>
> I think that returning some stale/bogus vma is causing those segfaults
> in udev. It shouldn't occur in a normal scenario. What puzzles me is
> that it's not always reproducible. This makes me wonder what else is
> going on...
I've
On Mon, 2014-04-28 at 15:05 -0700, Hugh Dickins wrote:
> On Mon, 28 Apr 2014, Linus Torvalds wrote:
> > On Mon, Apr 28, 2014 at 2:20 PM, Linus Torvalds
> > wrote:
> > >
> > > That said, the bug does seem to be that some path doesn't invalidate
> > > the vmacache sufficiently, or something inserts
On Mon, 28 Apr 2014, Linus Torvalds wrote:
> On Mon, Apr 28, 2014 at 2:20 PM, Linus Torvalds
> wrote:
> >
> > That said, the bug does seem to be that some path doesn't invalidate
> > the vmacache sufficiently, or something inserts a vmacache entry into
> > the current process when looking up a
On Mon, Apr 28, 2014 at 2:20 PM, Linus Torvalds
wrote:
>
> That said, the bug does seem to be that some path doesn't invalidate
> the vmacache sufficiently, or something inserts a vmacache entry into
> the current process when looking up a remote process or whatever.
> Davidlohr, ideas?
Maybe we
On Mon, Apr 28, 2014 at 12:18 PM, Srivatsa S. Bhat
wrote:
>
> I hit this during boot on v3.15-rc3, just once so far.
> Subsequent reboots went fine, and a few quick runs of multi-
> threaded ebizzy also didn't recreate the problem.
>
> The kernel I was running was v3.15-rc3 + some totally
>
On Mon, Apr 28, 2014 at 12:18 PM, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
I hit this during boot on v3.15-rc3, just once so far.
Subsequent reboots went fine, and a few quick runs of multi-
threaded ebizzy also didn't recreate the problem.
The kernel I was running was
On Mon, Apr 28, 2014 at 2:20 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
That said, the bug does seem to be that some path doesn't invalidate
the vmacache sufficiently, or something inserts a vmacache entry into
the current process when looking up a remote process or whatever.
On Mon, 28 Apr 2014, Linus Torvalds wrote:
On Mon, Apr 28, 2014 at 2:20 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
That said, the bug does seem to be that some path doesn't invalidate
the vmacache sufficiently, or something inserts a vmacache entry into
the current process
On Mon, 2014-04-28 at 15:05 -0700, Hugh Dickins wrote:
On Mon, 28 Apr 2014, Linus Torvalds wrote:
On Mon, Apr 28, 2014 at 2:20 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
That said, the bug does seem to be that some path doesn't invalidate
the vmacache sufficiently, or
On Mon, Apr 28, 2014 at 3:14 PM, Davidlohr Bueso davidl...@hp.com wrote:
I think that returning some stale/bogus vma is causing those segfaults
in udev. It shouldn't occur in a normal scenario. What puzzles me is
that it's not always reproducible. This makes me wonder what else is
going on...
Adding Oleg.
On Mon, 2014-04-28 at 14:55 -0700, Linus Torvalds wrote:
On Mon, Apr 28, 2014 at 2:20 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
That said, the bug does seem to be that some path doesn't invalidate
the vmacache sufficiently, or something inserts a vmacache entry
On Mon, Apr 28, 2014 at 3:39 PM, Davidlohr Bueso davidl...@hp.com wrote:
Is this perhaps a KVM guest? fwiw I see CONFIG_KVM_ASYNC_PF=y which is a
user of use_mm().
So I tried to look through these guys, and that was one of the ones I looked at.
It's using use_mm(), but it's only called
On Mon, 28 Apr 2014 15:58:02 -0700 Linus Torvalds
torva...@linux-foundation.org wrote:
On Mon, Apr 28, 2014 at 3:39 PM, Davidlohr Bueso davidl...@hp.com wrote:
Is this perhaps a KVM guest? fwiw I see CONFIG_KVM_ASYNC_PF=y which is a
user of use_mm().
So I tried to look through these
On Mon, Apr 28, 2014 at 4:11 PM, Andrew Morton
a...@linux-foundation.org wrote:
unuse_mm() leaves current-mm at NULL so we'd hear about it pretty
quickly if a user task was running use_mm/unuse_mm.
Yes.
I think so. Maybe it's time to cook up a debug patch for Srivatsa to
use? Dump the vma
On Tue, Apr 29, 2014 at 12:48:14AM +0530, Srivatsa S. Bhat wrote:
Hi,
I hit this during boot on v3.15-rc3, just once so far.
Subsequent reboots went fine, and a few quick runs of multi-
threaded ebizzy also didn't recreate the problem.
The kernel I was running was v3.15-rc3 + some
On Mon, 2014-04-28 at 16:57 -0700, Linus Torvalds wrote:
On Mon, Apr 28, 2014 at 4:11 PM, Andrew Morton
a...@linux-foundation.org wrote:
unuse_mm() leaves current-mm at NULL so we'd hear about it pretty
quickly if a user task was running use_mm/unuse_mm.
Yes.
I think so. Maybe it's
42 matches
Mail list logo