On Wed, 2015-10-21 at 17:26 +0300, Dāvis Mosāns wrote: > 2015-10-21 16:47 GMT+03:00 Johannes Thumshirn <jthumshirn@xxxxxxx>: > > On Wed, 2015-10-21 at 16:18 +0300, Dāvis Mosāns wrote: > > > 2015-10-21 10:33 GMT+03:00 Johannes Thumshirn <jthumshirn@xxxxxxx > > > >: > > > > On Tue, 2015-10-20 at 20:41 +0300, Dāvis Mosāns wrote: > > > > > 2015-08-21 7:29 GMT+03:00 Dāvis Mosāns <davispuh@xxxxxxxxx>: > > > > > > When pci_pool_alloc fails in mvs_task_prep then task- > > > > > > >lldd_task > > > > > > stays > > > > > > NULL but it's later used in mvs_abort_task as slot which is > > > > > > passed > > > > > > to mvs_slot_task_free causing NULL pointer dereference. > > > > > > > > > > > > Just return from mvs_slot_task_free when passed with NULL > > > > > > slot. > > > > > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=10189 > > > > > > 1 > > > > > > Signed-off-by: Dāvis Mosāns <davispuh@xxxxxxxxx> > > > > > > --- > > > > > > drivers/scsi/mvsas/mv_sas.c | 2 ++ > > > > > > 1 file changed, 2 insertions(+) > > > > > > > > > > > > diff --git a/drivers/scsi/mvsas/mv_sas.c > > > > > > b/drivers/scsi/mvsas/mv_sas.c > > > > > > index 454536c..9c78074 100644 > > > > > > --- a/drivers/scsi/mvsas/mv_sas.c > > > > > > +++ b/drivers/scsi/mvsas/mv_sas.c > > > > > > @@ -887,6 +887,8 @@ static void mvs_slot_free(struct > > > > > > mvs_info > > > > > > *mvi, > > > > > > u32 rx_desc) > > > > > > static void mvs_slot_task_free(struct mvs_info *mvi, > > > > > > struct > > > > > > sas_task *task, > > > > > > struct mvs_slot_info *slot, u32 > > > > > > slot_idx) > > > > > > { > > > > > > + if (!slot) > > > > > > + return; > > > > > > if (!slot->task) > > > > > > return; > > > > > > if (!sas_protocol_ata(task->task_proto)) > > > > > > -- > > > > > > 2.5.0 > > > > > > > > > > > > > > > > Can this get merged? > > > > > So far since august it have saved me from several kernel > > > > > crashes. > > > > > > > > If it saved you from several crashes, it probably should be > > > > tagged > > > > for > > > > stable, shouldn't it? > > > > > > > > Reviewed-by: Johannes Thumshirn <jthumshirn@xxxxxxx> > > > > > > > > > > > > > > I don't really know how that works... this is my first patch so > > > I'm > > > not really concerned about in which version it gets in as long as > > > it > > > does. > > > I've been compiling kernel with this patch for these months so > > > for me > > > it > > > doesn't really make any difference. > > > > You can add > > Cc: stable@xxxxxxxxxxxxxxx > > somewhere around your Signed-off-by > > > > Documentation/stable_kernel_rules.txt has all the process > > documentation. > > Should I add it together with review tags too and resend patch or > reply to this > thread with it edited or just leave it like it is now and whoever > will see it > will add it himself? good question, but I think James can help here. > > > also for stable requirements this line is a bit confusing > "It or an equivalent fix must already exist in Linus' tree > (upstream)." > > but then later seems it's not requirement for Option 1 yes, if you tag it with the Cc, it will get to stable review _after_ it is applied to Linus' tree -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
