* [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 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
* [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
@ 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
@ 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
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.