* 5.9-rc7 null ptr deref in __i915_gem_userptr_get_pages_worker
@ 2020-09-28 9:39 ` Jason A. Donenfeld
0 siblings, 0 replies; 21+ messages in thread
From: Jason A. Donenfeld @ 2020-09-28 9:39 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx, open list:DRM DRIVERS, open list
Seeing a new crash in 5.9-rc7 I didn't have in 5.9-rc6:
[ 1311.596896] BUG: kernel NULL pointer dereference, address: 0000000000000064
[ 1311.596898] #PF: supervisor write access in kernel mode
[ 1311.596899] #PF: error_code(0x0002) - not-present page
[ 1311.596899] PGD 0 P4D 0
[ 1311.596901] Oops: 0002 [#1] SMP
[ 1311.596902] CPU: 10 PID: 1431 Comm: kworker/u33:1 Tainted: P S U
O 5.9.0-rc7+ #140
[ 1311.596903] Hardware name: LENOVO 20QTCTO1WW/20QTCTO1WW, BIOS
N2OET47W (1.34 ) 08/06/2020
[ 1311.596955] Workqueue: i915-userptr-acquire
__i915_gem_userptr_get_pages_worker [i915]
[ 1311.596959] RIP: 0010:__get_user_pages_remote+0xd7/0x310
[ 1311.596960] Code: f5 01 00 00 83 7d 00 01 0f 85 ed 01 00 00 f7 c1
00 00 04 00 0f 84 58 01 00 00 65 48 8b 04 25 00 6d 01 00 48 8b 80 40
03 00 00 <c7> 40 64 01 00 00 00 65 48 8b 04 25 00 6d 01 00 48 c7 44 24
18 00
[ 1311.596961] RSP: 0018:ffff888fdfe47de0 EFLAGS: 00010206
[ 1311.596962] RAX: 0000000000000000 RBX: 00007fe188531000 RCX: 0000000000040001
[ 1311.596962] RDX: 0000000000000001 RSI: 00007fe188531000 RDI: ffff888ff0748f00
[ 1311.596963] RBP: ffff888fdfe47e54 R08: ffff888fedc7d7c8 R09: 0000000000000000
[ 1311.596963] R10: 0000000000000018 R11: fefefefefefefeff R12: ffff888ff0748f00
[ 1311.596963] R13: ffff888fedc7d7c8 R14: ffff888f81fe3a40 R15: 0000000000042003
[ 1311.596964] FS: 0000000000000000(0000) GS:ffff888ffc480000(0000)
knlGS:0000000000000000
[ 1311.596965] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1311.596965] CR2: 0000000000000064 CR3: 0000000002009003 CR4: 00000000003706e0
[ 1311.596966] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1311.596966] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 1311.596967] Call Trace:
[ 1311.596993] __i915_gem_userptr_get_pages_worker+0xc8/0x260 [i915]
[ 1311.596996] process_one_work+0x1ca/0x390
[ 1311.596997] worker_thread+0x48/0x3c0
[ 1311.596998] ? rescuer_thread+0x3d0/0x3d0
[ 1311.597000] kthread+0x114/0x130
[ 1311.597001] ? kthread_create_worker_on_cpu+0x40/0x40
[ 1311.597003] ret_from_fork+0x1f/0x30
[ 1311.597031] CR2: 0000000000000064
[ 1311.597033] ---[ end trace e2b8ddde994a6f6d ]---
^ permalink raw reply [flat|nested] 21+ messages in thread
* 5.9-rc7 null ptr deref in __i915_gem_userptr_get_pages_worker
@ 2020-09-28 9:39 ` Jason A. Donenfeld
0 siblings, 0 replies; 21+ messages in thread
From: Jason A. Donenfeld @ 2020-09-28 9:39 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx, open list, open list:DRM DRIVERS
Seeing a new crash in 5.9-rc7 I didn't have in 5.9-rc6:
[ 1311.596896] BUG: kernel NULL pointer dereference, address: 0000000000000064
[ 1311.596898] #PF: supervisor write access in kernel mode
[ 1311.596899] #PF: error_code(0x0002) - not-present page
[ 1311.596899] PGD 0 P4D 0
[ 1311.596901] Oops: 0002 [#1] SMP
[ 1311.596902] CPU: 10 PID: 1431 Comm: kworker/u33:1 Tainted: P S U
O 5.9.0-rc7+ #140
[ 1311.596903] Hardware name: LENOVO 20QTCTO1WW/20QTCTO1WW, BIOS
N2OET47W (1.34 ) 08/06/2020
[ 1311.596955] Workqueue: i915-userptr-acquire
__i915_gem_userptr_get_pages_worker [i915]
[ 1311.596959] RIP: 0010:__get_user_pages_remote+0xd7/0x310
[ 1311.596960] Code: f5 01 00 00 83 7d 00 01 0f 85 ed 01 00 00 f7 c1
00 00 04 00 0f 84 58 01 00 00 65 48 8b 04 25 00 6d 01 00 48 8b 80 40
03 00 00 <c7> 40 64 01 00 00 00 65 48 8b 04 25 00 6d 01 00 48 c7 44 24
18 00
[ 1311.596961] RSP: 0018:ffff888fdfe47de0 EFLAGS: 00010206
[ 1311.596962] RAX: 0000000000000000 RBX: 00007fe188531000 RCX: 0000000000040001
[ 1311.596962] RDX: 0000000000000001 RSI: 00007fe188531000 RDI: ffff888ff0748f00
[ 1311.596963] RBP: ffff888fdfe47e54 R08: ffff888fedc7d7c8 R09: 0000000000000000
[ 1311.596963] R10: 0000000000000018 R11: fefefefefefefeff R12: ffff888ff0748f00
[ 1311.596963] R13: ffff888fedc7d7c8 R14: ffff888f81fe3a40 R15: 0000000000042003
[ 1311.596964] FS: 0000000000000000(0000) GS:ffff888ffc480000(0000)
knlGS:0000000000000000
[ 1311.596965] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1311.596965] CR2: 0000000000000064 CR3: 0000000002009003 CR4: 00000000003706e0
[ 1311.596966] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1311.596966] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 1311.596967] Call Trace:
[ 1311.596993] __i915_gem_userptr_get_pages_worker+0xc8/0x260 [i915]
[ 1311.596996] process_one_work+0x1ca/0x390
[ 1311.596997] worker_thread+0x48/0x3c0
[ 1311.596998] ? rescuer_thread+0x3d0/0x3d0
[ 1311.597000] kthread+0x114/0x130
[ 1311.597001] ? kthread_create_worker_on_cpu+0x40/0x40
[ 1311.597003] ret_from_fork+0x1f/0x30
[ 1311.597031] CR2: 0000000000000064
[ 1311.597033] ---[ end trace e2b8ddde994a6f6d ]---
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 5.9-rc7 null ptr deref in __i915_gem_userptr_get_pages_worker
2020-09-28 9:39 ` Jason A. Donenfeld
(?)
@ 2020-09-28 9:57 ` Jason A. Donenfeld
-1 siblings, 0 replies; 21+ messages in thread
From: Jason A. Donenfeld @ 2020-09-28 9:57 UTC (permalink / raw)
To: Vasily Gorbik, Linux-MM, Jason Gunthorpe, Andrew Morton
Cc: intel-gfx, open list:DRM DRIVERS, open list, Chris Wilson
Increasing the CC list a bit, as i915 didn't really get much churn
rc6->rc7, but mm/gup.c did, and mm has had a lot of recent changes.
On Mon, Sep 28, 2020 at 11:39 AM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> Seeing a new crash in 5.9-rc7 I didn't have in 5.9-rc6:
>
> [ 1311.596896] BUG: kernel NULL pointer dereference, address: 0000000000000064
> [ 1311.596898] #PF: supervisor write access in kernel mode
> [ 1311.596899] #PF: error_code(0x0002) - not-present page
> [ 1311.596899] PGD 0 P4D 0
> [ 1311.596901] Oops: 0002 [#1] SMP
> [ 1311.596902] CPU: 10 PID: 1431 Comm: kworker/u33:1 Tainted: P S U
> O 5.9.0-rc7+ #140
> [ 1311.596903] Hardware name: LENOVO 20QTCTO1WW/20QTCTO1WW, BIOS
> N2OET47W (1.34 ) 08/06/2020
> [ 1311.596955] Workqueue: i915-userptr-acquire
> __i915_gem_userptr_get_pages_worker [i915]
> [ 1311.596959] RIP: 0010:__get_user_pages_remote+0xd7/0x310
> [ 1311.596960] Code: f5 01 00 00 83 7d 00 01 0f 85 ed 01 00 00 f7 c1
> 00 00 04 00 0f 84 58 01 00 00 65 48 8b 04 25 00 6d 01 00 48 8b 80 40
> 03 00 00 <c7> 40 64 01 00 00 00 65 48 8b 04 25 00 6d 01 00 48 c7 44 24
> 18 00
> [ 1311.596961] RSP: 0018:ffff888fdfe47de0 EFLAGS: 00010206
> [ 1311.596962] RAX: 0000000000000000 RBX: 00007fe188531000 RCX: 0000000000040001
> [ 1311.596962] RDX: 0000000000000001 RSI: 00007fe188531000 RDI: ffff888ff0748f00
> [ 1311.596963] RBP: ffff888fdfe47e54 R08: ffff888fedc7d7c8 R09: 0000000000000000
> [ 1311.596963] R10: 0000000000000018 R11: fefefefefefefeff R12: ffff888ff0748f00
> [ 1311.596963] R13: ffff888fedc7d7c8 R14: ffff888f81fe3a40 R15: 0000000000042003
> [ 1311.596964] FS: 0000000000000000(0000) GS:ffff888ffc480000(0000)
> knlGS:0000000000000000
> [ 1311.596965] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 1311.596965] CR2: 0000000000000064 CR3: 0000000002009003 CR4: 00000000003706e0
> [ 1311.596966] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 1311.596966] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 1311.596967] Call Trace:
> [ 1311.596993] __i915_gem_userptr_get_pages_worker+0xc8/0x260 [i915]
> [ 1311.596996] process_one_work+0x1ca/0x390
> [ 1311.596997] worker_thread+0x48/0x3c0
> [ 1311.596998] ? rescuer_thread+0x3d0/0x3d0
> [ 1311.597000] kthread+0x114/0x130
> [ 1311.597001] ? kthread_create_worker_on_cpu+0x40/0x40
> [ 1311.597003] ret_from_fork+0x1f/0x30
> [ 1311.597031] CR2: 0000000000000064
> [ 1311.597033] ---[ end trace e2b8ddde994a6f6d ]---
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 5.9-rc7 null ptr deref in __i915_gem_userptr_get_pages_worker
@ 2020-09-28 9:57 ` Jason A. Donenfeld
0 siblings, 0 replies; 21+ messages in thread
From: Jason A. Donenfeld @ 2020-09-28 9:57 UTC (permalink / raw)
To: Vasily Gorbik, Linux-MM, Jason Gunthorpe, Andrew Morton
Cc: intel-gfx, open list:DRM DRIVERS, open list, Chris Wilson
Increasing the CC list a bit, as i915 didn't really get much churn
rc6->rc7, but mm/gup.c did, and mm has had a lot of recent changes.
On Mon, Sep 28, 2020 at 11:39 AM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> Seeing a new crash in 5.9-rc7 I didn't have in 5.9-rc6:
>
> [ 1311.596896] BUG: kernel NULL pointer dereference, address: 0000000000000064
> [ 1311.596898] #PF: supervisor write access in kernel mode
> [ 1311.596899] #PF: error_code(0x0002) - not-present page
> [ 1311.596899] PGD 0 P4D 0
> [ 1311.596901] Oops: 0002 [#1] SMP
> [ 1311.596902] CPU: 10 PID: 1431 Comm: kworker/u33:1 Tainted: P S U
> O 5.9.0-rc7+ #140
> [ 1311.596903] Hardware name: LENOVO 20QTCTO1WW/20QTCTO1WW, BIOS
> N2OET47W (1.34 ) 08/06/2020
> [ 1311.596955] Workqueue: i915-userptr-acquire
> __i915_gem_userptr_get_pages_worker [i915]
> [ 1311.596959] RIP: 0010:__get_user_pages_remote+0xd7/0x310
> [ 1311.596960] Code: f5 01 00 00 83 7d 00 01 0f 85 ed 01 00 00 f7 c1
> 00 00 04 00 0f 84 58 01 00 00 65 48 8b 04 25 00 6d 01 00 48 8b 80 40
> 03 00 00 <c7> 40 64 01 00 00 00 65 48 8b 04 25 00 6d 01 00 48 c7 44 24
> 18 00
> [ 1311.596961] RSP: 0018:ffff888fdfe47de0 EFLAGS: 00010206
> [ 1311.596962] RAX: 0000000000000000 RBX: 00007fe188531000 RCX: 0000000000040001
> [ 1311.596962] RDX: 0000000000000001 RSI: 00007fe188531000 RDI: ffff888ff0748f00
> [ 1311.596963] RBP: ffff888fdfe47e54 R08: ffff888fedc7d7c8 R09: 0000000000000000
> [ 1311.596963] R10: 0000000000000018 R11: fefefefefefefeff R12: ffff888ff0748f00
> [ 1311.596963] R13: ffff888fedc7d7c8 R14: ffff888f81fe3a40 R15: 0000000000042003
> [ 1311.596964] FS: 0000000000000000(0000) GS:ffff888ffc480000(0000)
> knlGS:0000000000000000
> [ 1311.596965] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 1311.596965] CR2: 0000000000000064 CR3: 0000000002009003 CR4: 00000000003706e0
> [ 1311.596966] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 1311.596966] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 1311.596967] Call Trace:
> [ 1311.596993] __i915_gem_userptr_get_pages_worker+0xc8/0x260 [i915]
> [ 1311.596996] process_one_work+0x1ca/0x390
> [ 1311.596997] worker_thread+0x48/0x3c0
> [ 1311.596998] ? rescuer_thread+0x3d0/0x3d0
> [ 1311.597000] kthread+0x114/0x130
> [ 1311.597001] ? kthread_create_worker_on_cpu+0x40/0x40
> [ 1311.597003] ret_from_fork+0x1f/0x30
> [ 1311.597031] CR2: 0000000000000064
> [ 1311.597033] ---[ end trace e2b8ddde994a6f6d ]---
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 5.9-rc7 null ptr deref in __i915_gem_userptr_get_pages_worker
@ 2020-09-28 9:57 ` Jason A. Donenfeld
0 siblings, 0 replies; 21+ messages in thread
From: Jason A. Donenfeld @ 2020-09-28 9:57 UTC (permalink / raw)
To: Vasily Gorbik, Linux-MM, Jason Gunthorpe, Andrew Morton
Cc: intel-gfx, open list, open list:DRM DRIVERS, Chris Wilson
Increasing the CC list a bit, as i915 didn't really get much churn
rc6->rc7, but mm/gup.c did, and mm has had a lot of recent changes.
On Mon, Sep 28, 2020 at 11:39 AM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> Seeing a new crash in 5.9-rc7 I didn't have in 5.9-rc6:
>
> [ 1311.596896] BUG: kernel NULL pointer dereference, address: 0000000000000064
> [ 1311.596898] #PF: supervisor write access in kernel mode
> [ 1311.596899] #PF: error_code(0x0002) - not-present page
> [ 1311.596899] PGD 0 P4D 0
> [ 1311.596901] Oops: 0002 [#1] SMP
> [ 1311.596902] CPU: 10 PID: 1431 Comm: kworker/u33:1 Tainted: P S U
> O 5.9.0-rc7+ #140
> [ 1311.596903] Hardware name: LENOVO 20QTCTO1WW/20QTCTO1WW, BIOS
> N2OET47W (1.34 ) 08/06/2020
> [ 1311.596955] Workqueue: i915-userptr-acquire
> __i915_gem_userptr_get_pages_worker [i915]
> [ 1311.596959] RIP: 0010:__get_user_pages_remote+0xd7/0x310
> [ 1311.596960] Code: f5 01 00 00 83 7d 00 01 0f 85 ed 01 00 00 f7 c1
> 00 00 04 00 0f 84 58 01 00 00 65 48 8b 04 25 00 6d 01 00 48 8b 80 40
> 03 00 00 <c7> 40 64 01 00 00 00 65 48 8b 04 25 00 6d 01 00 48 c7 44 24
> 18 00
> [ 1311.596961] RSP: 0018:ffff888fdfe47de0 EFLAGS: 00010206
> [ 1311.596962] RAX: 0000000000000000 RBX: 00007fe188531000 RCX: 0000000000040001
> [ 1311.596962] RDX: 0000000000000001 RSI: 00007fe188531000 RDI: ffff888ff0748f00
> [ 1311.596963] RBP: ffff888fdfe47e54 R08: ffff888fedc7d7c8 R09: 0000000000000000
> [ 1311.596963] R10: 0000000000000018 R11: fefefefefefefeff R12: ffff888ff0748f00
> [ 1311.596963] R13: ffff888fedc7d7c8 R14: ffff888f81fe3a40 R15: 0000000000042003
> [ 1311.596964] FS: 0000000000000000(0000) GS:ffff888ffc480000(0000)
> knlGS:0000000000000000
> [ 1311.596965] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 1311.596965] CR2: 0000000000000064 CR3: 0000000002009003 CR4: 00000000003706e0
> [ 1311.596966] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 1311.596966] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 1311.596967] Call Trace:
> [ 1311.596993] __i915_gem_userptr_get_pages_worker+0xc8/0x260 [i915]
> [ 1311.596996] process_one_work+0x1ca/0x390
> [ 1311.596997] worker_thread+0x48/0x3c0
> [ 1311.596998] ? rescuer_thread+0x3d0/0x3d0
> [ 1311.597000] kthread+0x114/0x130
> [ 1311.597001] ? kthread_create_worker_on_cpu+0x40/0x40
> [ 1311.597003] ret_from_fork+0x1f/0x30
> [ 1311.597031] CR2: 0000000000000064
> [ 1311.597033] ---[ end trace e2b8ddde994a6f6d ]---
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 5.9-rc7 null ptr deref in __i915_gem_userptr_get_pages_worker
2020-09-28 9:57 ` Jason A. Donenfeld
(?)
@ 2020-09-28 10:17 ` Jason A. Donenfeld
-1 siblings, 0 replies; 21+ messages in thread
From: Jason A. Donenfeld @ 2020-09-28 10:17 UTC (permalink / raw)
To: Jason Gunthorpe, Peter Xu, Linus Torvalds
Cc: intel-gfx, open list:DRM DRIVERS, open list, Chris Wilson,
Linux-MM, Andrew Morton
Alright, the failing code seems to be in mm:
if (flags & FOLL_PIN)
atomic_set(¤t->mm->has_pinned, 1);
Apparently you can't rely on current->mm being valid in this context;
it's null here, hence the +0x64 for has_pinned's offset.
This was added by 008cfe4418b3 ("mm: Introduce mm_struct.has_pinned"),
which is new for rc7 indeed.
The crash goes away when changing that to:
if ((flags & FOLL_PIN) && current->mm)
atomic_set(¤t->mm->has_pinned, 1);
But I haven't really evaluated whether or not that's racy or if I need
to take locks to do such a thing.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 5.9-rc7 null ptr deref in __i915_gem_userptr_get_pages_worker
@ 2020-09-28 10:17 ` Jason A. Donenfeld
0 siblings, 0 replies; 21+ messages in thread
From: Jason A. Donenfeld @ 2020-09-28 10:17 UTC (permalink / raw)
To: Jason Gunthorpe, Peter Xu, Linus Torvalds
Cc: intel-gfx, open list:DRM DRIVERS, open list, Chris Wilson,
Linux-MM, Andrew Morton
Alright, the failing code seems to be in mm:
if (flags & FOLL_PIN)
atomic_set(¤t->mm->has_pinned, 1);
Apparently you can't rely on current->mm being valid in this context;
it's null here, hence the +0x64 for has_pinned's offset.
This was added by 008cfe4418b3 ("mm: Introduce mm_struct.has_pinned"),
which is new for rc7 indeed.
The crash goes away when changing that to:
if ((flags & FOLL_PIN) && current->mm)
atomic_set(¤t->mm->has_pinned, 1);
But I haven't really evaluated whether or not that's racy or if I need
to take locks to do such a thing.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 5.9-rc7 null ptr deref in __i915_gem_userptr_get_pages_worker
@ 2020-09-28 10:17 ` Jason A. Donenfeld
0 siblings, 0 replies; 21+ messages in thread
From: Jason A. Donenfeld @ 2020-09-28 10:17 UTC (permalink / raw)
To: Jason Gunthorpe, Peter Xu, Linus Torvalds
Cc: intel-gfx, open list, open list:DRM DRIVERS, Chris Wilson,
Linux-MM, Andrew Morton
Alright, the failing code seems to be in mm:
if (flags & FOLL_PIN)
atomic_set(¤t->mm->has_pinned, 1);
Apparently you can't rely on current->mm being valid in this context;
it's null here, hence the +0x64 for has_pinned's offset.
This was added by 008cfe4418b3 ("mm: Introduce mm_struct.has_pinned"),
which is new for rc7 indeed.
The crash goes away when changing that to:
if ((flags & FOLL_PIN) && current->mm)
atomic_set(¤t->mm->has_pinned, 1);
But I haven't really evaluated whether or not that's racy or if I need
to take locks to do such a thing.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 5.9-rc7 null ptr deref in __i915_gem_userptr_get_pages_worker
2020-09-28 10:17 ` Jason A. Donenfeld
(?)
@ 2020-09-28 10:22 ` Jason A. Donenfeld
-1 siblings, 0 replies; 21+ messages in thread
From: Jason A. Donenfeld @ 2020-09-28 10:22 UTC (permalink / raw)
To: Jason Gunthorpe, Peter Xu, Linus Torvalds
Cc: intel-gfx, open list:DRM DRIVERS, open list, Chris Wilson,
Linux-MM, Andrew Morton
Oh, this is just a copy and paste error, when the code was originally
pasted from internal_get_user_pages_fast, which assumes a current.
I'll fix this up and send a patch shortly.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 5.9-rc7 null ptr deref in __i915_gem_userptr_get_pages_worker
@ 2020-09-28 10:22 ` Jason A. Donenfeld
0 siblings, 0 replies; 21+ messages in thread
From: Jason A. Donenfeld @ 2020-09-28 10:22 UTC (permalink / raw)
To: Jason Gunthorpe, Peter Xu, Linus Torvalds
Cc: intel-gfx, open list:DRM DRIVERS, open list, Chris Wilson,
Linux-MM, Andrew Morton
Oh, this is just a copy and paste error, when the code was originally
pasted from internal_get_user_pages_fast, which assumes a current.
I'll fix this up and send a patch shortly.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 5.9-rc7 null ptr deref in __i915_gem_userptr_get_pages_worker
@ 2020-09-28 10:22 ` Jason A. Donenfeld
0 siblings, 0 replies; 21+ messages in thread
From: Jason A. Donenfeld @ 2020-09-28 10:22 UTC (permalink / raw)
To: Jason Gunthorpe, Peter Xu, Linus Torvalds
Cc: intel-gfx, open list, open list:DRM DRIVERS, Chris Wilson,
Linux-MM, Andrew Morton
Oh, this is just a copy and paste error, when the code was originally
pasted from internal_get_user_pages_fast, which assumes a current.
I'll fix this up and send a patch shortly.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH] mm: do not rely on mm == current->mm in __get_user_pages_locked
2020-09-28 10:22 ` Jason A. Donenfeld
@ 2020-09-28 10:35 ` Jason A. Donenfeld
-1 siblings, 0 replies; 21+ messages in thread
From: Jason A. Donenfeld @ 2020-09-28 10:35 UTC (permalink / raw)
To: linux-mm, peterx, jgg
Cc: torvalds, dri-devel, intel-gfx, chris, akpm, Jason A. Donenfeld
It seems likely this block was pasted from internal_get_user_pages_fast,
which is not passed an mm struct and therefore uses current's. But
__get_user_pages_locked is passed an explicit mm, and current->mm is not
always valid. This was hit when being called from i915, which uses:
pin_user_pages_remote->
__get_user_pages_remote->
__gup_longterm_locked->
__get_user_pages_locked
Before, this would lead to an OOPS:
BUG: kernel NULL pointer dereference, address: 0000000000000064
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 0 P4D 0
Oops: 0002 [#1] SMP
CPU: 10 PID: 1431 Comm: kworker/u33:1 Tainted: P S U O 5.9.0-rc7+ #140
Hardware name: LENOVO 20QTCTO1WW/20QTCTO1WW, BIOS N2OET47W (1.34 ) 08/06/2020
Workqueue: i915-userptr-acquire __i915_gem_userptr_get_pages_worker [i915]
RIP: 0010:__get_user_pages_remote+0xd7/0x310
Code: f5 01 00 00 83 7d 00 01 0f 85 ed 01 00 00 f7 c1 00 00 04 00 0f 84 58 01 00 00 65 48 8b 04 25 00 6d 01 00 48 8b 80 40 03 00 00 <c7> 40 64 01 00 00 00 65 48 8b 04 25 00 6d 01 00 48 c7 44 24 18 00
RSP: 0018:ffff888fdfe47de0 EFLAGS: 00010206
RAX: 0000000000000000 RBX: 00007fe188531000 RCX: 0000000000040001
RDX: 0000000000000001 RSI: 00007fe188531000 RDI: ffff888ff0748f00
RBP: ffff888fdfe47e54 R08: ffff888fedc7d7c8 R09: 0000000000000000
R10: 0000000000000018 R11: fefefefefefefeff R12: ffff888ff0748f00
R13: ffff888fedc7d7c8 R14: ffff888f81fe3a40 R15: 0000000000042003
FS: 0000000000000000(0000) GS:ffff888ffc480000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000064 CR3: 0000000002009003 CR4: 00000000003706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__i915_gem_userptr_get_pages_worker+0xc8/0x260 [i915]
process_one_work+0x1ca/0x390
worker_thread+0x48/0x3c0
? rescuer_thread+0x3d0/0x3d0
kthread+0x114/0x130
? kthread_create_worker_on_cpu+0x40/0x40
ret_from_fork+0x1f/0x30
CR2: 0000000000000064
This commit fixes the problem by using the mm pointer passed to the
function rather than the bogus one in current.
Fixes: 008cfe4418b3 ("mm: Introduce mm_struct.has_pinned")
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Peter Xu <peterx@redhat.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
mm/gup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/gup.c b/mm/gup.c
index dfe781d2ad4c..e869c634cc9a 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1256,7 +1256,7 @@ static __always_inline long __get_user_pages_locked(struct mm_struct *mm,
}
if (flags & FOLL_PIN)
- atomic_set(¤t->mm->has_pinned, 1);
+ atomic_set(&mm->has_pinned, 1);
/*
* FOLL_PIN and FOLL_GET are mutually exclusive. Traditional behavior
--
2.28.0
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH] mm: do not rely on mm == current->mm in __get_user_pages_locked
@ 2020-09-28 10:35 ` Jason A. Donenfeld
0 siblings, 0 replies; 21+ messages in thread
From: Jason A. Donenfeld @ 2020-09-28 10:35 UTC (permalink / raw)
To: linux-mm, peterx, jgg
Cc: Jason A. Donenfeld, intel-gfx, dri-devel, chris, akpm, torvalds
It seems likely this block was pasted from internal_get_user_pages_fast,
which is not passed an mm struct and therefore uses current's. But
__get_user_pages_locked is passed an explicit mm, and current->mm is not
always valid. This was hit when being called from i915, which uses:
pin_user_pages_remote->
__get_user_pages_remote->
__gup_longterm_locked->
__get_user_pages_locked
Before, this would lead to an OOPS:
BUG: kernel NULL pointer dereference, address: 0000000000000064
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 0 P4D 0
Oops: 0002 [#1] SMP
CPU: 10 PID: 1431 Comm: kworker/u33:1 Tainted: P S U O 5.9.0-rc7+ #140
Hardware name: LENOVO 20QTCTO1WW/20QTCTO1WW, BIOS N2OET47W (1.34 ) 08/06/2020
Workqueue: i915-userptr-acquire __i915_gem_userptr_get_pages_worker [i915]
RIP: 0010:__get_user_pages_remote+0xd7/0x310
Code: f5 01 00 00 83 7d 00 01 0f 85 ed 01 00 00 f7 c1 00 00 04 00 0f 84 58 01 00 00 65 48 8b 04 25 00 6d 01 00 48 8b 80 40 03 00 00 <c7> 40 64 01 00 00 00 65 48 8b 04 25 00 6d 01 00 48 c7 44 24 18 00
RSP: 0018:ffff888fdfe47de0 EFLAGS: 00010206
RAX: 0000000000000000 RBX: 00007fe188531000 RCX: 0000000000040001
RDX: 0000000000000001 RSI: 00007fe188531000 RDI: ffff888ff0748f00
RBP: ffff888fdfe47e54 R08: ffff888fedc7d7c8 R09: 0000000000000000
R10: 0000000000000018 R11: fefefefefefefeff R12: ffff888ff0748f00
R13: ffff888fedc7d7c8 R14: ffff888f81fe3a40 R15: 0000000000042003
FS: 0000000000000000(0000) GS:ffff888ffc480000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000064 CR3: 0000000002009003 CR4: 00000000003706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__i915_gem_userptr_get_pages_worker+0xc8/0x260 [i915]
process_one_work+0x1ca/0x390
worker_thread+0x48/0x3c0
? rescuer_thread+0x3d0/0x3d0
kthread+0x114/0x130
? kthread_create_worker_on_cpu+0x40/0x40
ret_from_fork+0x1f/0x30
CR2: 0000000000000064
This commit fixes the problem by using the mm pointer passed to the
function rather than the bogus one in current.
Fixes: 008cfe4418b3 ("mm: Introduce mm_struct.has_pinned")
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Peter Xu <peterx@redhat.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
mm/gup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/gup.c b/mm/gup.c
index dfe781d2ad4c..e869c634cc9a 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1256,7 +1256,7 @@ static __always_inline long __get_user_pages_locked(struct mm_struct *mm,
}
if (flags & FOLL_PIN)
- atomic_set(¤t->mm->has_pinned, 1);
+ atomic_set(&mm->has_pinned, 1);
/*
* FOLL_PIN and FOLL_GET are mutually exclusive. Traditional behavior
--
2.28.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH] mm: do not rely on mm == current->mm in __get_user_pages_locked
2020-09-28 10:35 ` Jason A. Donenfeld
(?)
@ 2020-09-28 10:43 ` Chris Wilson
-1 siblings, 0 replies; 21+ messages in thread
From: Chris Wilson @ 2020-09-28 10:43 UTC (permalink / raw)
To: Jason A. Donenfeld, jgg, linux-mm, peterx
Cc: torvalds, dri-devel, intel-gfx, akpm, Jason A. Donenfeld
Quoting Jason A. Donenfeld (2020-09-28 11:35:07)
> It seems likely this block was pasted from internal_get_user_pages_fast,
> which is not passed an mm struct and therefore uses current's. But
> __get_user_pages_locked is passed an explicit mm, and current->mm is not
> always valid. This was hit when being called from i915, which uses:
>
> pin_user_pages_remote->
> __get_user_pages_remote->
> __gup_longterm_locked->
> __get_user_pages_locked
>
> Before, this would lead to an OOPS:
>
> BUG: kernel NULL pointer dereference, address: 0000000000000064
> #PF: supervisor write access in kernel mode
> #PF: error_code(0x0002) - not-present page
> PGD 0 P4D 0
> Oops: 0002 [#1] SMP
> CPU: 10 PID: 1431 Comm: kworker/u33:1 Tainted: P S U O 5.9.0-rc7+ #140
> Hardware name: LENOVO 20QTCTO1WW/20QTCTO1WW, BIOS N2OET47W (1.34 ) 08/06/2020
> Workqueue: i915-userptr-acquire __i915_gem_userptr_get_pages_worker [i915]
> RIP: 0010:__get_user_pages_remote+0xd7/0x310
> Code: f5 01 00 00 83 7d 00 01 0f 85 ed 01 00 00 f7 c1 00 00 04 00 0f 84 58 01 00 00 65 48 8b 04 25 00 6d 01 00 48 8b 80 40 03 00 00 <c7> 40 64 01 00 00 00 65 48 8b 04 25 00 6d 01 00 48 c7 44 24 18 00
> RSP: 0018:ffff888fdfe47de0 EFLAGS: 00010206
> RAX: 0000000000000000 RBX: 00007fe188531000 RCX: 0000000000040001
> RDX: 0000000000000001 RSI: 00007fe188531000 RDI: ffff888ff0748f00
> RBP: ffff888fdfe47e54 R08: ffff888fedc7d7c8 R09: 0000000000000000
> R10: 0000000000000018 R11: fefefefefefefeff R12: ffff888ff0748f00
> R13: ffff888fedc7d7c8 R14: ffff888f81fe3a40 R15: 0000000000042003
> FS: 0000000000000000(0000) GS:ffff888ffc480000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000064 CR3: 0000000002009003 CR4: 00000000003706e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> __i915_gem_userptr_get_pages_worker+0xc8/0x260 [i915]
> process_one_work+0x1ca/0x390
> worker_thread+0x48/0x3c0
> ? rescuer_thread+0x3d0/0x3d0
> kthread+0x114/0x130
> ? kthread_create_worker_on_cpu+0x40/0x40
> ret_from_fork+0x1f/0x30
> CR2: 0000000000000064
>
> This commit fixes the problem by using the mm pointer passed to the
> function rather than the bogus one in current.
>
> Fixes: 008cfe4418b3 ("mm: Introduce mm_struct.has_pinned")
> Cc: Jason Gunthorpe <jgg@ziepe.ca>
> Cc: Peter Xu <peterx@redhat.com>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> ---
> mm/gup.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/gup.c b/mm/gup.c
> index dfe781d2ad4c..e869c634cc9a 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -1256,7 +1256,7 @@ static __always_inline long __get_user_pages_locked(struct mm_struct *mm,
> }
>
> if (flags & FOLL_PIN)
> - atomic_set(¤t->mm->has_pinned, 1);
> + atomic_set(&mm->has_pinned, 1);
That's literally the same diff as I was just testing :)
I can attest that it fixes the i915 issue, but since that's also your
test case, I'm not adding much information.
-Chris
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] mm: do not rely on mm == current->mm in __get_user_pages_locked
@ 2020-09-28 10:43 ` Chris Wilson
0 siblings, 0 replies; 21+ messages in thread
From: Chris Wilson @ 2020-09-28 10:43 UTC (permalink / raw)
To: Jason A. Donenfeld, jgg, linux-mm, peterx
Cc: intel-gfx, Jason A. Donenfeld, torvalds, akpm, dri-devel
Quoting Jason A. Donenfeld (2020-09-28 11:35:07)
> It seems likely this block was pasted from internal_get_user_pages_fast,
> which is not passed an mm struct and therefore uses current's. But
> __get_user_pages_locked is passed an explicit mm, and current->mm is not
> always valid. This was hit when being called from i915, which uses:
>
> pin_user_pages_remote->
> __get_user_pages_remote->
> __gup_longterm_locked->
> __get_user_pages_locked
>
> Before, this would lead to an OOPS:
>
> BUG: kernel NULL pointer dereference, address: 0000000000000064
> #PF: supervisor write access in kernel mode
> #PF: error_code(0x0002) - not-present page
> PGD 0 P4D 0
> Oops: 0002 [#1] SMP
> CPU: 10 PID: 1431 Comm: kworker/u33:1 Tainted: P S U O 5.9.0-rc7+ #140
> Hardware name: LENOVO 20QTCTO1WW/20QTCTO1WW, BIOS N2OET47W (1.34 ) 08/06/2020
> Workqueue: i915-userptr-acquire __i915_gem_userptr_get_pages_worker [i915]
> RIP: 0010:__get_user_pages_remote+0xd7/0x310
> Code: f5 01 00 00 83 7d 00 01 0f 85 ed 01 00 00 f7 c1 00 00 04 00 0f 84 58 01 00 00 65 48 8b 04 25 00 6d 01 00 48 8b 80 40 03 00 00 <c7> 40 64 01 00 00 00 65 48 8b 04 25 00 6d 01 00 48 c7 44 24 18 00
> RSP: 0018:ffff888fdfe47de0 EFLAGS: 00010206
> RAX: 0000000000000000 RBX: 00007fe188531000 RCX: 0000000000040001
> RDX: 0000000000000001 RSI: 00007fe188531000 RDI: ffff888ff0748f00
> RBP: ffff888fdfe47e54 R08: ffff888fedc7d7c8 R09: 0000000000000000
> R10: 0000000000000018 R11: fefefefefefefeff R12: ffff888ff0748f00
> R13: ffff888fedc7d7c8 R14: ffff888f81fe3a40 R15: 0000000000042003
> FS: 0000000000000000(0000) GS:ffff888ffc480000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000064 CR3: 0000000002009003 CR4: 00000000003706e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> __i915_gem_userptr_get_pages_worker+0xc8/0x260 [i915]
> process_one_work+0x1ca/0x390
> worker_thread+0x48/0x3c0
> ? rescuer_thread+0x3d0/0x3d0
> kthread+0x114/0x130
> ? kthread_create_worker_on_cpu+0x40/0x40
> ret_from_fork+0x1f/0x30
> CR2: 0000000000000064
>
> This commit fixes the problem by using the mm pointer passed to the
> function rather than the bogus one in current.
>
> Fixes: 008cfe4418b3 ("mm: Introduce mm_struct.has_pinned")
> Cc: Jason Gunthorpe <jgg@ziepe.ca>
> Cc: Peter Xu <peterx@redhat.com>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> ---
> mm/gup.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/gup.c b/mm/gup.c
> index dfe781d2ad4c..e869c634cc9a 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -1256,7 +1256,7 @@ static __always_inline long __get_user_pages_locked(struct mm_struct *mm,
> }
>
> if (flags & FOLL_PIN)
> - atomic_set(¤t->mm->has_pinned, 1);
> + atomic_set(&mm->has_pinned, 1);
That's literally the same diff as I was just testing :)
I can attest that it fixes the i915 issue, but since that's also your
test case, I'm not adding much information.
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Intel-gfx] [PATCH] mm: do not rely on mm == current->mm in __get_user_pages_locked
@ 2020-09-28 10:43 ` Chris Wilson
0 siblings, 0 replies; 21+ messages in thread
From: Chris Wilson @ 2020-09-28 10:43 UTC (permalink / raw)
To: Jason A. Donenfeld, jgg, linux-mm, peterx
Cc: intel-gfx, Jason A. Donenfeld, torvalds, akpm, dri-devel
Quoting Jason A. Donenfeld (2020-09-28 11:35:07)
> It seems likely this block was pasted from internal_get_user_pages_fast,
> which is not passed an mm struct and therefore uses current's. But
> __get_user_pages_locked is passed an explicit mm, and current->mm is not
> always valid. This was hit when being called from i915, which uses:
>
> pin_user_pages_remote->
> __get_user_pages_remote->
> __gup_longterm_locked->
> __get_user_pages_locked
>
> Before, this would lead to an OOPS:
>
> BUG: kernel NULL pointer dereference, address: 0000000000000064
> #PF: supervisor write access in kernel mode
> #PF: error_code(0x0002) - not-present page
> PGD 0 P4D 0
> Oops: 0002 [#1] SMP
> CPU: 10 PID: 1431 Comm: kworker/u33:1 Tainted: P S U O 5.9.0-rc7+ #140
> Hardware name: LENOVO 20QTCTO1WW/20QTCTO1WW, BIOS N2OET47W (1.34 ) 08/06/2020
> Workqueue: i915-userptr-acquire __i915_gem_userptr_get_pages_worker [i915]
> RIP: 0010:__get_user_pages_remote+0xd7/0x310
> Code: f5 01 00 00 83 7d 00 01 0f 85 ed 01 00 00 f7 c1 00 00 04 00 0f 84 58 01 00 00 65 48 8b 04 25 00 6d 01 00 48 8b 80 40 03 00 00 <c7> 40 64 01 00 00 00 65 48 8b 04 25 00 6d 01 00 48 c7 44 24 18 00
> RSP: 0018:ffff888fdfe47de0 EFLAGS: 00010206
> RAX: 0000000000000000 RBX: 00007fe188531000 RCX: 0000000000040001
> RDX: 0000000000000001 RSI: 00007fe188531000 RDI: ffff888ff0748f00
> RBP: ffff888fdfe47e54 R08: ffff888fedc7d7c8 R09: 0000000000000000
> R10: 0000000000000018 R11: fefefefefefefeff R12: ffff888ff0748f00
> R13: ffff888fedc7d7c8 R14: ffff888f81fe3a40 R15: 0000000000042003
> FS: 0000000000000000(0000) GS:ffff888ffc480000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000064 CR3: 0000000002009003 CR4: 00000000003706e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> __i915_gem_userptr_get_pages_worker+0xc8/0x260 [i915]
> process_one_work+0x1ca/0x390
> worker_thread+0x48/0x3c0
> ? rescuer_thread+0x3d0/0x3d0
> kthread+0x114/0x130
> ? kthread_create_worker_on_cpu+0x40/0x40
> ret_from_fork+0x1f/0x30
> CR2: 0000000000000064
>
> This commit fixes the problem by using the mm pointer passed to the
> function rather than the bogus one in current.
>
> Fixes: 008cfe4418b3 ("mm: Introduce mm_struct.has_pinned")
> Cc: Jason Gunthorpe <jgg@ziepe.ca>
> Cc: Peter Xu <peterx@redhat.com>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> ---
> mm/gup.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/gup.c b/mm/gup.c
> index dfe781d2ad4c..e869c634cc9a 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -1256,7 +1256,7 @@ static __always_inline long __get_user_pages_locked(struct mm_struct *mm,
> }
>
> if (flags & FOLL_PIN)
> - atomic_set(¤t->mm->has_pinned, 1);
> + atomic_set(&mm->has_pinned, 1);
That's literally the same diff as I was just testing :)
I can attest that it fixes the i915 issue, but since that's also your
test case, I'm not adding much information.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] mm: do not rely on mm == current->mm in __get_user_pages_locked
2020-09-28 10:35 ` Jason A. Donenfeld
@ 2020-09-28 11:59 ` Jason Gunthorpe
-1 siblings, 0 replies; 21+ messages in thread
From: Jason Gunthorpe @ 2020-09-28 11:59 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: linux-mm, peterx, torvalds, dri-devel, intel-gfx, chris, akpm
On Mon, Sep 28, 2020 at 12:35:07PM +0200, Jason A. Donenfeld wrote:
> It seems likely this block was pasted from internal_get_user_pages_fast,
> which is not passed an mm struct and therefore uses current's. But
> __get_user_pages_locked is passed an explicit mm, and current->mm is not
> always valid. This was hit when being called from i915, which uses:
>
> pin_user_pages_remote->
> __get_user_pages_remote->
> __gup_longterm_locked->
> __get_user_pages_locked
>
> Before, this would lead to an OOPS:
>
> BUG: kernel NULL pointer dereference, address: 0000000000000064
> #PF: supervisor write access in kernel mode
> #PF: error_code(0x0002) - not-present page
> PGD 0 P4D 0
> Oops: 0002 [#1] SMP
> CPU: 10 PID: 1431 Comm: kworker/u33:1 Tainted: P S U O 5.9.0-rc7+ #140
> Hardware name: LENOVO 20QTCTO1WW/20QTCTO1WW, BIOS N2OET47W (1.34 ) 08/06/2020
> Workqueue: i915-userptr-acquire __i915_gem_userptr_get_pages_worker [i915]
> RIP: 0010:__get_user_pages_remote+0xd7/0x310
> Code: f5 01 00 00 83 7d 00 01 0f 85 ed 01 00 00 f7 c1 00 00 04 00 0f 84 58 01 00 00 65 48 8b 04 25 00 6d 01 00 48 8b 80 40 03 00 00 <c7> 40 64 01 00 00 00 65 48 8b 04 25 00 6d 01 00 48 c7 44 24 18 00
> RSP: 0018:ffff888fdfe47de0 EFLAGS: 00010206
> RAX: 0000000000000000 RBX: 00007fe188531000 RCX: 0000000000040001
> RDX: 0000000000000001 RSI: 00007fe188531000 RDI: ffff888ff0748f00
> RBP: ffff888fdfe47e54 R08: ffff888fedc7d7c8 R09: 0000000000000000
> R10: 0000000000000018 R11: fefefefefefefeff R12: ffff888ff0748f00
> R13: ffff888fedc7d7c8 R14: ffff888f81fe3a40 R15: 0000000000042003
> FS: 0000000000000000(0000) GS:ffff888ffc480000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000064 CR3: 0000000002009003 CR4: 00000000003706e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> __i915_gem_userptr_get_pages_worker+0xc8/0x260 [i915]
> process_one_work+0x1ca/0x390
> worker_thread+0x48/0x3c0
> ? rescuer_thread+0x3d0/0x3d0
> kthread+0x114/0x130
> ? kthread_create_worker_on_cpu+0x40/0x40
> ret_from_fork+0x1f/0x30
> CR2: 0000000000000064
>
> This commit fixes the problem by using the mm pointer passed to the
> function rather than the bogus one in current.
>
> Fixes: 008cfe4418b3 ("mm: Introduce mm_struct.has_pinned")
> Cc: Jason Gunthorpe <jgg@ziepe.ca>
> Cc: Peter Xu <peterx@redhat.com>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> ---
> mm/gup.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Yes this looks like the right fix
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Thanks,
Jason
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] mm: do not rely on mm == current->mm in __get_user_pages_locked
@ 2020-09-28 11:59 ` Jason Gunthorpe
0 siblings, 0 replies; 21+ messages in thread
From: Jason Gunthorpe @ 2020-09-28 11:59 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: intel-gfx, dri-devel, chris, linux-mm, peterx, akpm, torvalds
On Mon, Sep 28, 2020 at 12:35:07PM +0200, Jason A. Donenfeld wrote:
> It seems likely this block was pasted from internal_get_user_pages_fast,
> which is not passed an mm struct and therefore uses current's. But
> __get_user_pages_locked is passed an explicit mm, and current->mm is not
> always valid. This was hit when being called from i915, which uses:
>
> pin_user_pages_remote->
> __get_user_pages_remote->
> __gup_longterm_locked->
> __get_user_pages_locked
>
> Before, this would lead to an OOPS:
>
> BUG: kernel NULL pointer dereference, address: 0000000000000064
> #PF: supervisor write access in kernel mode
> #PF: error_code(0x0002) - not-present page
> PGD 0 P4D 0
> Oops: 0002 [#1] SMP
> CPU: 10 PID: 1431 Comm: kworker/u33:1 Tainted: P S U O 5.9.0-rc7+ #140
> Hardware name: LENOVO 20QTCTO1WW/20QTCTO1WW, BIOS N2OET47W (1.34 ) 08/06/2020
> Workqueue: i915-userptr-acquire __i915_gem_userptr_get_pages_worker [i915]
> RIP: 0010:__get_user_pages_remote+0xd7/0x310
> Code: f5 01 00 00 83 7d 00 01 0f 85 ed 01 00 00 f7 c1 00 00 04 00 0f 84 58 01 00 00 65 48 8b 04 25 00 6d 01 00 48 8b 80 40 03 00 00 <c7> 40 64 01 00 00 00 65 48 8b 04 25 00 6d 01 00 48 c7 44 24 18 00
> RSP: 0018:ffff888fdfe47de0 EFLAGS: 00010206
> RAX: 0000000000000000 RBX: 00007fe188531000 RCX: 0000000000040001
> RDX: 0000000000000001 RSI: 00007fe188531000 RDI: ffff888ff0748f00
> RBP: ffff888fdfe47e54 R08: ffff888fedc7d7c8 R09: 0000000000000000
> R10: 0000000000000018 R11: fefefefefefefeff R12: ffff888ff0748f00
> R13: ffff888fedc7d7c8 R14: ffff888f81fe3a40 R15: 0000000000042003
> FS: 0000000000000000(0000) GS:ffff888ffc480000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000064 CR3: 0000000002009003 CR4: 00000000003706e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> __i915_gem_userptr_get_pages_worker+0xc8/0x260 [i915]
> process_one_work+0x1ca/0x390
> worker_thread+0x48/0x3c0
> ? rescuer_thread+0x3d0/0x3d0
> kthread+0x114/0x130
> ? kthread_create_worker_on_cpu+0x40/0x40
> ret_from_fork+0x1f/0x30
> CR2: 0000000000000064
>
> This commit fixes the problem by using the mm pointer passed to the
> function rather than the bogus one in current.
>
> Fixes: 008cfe4418b3 ("mm: Introduce mm_struct.has_pinned")
> Cc: Jason Gunthorpe <jgg@ziepe.ca>
> Cc: Peter Xu <peterx@redhat.com>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> ---
> mm/gup.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Yes this looks like the right fix
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Thanks,
Jason
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] mm: do not rely on mm == current->mm in __get_user_pages_locked
2020-09-28 10:35 ` Jason A. Donenfeld
(?)
@ 2020-09-28 13:49 ` Peter Xu
-1 siblings, 0 replies; 21+ messages in thread
From: Peter Xu @ 2020-09-28 13:49 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: linux-mm, jgg, torvalds, dri-devel, intel-gfx, chris, akpm
On Mon, Sep 28, 2020 at 12:35:07PM +0200, Jason A. Donenfeld wrote:
> It seems likely this block was pasted from internal_get_user_pages_fast,
> which is not passed an mm struct and therefore uses current's. But
> __get_user_pages_locked is passed an explicit mm, and current->mm is not
> always valid. This was hit when being called from i915, which uses:
>
> pin_user_pages_remote->
> __get_user_pages_remote->
> __gup_longterm_locked->
> __get_user_pages_locked
Afaict it's not only an "current->mm can be NULL" issue - because this flag is
used to mark "whether the mm pinned any page", so for remote pinning we
definitely should mark the remote mm rather than the current mm, simply because
it's the target mm page table that we'd want to stablize rather than the
current->mm (even if current->mm always existed).
>
> Before, this would lead to an OOPS:
>
> BUG: kernel NULL pointer dereference, address: 0000000000000064
> #PF: supervisor write access in kernel mode
> #PF: error_code(0x0002) - not-present page
> PGD 0 P4D 0
> Oops: 0002 [#1] SMP
> CPU: 10 PID: 1431 Comm: kworker/u33:1 Tainted: P S U O 5.9.0-rc7+ #140
> Hardware name: LENOVO 20QTCTO1WW/20QTCTO1WW, BIOS N2OET47W (1.34 ) 08/06/2020
> Workqueue: i915-userptr-acquire __i915_gem_userptr_get_pages_worker [i915]
> RIP: 0010:__get_user_pages_remote+0xd7/0x310
> Code: f5 01 00 00 83 7d 00 01 0f 85 ed 01 00 00 f7 c1 00 00 04 00 0f 84 58 01 00 00 65 48 8b 04 25 00 6d 01 00 48 8b 80 40 03 00 00 <c7> 40 64 01 00 00 00 65 48 8b 04 25 00 6d 01 00 48 c7 44 24 18 00
> RSP: 0018:ffff888fdfe47de0 EFLAGS: 00010206
> RAX: 0000000000000000 RBX: 00007fe188531000 RCX: 0000000000040001
> RDX: 0000000000000001 RSI: 00007fe188531000 RDI: ffff888ff0748f00
> RBP: ffff888fdfe47e54 R08: ffff888fedc7d7c8 R09: 0000000000000000
> R10: 0000000000000018 R11: fefefefefefefeff R12: ffff888ff0748f00
> R13: ffff888fedc7d7c8 R14: ffff888f81fe3a40 R15: 0000000000042003
> FS: 0000000000000000(0000) GS:ffff888ffc480000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000064 CR3: 0000000002009003 CR4: 00000000003706e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> __i915_gem_userptr_get_pages_worker+0xc8/0x260 [i915]
> process_one_work+0x1ca/0x390
> worker_thread+0x48/0x3c0
> ? rescuer_thread+0x3d0/0x3d0
> kthread+0x114/0x130
> ? kthread_create_worker_on_cpu+0x40/0x40
> ret_from_fork+0x1f/0x30
> CR2: 0000000000000064
>
> This commit fixes the problem by using the mm pointer passed to the
> function rather than the bogus one in current.
>
> Fixes: 008cfe4418b3 ("mm: Introduce mm_struct.has_pinned")
> Cc: Jason Gunthorpe <jgg@ziepe.ca>
> Cc: Peter Xu <peterx@redhat.com>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> ---
> mm/gup.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/gup.c b/mm/gup.c
> index dfe781d2ad4c..e869c634cc9a 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -1256,7 +1256,7 @@ static __always_inline long __get_user_pages_locked(struct mm_struct *mm,
> }
>
> if (flags & FOLL_PIN)
> - atomic_set(¤t->mm->has_pinned, 1);
> + atomic_set(&mm->has_pinned, 1);
>
> /*
> * FOLL_PIN and FOLL_GET are mutually exclusive. Traditional behavior
> --
> 2.28.0
>
Thanks! And sorry for this silly mistake. I even didn't understand how it was
written, because the normal gup change should have come earlier, anyway...
Reviewed-by: Peter Xu <peterx@redhat.com>
--
Peter Xu
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] mm: do not rely on mm == current->mm in __get_user_pages_locked
@ 2020-09-28 13:49 ` Peter Xu
0 siblings, 0 replies; 21+ messages in thread
From: Peter Xu @ 2020-09-28 13:49 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: jgg, intel-gfx, dri-devel, chris, linux-mm, akpm, torvalds
On Mon, Sep 28, 2020 at 12:35:07PM +0200, Jason A. Donenfeld wrote:
> It seems likely this block was pasted from internal_get_user_pages_fast,
> which is not passed an mm struct and therefore uses current's. But
> __get_user_pages_locked is passed an explicit mm, and current->mm is not
> always valid. This was hit when being called from i915, which uses:
>
> pin_user_pages_remote->
> __get_user_pages_remote->
> __gup_longterm_locked->
> __get_user_pages_locked
Afaict it's not only an "current->mm can be NULL" issue - because this flag is
used to mark "whether the mm pinned any page", so for remote pinning we
definitely should mark the remote mm rather than the current mm, simply because
it's the target mm page table that we'd want to stablize rather than the
current->mm (even if current->mm always existed).
>
> Before, this would lead to an OOPS:
>
> BUG: kernel NULL pointer dereference, address: 0000000000000064
> #PF: supervisor write access in kernel mode
> #PF: error_code(0x0002) - not-present page
> PGD 0 P4D 0
> Oops: 0002 [#1] SMP
> CPU: 10 PID: 1431 Comm: kworker/u33:1 Tainted: P S U O 5.9.0-rc7+ #140
> Hardware name: LENOVO 20QTCTO1WW/20QTCTO1WW, BIOS N2OET47W (1.34 ) 08/06/2020
> Workqueue: i915-userptr-acquire __i915_gem_userptr_get_pages_worker [i915]
> RIP: 0010:__get_user_pages_remote+0xd7/0x310
> Code: f5 01 00 00 83 7d 00 01 0f 85 ed 01 00 00 f7 c1 00 00 04 00 0f 84 58 01 00 00 65 48 8b 04 25 00 6d 01 00 48 8b 80 40 03 00 00 <c7> 40 64 01 00 00 00 65 48 8b 04 25 00 6d 01 00 48 c7 44 24 18 00
> RSP: 0018:ffff888fdfe47de0 EFLAGS: 00010206
> RAX: 0000000000000000 RBX: 00007fe188531000 RCX: 0000000000040001
> RDX: 0000000000000001 RSI: 00007fe188531000 RDI: ffff888ff0748f00
> RBP: ffff888fdfe47e54 R08: ffff888fedc7d7c8 R09: 0000000000000000
> R10: 0000000000000018 R11: fefefefefefefeff R12: ffff888ff0748f00
> R13: ffff888fedc7d7c8 R14: ffff888f81fe3a40 R15: 0000000000042003
> FS: 0000000000000000(0000) GS:ffff888ffc480000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000064 CR3: 0000000002009003 CR4: 00000000003706e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> __i915_gem_userptr_get_pages_worker+0xc8/0x260 [i915]
> process_one_work+0x1ca/0x390
> worker_thread+0x48/0x3c0
> ? rescuer_thread+0x3d0/0x3d0
> kthread+0x114/0x130
> ? kthread_create_worker_on_cpu+0x40/0x40
> ret_from_fork+0x1f/0x30
> CR2: 0000000000000064
>
> This commit fixes the problem by using the mm pointer passed to the
> function rather than the bogus one in current.
>
> Fixes: 008cfe4418b3 ("mm: Introduce mm_struct.has_pinned")
> Cc: Jason Gunthorpe <jgg@ziepe.ca>
> Cc: Peter Xu <peterx@redhat.com>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> ---
> mm/gup.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/gup.c b/mm/gup.c
> index dfe781d2ad4c..e869c634cc9a 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -1256,7 +1256,7 @@ static __always_inline long __get_user_pages_locked(struct mm_struct *mm,
> }
>
> if (flags & FOLL_PIN)
> - atomic_set(¤t->mm->has_pinned, 1);
> + atomic_set(&mm->has_pinned, 1);
>
> /*
> * FOLL_PIN and FOLL_GET are mutually exclusive. Traditional behavior
> --
> 2.28.0
>
Thanks! And sorry for this silly mistake. I even didn't understand how it was
written, because the normal gup change should have come earlier, anyway...
Reviewed-by: Peter Xu <peterx@redhat.com>
--
Peter Xu
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Intel-gfx] [PATCH] mm: do not rely on mm == current->mm in __get_user_pages_locked
@ 2020-09-28 13:49 ` Peter Xu
0 siblings, 0 replies; 21+ messages in thread
From: Peter Xu @ 2020-09-28 13:49 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: jgg, intel-gfx, dri-devel, chris, linux-mm, akpm, torvalds
On Mon, Sep 28, 2020 at 12:35:07PM +0200, Jason A. Donenfeld wrote:
> It seems likely this block was pasted from internal_get_user_pages_fast,
> which is not passed an mm struct and therefore uses current's. But
> __get_user_pages_locked is passed an explicit mm, and current->mm is not
> always valid. This was hit when being called from i915, which uses:
>
> pin_user_pages_remote->
> __get_user_pages_remote->
> __gup_longterm_locked->
> __get_user_pages_locked
Afaict it's not only an "current->mm can be NULL" issue - because this flag is
used to mark "whether the mm pinned any page", so for remote pinning we
definitely should mark the remote mm rather than the current mm, simply because
it's the target mm page table that we'd want to stablize rather than the
current->mm (even if current->mm always existed).
>
> Before, this would lead to an OOPS:
>
> BUG: kernel NULL pointer dereference, address: 0000000000000064
> #PF: supervisor write access in kernel mode
> #PF: error_code(0x0002) - not-present page
> PGD 0 P4D 0
> Oops: 0002 [#1] SMP
> CPU: 10 PID: 1431 Comm: kworker/u33:1 Tainted: P S U O 5.9.0-rc7+ #140
> Hardware name: LENOVO 20QTCTO1WW/20QTCTO1WW, BIOS N2OET47W (1.34 ) 08/06/2020
> Workqueue: i915-userptr-acquire __i915_gem_userptr_get_pages_worker [i915]
> RIP: 0010:__get_user_pages_remote+0xd7/0x310
> Code: f5 01 00 00 83 7d 00 01 0f 85 ed 01 00 00 f7 c1 00 00 04 00 0f 84 58 01 00 00 65 48 8b 04 25 00 6d 01 00 48 8b 80 40 03 00 00 <c7> 40 64 01 00 00 00 65 48 8b 04 25 00 6d 01 00 48 c7 44 24 18 00
> RSP: 0018:ffff888fdfe47de0 EFLAGS: 00010206
> RAX: 0000000000000000 RBX: 00007fe188531000 RCX: 0000000000040001
> RDX: 0000000000000001 RSI: 00007fe188531000 RDI: ffff888ff0748f00
> RBP: ffff888fdfe47e54 R08: ffff888fedc7d7c8 R09: 0000000000000000
> R10: 0000000000000018 R11: fefefefefefefeff R12: ffff888ff0748f00
> R13: ffff888fedc7d7c8 R14: ffff888f81fe3a40 R15: 0000000000042003
> FS: 0000000000000000(0000) GS:ffff888ffc480000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000064 CR3: 0000000002009003 CR4: 00000000003706e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> __i915_gem_userptr_get_pages_worker+0xc8/0x260 [i915]
> process_one_work+0x1ca/0x390
> worker_thread+0x48/0x3c0
> ? rescuer_thread+0x3d0/0x3d0
> kthread+0x114/0x130
> ? kthread_create_worker_on_cpu+0x40/0x40
> ret_from_fork+0x1f/0x30
> CR2: 0000000000000064
>
> This commit fixes the problem by using the mm pointer passed to the
> function rather than the bogus one in current.
>
> Fixes: 008cfe4418b3 ("mm: Introduce mm_struct.has_pinned")
> Cc: Jason Gunthorpe <jgg@ziepe.ca>
> Cc: Peter Xu <peterx@redhat.com>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> ---
> mm/gup.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/gup.c b/mm/gup.c
> index dfe781d2ad4c..e869c634cc9a 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -1256,7 +1256,7 @@ static __always_inline long __get_user_pages_locked(struct mm_struct *mm,
> }
>
> if (flags & FOLL_PIN)
> - atomic_set(¤t->mm->has_pinned, 1);
> + atomic_set(&mm->has_pinned, 1);
>
> /*
> * FOLL_PIN and FOLL_GET are mutually exclusive. Traditional behavior
> --
> 2.28.0
>
Thanks! And sorry for this silly mistake. I even didn't understand how it was
written, because the normal gup change should have come earlier, anyway...
Reviewed-by: Peter Xu <peterx@redhat.com>
--
Peter Xu
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2020-09-29 7:14 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-28 9:39 5.9-rc7 null ptr deref in __i915_gem_userptr_get_pages_worker Jason A. Donenfeld
2020-09-28 9:39 ` Jason A. Donenfeld
2020-09-28 9:57 ` Jason A. Donenfeld
2020-09-28 9:57 ` Jason A. Donenfeld
2020-09-28 9:57 ` Jason A. Donenfeld
2020-09-28 10:17 ` Jason A. Donenfeld
2020-09-28 10:17 ` Jason A. Donenfeld
2020-09-28 10:17 ` Jason A. Donenfeld
2020-09-28 10:22 ` Jason A. Donenfeld
2020-09-28 10:22 ` Jason A. Donenfeld
2020-09-28 10:22 ` Jason A. Donenfeld
2020-09-28 10:35 ` [PATCH] mm: do not rely on mm == current->mm in __get_user_pages_locked Jason A. Donenfeld
2020-09-28 10:35 ` Jason A. Donenfeld
2020-09-28 10:43 ` Chris Wilson
2020-09-28 10:43 ` [Intel-gfx] " Chris Wilson
2020-09-28 10:43 ` Chris Wilson
2020-09-28 11:59 ` Jason Gunthorpe
2020-09-28 11:59 ` Jason Gunthorpe
2020-09-28 13:49 ` Peter Xu
2020-09-28 13:49 ` [Intel-gfx] " Peter Xu
2020-09-28 13:49 ` Peter Xu
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.