Commit-ID: d38bc89c72e7235ac889ae64fe7828e2e61a18af
Gitweb: https://git.kernel.org/tip/d38bc89c72e7235ac889ae64fe7828e2e61a18af
Author: Andy Lutomirski
AuthorDate: Wed, 21 Nov 2018 15:11:24 -0800
Committer: Ingo Molnar
CommitDate: Thu, 22 Nov 2018 09:23:01 +0100
x86/oops: Show
Commit-ID: d38bc89c72e7235ac889ae64fe7828e2e61a18af
Gitweb: https://git.kernel.org/tip/d38bc89c72e7235ac889ae64fe7828e2e61a18af
Author: Andy Lutomirski
AuthorDate: Wed, 21 Nov 2018 15:11:24 -0800
Committer: Ingo Molnar
CommitDate: Thu, 22 Nov 2018 09:23:01 +0100
x86/oops: Show
* Andy Lutomirski wrote:
> One of Linus' favorite hobbies seems to be looking at OOPSes and
> decoding the error code in his head. This is not one of my favorite
> hobbies :)
>
> Teach the page fault OOPS hander to decode the error code. If it's
> a !USER fault fro
* Andy Lutomirski wrote:
> One of Linus' favorite hobbies seems to be looking at OOPSes and
> decoding the error code in his head. This is not one of my favorite
> hobbies :)
>
> Teach the page fault OOPS hander to decode the error code. If it's
> a !USER fault fro
show_regs() shows the CS in the CPU register instead of the value in
regs. This means that we'll probably print "CS: 0010" almost all
the time regardless of what was actually in CS when the kernel
malfunctioned. This gives a particularly confusing result if we
OOPSed due to an implicit
show_regs() shows the CS in the CPU register instead of the value in
regs. This means that we'll probably print "CS: 0010" almost all
the time regardless of what was actually in CS when the kernel
malfunctioned. This gives a particularly confusing result if we
OOPSed due to an implicit
ri, Nov 09, 2018 at 02:37:51PM +, Jan Glauber wrote:
> > > > > I'm seeing the following oops reproducible with upstream kernel on
> > > > > arm64
> > > > > (ThunderX2):
> > > >
> > > > [...]
> > > >
> >
ri, Nov 09, 2018 at 02:37:51PM +, Jan Glauber wrote:
> > > > > I'm seeing the following oops reproducible with upstream kernel on
> > > > > arm64
> > > > > (ThunderX2):
> > > >
> > > > [...]
> > > >
> >
On Tue, Nov 20, 2018 at 06:28:54PM +, Will Deacon wrote:
> On Sat, Nov 10, 2018 at 11:17:03AM +, Jan Glauber wrote:
> > On Fri, Nov 09, 2018 at 03:58:56PM +, Will Deacon wrote:
> > > On Fri, Nov 09, 2018 at 02:37:51PM +, Jan Glauber wrote:
> > > >
On Tue, Nov 20, 2018 at 06:28:54PM +, Will Deacon wrote:
> On Sat, Nov 10, 2018 at 11:17:03AM +, Jan Glauber wrote:
> > On Fri, Nov 09, 2018 at 03:58:56PM +, Will Deacon wrote:
> > > On Fri, Nov 09, 2018 at 02:37:51PM +, Jan Glauber wrote:
> > > >
On Sat, Nov 10, 2018 at 11:17:03AM +, Jan Glauber wrote:
> On Fri, Nov 09, 2018 at 03:58:56PM +, Will Deacon wrote:
> > On Fri, Nov 09, 2018 at 02:37:51PM +, Jan Glauber wrote:
> > > I'm seeing the following oops reproducible with upstream kernel on arm6
On Sat, Nov 10, 2018 at 11:17:03AM +, Jan Glauber wrote:
> On Fri, Nov 09, 2018 at 03:58:56PM +, Will Deacon wrote:
> > On Fri, Nov 09, 2018 at 02:37:51PM +, Jan Glauber wrote:
> > > I'm seeing the following oops reproducible with upstream kernel on arm6
show_regs() shows the CS in the CPU register instead of the value in
regs. This means that we'll probably print "CS: 0010" almost all
the time regardless of what was actually in CS when the kernel
malfunctioned. This gives a particularly confusing result if we
OOPSed due to an implicit
show_regs() shows the CS in the CPU register instead of the value in
regs. This means that we'll probably print "CS: 0010" almost all
the time regardless of what was actually in CS when the kernel
malfunctioned. This gives a particularly confusing result if we
OOPSed due to an implicit
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Trond Myklebust
commit bb6ad5572c0022e17e846b382d7413cdcf8055be upstream.
In call_xpt_users(), we delete the entry from the list, but we
do not reinitialise it. This triggers the list
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Trond Myklebust
commit bb6ad5572c0022e17e846b382d7413cdcf8055be upstream.
In call_xpt_users(), we delete the entry from the list, but we
do not reinitialise it. This triggers the list
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Trond Myklebust
commit bb6ad5572c0022e17e846b382d7413cdcf8055be upstream.
In call_xpt_users(), we delete the entry from the list, but we
do not reinitialise it. This triggers the list
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Trond Myklebust
commit bb6ad5572c0022e17e846b382d7413cdcf8055be upstream.
In call_xpt_users(), we delete the entry from the list, but we
do not reinitialise it. This triggers the list
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Ming Lei
commit 11d9ea6f2ca69237d35d6c55755beba3e006b106 upstream.
When nvmet_req_init() fails, __nvmet_req_complete() is called
to handle the target request via .queue_response(), so
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Ming Lei
commit 11d9ea6f2ca69237d35d6c55755beba3e006b106 upstream.
When nvmet_req_init() fails, __nvmet_req_complete() is called
to handle the target request via .queue_response(), so
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Ville Syrjälä
commit 6a8915d0f8cf323e1beb792a33095cf652db4056 upstream.
We deinit the lpe audio device before we call
drm_atomic_helper_shutdown(), which means the platform device
may already
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Ville Syrjälä
commit 6a8915d0f8cf323e1beb792a33095cf652db4056 upstream.
We deinit the lpe audio device before we call
drm_atomic_helper_shutdown(), which means the platform device
may already
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Ville Syrjälä
commit 6a8915d0f8cf323e1beb792a33095cf652db4056 upstream.
We deinit the lpe audio device before we call
drm_atomic_helper_shutdown(), which means the platform device
may already
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Ville Syrjälä
commit 6a8915d0f8cf323e1beb792a33095cf652db4056 upstream.
We deinit the lpe audio device before we call
drm_atomic_helper_shutdown(), which means the platform device
may already
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Ville Syrjälä
commit 6a8915d0f8cf323e1beb792a33095cf652db4056 upstream.
We deinit the lpe audio device before we call
drm_atomic_helper_shutdown(), which means the platform device
may already
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Ville Syrjälä
commit 6a8915d0f8cf323e1beb792a33095cf652db4056 upstream.
We deinit the lpe audio device before we call
drm_atomic_helper_shutdown(), which means the platform device
may already
On Thu, Nov 15, 2018 at 8:29 PM Kyle Sanderson wrote:
>
> 2008(!) dual-core Atom box.
> [1027541.963573] BUG: unable to handle kernel paging request at
> b0428a44
> [1027541.963647] IP: format_decode+0x20/0x3d0
The code decodes to:
0: 55push %rbp
1: 48 8d 2e
On Thu, Nov 15, 2018 at 8:29 PM Kyle Sanderson wrote:
>
> 2008(!) dual-core Atom box.
> [1027541.963573] BUG: unable to handle kernel paging request at
> b0428a44
> [1027541.963647] IP: format_decode+0x20/0x3d0
The code decodes to:
0: 55push %rbp
1: 48 8d 2e
wering kernel.perf_event_max_sample_rate to 12000
[1027541.963573] BUG: unable to handle kernel paging request at b0428a44
[1027541.963647] IP: format_decode+0x20/0x3d0
[1027541.963676] PGD 2100c067 P4D 2100c067 PUD 2100d063 PMD 800020e001e1
[1027541.963723] Oops: 0003 [#1] PREEMPT SMP NOPTI
[1027541.963752] M
wering kernel.perf_event_max_sample_rate to 12000
[1027541.963573] BUG: unable to handle kernel paging request at b0428a44
[1027541.963647] IP: format_decode+0x20/0x3d0
[1027541.963676] PGD 2100c067 P4D 2100c067 PUD 2100d063 PMD 800020e001e1
[1027541.963723] Oops: 0003 [#1] PREEMPT SMP NOPTI
[1027541.963752] M
On 11/15, Ravi Bangoria wrote:
>
> There could be a race between task exit and probe unregister:
>
> exit_mm()
> mmput()
> __mmput() uprobe_unregister()
> uprobe_clear_state() put_uprobe()
> delayed_uprobe_remove() delayed_uprobe_remove()
>
>
On 11/15, Ravi Bangoria wrote:
>
> There could be a race between task exit and probe unregister:
>
> exit_mm()
> mmput()
> __mmput() uprobe_unregister()
> uprobe_clear_state() put_uprobe()
> delayed_uprobe_remove() delayed_uprobe_remove()
>
>
Hi Oleg,
On 11/14/18 9:36 PM, Oleg Nesterov wrote:
> On 11/14, Ravi Bangoria wrote:
>>
>> syzbot reported a kernel crash with delayed_uprobe_remove():
>> https://lkml.org/lkml/2018/11/1/1244
>>
>> Backtrace mentioned in the link points to a race between process
>> exit and uprobe_unregister().
Hi Oleg,
On 11/14/18 9:36 PM, Oleg Nesterov wrote:
> On 11/14, Ravi Bangoria wrote:
>>
>> syzbot reported a kernel crash with delayed_uprobe_remove():
>> https://lkml.org/lkml/2018/11/1/1244
>>
>> Backtrace mentioned in the link points to a race between process
>> exit and uprobe_unregister().
From: Florian Westphal
[ Upstream commit 61792b677415b77c8db04991c22966bb8de7603e ]
Unlike ipv4 and normal ipv6 defrag, netfilter ipv6 defragmentation did
not save/restore skb->dst.
This causes oops when handling locally generated ipv6 fragments, as
output path needs a valid dst.
Repor
From: Florian Westphal
[ Upstream commit 61792b677415b77c8db04991c22966bb8de7603e ]
Unlike ipv4 and normal ipv6 defrag, netfilter ipv6 defragmentation did
not save/restore skb->dst.
This causes oops when handling locally generated ipv6 fragments, as
output path needs a valid dst.
Repor
On 11/14, Ravi Bangoria wrote:
>
> syzbot reported a kernel crash with delayed_uprobe_remove():
> https://lkml.org/lkml/2018/11/1/1244
>
> Backtrace mentioned in the link points to a race between process
> exit and uprobe_unregister(). Fix it by locking delayed_uprobe_lock
> before calling
On 11/14, Ravi Bangoria wrote:
>
> syzbot reported a kernel crash with delayed_uprobe_remove():
> https://lkml.org/lkml/2018/11/1/1244
>
> Backtrace mentioned in the link points to a race between process
> exit and uprobe_unregister(). Fix it by locking delayed_uprobe_lock
> before calling
syzbot reported a kernel crash with delayed_uprobe_remove():
https://lkml.org/lkml/2018/11/1/1244
Backtrace mentioned in the link points to a race between process
exit and uprobe_unregister(). Fix it by locking delayed_uprobe_lock
before calling delayed_uprobe_remove() from put_uprobe().
syzbot reported a kernel crash with delayed_uprobe_remove():
https://lkml.org/lkml/2018/11/1/1244
Backtrace mentioned in the link points to a race between process
exit and uprobe_unregister(). Fix it by locking delayed_uprobe_lock
before calling delayed_uprobe_remove() from put_uprobe().
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Trond Myklebust
commit bb6ad5572c0022e17e846b382d7413cdcf8055be upstream.
In call_xpt_users(), we delete the entry from the list, but we
do not reinitialise it. This triggers the list
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Trond Myklebust
commit bb6ad5572c0022e17e846b382d7413cdcf8055be upstream.
In call_xpt_users(), we delete the entry from the list, but we
do not reinitialise it. This triggers the list
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Hans Verkuil
commit 250854eed5d45a73d81e4137dfd85180af6f2ec3 upstream.
When the OSD is on (i.e. vivid displays text on top of the test pattern), and
you enable hflip, then the driver crashes.
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Hans Verkuil
commit 250854eed5d45a73d81e4137dfd85180af6f2ec3 upstream.
When the OSD is on (i.e. vivid displays text on top of the test pattern), and
you enable hflip, then the driver crashes.
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Trond Myklebust
commit bb6ad5572c0022e17e846b382d7413cdcf8055be upstream.
In call_xpt_users(), we delete the entry from the list, but we
do not reinitialise it. This triggers the list
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Trond Myklebust
commit bb6ad5572c0022e17e846b382d7413cdcf8055be upstream.
In call_xpt_users(), we delete the entry from the list, but we
do not reinitialise it. This triggers the list
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Hans Verkuil
commit 250854eed5d45a73d81e4137dfd85180af6f2ec3 upstream.
When the OSD is on (i.e. vivid displays text on top of the test pattern), and
you enable hflip, then the driver crashes.
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Hans Verkuil
commit 250854eed5d45a73d81e4137dfd85180af6f2ec3 upstream.
When the OSD is on (i.e. vivid displays text on top of the test pattern), and
you enable hflip, then the driver crashes.
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Trond Myklebust
commit bb6ad5572c0022e17e846b382d7413cdcf8055be upstream.
In call_xpt_users(), we delete the entry from the list, but we
do not reinitialise it. This triggers the list
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Trond Myklebust
commit bb6ad5572c0022e17e846b382d7413cdcf8055be upstream.
In call_xpt_users(), we delete the entry from the list, but we
do not reinitialise it. This triggers the list
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Hans Verkuil
commit 250854eed5d45a73d81e4137dfd85180af6f2ec3 upstream.
When the OSD is on (i.e. vivid displays text on top of the test pattern), and
you enable hflip, then the driver crashes.
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Hans Verkuil
commit 250854eed5d45a73d81e4137dfd85180af6f2ec3 upstream.
When the OSD is on (i.e. vivid displays text on top of the test pattern), and
you enable hflip, then the driver crashes.
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Hans Verkuil
commit 250854eed5d45a73d81e4137dfd85180af6f2ec3 upstream.
When the OSD is on (i.e. vivid displays text on top of the test pattern), and
you enable hflip, then the driver crashes.
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Hans Verkuil
commit 250854eed5d45a73d81e4137dfd85180af6f2ec3 upstream.
When the OSD is on (i.e. vivid displays text on top of the test pattern), and
you enable hflip, then the driver crashes.
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Trond Myklebust
commit bb6ad5572c0022e17e846b382d7413cdcf8055be upstream.
In call_xpt_users(), we delete the entry from the list, but we
do not reinitialise it. This triggers the list
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Trond Myklebust
commit bb6ad5572c0022e17e846b382d7413cdcf8055be upstream.
In call_xpt_users(), we delete the entry from the list, but we
do not reinitialise it. This triggers the list
On Fri, Nov 09, 2018 at 03:58:56PM +, Will Deacon wrote:
> On Fri, Nov 09, 2018 at 02:37:51PM +, Jan Glauber wrote:
> > I'm seeing the following oops reproducible with upstream kernel on arm64
> > (ThunderX2):
>
> [...]
>
> > It happens after 1-3 hours o
On Fri, Nov 09, 2018 at 03:58:56PM +, Will Deacon wrote:
> On Fri, Nov 09, 2018 at 02:37:51PM +, Jan Glauber wrote:
> > I'm seeing the following oops reproducible with upstream kernel on arm64
> > (ThunderX2):
>
> [...]
>
> > It happens after 1-3 hours o
On Fri, Nov 09, 2018 at 02:37:51PM +, Jan Glauber wrote:
> I'm seeing the following oops reproducible with upstream kernel on arm64
> (ThunderX2):
[...]
> It happens after 1-3 hours of running 'stress-ng --dev 128'. This testcase
> does a scandir of /dev and then calls rando
On Fri, Nov 09, 2018 at 02:37:51PM +, Jan Glauber wrote:
> I'm seeing the following oops reproducible with upstream kernel on arm64
> (ThunderX2):
[...]
> It happens after 1-3 hours of running 'stress-ng --dev 128'. This testcase
> does a scandir of /dev and then calls rando
Hi Al,
I'm seeing the following oops reproducible with upstream kernel on arm64
(ThunderX2):
[ 5428.795719] Unable to handle kernel NULL pointer dereference at virtual
address 0040
[ 5428.813838] Mem abort info:
[ 5428.820721] ESR = 0x9606
[ 5428.828476] Exception class
Hi Al,
I'm seeing the following oops reproducible with upstream kernel on arm64
(ThunderX2):
[ 5428.795719] Unable to handle kernel NULL pointer dereference at virtual
address 0040
[ 5428.813838] Mem abort info:
[ 5428.820721] ESR = 0x9606
[ 5428.828476] Exception class
ccurrences of helper.fbdev
in the source.
I see oops in nouveau_fbcon_accel_save_disable() called from
nouveau_fbcon_set_suspend_work() on Linux 3.13 when
CONFIG_DRM_FBDEV_EMULATION option is disabled.
Signed-off-by: Pavel Roskin
Reviewed-by: Daniel Vetter
Signed-off-by: Ben Skeggs
Signed-off-by: S
ccurrences of helper.fbdev
in the source.
I see oops in nouveau_fbcon_accel_save_disable() called from
nouveau_fbcon_set_suspend_work() on Linux 3.13 when
CONFIG_DRM_FBDEV_EMULATION option is disabled.
Signed-off-by: Pavel Roskin
Reviewed-by: Daniel Vetter
Signed-off-by: Ben Skeggs
Signed-off-by: S
3.18-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 42d6cfa0caec4b68a7f17147fbf13a36e94a8bf2 ]
We try to free an ERR_PTR on this error path.
Fixes: b44be2462dbe ('usb: gadget: gadgetfs: Free memory allocated by
memdup_user()')
3.18-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 42d6cfa0caec4b68a7f17147fbf13a36e94a8bf2 ]
We try to free an ERR_PTR on this error path.
Fixes: b44be2462dbe ('usb: gadget: gadgetfs: Free memory allocated by
memdup_user()')
This broke rendering on V3D, where we almost always have a 0
in-syncobj.
Signed-off-by: Eric Anholt
Fixes: 48197bc564c7 ("drm: add syncobj timeline support v9")
Cc: Chunming Zhou
Cc: Christian König
---
drivers/gpu/drm/drm_syncobj.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
This broke rendering on V3D, where we almost always have a 0
in-syncobj.
Signed-off-by: Eric Anholt
Fixes: 48197bc564c7 ("drm: add syncobj timeline support v9")
Cc: Chunming Zhou
Cc: Christian König
---
drivers/gpu/drm/drm_syncobj.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
On Mon, 2018-10-29 at 21:49 +, Roman Gushchin wrote:
> On Mon, Oct 29, 2018 at 09:46:54PM +0100, Mike Galbraith wrote:
>
> > Ah, I have cgroup_disable=memory on the command line, which turns out
> > to be why your box doesn't explode, while mine does.
>
> Yeah, here it is. I'll send the fix
On Mon, 2018-10-29 at 21:49 +, Roman Gushchin wrote:
> On Mon, Oct 29, 2018 at 09:46:54PM +0100, Mike Galbraith wrote:
>
> > Ah, I have cgroup_disable=memory on the command line, which turns out
> > to be why your box doesn't explode, while mine does.
>
> Yeah, here it is. I'll send the fix
On Mon, Oct 29, 2018 at 09:46:54PM +0100, Mike Galbraith wrote:
> On Mon, 2018-10-29 at 18:54 +, Roman Gushchin wrote:
> >
> > Hi Mike!
> >
> > Thank you for the report!
> >
> > Do you see it reliable every time you boot up the machine?
>
> Yeah.
>
> > How do you run kvm?
>
> My VMs are
On Mon, Oct 29, 2018 at 09:46:54PM +0100, Mike Galbraith wrote:
> On Mon, 2018-10-29 at 18:54 +, Roman Gushchin wrote:
> >
> > Hi Mike!
> >
> > Thank you for the report!
> >
> > Do you see it reliable every time you boot up the machine?
>
> Yeah.
>
> > How do you run kvm?
>
> My VMs are
On Mon, Oct 29, 2018 at 09:26:34PM +0100, Michal Hocko wrote:
> On Mon 29-10-18 18:54:19, Roman Gushchin wrote:
> > On Mon, Oct 29, 2018 at 05:35:38PM +0100, Mike Galbraith wrote:
> > > On Mon, 2018-10-29 at 14:20 +0100, Michal Hocko wrote:
> > > >
> > > > > [4.420976] Code: f3 c3 0f 1f 00 0f
On Mon, Oct 29, 2018 at 09:26:34PM +0100, Michal Hocko wrote:
> On Mon 29-10-18 18:54:19, Roman Gushchin wrote:
> > On Mon, Oct 29, 2018 at 05:35:38PM +0100, Mike Galbraith wrote:
> > > On Mon, 2018-10-29 at 14:20 +0100, Michal Hocko wrote:
> > > >
> > > > > [4.420976] Code: f3 c3 0f 1f 00 0f
On Mon, 2018-10-29 at 18:54 +, Roman Gushchin wrote:
>
> Hi Mike!
>
> Thank you for the report!
>
> Do you see it reliable every time you boot up the machine?
Yeah.
> How do you run kvm?
My VMs are full SW/data clones of my i7-4790/openSUSE box.
> Is there something special about your
On Mon, 2018-10-29 at 18:54 +, Roman Gushchin wrote:
>
> Hi Mike!
>
> Thank you for the report!
>
> Do you see it reliable every time you boot up the machine?
Yeah.
> How do you run kvm?
My VMs are full SW/data clones of my i7-4790/openSUSE box.
> Is there something special about your
On Mon 29-10-18 18:54:19, Roman Gushchin wrote:
> On Mon, Oct 29, 2018 at 05:35:38PM +0100, Mike Galbraith wrote:
> > On Mon, 2018-10-29 at 14:20 +0100, Michal Hocko wrote:
> > >
> > > > [4.420976] Code: f3 c3 0f 1f 00 0f 1f 44 00 00 48 85 ff 0f 84 a8 00
> > > > 00 00 41 56 48 89 f8 41 55 49
On Mon 29-10-18 18:54:19, Roman Gushchin wrote:
> On Mon, Oct 29, 2018 at 05:35:38PM +0100, Mike Galbraith wrote:
> > On Mon, 2018-10-29 at 14:20 +0100, Michal Hocko wrote:
> > >
> > > > [4.420976] Code: f3 c3 0f 1f 00 0f 1f 44 00 00 48 85 ff 0f 84 a8 00
> > > > 00 00 41 56 48 89 f8 41 55 49
On Mon, Oct 29, 2018 at 05:35:38PM +0100, Mike Galbraith wrote:
> On Mon, 2018-10-29 at 14:20 +0100, Michal Hocko wrote:
> >
> > > [4.420976] Code: f3 c3 0f 1f 00 0f 1f 44 00 00 48 85 ff 0f 84 a8 00
> > > 00 00 41 56 48 89 f8 41 55 49 89 fe 41 54 49 89 d5 55 49 89 f4 53 48 89
> > > f3 48
On Mon, Oct 29, 2018 at 05:35:38PM +0100, Mike Galbraith wrote:
> On Mon, 2018-10-29 at 14:20 +0100, Michal Hocko wrote:
> >
> > > [4.420976] Code: f3 c3 0f 1f 00 0f 1f 44 00 00 48 85 ff 0f 84 a8 00
> > > 00 00 41 56 48 89 f8 41 55 49 89 fe 41 54 49 89 d5 55 49 89 f4 53 48 89
> > > f3 48
On Mon, 2018-10-29 at 14:20 +0100, Michal Hocko wrote:
>
> > [4.420976] Code: f3 c3 0f 1f 00 0f 1f 44 00 00 48 85 ff 0f 84 a8 00 00
> > 00 41 56 48 89 f8 41 55 49 89 fe 41 54 49 89 d5 55 49 89 f4 53 48 89 f3
> > 48 0f c1 1f 48 01 f3 48 39 5f 18 48 89 fd 73 17 eb 41 48 89 e8
> > [
On Mon, 2018-10-29 at 14:20 +0100, Michal Hocko wrote:
>
> > [4.420976] Code: f3 c3 0f 1f 00 0f 1f 44 00 00 48 85 ff 0f 84 a8 00 00
> > 00 41 56 48 89 f8 41 55 49 89 fe 41 54 49 89 d5 55 49 89 f4 53 48 89 f3
> > 48 0f c1 1f 48 01 f3 48 39 5f 18 48 89 fd 73 17 eb 41 48 89 e8
> > [
irgin source with
> config based on the enterprise-ish RT config.
>
> [4.412732] BUG: unable to handle kernel NULL pointer dereference at
> 00f8
> [4.414047] PGD 0 P4D 0
> [4.414769] Oops: 0002 [#1] PREEMPT SMP PTI
> [4.415651] CPU: 7 PID: 1 Co
irgin source with
> config based on the enterprise-ish RT config.
>
> [4.412732] BUG: unable to handle kernel NULL pointer dereference at
> 00f8
> [4.414047] PGD 0 P4D 0
> [4.414769] Oops: 0002 [#1] PREEMPT SMP PTI
> [4.415651] CPU: 7 PID: 1 Co
;
> >9ee3e06610fd ("HID: i2c-hid: override HID descriptors for certain
> > devices")
> >
> > but that's simply because it's the only thing that seems to touch this
> > particular area in this merge window.
> >
> > The oops looks like this:
>
;
> >9ee3e06610fd ("HID: i2c-hid: override HID descriptors for certain
> > devices")
> >
> > but that's simply because it's the only thing that seems to touch this
> > particular area in this merge window.
> >
> > The oops looks like this:
>
s the only thing that seems to touch this
particular area in this merge window.
The oops looks like this:
BUG: unable to handle kernel paging request at 7a25d598
PGD 0 P4D 0
Oops: [#1] SMP PTI
CPU: 1 PID: 888 Comm: systemd-udevd Not tainted 4.19.0-07715-g345671ea0f92 #4
s the only thing that seems to touch this
particular area in this merge window.
The oops looks like this:
BUG: unable to handle kernel paging request at 7a25d598
PGD 0 P4D 0
Oops: [#1] SMP PTI
CPU: 1 PID: 888 Comm: systemd-udevd Not tainted 4.19.0-07715-g345671ea0f92 #4
On Sat, Oct 27, 2018 at 9:08 AM Linus Torvalds
wrote:
>
> I *think* the problem is that the i2c_hid_dmi_desc_override_table[]
> isn't terminated by a NULL entry, and I will test that next.
Confirmed. That makes my laptop boot cleanly.
See commit b59dfdaef173 ("i2c-hid: properly terminate
On Sat, Oct 27, 2018 at 9:08 AM Linus Torvalds
wrote:
>
> I *think* the problem is that the i2c_hid_dmi_desc_override_table[]
> isn't terminated by a NULL entry, and I will test that next.
Confirmed. That makes my laptop boot cleanly.
See commit b59dfdaef173 ("i2c-hid: properly terminate
On Sat, 27 Oct 2018, Linus Torvalds wrote:
> I *think* the problem is that the i2c_hid_dmi_desc_override_table[]
> isn't terminated by a NULL entry, and I will test that next.
Hm, that almost certainly is indeed the issue, thanks a lot for reporting
it.
> What makes me *very* unhappy about
On Sat, 27 Oct 2018, Linus Torvalds wrote:
> I *think* the problem is that the i2c_hid_dmi_desc_override_table[]
> isn't terminated by a NULL entry, and I will test that next.
Hm, that almost certainly is indeed the issue, thanks a lot for reporting
it.
> What makes me *very* unhappy about
cular area in this merge window.
The oops looks like this:
BUG: unable to handle kernel paging request at 7a25d598
PGD 0 P4D 0
Oops: [#1] SMP PTI
CPU: 1 PID: 888 Comm: systemd-udevd Not tainted 4.19.0-07715-g345671ea0f92 #4
Hardware name: Dell Inc. XPS 13 9350/09JHRY, BIOS 1.7.0
cular area in this merge window.
The oops looks like this:
BUG: unable to handle kernel paging request at 7a25d598
PGD 0 P4D 0
Oops: [#1] SMP PTI
CPU: 1 PID: 888 Comm: systemd-udevd Not tainted 4.19.0-07715-g345671ea0f92 #4
Hardware name: Dell Inc. XPS 13 9350/09JHRY, BIOS 1.7.0
] uio: Fix an Oops on load
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.
I was trying to solve a double free but I introduced a more serious NULL
dereference bug. The problem
] uio: Fix an Oops on load
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.
I was trying to solve a double free but I introduced a more serious NULL
dereference bug. The problem
ust
sets info->uio_dev to NULL on the error path so it should solve both
the Oops and the double free.
Fixes: f019f07ecf6a ("uio: potential double frees if __uio_register_device()
fails")
Reported-by: Mathias Thore
Signed-off-by: Dan Carpenter
---
drivers/uio/uio.c | 7 +--
1 file c
ust
sets info->uio_dev to NULL on the error path so it should solve both
the Oops and the double free.
Fixes: f019f07ecf6a ("uio: potential double frees if __uio_register_device()
fails")
Reported-by: Mathias Thore
Signed-off-by: Dan Carpenter
---
drivers/uio/uio.c | 7 +--
1 file c
Hi,
* John Stultz [181025 17:15]:
> On Thu, Oct 25, 2018 at 10:04 AM, John Stultz wrote:
> > Should we check wakeirq before we set the second elements of res[]?
>
> Here's my first swing at doing the above. It seems to work ok. Let me
> know if it looks reasonable and I'll submit it as a
Hi,
* John Stultz [181025 17:15]:
> On Thu, Oct 25, 2018 at 10:04 AM, John Stultz wrote:
> > Should we check wakeirq before we set the second elements of res[]?
>
> Here's my first swing at doing the above. It seems to work ok. Let me
> know if it looks reasonable and I'll submit it as a
901 - 1000 of 16129 matches
Mail list logo
