All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/1] cdrom: patch for inclusion
@ 2023-10-02 22:02 Phillip Potter
  2023-10-03  2:05 ` Jens Axboe
  0 siblings, 1 reply; 14+ messages in thread
From: Phillip Potter @ 2023-10-02 22:02 UTC (permalink / raw)
  To: axboe; +Cc: linux-block

Hi Jens,

Please include Joel's patch below, reviewed and signed off by myself.
Many thanks.

Regards,
Phil

Joel Granados (1):
  cdrom: Remove now superfluous sentinel element from ctl_table array

 drivers/cdrom/cdrom.c | 1 -
 1 file changed, 1 deletion(-)

-- 
2.41.0


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 0/1] cdrom: patch for inclusion
  2023-10-02 22:02 Phillip Potter
@ 2023-10-03  2:05 ` Jens Axboe
  0 siblings, 0 replies; 14+ messages in thread
From: Jens Axboe @ 2023-10-03  2:05 UTC (permalink / raw)
  To: Phillip Potter; +Cc: linux-block


On Mon, 02 Oct 2023 23:02:02 +0100, Phillip Potter wrote:
> Please include Joel's patch below, reviewed and signed off by myself.
> Many thanks.
> 
> Regards,
> Phil
> 
> Joel Granados (1):
>   cdrom: Remove now superfluous sentinel element from ctl_table array
> 
> [...]

Applied, thanks!

[1/1] cdrom: Remove now superfluous sentinel element from ctl_table array
      commit: 114b0ff62a6510eb218660cb4925b4c4a01cdd84

Best regards,
-- 
Jens Axboe




^ permalink raw reply	[flat|nested] 14+ messages in thread

* [PATCH 0/1] cdrom: patch for inclusion
@ 2024-06-01 22:18 Phillip Potter
  0 siblings, 0 replies; 14+ messages in thread
From: Phillip Potter @ 2024-06-01 22:18 UTC (permalink / raw)
  To: axboe; +Cc: linux-block

Hi Jens,

Please apply the following patch from Jeff Johnson, that adds a missing
MODULE_DESCRIPTION() invocation to drivers/cdrom/cdrom.c, to prevent a
build warning regarding its absence.

Many thanks in advance.

Regards,
Phil

Jeff Johnson (1):
  cdrom: Add missing MODULE_DESCRIPTION()

 drivers/cdrom/cdrom.c | 1 +
 1 file changed, 1 insertion(+)

-- 
2.45.1


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [PATCH 0/1] cdrom: patch for inclusion
@ 2025-05-14 22:33 Phillip Potter
  0 siblings, 0 replies; 14+ messages in thread
From: Phillip Potter @ 2025-05-14 22:33 UTC (permalink / raw)
  To: axboe; +Cc: phil, linux-block

Hi Jens,

I hope you are well :-)

Please accept the following patch from Chen Ni that removes an
unnecessary NULL check in cdrom_sysctl_unregister. I have verified the
necessary check is being done inside unregister_sysctl_table myself, and
indeed a number of other module_exit routines take this same approach.

Many thanks in advance.

Regards,
Phil

Chen Ni (1):
  cdrom: Remove unnecessary NULL check before unregister_sysctl_table()

 drivers/cdrom/cdrom.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

-- 
2.49.0


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [PATCH 0/1] cdrom: patch for inclusion
@ 2025-07-22 23:18 Phillip Potter
  2025-07-22 23:19 ` [PATCH 1/1] cdrom: Call cdrom_mrw_exit from cdrom_release function Phillip Potter
                   ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: Phillip Potter @ 2025-07-22 23:18 UTC (permalink / raw)
  To: axboe; +Cc: senozhatsky, linux-block

Hi Jens,

Please apply the following patch, suggested by yourself and credited as
such. I have tested that this call does not make things actively worse,
and indeed that optical drive functionality (and in particular release)
still works as expected.

That said, I've been unable to replicate the issue seen in the report
thus far. I have tried a variety of approaches including just yanking
the cable out several times, and in all cases, my kernel does crash or
post a BUG, and properly unloads the driver - this is both on the latest
6.16-rc7 and also on 6.6.98 LTS, and including when I am specifically
inside cdrom_mrw_exit. I plan to do more digging regarding this, hopefully
this weekend when I have some free time, as I'd really love to replicate
the original crash.

I still think this patch makes sense though and should be applied
anyway. I've also patched the unused exit field out in the documentation
file, and used the 'Closes' tag as suggested by checkpatch.
Many thanks in advance.

Regards,
Phil

Phillip Potter (1):
  cdrom: Call cdrom_mrw_exit from cdrom_release function

 Documentation/cdrom/cdrom-standard.rst | 1 -
 drivers/cdrom/cdrom.c                  | 8 ++------
 include/linux/cdrom.h                  | 1 -
 3 files changed, 2 insertions(+), 8 deletions(-)

-- 
2.50.1


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [PATCH 1/1] cdrom: Call cdrom_mrw_exit from cdrom_release function
  2025-07-22 23:18 [PATCH 0/1] cdrom: patch for inclusion Phillip Potter
@ 2025-07-22 23:19 ` Phillip Potter
  2025-07-24  3:55   ` Sergey Senozhatsky
  2025-07-23  1:10 ` [PATCH 0/1] cdrom: patch for inclusion Jens Axboe
  2025-07-23  1:14 ` Sergey Senozhatsky
  2 siblings, 1 reply; 14+ messages in thread
From: Phillip Potter @ 2025-07-22 23:19 UTC (permalink / raw)
  To: axboe; +Cc: senozhatsky, linux-block

Remove the cdrom_mrw_exit call from unregister_cdrom, as it invokes
block commands that can fail due to a NULL pointer dereference from the
call happening too late, during the unloading of the driver (e.g.
unplugging of USB optical drives).

Instead perform the call inside cdrom_release, thus also removing the
need for the exit function pointer inside the cdrom_device_info struct.

Reported-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Closes: https://lore.kernel.org/linux-block/uxgzea5ibqxygv3x7i4ojbpvcpv2wziorvb3ns5cdtyvobyn7h@y4g4l5ezv2ec
Suggested-by: Jens Axboe <axboe@kernel.dk>
Link: https://lore.kernel.org/linux-block/6686fe78-a050-4a1d-aa27-b7bf7ca6e912@kernel.dk
Tested-by: Phillip Potter <phil@philpotter.co.uk>
Signed-off-by: Phillip Potter <phil@philpotter.co.uk>
---
 Documentation/cdrom/cdrom-standard.rst | 1 -
 drivers/cdrom/cdrom.c                  | 8 ++------
 include/linux/cdrom.h                  | 1 -
 3 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/Documentation/cdrom/cdrom-standard.rst b/Documentation/cdrom/cdrom-standard.rst
index 6c1303cff159..b97a4e9b9bd3 100644
--- a/Documentation/cdrom/cdrom-standard.rst
+++ b/Documentation/cdrom/cdrom-standard.rst
@@ -273,7 +273,6 @@ The drive-specific, minor-like information that is registered with
 	__u8 media_written;			/*  dirty flag, DVD+RW bookkeeping */
 	unsigned short mmc3_profile;		/*  current MMC3 profile */
 	int for_data;				/*  unknown:TBD */
-	int (*exit)(struct cdrom_device_info *);/*  unknown:TBD */
 	int mrw_mode_page;			/*  which MRW mode page is in use */
   };
 
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 21a10552da61..31ba1f8c1f78 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -624,9 +624,6 @@ int register_cdrom(struct gendisk *disk, struct cdrom_device_info *cdi)
 	if (check_media_type == 1)
 		cdi->options |= (int) CDO_CHECK_TYPE;
 
-	if (CDROM_CAN(CDC_MRW_W))
-		cdi->exit = cdrom_mrw_exit;
-
 	if (cdi->ops->read_cdda_bpc)
 		cdi->cdda_method = CDDA_BPC_FULL;
 	else
@@ -651,9 +648,6 @@ void unregister_cdrom(struct cdrom_device_info *cdi)
 	list_del(&cdi->list);
 	mutex_unlock(&cdrom_mutex);
 
-	if (cdi->exit)
-		cdi->exit(cdi);
-
 	cd_dbg(CD_REG_UNREG, "drive \"/dev/%s\" unregistered\n", cdi->name);
 }
 EXPORT_SYMBOL(unregister_cdrom);
@@ -1264,6 +1258,8 @@ void cdrom_release(struct cdrom_device_info *cdi)
 		cd_dbg(CD_CLOSE, "Use count for \"/dev/%s\" now zero\n",
 		       cdi->name);
 		cdrom_dvd_rw_close_write(cdi);
+		if (CDROM_CAN(CDC_MRW_W))
+			cdrom_mrw_exit(cdi);
 
 		if ((cdo->capability & CDC_LOCK) && !cdi->keeplocked) {
 			cd_dbg(CD_CLOSE, "Unlocking door!\n");
diff --git a/include/linux/cdrom.h b/include/linux/cdrom.h
index fdfb61ccf55a..b907e6c2307d 100644
--- a/include/linux/cdrom.h
+++ b/include/linux/cdrom.h
@@ -62,7 +62,6 @@ struct cdrom_device_info {
 	__u8 last_sense;
 	__u8 media_written;		/* dirty flag, DVD+RW bookkeeping */
 	unsigned short mmc3_profile;	/* current MMC3 profile */
-	int (*exit)(struct cdrom_device_info *);
 	int mrw_mode_page;
 	bool opened_for_data;
 	__s64 last_media_change_ms;
-- 
2.50.1


^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [PATCH 0/1] cdrom: patch for inclusion
  2025-07-22 23:18 [PATCH 0/1] cdrom: patch for inclusion Phillip Potter
  2025-07-22 23:19 ` [PATCH 1/1] cdrom: Call cdrom_mrw_exit from cdrom_release function Phillip Potter
@ 2025-07-23  1:10 ` Jens Axboe
  2025-07-23  1:14 ` Sergey Senozhatsky
  2 siblings, 0 replies; 14+ messages in thread
From: Jens Axboe @ 2025-07-23  1:10 UTC (permalink / raw)
  To: Phillip Potter; +Cc: senozhatsky, linux-block


On Wed, 23 Jul 2025 00:18:59 +0100, Phillip Potter wrote:
> Please apply the following patch, suggested by yourself and credited as
> such. I have tested that this call does not make things actively worse,
> and indeed that optical drive functionality (and in particular release)
> still works as expected.
> 
> That said, I've been unable to replicate the issue seen in the report
> thus far. I have tried a variety of approaches including just yanking
> the cable out several times, and in all cases, my kernel does crash or
> post a BUG, and properly unloads the driver - this is both on the latest
> 6.16-rc7 and also on 6.6.98 LTS, and including when I am specifically
> inside cdrom_mrw_exit. I plan to do more digging regarding this, hopefully
> this weekend when I have some free time, as I'd really love to replicate
> the original crash.
> 
> [...]

Applied, thanks!

[1/1] cdrom: Call cdrom_mrw_exit from cdrom_release function
      commit: 5ec9d26b78c4eb7c2fab54dcec6c0eb845302a98

Best regards,
-- 
Jens Axboe




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 0/1] cdrom: patch for inclusion
  2025-07-22 23:18 [PATCH 0/1] cdrom: patch for inclusion Phillip Potter
  2025-07-22 23:19 ` [PATCH 1/1] cdrom: Call cdrom_mrw_exit from cdrom_release function Phillip Potter
  2025-07-23  1:10 ` [PATCH 0/1] cdrom: patch for inclusion Jens Axboe
@ 2025-07-23  1:14 ` Sergey Senozhatsky
  2025-07-23  8:02   ` Phillip Potter
  2 siblings, 1 reply; 14+ messages in thread
From: Sergey Senozhatsky @ 2025-07-23  1:14 UTC (permalink / raw)
  To: Phillip Potter; +Cc: axboe, senozhatsky, linux-block

On (25/07/23 00:18), Phillip Potter wrote:
> [..] I plan to do more digging regarding this, hopefully
> this weekend when I have some free time, as I'd really love to replicate
> the original crash.

I waiting for LG GP65NB60 shipment (arriving today/tomorrow), which
shows up in crash reports (it should have CDC_MRW_W.)  So I'll be able
to run some tests soon.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 0/1] cdrom: patch for inclusion
  2025-07-23  1:14 ` Sergey Senozhatsky
@ 2025-07-23  8:02   ` Phillip Potter
  2025-07-24  3:54     ` Sergey Senozhatsky
  0 siblings, 1 reply; 14+ messages in thread
From: Phillip Potter @ 2025-07-23  8:02 UTC (permalink / raw)
  To: Sergey Senozhatsky; +Cc: Phillip Potter, axboe, senozhatsky, linux-block

On Wed, Jul 23, 2025 at 10:14:32AM +0900, Sergey Senozhatsky wrote:
> On (25/07/23 00:18), Phillip Potter wrote:
> > [..] I plan to do more digging regarding this, hopefully
> > this weekend when I have some free time, as I'd really love to replicate
> > the original crash.
> 
> I waiting for LG GP65NB60 shipment (arriving today/tomorrow), which
> shows up in crash reports (it should have CDC_MRW_W.)  So I'll be able
> to run some tests soon.

Had to fake it with mine by forcing open the relevant code path for the
check to be done. It still didn't crash, so I'll be interested to see
your results. Will hopefully have a dig myself at the weekend :-)

Regards,
Phil

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 0/1] cdrom: patch for inclusion
  2025-07-23  8:02   ` Phillip Potter
@ 2025-07-24  3:54     ` Sergey Senozhatsky
  2025-07-24  7:51       ` Sergey Senozhatsky
  0 siblings, 1 reply; 14+ messages in thread
From: Sergey Senozhatsky @ 2025-07-24  3:54 UTC (permalink / raw)
  To: Phillip Potter; +Cc: Sergey Senozhatsky, axboe, linux-block

On (25/07/23 09:02), Phillip Potter wrote:
> On Wed, Jul 23, 2025 at 10:14:32AM +0900, Sergey Senozhatsky wrote:
> > On (25/07/23 00:18), Phillip Potter wrote:
> > > [..] I plan to do more digging regarding this, hopefully
> > > this weekend when I have some free time, as I'd really love to replicate
> > > the original crash.
> > 
> > I waiting for LG GP65NB60 shipment (arriving today/tomorrow), which
> > shows up in crash reports (it should have CDC_MRW_W.)  So I'll be able
> > to run some tests soon.
> 
> Had to fake it with mine by forcing open the relevant code path for the
> check to be done. It still didn't crash, so I'll be interested to see
> your results

100% reproducible (at least on 6.6 LTS) with LG GP65.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 1/1] cdrom: Call cdrom_mrw_exit from cdrom_release function
  2025-07-22 23:19 ` [PATCH 1/1] cdrom: Call cdrom_mrw_exit from cdrom_release function Phillip Potter
@ 2025-07-24  3:55   ` Sergey Senozhatsky
  0 siblings, 0 replies; 14+ messages in thread
From: Sergey Senozhatsky @ 2025-07-24  3:55 UTC (permalink / raw)
  To: Jens Axboe, Phillip Potter; +Cc: senozhatsky, linux-block

On (25/07/23 00:19), Phillip Potter wrote:
> Remove the cdrom_mrw_exit call from unregister_cdrom, as it invokes
> block commands that can fail due to a NULL pointer dereference from the
> call happening too late, during the unloading of the driver (e.g.
> unplugging of USB optical drives).
> 
> Instead perform the call inside cdrom_release, thus also removing the
> need for the exit function pointer inside the cdrom_device_info struct.
> 
> Reported-by: Sergey Senozhatsky <senozhatsky@chromium.org>
> Closes: https://lore.kernel.org/linux-block/uxgzea5ibqxygv3x7i4ojbpvcpv2wziorvb3ns5cdtyvobyn7h@y4g4l5ezv2ec
> Suggested-by: Jens Axboe <axboe@kernel.dk>
> Link: https://lore.kernel.org/linux-block/6686fe78-a050-4a1d-aa27-b7bf7ca6e912@kernel.dk
> Tested-by: Phillip Potter <phil@philpotter.co.uk>
> Signed-off-by: Phillip Potter <phil@philpotter.co.uk>

FWIW,
Tested-by: Sergey Senozhatsky <senozhatsky@chromium.org>  # with LG GP65

Thanks!

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 0/1] cdrom: patch for inclusion
  2025-07-24  3:54     ` Sergey Senozhatsky
@ 2025-07-24  7:51       ` Sergey Senozhatsky
  2025-07-25  7:40         ` Phillip Potter
  0 siblings, 1 reply; 14+ messages in thread
From: Sergey Senozhatsky @ 2025-07-24  7:51 UTC (permalink / raw)
  To: Phillip Potter; +Cc: axboe, linux-block, Sergey Senozhatsky

On (25/07/24 12:54), Sergey Senozhatsky wrote:
> On (25/07/23 09:02), Phillip Potter wrote:
> > On Wed, Jul 23, 2025 at 10:14:32AM +0900, Sergey Senozhatsky wrote:
> > > On (25/07/23 00:18), Phillip Potter wrote:
> > > > [..] I plan to do more digging regarding this, hopefully
> > > > this weekend when I have some free time, as I'd really love to replicate
> > > > the original crash.
> > > 
> > > I waiting for LG GP65NB60 shipment (arriving today/tomorrow), which
> > > shows up in crash reports (it should have CDC_MRW_W.)  So I'll be able
> > > to run some tests soon.
> > 
> > Had to fake it with mine by forcing open the relevant code path for the
> > check to be done. It still didn't crash, so I'll be interested to see
> > your results
> 
> 100% reproducible (at least on 6.6 LTS) with LG GP65.

And unpatched 6.12 LTS sometimes UAFs

[  106.092832] ==================================================================
[  106.092866] BUG: KASAN: slab-use-after-free in sr_packet+0x179/0x1c0 [sr_mod]
[  106.092903] Read of size 8 at addr ffff888002a6c154 by task cros-disks/1958

[  106.092943] CPU: 2 UID: 213 PID: 1958 Comm: cros-disks Not tainted 6.12.24-kasan-00964-g86abb5aa35ec
[  106.092969] Call Trace:
[  106.092976]  <TASK>
[  106.092983]  dump_stack_lvl+0x85/0xc0
[  106.093007]  print_address_description+0x72/0x210
[  106.093023]  print_report+0x4e/0x60
[  106.093037]  kasan_report+0x131/0x170
[  106.093052]  ? sr_packet+0x179/0x1c0 [sr_mod f28dbac28d644b5cb94db24e267ca134450739a2]
[  106.093075]  sr_packet+0x179/0x1c0 [sr_mod f28dbac28d644b5cb94db24e267ca134450739a2]
[  106.093095]  cdrom_mrw_exit+0xea/0x2e0 [cdrom 2d8b336738c9be415c8730ee14c0fc4e4c0367db]
[  106.093120]  sr_free_disk+0x9a/0xc0 [sr_mod f28dbac28d644b5cb94db24e267ca134450739a2]
[  106.093138]  disk_release+0x248/0x280
[  106.093156]  device_release+0x94/0x190
[  106.093172]  kobject_put+0x177/0x1f0
[  106.093187]  blkdev_release+0x11/0x20
[  106.093201]  __fput+0x1a7/0x7c0
[  106.093221]  task_work_run+0x107/0x180
[  106.093240]  resume_user_mode_work+0x4e/0x50
[  106.093254]  syscall_exit_to_user_mode+0x63/0xb0
[  106.093268]  do_syscall_64+0x76/0xe0
[  106.093818]  </TASK>

[  106.094277] Allocated by task 12:
[  106.094295]  kasan_save_track+0x3a/0x80
[  106.094318]  __kasan_kmalloc+0x75/0x90
[  106.094339]  __kmalloc_noprof+0x18e/0x310
[  106.094360]  scsi_alloc_sdev+0x117/0x9d0
[  106.094383]  scsi_probe_and_add_lun+0x168/0x3670
[  106.094405]  __scsi_scan_target+0x121/0x7a0
[  106.094426]  scsi_scan_host_selected+0x291/0x4f0
[  106.094448]  do_scan_async+0x21b/0x710
[  106.094469]  async_run_entry_fn+0x97/0x360
[  106.094490]  process_scheduled_works+0x757/0xe20
[  106.094512]  worker_thread+0xb4c/0x1150
[  106.094533]  kthread+0x274/0x300
[  106.094553]  ret_from_fork+0x3b/0x70
[  106.094576]  ret_from_fork_asm+0x11/0x20

[  106.094611] Freed by task 1958:
[  106.094628]  kasan_save_track+0x3a/0x80
[  106.094649]  kasan_save_free_info+0x46/0x60
[  106.094670]  __kasan_slab_free+0x37/0x50
[  106.094690]  kfree+0x103/0x300
[  106.094710]  scsi_device_dev_release+0x95d/0x9d0
[  106.094732]  device_release+0x94/0x190
[  106.094753]  kobject_put+0x177/0x1f0
[  106.094773]  scsi_device_put+0x7f/0x90
[  106.094793]  bdev_release+0x46a/0x570
[  106.094818]  blkdev_release+0x11/0x20
[  106.094836]  __fput+0x1a7/0x7c0
[  106.094856]  task_work_run+0x107/0x180
[  106.094880]  resume_user_mode_work+0x4e/0x50
[  106.094900]  syscall_exit_to_user_mode+0x63/0xb0
[  106.094920]  do_syscall_64+0x76/0xe0
[  106.094940]  entry_SYSCALL_64_after_hwframe+0x55/0x5d


The patched one doesn't.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 0/1] cdrom: patch for inclusion
  2025-07-24  7:51       ` Sergey Senozhatsky
@ 2025-07-25  7:40         ` Phillip Potter
  2025-07-25  7:47           ` Sergey Senozhatsky
  0 siblings, 1 reply; 14+ messages in thread
From: Phillip Potter @ 2025-07-25  7:40 UTC (permalink / raw)
  To: Sergey Senozhatsky; +Cc: Phillip Potter, axboe, linux-block, Sergey Senozhatsky

On Thu, Jul 24, 2025 at 04:51:34PM +0900, Sergey Senozhatsky wrote:
> On (25/07/24 12:54), Sergey Senozhatsky wrote:
> > On (25/07/23 09:02), Phillip Potter wrote:
> > > On Wed, Jul 23, 2025 at 10:14:32AM +0900, Sergey Senozhatsky wrote:
> > > > On (25/07/23 00:18), Phillip Potter wrote:
> > > > > [..] I plan to do more digging regarding this, hopefully
> > > > > this weekend when I have some free time, as I'd really love to replicate
> > > > > the original crash.
> > > > 
> > > > I waiting for LG GP65NB60 shipment (arriving today/tomorrow), which
> > > > shows up in crash reports (it should have CDC_MRW_W.)  So I'll be able
> > > > to run some tests soon.
> > > 
> > > Had to fake it with mine by forcing open the relevant code path for the
> > > check to be done. It still didn't crash, so I'll be interested to see
> > > your results
> > 
> > 100% reproducible (at least on 6.6 LTS) with LG GP65.
> 
> And unpatched 6.12 LTS sometimes UAFs
> 
> [  106.092832] ==================================================================
> [  106.092866] BUG: KASAN: slab-use-after-free in sr_packet+0x179/0x1c0 [sr_mod]
> [  106.092903] Read of size 8 at addr ffff888002a6c154 by task cros-disks/1958
> 
> [  106.092943] CPU: 2 UID: 213 PID: 1958 Comm: cros-disks Not tainted 6.12.24-kasan-00964-g86abb5aa35ec
> [  106.092969] Call Trace:
> [  106.092976]  <TASK>
> [  106.092983]  dump_stack_lvl+0x85/0xc0
> [  106.093007]  print_address_description+0x72/0x210
> [  106.093023]  print_report+0x4e/0x60
> [  106.093037]  kasan_report+0x131/0x170
> [  106.093052]  ? sr_packet+0x179/0x1c0 [sr_mod f28dbac28d644b5cb94db24e267ca134450739a2]
> [  106.093075]  sr_packet+0x179/0x1c0 [sr_mod f28dbac28d644b5cb94db24e267ca134450739a2]
> [  106.093095]  cdrom_mrw_exit+0xea/0x2e0 [cdrom 2d8b336738c9be415c8730ee14c0fc4e4c0367db]
> [  106.093120]  sr_free_disk+0x9a/0xc0 [sr_mod f28dbac28d644b5cb94db24e267ca134450739a2]
> [  106.093138]  disk_release+0x248/0x280
> [  106.093156]  device_release+0x94/0x190
> [  106.093172]  kobject_put+0x177/0x1f0
> [  106.093187]  blkdev_release+0x11/0x20
> [  106.093201]  __fput+0x1a7/0x7c0
> [  106.093221]  task_work_run+0x107/0x180
> [  106.093240]  resume_user_mode_work+0x4e/0x50
> [  106.093254]  syscall_exit_to_user_mode+0x63/0xb0
> [  106.093268]  do_syscall_64+0x76/0xe0
> [  106.093818]  </TASK>
> 
> [  106.094277] Allocated by task 12:
> [  106.094295]  kasan_save_track+0x3a/0x80
> [  106.094318]  __kasan_kmalloc+0x75/0x90
> [  106.094339]  __kmalloc_noprof+0x18e/0x310
> [  106.094360]  scsi_alloc_sdev+0x117/0x9d0
> [  106.094383]  scsi_probe_and_add_lun+0x168/0x3670
> [  106.094405]  __scsi_scan_target+0x121/0x7a0
> [  106.094426]  scsi_scan_host_selected+0x291/0x4f0
> [  106.094448]  do_scan_async+0x21b/0x710
> [  106.094469]  async_run_entry_fn+0x97/0x360
> [  106.094490]  process_scheduled_works+0x757/0xe20
> [  106.094512]  worker_thread+0xb4c/0x1150
> [  106.094533]  kthread+0x274/0x300
> [  106.094553]  ret_from_fork+0x3b/0x70
> [  106.094576]  ret_from_fork_asm+0x11/0x20
> 
> [  106.094611] Freed by task 1958:
> [  106.094628]  kasan_save_track+0x3a/0x80
> [  106.094649]  kasan_save_free_info+0x46/0x60
> [  106.094670]  __kasan_slab_free+0x37/0x50
> [  106.094690]  kfree+0x103/0x300
> [  106.094710]  scsi_device_dev_release+0x95d/0x9d0
> [  106.094732]  device_release+0x94/0x190
> [  106.094753]  kobject_put+0x177/0x1f0
> [  106.094773]  scsi_device_put+0x7f/0x90
> [  106.094793]  bdev_release+0x46a/0x570
> [  106.094818]  blkdev_release+0x11/0x20
> [  106.094836]  __fput+0x1a7/0x7c0
> [  106.094856]  task_work_run+0x107/0x180
> [  106.094880]  resume_user_mode_work+0x4e/0x50
> [  106.094900]  syscall_exit_to_user_mode+0x63/0xb0
> [  106.094920]  do_syscall_64+0x76/0xe0
> [  106.094940]  entry_SYSCALL_64_after_hwframe+0x55/0x5d
> 
> 
> The patched one doesn't.

Fantastic news. Thanks for testing this, and for your other testing
too, much appreciated. Have a great weekend.

Regards,
Phil

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 0/1] cdrom: patch for inclusion
  2025-07-25  7:40         ` Phillip Potter
@ 2025-07-25  7:47           ` Sergey Senozhatsky
  0 siblings, 0 replies; 14+ messages in thread
From: Sergey Senozhatsky @ 2025-07-25  7:47 UTC (permalink / raw)
  To: Phillip Potter; +Cc: Sergey Senozhatsky, axboe, linux-block

On (25/07/25 08:40), Phillip Potter wrote:
> > The patched one doesn't.
> 
> Fantastic news. Thanks for testing this, and for your other testing
> too, much appreciated.

Thanks for working on this, folks.

> Have a great weekend.

Thanks, have a great one too!

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2025-07-25  7:47 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-07-22 23:18 [PATCH 0/1] cdrom: patch for inclusion Phillip Potter
2025-07-22 23:19 ` [PATCH 1/1] cdrom: Call cdrom_mrw_exit from cdrom_release function Phillip Potter
2025-07-24  3:55   ` Sergey Senozhatsky
2025-07-23  1:10 ` [PATCH 0/1] cdrom: patch for inclusion Jens Axboe
2025-07-23  1:14 ` Sergey Senozhatsky
2025-07-23  8:02   ` Phillip Potter
2025-07-24  3:54     ` Sergey Senozhatsky
2025-07-24  7:51       ` Sergey Senozhatsky
2025-07-25  7:40         ` Phillip Potter
2025-07-25  7:47           ` Sergey Senozhatsky
  -- strict thread matches above, loose matches on Subject: below --
2025-05-14 22:33 Phillip Potter
2024-06-01 22:18 Phillip Potter
2023-10-02 22:02 Phillip Potter
2023-10-03  2:05 ` Jens Axboe

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.