On 2019/7/20 上午12:34, syzbot wrote:
syzbot has bisected this bug to:
commit 7f466032dc9e5a61217f22ea34b2df932786bbfc
Author: Jason Wang
Date: Fri May 24 08:12:18 2019 +
vhost: access vq metadata through kernel virtual address
bisection log:
https://syzkaller.appspot.com/x/bisect.
syzbot has bisected this bug to:
commit 7f466032dc9e5a61217f22ea34b2df932786bbfc
Author: Jason Wang
Date: Fri May 24 08:12:18 2019 +
vhost: access vq metadata through kernel virtual address
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=123faf7060
start commit: 22
Hello,
syzbot found the following crash on:
HEAD commit:22051d9c Merge tag 'platform-drivers-x86-v5.3-2' of git://..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12dab5a460
kernel config: https://syzkaller.appspot.com/x/.config?x=135cb826ac59d7fc
da
syzbot has found a reproducer for the following crash on:
HEAD commit:4110b42356f3 Add linux-next specific files for 20180810
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=107162c440
kernel config: https://syzkaller.appspot.com/x/.config?x=1d80606e3
Hello,
syzbot found the following crash on:
HEAD commit:8c8399e0a3fb Add linux-next specific files for 20180806
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=173d867240
kernel config: https://syzkaller.appspot.com/x/.config?x=1b6bc1781e49e93e
dashb
On Thu, Feb 15, 2018 at 02:22:39PM +, Will Deacon wrote:
> Instead, we've come up with a more plausible sequence that can in theory
> happen on a single CPU:
>
>
>
> do_exit
> exit_mm
> mmgrab(mm); // foo's mm has count +1
> BUG_ON(mm !=
On Fri, Feb 16, 2018 at 05:17:57PM +, Mathieu Desnoyers wrote:
> - On Feb 16, 2018, at 11:53 AM, Mark Rutland mark.rutl...@arm.com wrote:
> > I suspect we have a bogus mmdrop or mmput elsewhere, and do_exit() and
> > finish_task_switch() aren't to blame.
>
> Currently reviewing: fs/proc/ba
- On Feb 16, 2018, at 11:53 AM, Mark Rutland mark.rutl...@arm.com wrote:
> Hi,
>
> On Thu, Feb 15, 2018 at 10:08:56PM +, Mathieu Desnoyers wrote:
>> My current theory: do_exit() gets preempted after having set current->mm
>> to NULL, and after having issued mmput(), which brings the mm_co
Hi,
On Thu, Feb 15, 2018 at 10:08:56PM +, Mathieu Desnoyers wrote:
> My current theory: do_exit() gets preempted after having set current->mm
> to NULL, and after having issued mmput(), which brings the mm_count down
> to 0.
>
> Unfortunately, if the scheduler switches from a userspace thread
Please trim..
On Fri, Feb 16, 2018 at 12:02:42AM +, Mathieu Desnoyers wrote:
> > My current theory: do_exit() gets preempted after having set current->mm
> > to NULL, and after having issued mmput(), which brings the mm_count down
> > to 0.
No it doesn't..
remember, the last thread of a pro
- On Feb 15, 2018, at 5:08 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Feb 15, 2018, at 1:21 PM, Will Deacon will.dea...@arm.com wrote:
>
>> On Thu, Feb 15, 2018 at 05:47:54PM +0100, Peter Zijlstra wrote:
>>> On Thu, Feb 15, 2018 at 02:22:39PM +, Will Deacon wr
- On Feb 15, 2018, at 1:21 PM, Will Deacon will.dea...@arm.com wrote:
> On Thu, Feb 15, 2018 at 05:47:54PM +0100, Peter Zijlstra wrote:
>> On Thu, Feb 15, 2018 at 02:22:39PM +, Will Deacon wrote:
>> > Instead, we've come up with a more plausible sequence that can in theory
>> > happen on a
On Thu, Feb 15, 2018 at 05:47:54PM +0100, Peter Zijlstra wrote:
> On Thu, Feb 15, 2018 at 02:22:39PM +, Will Deacon wrote:
> > Instead, we've come up with a more plausible sequence that can in theory
> > happen on a single CPU:
> >
> >
> >
> > do_exit
> > exit_mm
>
> If this is the last
On Thu, Feb 15, 2018 at 02:22:39PM +, Will Deacon wrote:
> Assuming others agree with this diagnosis, I'm not sure how to fix it.
> It's basically not safe to set current->mm = NULL with preemption enabled.
One thing we could try would be to leave current->mm alone and just do the
mmdrop in fi
On Thu, Feb 15, 2018 at 02:22:39PM +, Will Deacon wrote:
> Instead, we've come up with a more plausible sequence that can in theory
> happen on a single CPU:
>
>
>
> do_exit
> exit_mm
If this is the last task of the process, we would expect:
mm_count == 1
mm_users == 1
at this p
On Wed, Feb 14, 2018 at 06:53:44PM +, Mathieu Desnoyers wrote:
> - On Feb 14, 2018, at 11:51 AM, Mark Rutland mark.rutl...@arm.com wrote:
> > On Wed, Feb 14, 2018 at 03:07:41PM +, Will Deacon wrote:
> >> If the exit()ing task had recently migrated from another CPU, then that
> >> CPU co
- On Feb 15, 2018, at 6:49 AM, Peter Zijlstra pet...@infradead.org wrote:
> On Wed, Feb 14, 2018 at 06:53:44PM +, Mathieu Desnoyers wrote:
>> However, given the scenario involves multiples CPUs (one doing exit_mm(),
>> the other doing context switch), the actual order of perceived load/sto
On Wed, Feb 14, 2018 at 06:53:44PM +, Mathieu Desnoyers wrote:
> However, given the scenario involves multiples CPUs (one doing exit_mm(),
> the other doing context switch), the actual order of perceived load/store
> can be shuffled. And AFAIU nothing prevents the CPU from ordering the
> atomic
- On Feb 14, 2018, at 11:51 AM, Mark Rutland mark.rutl...@arm.com wrote:
> On Wed, Feb 14, 2018 at 03:07:41PM +, Will Deacon wrote:
>> Hi Mark,
>
> Hi Will,
>
>> Cheers for the report. These things tend to be a pain to debug, but I've had
>> a go.
>
> Thanks for taking a look!
>
>> On
On Wed, Feb 14, 2018 at 03:07:41PM +, Will Deacon wrote:
> Hi Mark,
Hi Will,
> Cheers for the report. These things tend to be a pain to debug, but I've had
> a go.
Thanks for taking a look!
> On Wed, Feb 14, 2018 at 12:02:54PM +, Mark Rutland wrote:
> The interesting thing here is on th
Hi Mark,
Cheers for the report. These things tend to be a pain to debug, but I've had
a go.
On Wed, Feb 14, 2018 at 12:02:54PM +, Mark Rutland wrote:
> As a heads-up, I hit the splat below when fuzzing v4.16-rc1 on arm64.
>
> Evidently, we get to finish_task_switch() with rq->prev_mm != NULL
Hi,
As a heads-up, I hit the splat below when fuzzing v4.16-rc1 on arm64.
Evidently, we get to finish_task_switch() with rq->prev_mm != NULL,
despite rq->prev_mm having been freed. KASAN spots the dereference of
mm->membarrier_state in membarrier_mm_sync_core_before_usermode(mm), but
AFAICT the u
22 matches
Mail list logo
