Control: tags -1 + upstream
Hi,
On Wed, Apr 10, 2024 at 07:00:14PM +0200, Cyril Brulebois wrote:
> Cyril Brulebois <k...@debian.org> (2024-04-10):
> > Intermediate results based on upstream stable releases: v6.1.80 is good,
> > v6.1.81 is bad. Still ~200 commits to bisect.
>
> Final results:
>
> kibi@genova:~/hack/linux.git ((cf33e6ca12d81...)|BISECTING)$ git bisect
> bad
> cf33e6ca12d814e1be2263cb76960d0019d7fb94 is the first bad commit
> commit cf33e6ca12d814e1be2263cb76960d0019d7fb94
> Author: Mike Christie <michael.chris...@oracle.com>
> Date: Thu Dec 29 13:01:40 2022 -0600
>
> scsi: core: Add struct for args to execution functions
>
> [ Upstream commit d0949565811f0896c1c7e781ab2ad99d34273fdf ]
>
> Move the SCSI execution functions to use a struct for passing in
> optional
> args. This commit adds the new struct, temporarily converts
> scsi_execute()
> and scsi_execute_req() ands a new helper, scsi_execute_cmd(), which
> takes
> the scsi_exec_args struct.
>
> There should be no change in behavior. We no longer allow users to
> pass in
> any request->rq_flags value, but they were only passing in RQF_PM
> which we
> do support by allowing users to pass in the BLK_MQ_REQ flags used by
> blk_mq_alloc_request().
>
> Subsequent commits will convert scsi_execute() and scsi_execute_req()
> users
> to the new helpers then remove scsi_execute() and scsi_execute_req().
>
> Signed-off-by: Mike Christie <michael.chris...@oracle.com>
> Reviewed-by: Bart Van Assche <bvanass...@acm.org>
> Reviewed-by: Christoph Hellwig <h...@lst.de>
> Reviewed-by: John Garry <john.g.ga...@oracle.com>
> Signed-off-by: Martin K. Petersen <martin.peter...@oracle.com>
> Stable-dep-of: 321da3dc1f3c ("scsi: sd: usb_storage: uas: Access
> media prior to querying device properties")
> Signed-off-by: Sasha Levin <sas...@kernel.org>
>
> drivers/scsi/scsi_lib.c | 52
> ++++++++++++++++++++++------------------------
> include/scsi/scsi_device.h | 51
> ++++++++++++++++++++++++++++++++-------------
> 2 files changed, 62 insertions(+), 41 deletions(-)
>
>
> That's one of the 3 commits suggested by Diederik, good hunch.
>
> I know hindsight is always 100% but “There should be no change in
> behavior.”… :D
>
> Of course, since there are companion changes afterwards, it cannot be
> simply reverted on top of either v6.1.82 (Debian) or v6.1.84 (upstream).
>
>
> I'd appreciate if someone could carry the ball through the appropriate
> channels upstream.
Great, thanks a lot for your bisecting work!
Yes, if you prefer to not do the forwarding upstream (stable list, CC
to involved people + regression list), then I can try to take care of
it. Obviously the former would be great, as you are the finder and
have done all the work.
Regards,
Salvatore
