Re: FAILED: patch "[PATCH] scsi: zfcp: fix capping of unsuccessful GPN_FT SAN response" failed to apply to 3.18-stable tree

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Sep 25, 2017 at 03:42:23PM +0200, Steffen Maier wrote:
> Hi Greg,
> 
> the following upstream zfcp patches since v3.18 were tagged for stable:
> 
> > $ git log --grep=stable --pretty=fixes v3.18.. -- drivers/s390/scsi/
> > 5d4a3d0a2ff2 ("scsi: zfcp: trace high part of "new" 64 bit SCSI LUN")
> > fdb7cee3b9e3 ("scsi: zfcp: trace HBA FSF response by default on dismiss or timedout late response")
> > 12c3e5754c80 ("scsi: zfcp: fix payload with full FCP_RSP IU in SCSI trace records")
> > 1a5d999ebfc7 ("scsi: zfcp: fix missing trace records for early returns in TMF eh handlers")
> 
> This depends on the next one which is why it caused the build error.
> 
> > 9fe5d2b2fd30 ("scsi: zfcp: fix passing fsf_req to SCSI trace on TMF to correlate with HBA")
> 
> This in turn depends on below aceeffbb59bb ("zfcp: trace full payload of all
> SAN records (req,resp,iels)") which is why it failed.
> 
> > 975171b4461b ("scsi: zfcp: fix capping of unsuccessful GPN_FT SAN response trace records")
> > a099b7b1fc1f ("scsi: zfcp: add handling for FCP_RESID_OVER to the fcp ingress path")
> > 71b8e45da51a ("scsi: zfcp: fix queuecommand for scsi_eh commands when DIX enabled")
> 
> Above are the ones you included for longterm 3.18.72.
> 
> Below are the ones I cannot seem to find in branch linux-3.18.y of
> linux-stable.git up to the current HEAD with tag v3.18.71:
> * linux-3.18.y 60a8261b1257 [origin/linux-3.18.y] Linux 3.18.71.
> 
> > 2dfa6688aafd ("scsi: zfcp: fix use-after-free by not tracing WKA port open/close on failed send")
> > 6f2ce1c6af37 ("scsi: zfcp: fix rport unblock race with LUN recovery")
> > 56d23ed7adf3 ("scsi: zfcp: do not trace pure benign residual HBA responses at default level")
> > dac37e15b7d5 ("scsi: zfcp: fix use-after-"free" in FC ingress path after TMF")
> > e7cb08e894a0 ("scsi: zfcp: spin_lock_irqsave() is not nestable")
> > aceeffbb59bb ("zfcp: trace full payload of all SAN records (req,resp,iels)")
> 
> This is a dependency for some of the above patches included for 3.18.72.
> 
> > 94db3725f049 ("zfcp: fix payload trace length for SAN request&response")
> > 771bf03537dd ("zfcp: fix D_ID field with actual value on tracing SAN responses")
> > 7c964ffe586b ("zfcp: restore tracing of handle for port and LUN with HBA records")
> > d27a7cb91960 ("zfcp: trace on request for open and close of WKA port")
> > 0102a30a6ff6 ("zfcp: restore: Dont use 0 to indicate invalid LUN in rec trace")
> > 35f040df97fa ("zfcp: retain trace level for SCSI and HBA FSF response records")
> > 4eeaa4f3f1d6 ("zfcp: close window with unblocked rport during rport gone")
> > 70369f8e15b2 ("zfcp: fix ELS/GS request&response length for hardware data router")
> > bd77befa5bcf ("zfcp: fix fc_host port_type with NPIV")
> 
> How should we proceed?
> Either also pull in the old patches (belatedly?) into 3.18.72,
> or maybe even drop all zfcp patches from 3.18.72 so zfcp effectively remains
> on 3.18.0 level which would also be OK with me.
> 
> Even if the partial zfcp stable patches including your latest 3.18.y
> longterm commit ("fix up s390 build error for 3.18") would make up a working
> zfcp, the stable subset does not seem optimal.

Can you send me a patch series of the fixed up patches that need to get
into 3.18-stable, if you think people are actually running this hardware
on that kernel?

I know I'm not :)

thanks,

greg k-h