On Tue, Nov 07, 2017 at 03:01:02PM +0100, Borislav Petkov wrote:
On Tue, Nov 07, 2017 at 09:06:26PM +0800, Fengguang Wu wrote:
It turns out rather hard to reproduce -- that's the only occurrence in
100 boots. Perhaps we'll have to give up on this.
Right,
you could blacklist CONFIG_IDE from your randconfig testing - IDE has
been going away since forever :-)
Alternatively, we could brown-paper bag it with something like this:
Tested-by: Fengguang Wu <fengguang.wu@xxxxxxxxx>
I managed to reproduce the issue ~10 times with 500+ boots.
With this fix applied, the BUG no longer shows up in so many boots.
Thanks,
Fengguang
---
diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
index a7355ab3bb22..6ff0be8cbdc9 100644
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -867,11 +867,16 @@ static void msf_from_bcd(struct atapi_msf *msf)
int cdrom_check_status(ide_drive_t *drive, struct request_sense *sense)
{
struct cdrom_info *info = drive->driver_data;
- struct cdrom_device_info *cdi = &info->devinfo;
+ struct cdrom_device_info *cdi;
unsigned char cmd[BLK_MAX_CDB];
ide_debug_log(IDE_DBG_FUNC, "enter");
+ if (!info)
+ return -EIO;
+
+ cdi = &info->devinfo;
+
memset(cmd, 0, BLK_MAX_CDB);
cmd[0] = GPCMD_TEST_UNIT_READY;
--
but from looking at this (I had forgotten how, hm, "interesting" the
IDE code was :-)) it looks like some sort of a race where we've called
->release earlier and drive->driver_data is gone by the time the
workqueue function runs. Or something to that effect...
Anyway, you can still give me your qemu command line and I can try to
debug it, if you'd like. But yeah, it would probably be a waste of time
as IDE is long deprecated...
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
