On Tue, 2019-06-18 at 12:51 +0200, Hannes Reinecke wrote:
> On 6/15/19 12:10 AM, Himanshu Madhani wrote:
> > From: Arun Easi <aeasi@xxxxxxxxxxx>
> >
> > BUG: unable to handle kernel NULL pointer dereference at (null)
> > IP: [<ffffffffc050d10c>] qla_nvme_unregister_remote_port+0x6c/0xf0 [qla2xxx]
> > PGD 800000084cf41067 PUD 84d288067 PMD 0
> > Oops: 0000 [#1] SMP
> > Call Trace:
> > [<ffffffff98abcfdf>] process_one_work+0x17f/0x440
> > [<ffffffff98abdca6>] worker_thread+0x126/0x3c0
> > [<ffffffff98abdb80>] ? manage_workers.isra.26+0x2a0/0x2a0
> > [<ffffffff98ac4f81>] kthread+0xd1/0xe0
> > [<ffffffff98ac4eb0>] ? insert_kthread_work+0x40/0x40
> > [<ffffffff9918ad37>] ret_from_fork_nospec_begin+0x21/0x21
> > [<ffffffff98ac4eb0>] ? insert_kthread_work+0x40/0x40
> > RIP [<ffffffffc050d10c>] qla_nvme_unregister_remote_port+0x6c/0xf0 [qla2xxx]
> >
> > The crash is due to a bad entry in the nvme_rport_list. This list is not
> > protected, and when a remoteport_delete callback is called, driver
> > traverses the list and crashes.
> >
> > Actually, the list could be removed and driver could traverse the main
> > fcport list instead. Fix does exactly that.
> >
> > Signed-off-by: Arun Easi <aeasi@xxxxxxxxxxx>
> > Signed-off-by: Himanshu Madhani <hmadhani@xxxxxxxxxxx>
> > ---
> > drivers/scsi/qla2xxx/qla_def.h | 1 -
> > drivers/scsi/qla2xxx/qla_nvme.c | 52 ++++++++++++++++++++---------------------
> > drivers/scsi/qla2xxx/qla_nvme.h | 1 -
> > drivers/scsi/qla2xxx/qla_os.c | 1 -
> > 4 files changed, 25 insertions(+), 30 deletions(-)
> >
>
> [ .. ]
> > diff --git a/drivers/scsi/qla2xxx/qla_nvme.h b/drivers/scsi/qla2xxx/qla_nvme.h
> > index d3b8a6440113..2d088add7011 100644
> > --- a/drivers/scsi/qla2xxx/qla_nvme.h
> > +++ b/drivers/scsi/qla2xxx/qla_nvme.h
> > @@ -37,7 +37,6 @@ struct nvme_private {
> > };
> >
> > struct qla_nvme_rport {
> > - struct list_head list;
> > struct fc_port *fcport;
> > };
> >
>
> Where is the point of this structure now?
> Please drop it, and use fc_port directly.
I thought about mentioning that, but nvme_fc_remote_port's
->private field is allocated by .remote_priv_sz in the call to
nvme_fc_register_remoteport(), so I don't see a clean way to
just set ->private to the fc_port.
And, if a driver-specific field needs to be added later, it
would all have to be put back.
-Ewan
>
> Cheers,
>
> Hannes
