On Wed, Jun 30 2021 at 4:12P -0400, Martin Wilck <mwilck@xxxxxxxx> wrote: > On Di, 2021-06-29 at 14:23 -0700, Keith Busch wrote: > > On Tue, Jun 29, 2021 at 09:23:18PM +0200, Martin Wilck wrote: > > > On Di, 2021-06-29 at 14:59 +0200, Christoph Hellwig wrote: > > > > On Mon, Jun 28, 2021 at 04:57:33PM +0200, Martin Wilck wrote: > > > > > > > > > The sg_io-on-multipath code needs to answer the question "is > > > > > this a > > > > > path or a target error?". Therefore it calls blk_path_error(), > > > > > which > > > > > requires obtaining a blk_status_t first. But that's not > > > > > available > > > > > in > > > > > the sg_io code path. So how should I deal with this situation? > > > > > > > > Not by exporting random crap from the SCSI code. Helpful as always Christoph... ;) > > > So, you'd prefer inlining scsi_result_to_blk_status()? > > > > I don't think you need to. The only scsi_result_to_blk_status() > > caller > > is sg_io_to_blk_status(). That's already in the same file as > > scsi_result_to_blk_status() so no need to export it. You could even > > make > > it static. > > Thanks for your suggestion. I'd be lucky if this was true. But the most > important users of scsi_result_to_blk_status() are in scsi_lib.c > (scsi_io_completion_action(), scsi_io_completion_nz_result()). > > If I move scsi_result_to_blk_status() to vmlinux without exporting it, > it won't be available in the SCSI core any more, at least not with > CONFIG_SCSI=m. For what you're trying to accomplish with this patchset, you only need sg_io_to_blk_status() exported. So check with Martin and/or Bart on the best way to give sg_io_to_blk_status() access to the equivalent of your __scsi_result_to_blk_status() without exporting it. I'd start by just folding patches 1 and 2, fixing up the logic Dan Carpenter pointed ouit, and only exporting sg_io_to_blk_status(). Mike
