Update README #650
Closed
Update README #650
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
diaevd
pushed a commit
to diaevd/zen-kernel
that referenced
this pull request
Mar 17, 2019
[ Upstream commit 2d097c5 ] We can't just use scsi_cd() to get the scsi_cd structure, we have to grab a live reference to the device. For both callbacks, we're not inside an open where we already hold a reference to the device. This fixes device removal/addition under concurrent device access, which otherwise could result in the below oops. NULL pointer dereference at 0000000000000010 PGD 0 P4D 0 Oops: 0000 [zen-kernel#1] PREEMPT SMP Modules linked in: sr 12:0:0:0: [sr2] scsi-1 drive scsi_debug crc_t10dif crct10dif_generic crct10dif_common nvme nvme_core sb_edac xl sr 12:0:0:0: Attached scsi CD-ROM sr2 sr_mod cdrom btrfs xor zstd_decompress zstd_compress xxhash lzo_compress zlib_defc sr 12:0:0:0: Attached scsi generic sg7 type 5 igb ahci libahci i2c_algo_bit libata dca [last unloaded: crc_t10dif] CPU: 43 PID: 4629 Comm: systemd-udevd Not tainted 4.16.0+ torvalds#650 Hardware name: Dell Inc. PowerEdge T630/0NT78X, BIOS 2.3.4 11/09/2016 RIP: 0010:sr_block_revalidate_disk+0x23/0x190 [sr_mod] RSP: 0018:ffff883ff357bb58 EFLAGS: 00010292 RAX: ffffffffa00b07d0 RBX: ffff883ff3058000 RCX: ffff883ff357bb66 RDX: 0000000000000003 RSI: 0000000000007530 RDI: ffff881fea631000 RBP: 0000000000000000 R08: ffff881fe4d38400 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000000001b6 R12: 000000000800005d R13: 000000000800005d R14: ffff883ffd9b3790 R15: 0000000000000000 FS: 00007f7dc8e6d8c0(0000) GS:ffff883fff340000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 0000003ffda98005 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __invalidate_device+0x48/0x60 check_disk_change+0x4c/0x60 sr_block_open+0x16/0xd0 [sr_mod] __blkdev_get+0xb9/0x450 ? iget5_locked+0x1c0/0x1e0 blkdev_get+0x11e/0x320 ? bdget+0x11d/0x150 ? _raw_spin_unlock+0xa/0x20 ? bd_acquire+0xc0/0xc0 do_dentry_open+0x1b0/0x320 ? inode_permission+0x24/0xc0 path_openat+0x4e6/0x1420 ? cpumask_any_but+0x1f/0x40 ? flush_tlb_mm_range+0xa0/0x120 do_filp_open+0x8c/0xf0 ? __seccomp_filter+0x28/0x230 ? _raw_spin_unlock+0xa/0x20 ? __handle_mm_fault+0x7d6/0x9b0 ? list_lru_add+0xa8/0xc0 ? _raw_spin_unlock+0xa/0x20 ? __alloc_fd+0xaf/0x160 ? do_sys_open+0x1a6/0x230 do_sys_open+0x1a6/0x230 do_syscall_64+0x5a/0x100 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Reviewed-by: Lee Duncan <[email protected]> Reviewed-by: Jan Kara <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
JeremyGrosser
pushed a commit
to JeremyGrosser/linux
that referenced
this pull request
Jul 2, 2019
[ Upstream commit 2d097c5 ] We can't just use scsi_cd() to get the scsi_cd structure, we have to grab a live reference to the device. For both callbacks, we're not inside an open where we already hold a reference to the device. This fixes device removal/addition under concurrent device access, which otherwise could result in the below oops. NULL pointer dereference at 0000000000000010 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: sr 12:0:0:0: [sr2] scsi-1 drive scsi_debug crc_t10dif crct10dif_generic crct10dif_common nvme nvme_core sb_edac xl sr 12:0:0:0: Attached scsi CD-ROM sr2 sr_mod cdrom btrfs xor zstd_decompress zstd_compress xxhash lzo_compress zlib_defc sr 12:0:0:0: Attached scsi generic sg7 type 5 igb ahci libahci i2c_algo_bit libata dca [last unloaded: crc_t10dif] CPU: 43 PID: 4629 Comm: systemd-udevd Not tainted 4.16.0+ torvalds#650 Hardware name: Dell Inc. PowerEdge T630/0NT78X, BIOS 2.3.4 11/09/2016 RIP: 0010:sr_block_revalidate_disk+0x23/0x190 [sr_mod] RSP: 0018:ffff883ff357bb58 EFLAGS: 00010292 RAX: ffffffffa00b07d0 RBX: ffff883ff3058000 RCX: ffff883ff357bb66 RDX: 0000000000000003 RSI: 0000000000007530 RDI: ffff881fea631000 RBP: 0000000000000000 R08: ffff881fe4d38400 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000000001b6 R12: 000000000800005d R13: 000000000800005d R14: ffff883ffd9b3790 R15: 0000000000000000 FS: 00007f7dc8e6d8c0(0000) GS:ffff883fff340000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 0000003ffda98005 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __invalidate_device+0x48/0x60 check_disk_change+0x4c/0x60 sr_block_open+0x16/0xd0 [sr_mod] __blkdev_get+0xb9/0x450 ? iget5_locked+0x1c0/0x1e0 blkdev_get+0x11e/0x320 ? bdget+0x11d/0x150 ? _raw_spin_unlock+0xa/0x20 ? bd_acquire+0xc0/0xc0 do_dentry_open+0x1b0/0x320 ? inode_permission+0x24/0xc0 path_openat+0x4e6/0x1420 ? cpumask_any_but+0x1f/0x40 ? flush_tlb_mm_range+0xa0/0x120 do_filp_open+0x8c/0xf0 ? __seccomp_filter+0x28/0x230 ? _raw_spin_unlock+0xa/0x20 ? __handle_mm_fault+0x7d6/0x9b0 ? list_lru_add+0xa8/0xc0 ? _raw_spin_unlock+0xa/0x20 ? __alloc_fd+0xaf/0x160 ? do_sys_open+0x1a6/0x230 do_sys_open+0x1a6/0x230 do_syscall_64+0x5a/0x100 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Reviewed-by: Lee Duncan <[email protected]> Reviewed-by: Jan Kara <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Nov 23, 2019
…tal arm64 allmodconfig boot) Hi John, thanks for testing and reporting this. See inline. On 21.11.19 12:34:22, John Garry wrote: > On 14/10/2019 16:18, John Garry wrote: > JFYI, I see an issue on linuxnext-2019119, as follows: > > 21.645388] io scheduler kyber registered > [ 21.734011] input: Power Button as > /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0 > [ 21.743295] ACPI: Power Button [PWRB] > [ 21.809644] [Firmware Bug]: APEI: Invalid bit width + offset in GAR > [0x94110034/64/0/3/0] > [ 21.821974] EDAC MC0: Giving out device to module ghes_edac.c controller > ghes_edac: DEV ghes (INTERRUPT) > [ 21.831763] ------------[ cut here ]------------ > [ 21.836374] refcount_t: increment on 0; use-after-free. > [ 21.841620] WARNING: CPU: 36 PID: 1 at lib/refcount.c:156 > refcount_inc_checked+0x44/0x50 > [ 21.849697] Modules linked in: > [ 21.852745] CPU: 36 PID: 1 Comm: swapper/0 Not tainted > 5.4.0-rc8-next-20191119-00003-g141a9fef5092-dirty torvalds#650 > [ 21.862645] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - > V1.16.01 03/15/2019 > [ 21.871157] pstate: 60c00009 (nZCv daif +PAN +UAO) > [ 21.875936] pc : refcount_inc_checked+0x44/0x50 > [ 21.880455] lr : refcount_inc_checked+0x44/0x50 This is a warning from the refcount framework. It warns if we increment from zero. This is reasonable as typically a kernel object is created with a refcount of 1 and thrown away once the refcount is zero. Afterwards the object is used-after-free. For ghes the refcount is initialized with zero, and that is why we see this message. However, we protect the refcount with the ghes_reg_mutex and thus there is no use after free. The device is allocated and registered if the refcount is zero. So this works fine. Enclosed a fix that avoids the warning, please test. But see below... > [ 21.884972] sp : ffff00236ffbf8a0 > [ 21.888274] x29: ffff00236ffbf8a0 x28: 0000000000000002 > [ 21.893576] x27: ffff00236cd07900 x26: ffff002369063010 > [ 21.898876] x25: 0000000000000000 x24: ffff00233c236824 > [ 21.904177] x23: ffffa000137b9000 x22: ffffa00016fbb7c0 > [ 21.909477] x21: ffffa00012dfd000 x20: 1fffe0046dff7f24 > [ 21.914777] x19: ffff00233c236000 x18: 0000000000000000 > [ 21.920077] x17: 0000000000000000 x16: 0000000000000000 > [ 21.925377] x15: 0000000000007700 x14: 64655f7365686720 > [ 21.930677] x13: 72656c6c6f72746e x12: 1ffff40002719618 > [ 21.935977] x11: ffff940002719618 x10: dfffa00000000000 > [ 21.941278] x9 : ffff940002719619 x8 : 0000000000000001 > [ 21.946578] x7 : 0000000000000000 x6 : 0000000000000001 > [ 21.951877] x5 : ffff940002719618 x4 : ffff00236ffb0010 > [ 21.957178] x3 : ffffa000112415e4 x2 : ffff80046dff7ede > [ 21.962478] x1 : 5aff78756b1cf400 x0 : 0000000000000000 > [ 21.967779] Call trace: > [ 21.970214] refcount_inc_checked+0x44/0x50 > [ 21.974389] ghes_edac_register+0x258/0x388 > [ 21.978562] ghes_probe+0x28c/0x5f0 > [ 21.982041] platform_drv_probe+0x70/0xd8 > [ 21.986039] really_probe+0x174/0x468 > [ 21.989690] driver_probe_device+0x7c/0x148 > [ 21.993862] device_driver_attach+0x94/0xa0 > [ 21.998033] __driver_attach+0xa4/0x110 > [ 22.001857] bus_for_each_dev+0xe8/0x158 > [ 22.005768] driver_attach+0x30/0x40 > [ 22.009331] bus_add_driver+0x234/0x2f0 > [ 22.013156] driver_register+0xbc/0x1d0 > [ 22.016981] __platform_driver_register+0x7c/0x88 > [ 22.021675] ghes_init+0xbc/0x14c > [ 22.024979] do_one_initcall+0xb4/0x254 > [ 22.028805] kernel_init_freeable+0x248/0x2f4 > [ 22.033151] kernel_init+0x10/0x118 > [ 22.036628] ret_from_fork+0x10/0x18 > [ 22.040194] ---[ end trace 33655bb65a9835fe ]--- > [ 22.046666] EDAC MC: bug in low-level driver: attempt to assign > [ 22.046666] duplicate mc_idx 0 in add_mc_to_global_list() > [ 22.058311] ghes_edac: Can't register at EDAC core > [ 22.065402] EDAC MC: bug in low-level driver: attempt to assign > [ 22.065402] duplicate mc_idx 0 in add_mc_to_global_list() > [ 22.077080] ghes_edac: Can't register at EDAC core > [ 22.084140] EDAC MC: bug in low-level driver: attempt to assign > [ 22.084140] duplicate mc_idx 0 in add_mc_to_global_list() > [ 22.095789] ghes_edac: Can't register at EDAC core > [ 22.102873] EDAC MC: bug in low-level driver: attempt to assign > [ 22.102873] duplicate mc_idx 0 in add_mc_to_global_list() > [ 22.115442] ghes_edac: Can't register at EDAC core > [ 22.122536] EDAC MC: bug in low-level driver: attempt to assign > [ 22.122536] duplicate mc_idx 0 in add_mc_to_global_list() > [ 22.134344] ghes_edac: Can't register at EDAC core > [ 22.141441] EDAC MC: bug in low-level driver: attempt to assign > [ 22.141441] duplicate mc_idx 0 in add_mc_to_global_list() > [ 22.153089] ghes_edac: Can't register at EDAC core > [ 22.160161] EDAC MC: bug in low-level driver: attempt to assign > [ 22.160161] duplicate mc_idx 0 in add_mc_to_global_list() > [ 22.171810] ghes_edac: Can't register at EDAC core What I am more concerned is this here. In total this implies 8 ghes users that all try to register a (single-instance) ghes mc device. For non-x86 only one instance is allowed (see ghes_edac_register(), idx = 0). So on your platform, when parsing the HEST table (hest_ghes_dev_register()), more than one "GHES" device is parsed, allocated and registered. Mind sending me your HEST table (/sys/firmware/acpi/tables/HEST), or explain what happens here? If this is a valid use case, we need to change ghes_edac_register() to support more than one instance. Again, please try the patch below. Thanks, -Robert From 6962f8af4a7c1051c9e87a5ac60571f70d2b6814 Mon Sep 17 00:00:00 2001 From: Robert Richter <[email protected]> Date: Thu, 21 Nov 2019 15:01:28 +0100 Subject: [PATCH] EDAC/ghes: Do not warn on when increment refcount on 0 Signed-off-by: Robert Richter <[email protected]>
samueldr
pushed a commit
to mobile-nixos/linux
that referenced
this pull request
Jul 29, 2020
[ Upstream commit 2d097c5 ] We can't just use scsi_cd() to get the scsi_cd structure, we have to grab a live reference to the device. For both callbacks, we're not inside an open where we already hold a reference to the device. This fixes device removal/addition under concurrent device access, which otherwise could result in the below oops. NULL pointer dereference at 0000000000000010 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: sr 12:0:0:0: [sr2] scsi-1 drive scsi_debug crc_t10dif crct10dif_generic crct10dif_common nvme nvme_core sb_edac xl sr 12:0:0:0: Attached scsi CD-ROM sr2 sr_mod cdrom btrfs xor zstd_decompress zstd_compress xxhash lzo_compress zlib_defc sr 12:0:0:0: Attached scsi generic sg7 type 5 igb ahci libahci i2c_algo_bit libata dca [last unloaded: crc_t10dif] CPU: 43 PID: 4629 Comm: systemd-udevd Not tainted 4.16.0+ torvalds#650 Hardware name: Dell Inc. PowerEdge T630/0NT78X, BIOS 2.3.4 11/09/2016 RIP: 0010:sr_block_revalidate_disk+0x23/0x190 [sr_mod] RSP: 0018:ffff883ff357bb58 EFLAGS: 00010292 RAX: ffffffffa00b07d0 RBX: ffff883ff3058000 RCX: ffff883ff357bb66 RDX: 0000000000000003 RSI: 0000000000007530 RDI: ffff881fea631000 RBP: 0000000000000000 R08: ffff881fe4d38400 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000000001b6 R12: 000000000800005d R13: 000000000800005d R14: ffff883ffd9b3790 R15: 0000000000000000 FS: 00007f7dc8e6d8c0(0000) GS:ffff883fff340000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 0000003ffda98005 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __invalidate_device+0x48/0x60 check_disk_change+0x4c/0x60 sr_block_open+0x16/0xd0 [sr_mod] __blkdev_get+0xb9/0x450 ? iget5_locked+0x1c0/0x1e0 blkdev_get+0x11e/0x320 ? bdget+0x11d/0x150 ? _raw_spin_unlock+0xa/0x20 ? bd_acquire+0xc0/0xc0 do_dentry_open+0x1b0/0x320 ? inode_permission+0x24/0xc0 path_openat+0x4e6/0x1420 ? cpumask_any_but+0x1f/0x40 ? flush_tlb_mm_range+0xa0/0x120 do_filp_open+0x8c/0xf0 ? __seccomp_filter+0x28/0x230 ? _raw_spin_unlock+0xa/0x20 ? __handle_mm_fault+0x7d6/0x9b0 ? list_lru_add+0xa8/0xc0 ? _raw_spin_unlock+0xa/0x20 ? __alloc_fd+0xaf/0x160 ? do_sys_open+0x1a6/0x230 do_sys_open+0x1a6/0x230 do_syscall_64+0x5a/0x100 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Reviewed-by: Lee Duncan <[email protected]> Reviewed-by: Jan Kara <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
ojeda
added a commit
to ojeda/linux
that referenced
this pull request
Feb 8, 2022
Sync with v5.17-rc1
kikei
pushed a commit
to kikei/linux
that referenced
this pull request
Jan 17, 2023
We can't just use scsi_cd() to get the scsi_cd structure, we have to grab a live reference to the device. For both callbacks, we're not inside an open where we already hold a reference to the device. This fixes device removal/addition under concurrent device access, which otherwise could result in the below oops. NULL pointer dereference at 0000000000000010 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: sr 12:0:0:0: [sr2] scsi-1 drive scsi_debug crc_t10dif crct10dif_generic crct10dif_common nvme nvme_core sb_edac xl sr 12:0:0:0: Attached scsi CD-ROM sr2 sr_mod cdrom btrfs xor zstd_decompress zstd_compress xxhash lzo_compress zlib_defc sr 12:0:0:0: Attached scsi generic sg7 type 5 igb ahci libahci i2c_algo_bit libata dca [last unloaded: crc_t10dif] CPU: 43 PID: 4629 Comm: systemd-udevd Not tainted 4.16.0+ torvalds#650 Hardware name: Dell Inc. PowerEdge T630/0NT78X, BIOS 2.3.4 11/09/2016 RIP: 0010:sr_block_revalidate_disk+0x23/0x190 [sr_mod] RSP: 0018:ffff883ff357bb58 EFLAGS: 00010292 RAX: ffffffffa00b07d0 RBX: ffff883ff3058000 RCX: ffff883ff357bb66 RDX: 0000000000000003 RSI: 0000000000007530 RDI: ffff881fea631000 RBP: 0000000000000000 R08: ffff881fe4d38400 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000000001b6 R12: 000000000800005d R13: 000000000800005d R14: ffff883ffd9b3790 R15: 0000000000000000 FS: 00007f7dc8e6d8c0(0000) GS:ffff883fff340000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 0000003ffda98005 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __invalidate_device+0x48/0x60 check_disk_change+0x4c/0x60 sr_block_open+0x16/0xd0 [sr_mod] __blkdev_get+0xb9/0x450 ? iget5_locked+0x1c0/0x1e0 blkdev_get+0x11e/0x320 ? bdget+0x11d/0x150 ? _raw_spin_unlock+0xa/0x20 ? bd_acquire+0xc0/0xc0 do_dentry_open+0x1b0/0x320 ? inode_permission+0x24/0xc0 path_openat+0x4e6/0x1420 ? cpumask_any_but+0x1f/0x40 ? flush_tlb_mm_range+0xa0/0x120 do_filp_open+0x8c/0xf0 ? __seccomp_filter+0x28/0x230 ? _raw_spin_unlock+0xa/0x20 ? __handle_mm_fault+0x7d6/0x9b0 ? list_lru_add+0xa8/0xc0 ? _raw_spin_unlock+0xa/0x20 ? __alloc_fd+0xaf/0x160 ? do_sys_open+0x1a6/0x230 do_sys_open+0x1a6/0x230 do_syscall_64+0x5a/0x100 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Reviewed-by: Lee Duncan <[email protected]> Reviewed-by: Jan Kara <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
test