From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 667443D47AC for ; Tue, 10 Mar 2026 17:54:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773165297; cv=none; b=k+4HtIg6YQqBalWqyGvjNL1qU0WZUep89uqAfQ9pX0z27K8b7W1EiuFpghIBuVOKLEvnYSK8VQf5KfeCmaJFedvFAqkQucCO/UXoVR1QDbWrk1A6SowxMB3ZXovFKpPGPFyqmQB8I5x5RXkh6pDjgj4u1qmiLhJ6xo5pmB5ocBk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773165297; c=relaxed/simple; bh=SwJIA9MTxdZ8STOa+2dg+eURC0+yijgQo1QtJ+LnHiw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=FvMqPziqng/i4nOy+ZZTcYXOiUt5TJKP5A79fyIxesWhZ9lDxFqVL3g6cl9JDBC2C5e7o1rgMACILOPq2b+5yVbtnYk+Yrsza/6/m5+Te4xgTZhgwzs9qAdXdLxqvXh+iuTW762ZLeWl//KGhOq1eaFsEjbV6wtw663tCWv9tEw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=V3jNy6dv; arc=none smtp.client-ip=209.85.221.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="V3jNy6dv" Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-439f59dfda2so556565f8f.2 for ; Tue, 10 Mar 2026 10:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773165293; x=1773770093; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=qEnF/Lg25U18+ZKcj41EcZIOIb03fm6HJ1Ff4fvEotU=; b=V3jNy6dvVhKuTYRrpBi9+1OyGzaolT+AR1LXjNHavu87kH5nOzXLwG+fV05yejmWuw i8kibIDkgB/o2ixHDqQanQTC9SucE7aObO30M73GszZoSGVjsxVIruZDvsmHHj+Iiv6W rmBW4weBJ5yjYd+mGbV1X4o24a9mxNXZIlJizxAb+NwNpAGPEu9TcGuSmExktgPoYrw+ J6l1exm8q3ZDAvlj9KiuQyQrI6IIymLtGahqfOJhiGsJJZ7augcn35Zc8JoM/JzhBpxg +AtLdejy3XWBzj0FsZRzIF/D3aGYfJXOIE3B+kI+mT6YNsyZmT29lz51/KL6z8dV676S XKPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773165293; x=1773770093; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qEnF/Lg25U18+ZKcj41EcZIOIb03fm6HJ1Ff4fvEotU=; b=AnD68P6H3olpIDpcsE+QFzi/LcwpsAFhe2xwGbPayBxoLY3pzymP30zN9b2X/g5ycQ kxIZJqAH0vU+cxnoKWl5xBi8wHy6VCUM+Iuafofzl2Hy7E7oGCuNnuVB4/W+QkBRxDvg NykSv65JWRYKB24fpIaoZpe/cMnXhjsB2gXjHpSQcV6kX32iyc7paJOnNkLcgxwIOojP caIzz7qzVB1C7ib8wvBBiPpp3yNDJTQBCy5FOjHNT0e7dC48mLSQzyHPvQhTZEiLgZZb +KvPoGOm/TICvIjs18chWd2qy5kWQSFv9el6QmSU5IE4uqAlfAo3srzYvuTQQU4BZoFT Z6RA== X-Forwarded-Encrypted: i=1; AJvYcCVNhESgIfPEHp5z5hBqHTfXKQk7yd7q8Jn6T/ACiPb472wWx6WKUDcWWdC2B0Rsqr4EoB+m61piTHDdKJI=@vger.kernel.org X-Gm-Message-State: AOJu0Yx8OXyLHWXq1EhpG9Xv5K8cI+nrEa19gWzZGDbgRycqeZK2Mdt7 Ti9mJr0LVNqSS+u5LQf695pTxqLC99VwRZDefpwlHaAFeoLFOAxCXN+nTqUWFS9ZuQc= X-Gm-Gg: ATEYQzx3M4P0PLPlvVBwtXnMxcJLtB94FGHFEXPb3ecPAiF2TzdiHL+Aarf8iXiqbm5 1Wnk1LlTHt38VWh3ANW09H5Fz9RuWQhD5AzbzEbwSQcroaBPUeb0OMbqGOPzywKR9Q23OOzC4F1 Qh08QIBlEYNAZahfvZ9QEJv0dqaDJ/NtyyET2s2baY6NeDrliA/Uakuzj2/BkHhZxFqfqarRR+P l0WgAzXOnaw15at6n0ZoUJgNroDUNBxgkWv/MCW+FPl5Q+GcoiI+iSeRvRKlzP/5wEn4/wd9f2N kx5fPTWtooq0VBwDfu5YYKHVR0H/kSJVl+pNCZp05RLHbR4IZ74HcAxiJ0N0wHH/584OKbc78l3 LcW3MJwWAiY0kzubEfK5a7eKFS9mKUJDbbb4PUWh8bmEj69uwotuz3QN2ykzfmBdo+XEJbC4Bp9 TiQRmuaLTGYwgEzjHgV0A3L4DjyeHtCZOv/ilwkz9VMES3eRMoN00SLZkndrXA X-Received: by 2002:a05:600c:4f07:b0:485:3171:7845 with SMTP id 5b1f17b1804b1-48531717a94mr200528055e9.4.1773165292732; Tue, 10 Mar 2026 10:54:52 -0700 (PDT) Received: from ?IPV6:2001:a61:2a16:da01:fd99:79eb:2f5d:d346? ([2001:a61:2a16:da01:fd99:79eb:2f5d:d346]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48541b6f708sm126141845e9.11.2026.03.10.10.54.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2026 10:54:52 -0700 (PDT) Message-ID: <6b6a822c-4e49-4e80-ba57-57704e3c1307@suse.com> Date: Tue, 10 Mar 2026 18:54:51 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 5/8] scsi: scsi-multipath: Add basic ALUA support To: John Garry , hch@lst.de, kbusch@kernel.org, martin.petersen@oracle.com, james.bottomley@hansenpartnership.com, bmarzins@redhat.com Cc: jmeneghi@redhat.com, linux-nvme@lists.infradead.org, sagi@grimberg.me, axboe@fb.com, linux-scsi@vger.kernel.org, michael.christie@oracle.com, snitzer@kernel.org, dm-devel@lists.linux.dev, linux-kernel@vger.kernel.org, nilay@linux.ibm.com References: <20260310114925.1222263-1-john.g.garry@oracle.com> <20260310114925.1222263-6-john.g.garry@oracle.com> <3178d371-7a4c-4d07-885c-42496190f242@oracle.com> Content-Language: en-US From: Hannes Reinecke In-Reply-To: <3178d371-7a4c-4d07-885c-42496190f242@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 3/10/26 16:52, John Garry wrote: > On 10/03/2026 13:23, Hannes Reinecke wrote: >>>       sdev->scsi_mpath_dev->index = ida_alloc(&scsi_mpath_head->ida, >>> GFP_KERNEL); >>>       if (sdev->scsi_mpath_dev->index < 0) { >>>           ret = sdev->scsi_mpath_dev->index; >>> diff --git a/include/scsi/scsi_multipath.h b/include/scsi/ >>> scsi_multipath.h >>> index 2011447f482d6..7c7ee2fb7def7 100644 >>> --- a/include/scsi/scsi_multipath.h >>> +++ b/include/scsi/scsi_multipath.h >>> @@ -38,6 +38,9 @@ struct scsi_mpath_device { >>>       int            index; >>>       atomic_t        nr_active; >>>       struct scsi_mpath_head    *scsi_mpath_head; >>> +    int            alua_state; >>> +    int            alua_pref; >>> +    int            alua_valid_states; >>>       char            device_id_str[SCSI_MPATH_DEVICE_ID_LEN]; >>>   }; >> >> Is there a specific reason why this cannot be in the generic code? > > Sure, it's possible.... > >> After all, if the device reports anything else than ALUA_STATE_OPTIMAL >> or ALUA_STATE_ACTIVE I/O will fail, irrespective of multipath being >> active. >> >> I would love to see that in the generic SCSI code, independent on this >> patchset. It would allow us to simplify the device handler code, too, >> as then device handler really would only be required for explicit >> ALUA. (And could be ignored for scsi-multipathing). > > Right, so you would like to see alua_port_group management in a core > ALUA driver as well, right? > > If yes, to repeat, it is hard to separate the DH stuff out...but I can > try. Examples I would need to deal with (and associated handling): > > - alua_port_group members like dh_list > - alua_dh_data memebers like init_error > - everything in alua_queue_data > While the port group handling looks nice (and there certainly is a certain neatness to it), it kinda assumes too much about the internal layout of the hierarchy within the target. Technically, a target is only required to provide a device identifier, and a group id (such that you can match with RTPG output). However, you have no idea which of the various device IDs are part of the same enclosure; that information is not required to be present. So you cannot assume that group ID A reported from device X is the same group as group ID A reported from device Y. The only reliable way is to check with the RTPG output, as that contains all device identifiers for the defined group IDs. But: caching RTPG output is problematic (as it'll change whenever a path state change happens), and it'll need to contain references to the SCSI devices, introducing all sorts of locking issues and race conditions. So probably I would not go down that way (at least initially), but rather read RTPG during scanning, and set the values directly in the scsi device. We then need to re-read that information whenever we hit a relevant sense code, but arguably we'll need to do that 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