Following on the back of the ALUA support for native SCSI multipath
proposal at [0], this is an attempt to move to a SCSI core ALUA driver.

Essentially this series move the bulk of the ALUA handling from
scsi_dh_alua.c to a core driver. We still need to support ALUA for DH, so
the scsi_dh_alua.c is still responsible for driving ALUA support and the
SCSI core ALUA driver just provides a set of library functions for that.

The SCSI core ALUA driver also provides implicit ALUA support for no DH,
like when we would be native SCSI multipath.

This series is just really an RFC quality work and its purpose is
to decide on the direction of ALUA support for native SCSI multipath.

I think that this work is a real regression possibility for
dm-multipath, so we need to be careful.

[0] https://lore.kernel.org/linux-scsi/20260310114925.1222263-1-john.g.garry@oracle.com/T/#m9c054433076812dff464d0e3b50a00620cfe0af1

John Garry (13):
  scsi: scsi_dh_alua: Delete alua_port_group
  scsi: alua: Create a core ALUA driver
  scsi: alua: Add scsi_alua_rtpg()
  scsi: alua: Add scsi_alua_stpg()
  scsi: alua: Add scsi_alua_tur()
  scsi: alua: Add scsi_alua_rtpg_run()
  scsi: alua: Add scsi_alua_stpg_run()
  scsi: alua: Add scsi_alua_check_tpgs()
  scsi: alua: Add scsi_alua_handle_state_transition()
  scsi: alua: Add scsi_alua_prep_fn()
  scsi: alua: Add scsi_device_alua_implicit()
  scsi: scsi_dh_alua: Switch to use core support
  scsi: core: Add implicit ALUA support

 drivers/scsi/Kconfig                       |   10 +-
 drivers/scsi/Makefile                      |    1 +
 drivers/scsi/device_handler/Kconfig        |    1 +
 drivers/scsi/device_handler/scsi_dh_alua.c | 1003 ++------------------
 drivers/scsi/scsi.c                        |    7 +
 drivers/scsi/scsi_alua.c                   |  748 +++++++++++++++
 drivers/scsi/scsi_error.c                  |    7 +
 drivers/scsi/scsi_lib.c                    |    7 +
 drivers/scsi/scsi_scan.c                   |    6 +
 drivers/scsi/scsi_sysfs.c                  |    7 +-
 include/scsi/scsi_alua.h                   |  103 ++
 include/scsi/scsi_device.h                 |    1 +
 12 files changed, 977 insertions(+), 924 deletions(-)
 create mode 100644 drivers/scsi/scsi_alua.c
 create mode 100644 include/scsi/scsi_alua.h

-- 
2.43.5

On Tue, Mar 17, 2026 at 12:06:50PM +0000, John Garry wrote:
> Following on the back of the ALUA support for native SCSI multipath
> proposal at [0], this is an attempt to move to a SCSI core ALUA driver.
> 
> Essentially this series move the bulk of the ALUA handling from
> scsi_dh_alua.c to a core driver. We still need to support ALUA for DH, so
> the scsi_dh_alua.c is still responsible for driving ALUA support and the
> SCSI core ALUA driver just provides a set of library functions for that.
> 
> The SCSI core ALUA driver also provides implicit ALUA support for no DH,
> like when we would be native SCSI multipath.
> 
> This series is just really an RFC quality work and its purpose is
> to decide on the direction of ALUA support for native SCSI multipath.
> 
> I think that this work is a real regression possibility for
> dm-multipath, so we need to be careful.

At the risk of showing just how limited my SCSI knowledge is, I need to
ask, Is any of this actually necessary to get native scsi multipath
working with Implicit ALUA?

If the goal is to limit this to IMPLICT ALUA only, I was expecting that
you could just leave the scsi_dh_alua code completely alone. If native
scsi multipathing didn't disable the device handler, it seemed that this
would basically just work. With the device handler attached, when the
array updates the ALUA state, that should, at least I believe, trigger a
unit attention that will fire off a RTPG command. That should update the
sdev->access_state, which the multipath code could use to pick the
correct path. Right? What am I missing here? Is this just a parallel
exercise to overhaul the ALUA code?

-Ben

> 
> [0] https://lore.kernel.org/linux-scsi/20260310114925.1222263-1-john.g.garry@oracle.com/T/#m9c054433076812dff464d0e3b50a00620cfe0af1
> 
> John Garry (13):
>   scsi: scsi_dh_alua: Delete alua_port_group
>   scsi: alua: Create a core ALUA driver
>   scsi: alua: Add scsi_alua_rtpg()
>   scsi: alua: Add scsi_alua_stpg()
>   scsi: alua: Add scsi_alua_tur()
>   scsi: alua: Add scsi_alua_rtpg_run()
>   scsi: alua: Add scsi_alua_stpg_run()
>   scsi: alua: Add scsi_alua_check_tpgs()
>   scsi: alua: Add scsi_alua_handle_state_transition()
>   scsi: alua: Add scsi_alua_prep_fn()
>   scsi: alua: Add scsi_device_alua_implicit()
>   scsi: scsi_dh_alua: Switch to use core support
>   scsi: core: Add implicit ALUA support
> 
>  drivers/scsi/Kconfig                       |   10 +-
>  drivers/scsi/Makefile                      |    1 +
>  drivers/scsi/device_handler/Kconfig        |    1 +
>  drivers/scsi/device_handler/scsi_dh_alua.c | 1003 ++------------------
>  drivers/scsi/scsi.c                        |    7 +
>  drivers/scsi/scsi_alua.c                   |  748 +++++++++++++++
>  drivers/scsi/scsi_error.c                  |    7 +
>  drivers/scsi/scsi_lib.c                    |    7 +
>  drivers/scsi/scsi_scan.c                   |    6 +
>  drivers/scsi/scsi_sysfs.c                  |    7 +-
>  include/scsi/scsi_alua.h                   |  103 ++
>  include/scsi/scsi_device.h                 |    1 +
>  12 files changed, 977 insertions(+), 924 deletions(-)
>  create mode 100644 drivers/scsi/scsi_alua.c
>  create mode 100644 include/scsi/scsi_alua.h
> 
> -- 
> 2.43.5

On 22/03/2026 17:37, Benjamin Marzinski wrote:
>> I think that this work is a real regression possibility for
>> dm-multipath, so we need to be careful.
> At the risk of showing just how limited my SCSI knowledge is, I need to
> ask, Is any of this actually necessary to get native scsi multipath
> working with Implicit ALUA?
> 
> If the goal is to limit this to IMPLICT ALUA only, I was expecting that
> you could just leave the scsi_dh_alua code completely alone. If native
> scsi multipathing didn't disable the device handler, it seemed that this
> would basically just work. With the device handler attached,

We only get the scsi_dh_activate() -> alua_activate() call from 
dm-mpath.c, and that callchain could not happen for native SCSI 
multipath. But, yes, we do the alua_rtpg_queue() call from a rescan, but 
we should be checking if the path is available first (and not rely on a 
rescan).

> when the
> array updates the ALUA state, that should, at least I believe, trigger a
> unit attention that will fire off a RTPG command. That should update the
> sdev->access_state, which the multipath code could use to pick the
> correct path. Right? What am I missing here?
> Is this just a parallel
> exercise to overhaul the ALUA code?

The SCSI community would rather not see more usage for device handlers.

How we then get ALUA support for native SCSI multipath is the question. 
My original series just really duplicated the scsi_dh_alua.c RTPG 
support for native SCSI multipath into a limited "core" driver. Hannes 
thinks that a core ALUA driver to also support DH would be better 
(IIUC), which I am attempting in this series. I will re-iterate that I 
would rather not touch scsi_dh_alua.c, unless the changes are simple and 
obvious(ly correct).

Thanks,
John

On Mon, Mar 23, 2026 at 09:57:15AM +0000, John Garry wrote:
> On 22/03/2026 17:37, Benjamin Marzinski wrote:
> > > I think that this work is a real regression possibility for
> > > dm-multipath, so we need to be careful.
> > At the risk of showing just how limited my SCSI knowledge is, I need to
> > ask, Is any of this actually necessary to get native scsi multipath
> > working with Implicit ALUA?
> > 
> > If the goal is to limit this to IMPLICT ALUA only, I was expecting that
> > you could just leave the scsi_dh_alua code completely alone. If native
> > scsi multipathing didn't disable the device handler, it seemed that this
> > would basically just work. With the device handler attached,
> 
> We only get the scsi_dh_activate() -> alua_activate() call from dm-mpath.c,
> and that callchain could not happen for native SCSI multipath. But, yes, we
> do the alua_rtpg_queue() call from a rescan, but we should be checking if
> the path is available first (and not rely on a rescan).
> 
> > when the
> > array updates the ALUA state, that should, at least I believe, trigger a
> > unit attention that will fire off a RTPG command. That should update the
> > sdev->access_state, which the multipath code could use to pick the
> > correct path. Right? What am I missing here?
> > Is this just a parallel
> > exercise to overhaul the ALUA code?
> 
> The SCSI community would rather not see more usage for device handlers.

I guess it depends on what you mean by using a device handler. I don't
think the Native SCSI multipath code would need to actively interface
with the device handler code to support IMPLICIT ALUA. IIUC, looking at
sdev->access_state should be enough to pick the correct path. If that's
right, then it doesn't really matter to the multipath code whether this
is getting updated in scsi_dh_alua.c or scsi_alua.c. So refactoring the
scsi ALUA handling code seems orthogonal to the adding IMPLICIT ALUA
support to the Native scsi multipathing code.

-Ben

> 
> How we then get ALUA support for native SCSI multipath is the question. My
> original series just really duplicated the scsi_dh_alua.c RTPG support for
> native SCSI multipath into a limited "core" driver. Hannes thinks that a
> core ALUA driver to also support DH would be better (IIUC), which I am
> attempting in this series. I will re-iterate that I would rather not touch
> scsi_dh_alua.c, unless the changes are simple and obvious(ly correct).
> 
> Thanks,
> John

On 23/03/2026 16:25, Benjamin Marzinski wrote:
>>> If the goal is to limit this to IMPLICT ALUA only, I was expecting that
>>> you could just leave the scsi_dh_alua code completely alone. If native
>>> scsi multipathing didn't disable the device handler, it seemed that this
>>> would basically just work. With the device handler attached,
>> We only get the scsi_dh_activate() -> alua_activate() call from dm-mpath.c,
>> and that callchain could not happen for native SCSI multipath. But, yes, we
>> do the alua_rtpg_queue() call from a rescan, but we should be checking if
>> the path is available first (and not rely on a rescan).
>>
>>> when the
>>> array updates the ALUA state, that should, at least I believe, trigger a
>>> unit attention that will fire off a RTPG command. That should update the
>>> sdev->access_state, which the multipath code could use to pick the
>>> correct path. Right? What am I missing here?
>>> Is this just a parallel
>>> exercise to overhaul the ALUA code?
>> The SCSI community would rather not see more usage for device handlers.
> I guess it depends on what you mean by using a device handler.

My meaning is anything in drivers/scsi/device_handler

> I don't
> think the Native SCSI multipath code would need to actively interface
> with the device handler code to support IMPLICIT ALUA. IIUC, looking at
> sdev->access_state should be enough to pick the correct path.

We also have the functionality from alua_check_sense() to consider.

> If that's
> right, then it doesn't really matter to the multipath code whether this
> is getting updated in scsi_dh_alua.c or scsi_alua.c. 
 > So refactoring the> scsi ALUA handling code seems orthogonal to the 
adding IMPLICIT ALUA
> support to the Native scsi multipathing code.

DH support is considered legacy. As I understand, DH was originally 
added for early explicit ALUA support and other DH-related standards, 
and explicit ALUA is considered flawed. So that is why Martin/Hannes 
doesn't want to see more users (for DH). This is my understanding.

Now I a need to try to separate out the ALUA parts we need from 
scsi_dh_alua.c into SCSI core code. I'll talk to Martin about this 
approach again.

Thanks,
John

On Mon, Mar 23, 2026 at 06:04:54PM +0000, John Garry wrote:
> On 23/03/2026 16:25, Benjamin Marzinski wrote:
> > > > If the goal is to limit this to IMPLICT ALUA only, I was expecting that
> > > > you could just leave the scsi_dh_alua code completely alone. If native
> > > > scsi multipathing didn't disable the device handler, it seemed that this
> > > > would basically just work. With the device handler attached,
> > > We only get the scsi_dh_activate() -> alua_activate() call from dm-mpath.c,
> > > and that callchain could not happen for native SCSI multipath. But, yes, we
> > > do the alua_rtpg_queue() call from a rescan, but we should be checking if
> > > the path is available first (and not rely on a rescan).
> > > 
> > > > when the
> > > > array updates the ALUA state, that should, at least I believe, trigger a
> > > > unit attention that will fire off a RTPG command. That should update the
> > > > sdev->access_state, which the multipath code could use to pick the
> > > > correct path. Right? What am I missing here?
> > > > Is this just a parallel
> > > > exercise to overhaul the ALUA code?
> > > The SCSI community would rather not see more usage for device handlers.
> > I guess it depends on what you mean by using a device handler.
> 
> My meaning is anything in drivers/scsi/device_handler
> 
> > I don't
> > think the Native SCSI multipath code would need to actively interface
> > with the device handler code to support IMPLICIT ALUA. IIUC, looking at
> > sdev->access_state should be enough to pick the correct path.
> 
> We also have the functionality from alua_check_sense() to consider.

But the multipath code won't call that directly. Right now, the scsi
device handler will, at least for every scsi device except ones using
the Native Multipath code. My point is that this would just work, except
that the Native Multipath code goes out of its way to break it, by
disabling device handlers, and I don't really see the point of disabling
something that every other scsi device, multipathed or not, has enabled.
It's not like leaving it enabled makes it any harder to move the
implicit ALUA support from the device handler to the generic scsi code,
if that's the goal, since the Native Multipath code doesn't care who is
issuing those rtpgs and updating the state.

I guess this is more of a question for Hannes. Is the goal to turn off
automatic device handler attachment in general, and go back to making
dm-multipath attach device handlers to the scsi devices it is using? If
not, then I don't see any reason to have the Native Multipath code
disable it. If it allowed device handlers to get attached, these two
developement efforts (native scsi multipath and refactoring the alua
support) could go on in parallel.

Or am I missing something here?
-Ben

> 
> > If that's
> > right, then it doesn't really matter to the multipath code whether this
> > is getting updated in scsi_dh_alua.c or scsi_alua.c.
> > So refactoring the> scsi ALUA handling code seems orthogonal to the adding
> IMPLICIT ALUA
> > support to the Native scsi multipathing code.
> 
> DH support is considered legacy. As I understand, DH was originally added
> for early explicit ALUA support and other DH-related standards, and explicit
> ALUA is considered flawed. So that is why Martin/Hannes doesn't want to see
> more users (for DH). This is my understanding.
> 
> Now I a need to try to separate out the ALUA parts we need from
> scsi_dh_alua.c into SCSI core code. I'll talk to Martin about this approach
> again.
> 
> Thanks,
> John

On 23/03/2026 19:45, Benjamin Marzinski wrote:
>>> I don't
>>> think the Native SCSI multipath code would need to actively interface
>>> with the device handler code to support IMPLICIT ALUA. IIUC, looking at
>>> sdev->access_state should be enough to pick the correct path.
>> We also have the functionality from alua_check_sense() to consider.
> But the multipath code won't call that directly. Right now, the scsi
> device handler will, at least for every scsi device except ones using
> the Native Multipath code. My point is that this would just work, except
> that the Native Multipath code goes out of its way to break it, by
> disabling device handlers, and I don't really see the point of disabling
> something that every other scsi device, multipathed or not, has enabled.
> It's not like leaving it enabled makes it any harder to move the
> implicit ALUA support from the device handler to the generic scsi code,
> if that's the goal, since the Native Multipath code doesn't care who is
> issuing those rtpgs and updating the state.
> 
> I guess this is more of a question for Hannes. Is the goal to turn off
> automatic device handler attachment in general, and go back to making
> dm-multipath attach device handlers to the scsi devices it is using?

I'm not answering for Hannes, but I don't think that is the goal.

> If
> not, then I don't see any reason to have the Native Multipath code
> disable it. 

It was just disabled it as we now had another method in the scsi core 
code to get ALUA info.

My plan would be - based on this series - to not attach DH just when 
using native SCSI multipath for a device.

> If it allowed device handlers to get attached, these two
> developement efforts (native scsi multipath and refactoring the alua
> support) could go on in parallel.
> 
> Or am I missing something here?

It just seems to be about this DH stuff is that there is bad history 
there and no more users are wanted.

But now I am getting bogged down in this ALUA support because of that, 
which I feared would happen.

Thanks,
John

On Tue, Mar 24, 2026 at 10:57:20AM +0000, John Garry wrote:
> On 23/03/2026 19:45, Benjamin Marzinski wrote:
> > > > I don't
> > > > think the Native SCSI multipath code would need to actively interface
> > > > with the device handler code to support IMPLICIT ALUA. IIUC, looking at
> > > > sdev->access_state should be enough to pick the correct path.
> > > We also have the functionality from alua_check_sense() to consider.
> > But the multipath code won't call that directly. Right now, the scsi
> > device handler will, at least for every scsi device except ones using
> > the Native Multipath code. My point is that this would just work, except
> > that the Native Multipath code goes out of its way to break it, by
> > disabling device handlers, and I don't really see the point of disabling
> > something that every other scsi device, multipathed or not, has enabled.
> > It's not like leaving it enabled makes it any harder to move the
> > implicit ALUA support from the device handler to the generic scsi code,
> > if that's the goal, since the Native Multipath code doesn't care who is
> > issuing those rtpgs and updating the state.
> > 
> > I guess this is more of a question for Hannes. Is the goal to turn off
> > automatic device handler attachment in general, and go back to making
> > dm-multipath attach device handlers to the scsi devices it is using?
> 
> I'm not answering for Hannes, but I don't think that is the goal.
> 
> > If
> > not, then I don't see any reason to have the Native Multipath code
> > disable it.
> 
> It was just disabled it as we now had another method in the scsi core code
> to get ALUA info.
> 
> My plan would be - based on this series - to not attach DH just when using
> native SCSI multipath for a device.
> 
> > If it allowed device handlers to get attached, these two
> > developement efforts (native scsi multipath and refactoring the alua
> > support) could go on in parallel.
> > 
> > Or am I missing something here?
> 
> It just seems to be about this DH stuff is that there is bad history there
> and no more users are wanted.

Just to be clear, if the idea was that the Native Multipath code
shouldn't use include/scsi/scsi_dh.h, I completely agree with that. But
I don't see why it can't make use of the results of the existing
implicit ALUA support, since IIUC it doesn't need the scsi_dh interface
to do that. That shouldn't interfere with any refactoring that people
want to do of how the scsi layer actually handles ALUA support. Again,
this is more for Hannes than you, John.

-Ben

> 
> But now I am getting bogged down in this ALUA support because of that, which
> I feared would happen.
> 
> Thanks,
> John

On 3/24/26 14:58, Benjamin Marzinski wrote:
> On Tue, Mar 24, 2026 at 10:57:20AM +0000, John Garry wrote:
>> On 23/03/2026 19:45, Benjamin Marzinski wrote:
>>>>> I don't
>>>>> think the Native SCSI multipath code would need to actively interface
>>>>> with the device handler code to support IMPLICIT ALUA. IIUC, looking at
>>>>> sdev->access_state should be enough to pick the correct path.
>>>> We also have the functionality from alua_check_sense() to consider.
>>> But the multipath code won't call that directly. Right now, the scsi
>>> device handler will, at least for every scsi device except ones using
>>> the Native Multipath code. My point is that this would just work, except
>>> that the Native Multipath code goes out of its way to break it, by
>>> disabling device handlers, and I don't really see the point of disabling
>>> something that every other scsi device, multipathed or not, has enabled.
>>> It's not like leaving it enabled makes it any harder to move the
>>> implicit ALUA support from the device handler to the generic scsi code,
>>> if that's the goal, since the Native Multipath code doesn't care who is
>>> issuing those rtpgs and updating the state.
>>>
>>> I guess this is more of a question for Hannes. Is the goal to turn off
>>> automatic device handler attachment in general, and go back to making
>>> dm-multipath attach device handlers to the scsi devices it is using?
>>
>> I'm not answering for Hannes, but I don't think that is the goal.
>>
>>> If
>>> not, then I don't see any reason to have the Native Multipath code
>>> disable it.
>>
>> It was just disabled it as we now had another method in the scsi core code
>> to get ALUA info.
>>
>> My plan would be - based on this series - to not attach DH just when using
>> native SCSI multipath for a device.
>>
>>> If it allowed device handlers to get attached, these two
>>> developement efforts (native scsi multipath and refactoring the alua
>>> support) could go on in parallel.
>>>
>>> Or am I missing something here?
>>
>> It just seems to be about this DH stuff is that there is bad history there
>> and no more users are wanted.
> 
> Just to be clear, if the idea was that the Native Multipath code
> shouldn't use include/scsi/scsi_dh.h, I completely agree with that. But
> I don't see why it can't make use of the results of the existing
> implicit ALUA support, since IIUC it doesn't need the scsi_dh interface
> to do that. That shouldn't interfere with any refactoring that people
> want to do of how the scsi layer actually handles ALUA support. Again,
> this is more for Hannes than you, John.
> 
Oh, it's not that it technically cannot use it.
It's just a design thingie: my idea for the native SCSI multipathing
is that it should be _simple_. There really is not point (and, in fact,
was one of the main motivators of this idea) to re-implement every nook
and crannie from dm-multipathing.
SCSI multipathing should only handle implicit ALUA, and leave every
other functionality to dm-multipathing.

And on the other side, I always found it completely irritating that
one had to enable multipathing in order to get ALUA support (ie
being able to figure out the ALUA state). The ALUA state is a property
of the LUN, and the system has to react on that one. It really doesn't
matter whether the system has multipathing enabled; if the LUN is in
ALUA Standby state we cannot send I/O, full stop.

And that's what we're trying to achieve here; move implicit alua support
from SCSI DH into the SCSI core, and leave SCSI DH to handle explicit
ALUA support.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.com                               +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich

On 24/03/2026 13:58, Benjamin Marzinski wrote:
>>> If it allowed device handlers to get attached, these two
>>> developement efforts (native scsi multipath and refactoring the alua
>>> support) could go on in parallel.
>>>
>>> Or am I missing something here?
>> It just seems to be about this DH stuff is that there is bad history there
>> and no more users are wanted.
> Just to be clear, if the idea was that the Native Multipath code
> shouldn't use include/scsi/scsi_dh.h, I completely agree with that. But
> I don't see why it can't make use of the results of the existing
> implicit ALUA support, since IIUC it doesn't need the scsi_dh interface
> to do that.

We would need something like the following to ensure that DH ALUA is 
present to update sdev access_state:

@@ -80,6 +80,7 @@ config SCSI_MULTIPATH
         bool "SCSI multipath support"
         depends on SCSI_MOD
         select LIBMULTIPATH
+       select SCSI_DH_ALUA
         help
           This option enables support for native SCSI multipath support for
           SCSI host.

And that is even enough, as Kconfigs should only specify build requirements.

We really should be also calling something like scsi_dh_attach() for 
scsi multipath to ensure that DH is attached (and running to update 
sdev->access_state).

And I am not sure how the dh alua module is even autoloaded. I think 
that on my ubuntu machine the multipath-tools.service does it - 
something like this would not be nice for native SCSI multipath support.

  That shouldn't interfere with any refactoring that people
> want to do of how the scsi layer actually handles ALUA support. Again,
> this is more for Hannes than you, John.

Thanks,
John

On 3/24/26 16:12, John Garry wrote:
> On 24/03/2026 13:58, Benjamin Marzinski wrote:
>>>> If it allowed device handlers to get attached, these two
>>>> developement efforts (native scsi multipath and refactoring the alua
>>>> support) could go on in parallel.
>>>>
>>>> Or am I missing something here?
>>> It just seems to be about this DH stuff is that there is bad history 
>>> there
>>> and no more users are wanted.
>> Just to be clear, if the idea was that the Native Multipath code
>> shouldn't use include/scsi/scsi_dh.h, I completely agree with that. But
>> I don't see why it can't make use of the results of the existing
>> implicit ALUA support, since IIUC it doesn't need the scsi_dh interface
>> to do that.
> 
> We would need something like the following to ensure that DH ALUA is 
> present to update sdev access_state:
> 
> @@ -80,6 +80,7 @@ config SCSI_MULTIPATH
>          bool "SCSI multipath support"
>          depends on SCSI_MOD
>          select LIBMULTIPATH
> +       select SCSI_DH_ALUA
>          help
>            This option enables support for native SCSI multipath support 
> for
>            SCSI host.
> 
> And that is even enough, as Kconfigs should only specify build 
> requirements.
> 
> We really should be also calling something like scsi_dh_attach() for 
> scsi multipath to ensure that DH is attached (and running to update 
> sdev->access_state).
> 
> And I am not sure how the dh alua module is even autoloaded. I think 
> that on my ubuntu machine the multipath-tools.service does it - 
> something like this would not be nice for native SCSI multipath support.
> 
Gnaa. But then we don't need this patchset at all.
Main point was that we _do not_ need to hook into scsi dh for implicit
ALUA.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.com                               +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich

On 26/03/2026 10:19, Hannes Reinecke wrote:
>> @@ -80,6 +80,7 @@ config SCSI_MULTIPATH
>>          bool "SCSI multipath support"
>>          depends on SCSI_MOD
>>          select LIBMULTIPATH
>> +       select SCSI_DH_ALUA
>>          help
>>            This option enables support for native SCSI multipath 
>> support for
>>            SCSI host.
>>
>> And that is even enough, as Kconfigs should only specify build 
>> requirements.
>>
>> We really should be also calling something like scsi_dh_attach() for 
>> scsi multipath to ensure that DH is attached (and running to update 
>> sdev->access_state).
>>
>> And I am not sure how the dh alua module is even autoloaded. I think 
>> that on my ubuntu machine the multipath-tools.service does it - 
>> something like this would not be nice for native SCSI multipath support.
>>
> Gnaa. But then we don't need this patchset at all.
> Main point was that we _do not_ need to hook into scsi dh for implicit
> ALUA.

But again I don't think that this is good enough. Native SCSI 
multipathing will read sdev->access_state to know ALUA state. We can't 
just rely on dh alua module running and doing what we need to know that 
this value is valid. AFAICS, dm mpath relies on dh alua module to even 
work at all:

device-mapper: table: 252:1: multipath: error attaching hardware
handler (-EINVAL)

At this point I am more inclined to just have a small SCSI core ALUA 
support for implicit ALUA, and allow scsi_dh_alua.c reuse functions from 
that but not use sdev->alua structure, like in this series - trying that 
is turning into a mess, I am finding.

Thanks,
John

On 3/26/26 13:16, John Garry wrote:
> On 26/03/2026 10:19, Hannes Reinecke wrote:
>>> @@ -80,6 +80,7 @@ config SCSI_MULTIPATH
>>>          bool "SCSI multipath support"
>>>          depends on SCSI_MOD
>>>          select LIBMULTIPATH
>>> +       select SCSI_DH_ALUA
>>>          help
>>>            This option enables support for native SCSI multipath 
>>> support for
>>>            SCSI host.
>>>
>>> And that is even enough, as Kconfigs should only specify build 
>>> requirements.
>>>
>>> We really should be also calling something like scsi_dh_attach() for 
>>> scsi multipath to ensure that DH is attached (and running to update 
>>> sdev->access_state).
>>>
>>> And I am not sure how the dh alua module is even autoloaded. I think 
>>> that on my ubuntu machine the multipath-tools.service does it - 
>>> something like this would not be nice for native SCSI multipath support.
>>>
>> Gnaa. But then we don't need this patchset at all.
>> Main point was that we _do not_ need to hook into scsi dh for implicit
>> ALUA.
> 
> But again I don't think that this is good enough. Native SCSI 
> multipathing will read sdev->access_state to know ALUA state. We can't 
> just rely on dh alua module running and doing what we need to know that 
> this value is valid. AFAICS, dm mpath relies on dh alua module to even 
> work at all:
> 
> device-mapper: table: 252:1: multipath: error attaching hardware
> handler (-EINVAL)
> 
> At this point I am more inclined to just have a small SCSI core ALUA 
> support for implicit ALUA, and allow scsi_dh_alua.c reuse functions from 
> that but not use sdev->alua structure, like in this series - trying that 
> is turning into a mess, I am finding.
> 
... where one finds himself inclined to think: 'told you so' :-)

And really, the SCSI alua handling doesn't need to be precise, in the
sense that the state is always up-to-date. It should be sufficient to
read the state once during startup, and then resend RTPG whenever we
get a sense code indicating that the ALUA state doesn't match.
We will be missing any changes between non-optimized and optimized,
but they are meaningless for the SCSI core anyway.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.com                               +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich

On Tue, Mar 24, 2026 at 03:12:38PM +0000, John Garry wrote:
> On 24/03/2026 13:58, Benjamin Marzinski wrote:
> > > > If it allowed device handlers to get attached, these two
> > > > developement efforts (native scsi multipath and refactoring the alua
> > > > support) could go on in parallel.
> > > > 
> > > > Or am I missing something here?
> > > It just seems to be about this DH stuff is that there is bad history there
> > > and no more users are wanted.
> > Just to be clear, if the idea was that the Native Multipath code
> > shouldn't use include/scsi/scsi_dh.h, I completely agree with that. But
> > I don't see why it can't make use of the results of the existing
> > implicit ALUA support, since IIUC it doesn't need the scsi_dh interface
> > to do that.
> 
> We would need something like the following to ensure that DH ALUA is present
> to update sdev access_state:
> 
> @@ -80,6 +80,7 @@ config SCSI_MULTIPATH
>         bool "SCSI multipath support"
>         depends on SCSI_MOD
>         select LIBMULTIPATH
> +       select SCSI_DH_ALUA
>         help
>           This option enables support for native SCSI multipath support for
>           SCSI host.

DM_MULTIPATH doesn't force the device handlers to be built. You just
don't have their support if they aren't there. Granted, it does make
sure that if they are built, you can't build dm-multipath directly into
the kernel, if the device handlers are built as modules.

> 
> And that is even enough, as Kconfigs should only specify build requirements.
> 
> We really should be also calling something like scsi_dh_attach() for scsi
> multipath to ensure that DH is attached (and running to update
> sdev->access_state).

That isn't necessary. If there is an alua device handler, kernel will
auto-attach it to any device that supports alua (see scsi_dh_add_device
and scsi_dh_find_driver). DM-multipath's calling of scsi_dh_attach() is
mostly a historical relic.

> And I am not sure how the dh alua module is even autoloaded. I think that on
> my ubuntu machine the multipath-tools.service does it - something like this
> would not be nice for native SCSI multipath support.

Fair point. Depending on how the kernel is built, there could be system
configuration work that needs to happen if implicit alua support
wasn't in the generic scsi code. But as far as the kernel code goes, I
still see them as parallel efforts. 

-Ben

>  That shouldn't interfere with any refactoring that people
> > want to do of how the scsi layer actually handles ALUA support. Again,
> > this is more for Hannes than you, John.
> 
> Thanks,
> John

On 24/03/2026 15:48, Benjamin Marzinski wrote:
>> We would need something like the following to ensure that DH ALUA is present
>> to update sdev access_state:
>>
>> @@ -80,6 +80,7 @@ config SCSI_MULTIPATH
>>          bool "SCSI multipath support"
>>          depends on SCSI_MOD
>>          select LIBMULTIPATH
>> +       select SCSI_DH_ALUA
>>          help
>>            This option enables support for native SCSI multipath support for
>>            SCSI host.
> DM_MULTIPATH doesn't force the device handlers to be built. You just
> don't have their support if they aren't there. Granted, it does make
> sure that if they are built, you can't build dm-multipath directly into
> the kernel, if the device handlers are built as modules.

Note that dm-mpath does not even work without DH ALUA module:

device-mapper: table: 252:1: multipath: error attaching hardware
handler (-EINVAL)

> 
>> And that is even enough, as Kconfigs should only specify build requirements.
>>
>> We really should be also calling something like scsi_dh_attach() for scsi
>> multipath to ensure that DH is attached (and running to update
>> sdev->access_state).
> That isn't necessary. If there is an alua device handler, kernel will
> auto-attach it to any device that supports alua (see scsi_dh_add_device
> and scsi_dh_find_driver). DM-multipath's calling of scsi_dh_attach() is
> mostly a historical relic.
> 

We still need to know that DH is attached to know that whatever is in 
sdev->access_state is valid for scsi multipath.

>> And I am not sure how the dh alua module is even autoloaded. I think that on
>> my ubuntu machine the multipath-tools.service does it - something like this
>> would not be nice for native SCSI multipath support.
> Fair point. Depending on how the kernel is built, there could be system
> configuration work that needs to happen if implicit alua support
> wasn't in the generic scsi code. But as far as the kernel code goes, I
> still see them as parallel efforts.

I see what you are saying, I'll defer to Martin/Hannes on this.

Thanks,
John