Dear Maintainers,
It seems we found a race condition in the aoe driver that leads to a
kernel crash. It is triggered when an aoe device is unavailable and
therefore produces an I/O error in the code that tries to remove the
device. (drivers/block/aoe/aoedev.c: aoedev_downdev)
I reproduced this
, then
cfg80211_get_drvinfo will be called by below call stack, but the
wiphy->dev.parent is NULL, so kernel crash.
Call stack to cfg80211_get_drvinfo:
NetworkManager 826 [001] 6696.731371:probe:cfg80211_get_drvinfo:
(c107d8f0)
c107d8f1 cfg80211_get_drvinfo+0x1
(/lib/modules/5
, then
cfg80211_get_drvinfo will be called by below call stack, but the
wiphy->dev.parent is NULL, so kernel crash.
Call stack to cfg80211_get_drvinfo:
NetworkManager 826 [001] 6696.731371:probe:cfg80211_get_drvinfo:
(c107d8f0)
c107d8f1 cfg80211_get_drvinfo+0x1
(/lib/modules/5
Hi folks,
while playing around with overlays, I've encountered a funny crash,
that even seems to affect the filesystem. No idea what really happens,
as oftree code detected the broken phandle.
What I did:
* i've written a driver that loads a builtin oftree overlay and tries
to apply it.
* as
From: Lorenzo Bianconi
commit 0acb20a5438c36e0cf2b8bf255f314b59fcca6ef upstream.
The following crash log can occur unplugging the usb dongle since,
after the urb poison in mt7601u_free_tx_queue(), usb_submit_urb() will
always fail resulting in a skb kfree while the skb has been already
queued.
From: Lorenzo Bianconi
commit 0acb20a5438c36e0cf2b8bf255f314b59fcca6ef upstream.
The following crash log can occur unplugging the usb dongle since,
after the urb poison in mt7601u_free_tx_queue(), usb_submit_urb() will
always fail resulting in a skb kfree while the skb has been already
queued.
From: Lorenzo Bianconi
commit 0acb20a5438c36e0cf2b8bf255f314b59fcca6ef upstream.
The following crash log can occur unplugging the usb dongle since,
after the urb poison in mt7601u_free_tx_queue(), usb_submit_urb() will
always fail resulting in a skb kfree while the skb has been already
queued.
From: Lorenzo Bianconi
commit 0acb20a5438c36e0cf2b8bf255f314b59fcca6ef upstream.
The following crash log can occur unplugging the usb dongle since,
after the urb poison in mt7601u_free_tx_queue(), usb_submit_urb() will
always fail resulting in a skb kfree while the skb has been already
queued.
From: Lorenzo Bianconi
commit 0acb20a5438c36e0cf2b8bf255f314b59fcca6ef upstream.
The following crash log can occur unplugging the usb dongle since,
after the urb poison in mt7601u_free_tx_queue(), usb_submit_urb() will
always fail resulting in a skb kfree while the skb has been already
queued.
From: Lorenzo Bianconi
commit 0acb20a5438c36e0cf2b8bf255f314b59fcca6ef upstream.
The following crash log can occur unplugging the usb dongle since,
after the urb poison in mt7601u_free_tx_queue(), usb_submit_urb() will
always fail resulting in a skb kfree while the skb has been already
queued.
Thanks,
applied.
if dma_map_single() fails, kernel will give the below oops since
task_struct has been destroyed and we are running into the memory
corruption due to use-after-free in kthread_stop():
[ 48.095310] Unable to handle kernel paging request at virtual address
00c473548040
[ 48.095736] Mem abort
On Wed, 13 Jan 2021 at 17:57, Greg Kroah-Hartman
wrote:
>
> And, if you look close at the above links, you will see where the error
> is, and what the out-of-tree code needs to to do be fixed up properly.
> An exercise for that is left for the vendor :)
Seems like I have fixed the issue myself.
On Wed, Jan 13, 2021 at 01:26:11PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Jan 13, 2021 at 05:35:18PM +0530, Pintu Agarwal wrote:
> > On Tue, 12 Jan 2021 at 17:39, Greg Kroah-Hartman
> > wrote:
> > >
> > > On Tue, Jan 12, 2021 at 05:31:54PM +0530, Pintu Agarwal wrote:
> > > > Hi,
> > > >
> > >
On Wed, Jan 13, 2021 at 05:35:18PM +0530, Pintu Agarwal wrote:
> On Tue, 12 Jan 2021 at 17:39, Greg Kroah-Hartman
> wrote:
> >
> > On Tue, Jan 12, 2021 at 05:31:54PM +0530, Pintu Agarwal wrote:
> > > Hi,
> > >
> > > I am using Kernel: 4.9.217 for one of the ARM32 boards for Qualcomm SOC.
> > > htt
On Tue, 12 Jan 2021 at 17:39, Greg Kroah-Hartman
wrote:
>
> On Tue, Jan 12, 2021 at 05:31:54PM +0530, Pintu Agarwal wrote:
> > Hi,
> >
> > I am using Kernel: 4.9.217 for one of the ARM32 boards for Qualcomm SOC.
> > https://github.com/android-linux-stable/msm-4.9
> >
> > But I think this is a gene
On Tue, Jan 12, 2021 at 05:31:54PM +0530, Pintu Agarwal wrote:
> Hi,
>
> I am using Kernel: 4.9.217 for one of the ARM32 boards for Qualcomm SOC.
> https://github.com/android-linux-stable/msm-4.9
>
> But I think this is a general bug applicable to :Kernel 4.9 under
> fs/sysfs/file.c
> So, I wante
On Tue, Jan 12, 2021 at 05:31:54PM +0530, Pintu Agarwal wrote:
> Hi,
>
> I am using Kernel: 4.9.217 for one of the ARM32 boards for Qualcomm SOC.
> https://github.com/android-linux-stable/msm-4.9
>
> But I think this is a general bug applicable to :Kernel 4.9 under
> fs/sysfs/file.c
> So, I wante
Hi,
I am using Kernel: 4.9.217 for one of the ARM32 boards for Qualcomm SOC.
https://github.com/android-linux-stable/msm-4.9
But I think this is a general bug applicable to :Kernel 4.9 under
fs/sysfs/file.c
So, I wanted to quickly check here if others are familiar with this
issue and if it is fix
if dma_map_single() fails, kernel will give the below oops since
task_struct has been destroyed and we are running into the memory
corruption due to use-after-free in kthread_stop():
[ 48.095310] Unable to handle kernel paging request at virtual address
00c473548040
[ 48.095736] Mem abort
Hi Parth,
On 06-12-20, 15:51, Parth Y Shah wrote:
> While performing suspend/resume, we were getting below kernel crash.
>
> [ 54.541672] [FTS][Info]gesture suspend...
> [ 54.605256] [FTS][Error][GESTURE]Enter into gesture(suspend) failed!
> [ 54.605256]
> [ 58.34
While performing suspend/resume, we were getting below kernel crash.
[ 54.541672] [FTS][Info]gesture suspend...
[ 54.605256] [FTS][Error][GESTURE]Enter into gesture(suspend) failed!
[ 54.605256]
[ 58.345850] irq event 10: bogus return value fff3
..
[ 58.345966] [] el1_irq+0xb0
From: James Smart
[ Upstream commit 6c1e803eac846f886cd35131e6516fc51a8414b9 ]
When reading sysfs nvme_info file while a remote port leaves and comes
back, a NULL pointer is encountered. The issue is due to ndlp list
corruption as the the nvme_info_show does not use the same lock as the rest
of
From: James Smart
[ Upstream commit 6c1e803eac846f886cd35131e6516fc51a8414b9 ]
When reading sysfs nvme_info file while a remote port leaves and comes
back, a NULL pointer is encountered. The issue is due to ndlp list
corruption as the the nvme_info_show does not use the same lock as the rest
of
From: James Smart
[ Upstream commit 6c1e803eac846f886cd35131e6516fc51a8414b9 ]
When reading sysfs nvme_info file while a remote port leaves and comes
back, a NULL pointer is encountered. The issue is due to ndlp list
corruption as the the nvme_info_show does not use the same lock as the rest
of
From: James Smart
[ Upstream commit 6c1e803eac846f886cd35131e6516fc51a8414b9 ]
When reading sysfs nvme_info file while a remote port leaves and comes
back, a NULL pointer is encountered. The issue is due to ndlp list
corruption as the the nvme_info_show does not use the same lock as the rest
of
On 2020-08-12 14:45:22 [+0200], Thomas Graziadei wrote:
> Hi Sebastian,
Hi Thomas,
> any progress on your side?
>
> Do you think the patch could be applied for the next versions?
Yes. The ->active_mm change needs to be protected against scheduling
regardless of the arch/mmu. Otherwise the mm wi
On 2020-08-12 14:45:22 [+0200], Thomas Graziadei wrote:
> Hi Sebastian,
Hi Thomas,
> any progress on your side?
due to lack of time none. But I am on it…
> Do you think the patch could be applied for the next versions?
So I had a theory why it happens but then you said no so now I need
to figur
om>; Thomas Graziadei <
> thomas.grazia...@omicronenergy.com>; Thomas Gleixner <
> t...@linutronix.de>; linux-kernel@vger.kernel.org;
> rost...@goodmis.org
> Subject: Re: Kernel crash due to memory corruption with v5.4.26-rt17
> and PowerPC e500
>
> On 2020-05-29 18:3
From: Alaa Hleihel
[ Upstream commit 350a63249d270b1f5bd05c7e2a24cd8de0f9db20 ]
After the cited commit, function 'mlx5_eswitch_set_vport_vlan' started
to acquire esw->state_lock.
However, esw is not defined for VF devices, hence attempting to set vf
VLANID on a VF dev will cause a kernel panic.
From: Alaa Hleihel
[ Upstream commit 350a63249d270b1f5bd05c7e2a24cd8de0f9db20 ]
After the cited commit, function 'mlx5_eswitch_set_vport_vlan' started
to acquire esw->state_lock.
However, esw is not defined for VF devices, hence attempting to set vf
VLANID on a VF dev will cause a kernel panic.
From: Aneesh Kumar K.V
[ Upstream commit c1ed1754f271f6b7acb1bfdc8cfb62220fbed423 ]
With CONFIG_DEBUG_VIRTUAL=y, __pa() checks for addr value and if it's
less than PAGE_OFFSET it leads to a BUG().
#define __pa(x)
({
VIRTUAL_BUG_ON((unsigned long)(x) < PAGE_OFFSET);
(unsigned
From: Aneesh Kumar K.V
[ Upstream commit c1ed1754f271f6b7acb1bfdc8cfb62220fbed423 ]
With CONFIG_DEBUG_VIRTUAL=y, __pa() checks for addr value and if it's
less than PAGE_OFFSET it leads to a BUG().
#define __pa(x)
({
VIRTUAL_BUG_ON((unsigned long)(x) < PAGE_OFFSET);
(unsigned
goodmis.org
Subject: Re: Kernel crash due to memory corruption with v5.4.26-rt17 and
PowerPC e500
On 2020-05-29 18:37:22 [+0200], To Mark Marshall wrote:
> On 2020-05-29 18:15:18 [+0200], To Mark Marshall wrote:
> > In order to get it back into the RT queue I need to understand why
>
On 2020-05-29 18:37:22 [+0200], To Mark Marshall wrote:
> On 2020-05-29 18:15:18 [+0200], To Mark Marshall wrote:
> > In order to get it back into the RT queue I need to understand why it is
> > required. What exactly is it fixing. Let me stare at for a little…
>
> it used to be local_irq_disable(
From: "Aneesh Kumar K.V"
[ Upstream commit c1ed1754f271f6b7acb1bfdc8cfb62220fbed423 ]
With CONFIG_DEBUG_VIRTUAL=y, __pa() checks for addr value and if it's
less than PAGE_OFFSET it leads to a BUG().
#define __pa(x)
({
VIRTUAL_BUG_ON((unsigned long)(x) < PAGE_OFFSET);
(unsign
From: "Aneesh Kumar K.V"
[ Upstream commit c1ed1754f271f6b7acb1bfdc8cfb62220fbed423 ]
With CONFIG_DEBUG_VIRTUAL=y, __pa() checks for addr value and if it's
less than PAGE_OFFSET it leads to a BUG().
#define __pa(x)
({
VIRTUAL_BUG_ON((unsigned long)(x) < PAGE_OFFSET);
(unsign
On Fri, Jun 26, 2020 at 08:45:23PM +0800, Luo Xiaogang wrote:
> At 2020-06-24 09:29:01, "J. Bruce Fields" wrote:
> >On Mon, Jun 15, 2020 at 03:12:11PM +0800, Luo Xiaogang wrote:
> >> We load nfsd module in the docker container, kernel crash as following.
> >>
At 2020-06-24 09:29:01, "J. Bruce Fields" wrote:
>On Mon, Jun 15, 2020 at 03:12:11PM +0800, Luo Xiaogang wrote:
>> We load nfsd module in the docker container, kernel crash as following.
>>
>> The 'current->nsproxy->net_ns->gen->ptr[nfsd_net_id]
Thanks for reply. Very well, the two patches you provided solved this problem.
On Mon, Jun 15, 2020 at 03:12:11PM +0800, Luo Xiaogang wrote:
> We load nfsd module in the docker container, kernel crash as following.
>
> The 'current->nsproxy->net_ns->gen->ptr[nfsd_net_id]' is overflow in the
> nfsd_init_net.
>
> We should u
From: Aneesh Kumar K.V
[ Upstream commit a6e2c226c3d51fd93636320e47cabc8a8f0824c5 ]
With CONFIG_DEBUG_VIRTUAL=y, we can hit a BUG() if we take a hard
lockup watchdog interrupt when in OPAL mode.
This happens in show_instructions() if the kernel takes the watchdog
NMI IPI, or any other interrupt
From: Aneesh Kumar K.V
[ Upstream commit a6e2c226c3d51fd93636320e47cabc8a8f0824c5 ]
With CONFIG_DEBUG_VIRTUAL=y, we can hit a BUG() if we take a hard
lockup watchdog interrupt when in OPAL mode.
This happens in show_instructions() if the kernel takes the watchdog
NMI IPI, or any other interrupt
We load nfsd module in the docker container, kernel crash as following.
The 'current->nsproxy->net_ns->gen->ptr[nfsd_net_id]' is overflow in the
nfsd_init_net.
We should use the net_ns which is being init in the nfsd_init_net,
not the 'current->nsproxy->net_ns&#
My config is attached. This is the greatly reduced config that I used
when trying to narrow down the problem. We normally have much more
enabled, but that had no effect on the bug in my testing. We do,
unfortunately, have quite a few out-of-tree patches, but they are all
in USB or Networking, wh
On 2020-05-29 18:15:18 [+0200], To Mark Marshall wrote:
> In order to get it back into the RT queue I need to understand why it is
> required. What exactly is it fixing. Let me stare at for a little…
it used to be local_irq_disable() which then became preempt_disable()
local_irq_disable() due to A
On 2020-05-29 17:38:39 [+0200], Mark Marshall wrote:
> Hi Sebastian & list,
Hi,
> I had assumed that my e-mail had got lost or overlooked, I was meaning to
> post a follow up message this week...
>
> All I could find from the debugging and tracing that we added was that
> something was going wron
Hi Sebastian & list,
I had assumed that my e-mail had got lost or overlooked, I was meaning to
post a follow up message this week...
All I could find from the debugging and tracing that we added was that
something was going wrong with the mm data structures somewhere in the
exec code. In the end
On 2020-05-04 11:40:08 [+0200], Mark Marshall wrote:
> The easiest way we have found to reproduce the crash is to repeatedly
> insert and then remove a module. The crash then appears to be related
> to either paging in the module or in exiting the mdev process. (The
> crash does also happen at ot
On 5/11/20 9:23 AM, Mian Yousaf Kaukab wrote:
> On Mon, May 11, 2020 at 12:25:00PM +0100, Robin Murphy wrote:
>> On 2020-05-08 9:40 am, Mian Yousaf Kaukab wrote:
>>> I am seeing following kernel crash on Jetson TX2. Board is flashed with
>>> firmware bits from L4T R
On Mon, May 11, 2020 at 12:25:00PM +0100, Robin Murphy wrote:
> On 2020-05-08 9:40 am, Mian Yousaf Kaukab wrote:
> > I am seeing following kernel crash on Jetson TX2. Board is flashed with
> > firmware bits from L4T R32.4.2 with upstream u-boot. Crash always
> > happens while
On 2020-05-08 9:40 am, Mian Yousaf Kaukab wrote:
I am seeing following kernel crash on Jetson TX2. Board is flashed with
firmware bits from L4T R32.4.2 with upstream u-boot. Crash always
happens while decompressing initrd. Initrd is approximately 80 MiB in
size and compressed with xz (xz --check
I am seeing following kernel crash on Jetson TX2. Board is flashed with
firmware bits from L4T R32.4.2 with upstream u-boot. Crash always
happens while decompressing initrd. Initrd is approximately 80 MiB in
size and compressed with xz (xz --check=crc32 --lzma2=dict=32MiB).
Crash is not observed
Hi RT experts,
We are using the RT kernel with the PowerPC e500. Until recently we
were on the 4.19 kernel series, and are in the process of upgrading.
When we switched to the v5.4 version, we get a reproducible kernel
crash. The crashes all contain the "BUG: Bad rss-counter state"
he ioremap() function. Without ioremap() many drivers will
not work, one example is the tulip driver which then simply crashes the
kernel if it tries to access the ports on the HP HSC card.
This patch disables the HP HSC card if it finds one, and as such
fixes the kernel crash on a HP D350/2 machin
he ioremap() function. Without ioremap() many drivers will
not work, one example is the tulip driver which then simply crashes the
kernel if it tries to access the ports on the HP HSC card.
This patch disables the HP HSC card if it finds one, and as such
fixes the kernel crash on a HP D350/2 machin
he ioremap() function. Without ioremap() many drivers will
not work, one example is the tulip driver which then simply crashes the
kernel if it tries to access the ports on the HP HSC card.
This patch disables the HP HSC card if it finds one, and as such
fixes the kernel crash on a HP D350/2 machin
he ioremap() function. Without ioremap() many drivers will
not work, one example is the tulip driver which then simply crashes the
kernel if it tries to access the ports on the HP HSC card.
This patch disables the HP HSC card if it finds one, and as such
fixes the kernel crash on a HP D350/2 machin
he ioremap() function. Without ioremap() many drivers will
not work, one example is the tulip driver which then simply crashes the
kernel if it tries to access the ports on the HP HSC card.
This patch disables the HP HSC card if it finds one, and as such
fixes the kernel crash on a HP D350/2 machin
he ioremap() function. Without ioremap() many drivers will
not work, one example is the tulip driver which then simply crashes the
kernel if it tries to access the ports on the HP HSC card.
This patch disables the HP HSC card if it finds one, and as such
fixes the kernel crash on a HP D350/2 machin
[ Upstream commit 430380b4637aec646996b4aef67ad417593923b2 ]
Since commit 3582dd291788 ("aoe: convert aoeblk to blk-mq"), aoedev_downdev
has had the possibility of sleeping and causing the following crash.
BUG: scheduling while atomic: rmmod/2242/0x0003
Modules linked in: aoe
Preemption disab
On Tue, Aug 06, 2019 at 05:41:04PM +0800, zhe...@windriver.com wrote:
> From: He Zhe
>
> reply_cache_stats uses wrong parameter as seq file private structure and
> thus causes the following kernel crash when users read
> /proc/fs/nfsd/reply_cache_stats
Thanks, applying for 5.3.
From: He Zhe
[ Upstream commit 430380b4637aec646996b4aef67ad417593923b2 ]
Since commit 3582dd291788 ("aoe: convert aoeblk to blk-mq"), aoedev_downdev
has had the possibility of sleeping and causing the following crash.
BUG: scheduling while atomic: rmmod/2242/0x0003
Modules linked in: aoe
P
Please ignore this one. Resent.
Thanks,
Zhe
On 8/6/19 5:38 PM, zhe...@windriver.com wrote:
> From: He Zhe
>
> reply_cache_stats uses wrong parameter as seq file private structure and
> thus causes the following kernel crash when users read
> /proc/fs/nfsd/reply_ca
From: He Zhe
reply_cache_stats uses wrong parameter as seq file private structure and
thus causes the following kernel crash when users read
/proc/fs/nfsd/reply_cache_stats
BUG: kernel NULL pointer dereference, address: 01f9
PGD 0 P4D 0
Oops: [#3] SMP PTI
CPU: 6 PID: 1502 Comm
From: He Zhe
reply_cache_stats uses wrong parameter as seq file private structure and
thus causes the following kernel crash when users read
/proc/fs/nfsd/reply_cache_stats
m=a2ec03f7 v=f5777155
BUG: kernel NULL pointer dereference, address: 01f9
PGD 0 P4D 0
Oops
The Linux kernel for powerpc since v3.9 has a bug in the TM handling where any
unprivileged local user may crash the operating system.
This bug affects machines using 64-bit CPUs where Transactional Memory (TM) is
not present or has been disabled (see below for more details on affected CPUs).
To
From: Kloetzke Jan
[ Upstream commit ad70411a978d1e6e97b1e341a7bde9a79af0c93d ]
When disconnecting cdc_ncm the kernel sporadically crashes shortly
after the disconnect:
[ 57.868812] Unable to handle kernel NULL pointer dereference at virtual
address
...
[ 58.006653] PC is at
From: Kloetzke Jan
[ Upstream commit ad70411a978d1e6e97b1e341a7bde9a79af0c93d ]
When disconnecting cdc_ncm the kernel sporadically crashes shortly
after the disconnect:
[ 57.868812] Unable to handle kernel NULL pointer dereference at virtual
address
...
[ 58.006653] PC is at
From: Kees Cook
commit 8880fa32c557600f5f624084152668ed3c2ea51e upstream.
The ram pstore backend has always had the crash dumper frontend enabled
unconditionally. However, it was possible to effectively disable it
by setting a record_size=0. All the machinery would run (storing dumps
to the temp
From: Kees Cook
commit 8880fa32c557600f5f624084152668ed3c2ea51e upstream.
The ram pstore backend has always had the crash dumper frontend enabled
unconditionally. However, it was possible to effectively disable it
by setting a record_size=0. All the machinery would run (storing dumps
to the temp
From: Kees Cook
commit 8880fa32c557600f5f624084152668ed3c2ea51e upstream.
The ram pstore backend has always had the crash dumper frontend enabled
unconditionally. However, it was possible to effectively disable it
by setting a record_size=0. All the machinery would run (storing dumps
to the temp
From: Kloetzke Jan
[ Upstream commit ad70411a978d1e6e97b1e341a7bde9a79af0c93d ]
When disconnecting cdc_ncm the kernel sporadically crashes shortly
after the disconnect:
[ 57.868812] Unable to handle kernel NULL pointer dereference at virtual
address
...
[ 58.006653] PC is at
From: Kloetzke Jan
[ Upstream commit ad70411a978d1e6e97b1e341a7bde9a79af0c93d ]
When disconnecting cdc_ncm the kernel sporadically crashes shortly
after the disconnect:
[ 57.868812] Unable to handle kernel NULL pointer dereference at virtual
address
...
[ 58.006653] PC is at
From: Kloetzke Jan
[ Upstream commit ad70411a978d1e6e97b1e341a7bde9a79af0c93d ]
When disconnecting cdc_ncm the kernel sporadically crashes shortly
after the disconnect:
[ 57.868812] Unable to handle kernel NULL pointer dereference at virtual
address
...
[ 58.006653] PC is at
From: Kloetzke Jan
[ Upstream commit ad70411a978d1e6e97b1e341a7bde9a79af0c93d ]
When disconnecting cdc_ncm the kernel sporadically crashes shortly
after the disconnect:
[ 57.868812] Unable to handle kernel NULL pointer dereference at virtual
address
...
[ 58.006653] PC is at
On 04/06/2019 11:17, Peter Ujfalusi wrote:
> irq_create_fwspec_mapping() can fail, returning 0 as parent_virq. In this
> case vint_desc is going to be NULL in ti_sci_inta_alloc_irq() which will
> cause NULL pointer dereference.
>
> Also note that irq_create_fwspec_mapping() returns 'unsigned int'
irq_create_fwspec_mapping() can fail, returning 0 as parent_virq. In this
case vint_desc is going to be NULL in ti_sci_inta_alloc_irq() which will
cause NULL pointer dereference.
Also note that irq_create_fwspec_mapping() returns 'unsigned int' so the
check '<=' was wrong.
Use -EINVAL if irq_crea
From: Kloetzke Jan
[ Upstream commit ad70411a978d1e6e97b1e341a7bde9a79af0c93d ]
When disconnecting cdc_ncm the kernel sporadically crashes shortly
after the disconnect:
[ 57.868812] Unable to handle kernel NULL pointer dereference at virtual
address
...
[ 58.006653] PC is at
From: Kloetzke Jan
[ Upstream commit ad70411a978d1e6e97b1e341a7bde9a79af0c93d ]
When disconnecting cdc_ncm the kernel sporadically crashes shortly
after the disconnect:
[ 57.868812] Unable to handle kernel NULL pointer dereference at virtual
address
...
[ 58.006653] PC is at
From: Kloetzke Jan
[ Upstream commit ad70411a978d1e6e97b1e341a7bde9a79af0c93d ]
When disconnecting cdc_ncm the kernel sporadically crashes shortly
after the disconnect:
[ 57.868812] Unable to handle kernel NULL pointer dereference at virtual
address
...
[ 58.006653] PC is at
[ Upstream commit a4b7013db23e93824ac53083eeb3e4efdef4b5b0 ]
BUG: KASAN: slab-out-of-bounds in rxe_mem_init_user+0x6c1/0x740 [rdma_rxe]
Read of size 8 at addr 88805c01a608 by task ib_send_bw/573
CPU: 24 PID: 573 Comm: ib_send_bw Not tainted 5.0.0-rc5+ #189
Hardware name: QEMU Standard PC (Q35
Matthias, ping? Any suggestions?
Thanks,
Pingfan
On Thu, May 2, 2019 at 2:22 PM Pingfan Liu wrote:
>
> On Thu, Apr 25, 2019 at 4:20 PM Pingfan Liu wrote:
> >
> > On Wed, Apr 24, 2019 at 4:31 PM Matthias Brugger wrote:
> > >
> > >
> > [...]
> > > > @@ -139,6 +141,8 @@ static int __init parse_c
On Wed, Apr 24, 2019 at 4:31 PM Matthias Brugger wrote:
>
>
[...]
> > @@ -139,6 +141,8 @@ static int __init parse_crashkernel_simple(char
> > *cmdline,
> > pr_warn("crashkernel: unrecognized char: %c\n", *cur);
> > return -EINVAL;
> > }
> > + if (*crash_size
On 24/04/2019 08:33, Pingfan Liu wrote:
> At present, both return and crash_size should be checked to guarantee the
> success of parse_crashkernel().
>
> Take a close look at the cases, which causes crash_size=0. Beside syntax
> error, three cases cause parsing to get crash_size=0.
> -1st. in p
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Archer Yan
commit 47c25036b60f27b86ab44b66a8861bcf81cde39b upstream.
Insert Branch instruction instead of NOP to make sure assembler don't
patch code in forbidden slot. In jump label function,
5.0-stable review patch. If anyone has any objections, please let me know.
--
From: Archer Yan
commit 47c25036b60f27b86ab44b66a8861bcf81cde39b upstream.
Insert Branch instruction instead of NOP to make sure assembler don't
patch code in forbidden slot. In jump label function,
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Archer Yan
commit 47c25036b60f27b86ab44b66a8861bcf81cde39b upstream.
Insert Branch instruction instead of NOP to make sure assembler don't
patch code in forbidden slot. In jump label function,
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Archer Yan
commit 47c25036b60f27b86ab44b66a8861bcf81cde39b upstream.
Insert Branch instruction instead of NOP to make sure assembler don't
patch code in forbidden slot. In jump label function,
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Archer Yan
commit 47c25036b60f27b86ab44b66a8861bcf81cde39b upstream.
Insert Branch instruction instead of NOP to make sure assembler don't
patch code in forbidden slot. In jump label function,
On Mon, Mar 04, 2019 at 08:59:52PM +0100, Laurent Vivier wrote:
> This happens because initially powerpc code computes
> sched_domains_numa_masks of offline nodes as if they were merged with
> node 0 (because firmware doesn't provide the distance information for
> memoryless/cpuless nodes):
>
>
When we hotplug a CPU in a memoryless/cpuless node,
the kernel crashes when it rebuilds the sched_domains data.
I reproduce this problem on POWER and with a pseries VM, with the following
QEMU parameters:
-machine pseries -enable-kvm -m 8192 \
-smp 2,maxcpus=8,sockets=4,cores=2,threads=1 \
On 20/02/2019 18:08, Peter Zijlstra wrote:
> On Wed, Feb 20, 2019 at 05:55:20PM +0100, Laurent Vivier wrote:
>> index 3f35ba1d8fde..372278605f0d 100644
>> --- a/kernel/sched/topology.c
>> +++ b/kernel/sched/topology.c
>> @@ -1651,6 +1651,7 @@ void sched_init_numa(void)
>> */
>> tl[i++] =
On Wed, Feb 20, 2019 at 05:55:20PM +0100, Laurent Vivier wrote:
> index 3f35ba1d8fde..372278605f0d 100644
> --- a/kernel/sched/topology.c
> +++ b/kernel/sched/topology.c
> @@ -1651,6 +1651,7 @@ void sched_init_numa(void)
>*/
> tl[i++] = (struct sched_domain_topology_level){
>
_overlap_sched_groups()).
As I don't see any reason (and it is not documented in the involved commit)
to remove this flag, this patch re-introduces the SDTL_OVERLAP flag for the
first level. This fixes the problem described above and a CPU can be hotplugged
again without kernel crash.
Fixes:
uild_overlap_sched_groups()).
As I don't see any reason (and it is not documented in the involved commit)
to remove this flag, this patch re-introduces the SDTL_OVERLAP flag for the
first level. This fixes the problem described above and a CPU can be hotplugged
again without kernel crash.
Fixes:
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Aneesh Kumar K.V
commit 579b9239c1f38665b21e8d0e6ee83ecc96dbd6bb upstream.
With support for split pmd lock, we use pmd page pmd_huge_pte pointer
to store the deposited page table. In those con
4.20-stable review patch. If anyone has any objections, please let me know.
--
From: Aneesh Kumar K.V
commit 579b9239c1f38665b21e8d0e6ee83ecc96dbd6bb upstream.
With support for split pmd lock, we use pmd page pmd_huge_pte pointer
to store the deposited page table. In those con
On 10/27/2018 06:07 AM, Stephen Smith wrote:
> On Wednesday, October 24, 2018 10:20:05 PM MST Stephen Smith wrote:
>>
>> Whenever I run "shutdown -h now" or "reboot" I receive an immediate kernel
>> crash with a dump that has:
>>
>> "
On Wednesday, October 24, 2018 10:20:05 PM MST Stephen Smith wrote:
>
> Whenever I run "shutdown -h now" or "reboot" I receive an immediate kernel
> crash with a dump that has:
>
> "Code: Bad RIP value"
I Canonical response noted the following from
1 - 100 of 644 matches
Mail list logo
