Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp2465517pxb; Tue, 13 Apr 2021 02:33:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxenKZCddcY6bm3svLSEMzmXANffE52vSqEZJcFzmuZc3hK2JbmBIrXIA5Xqo15ociiuD0U X-Received: by 2002:a05:6a00:706:b029:217:9e8d:f9cc with SMTP id 6-20020a056a000706b02902179e8df9ccmr28975386pfl.1.1618306404490; Tue, 13 Apr 2021 02:33:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618306404; cv=none; d=google.com; s=arc-20160816; b=aXnhBytlXs/l4N76xQQNv2na+/1jgyqSJ8/QOUmNA+cyatEa94IU8k0wVNjka0ZZhF Vv+oaM2dGeQAYK4TFMmVWTLcaBzZMmdp9OMFSp7lAx6/30JRBTIfGkRF4K+neGjzDICY PdyrIFnSai1n2eMogPbWz7fCcQ+/1AUXnAtFho7AUkANnu3W1I1C+Crz+QxUNl/3owNH 8gOdToHDOJUVCxh6vcz9bgDdqksBvhYN896ADFy6AOM1mD0N7qxKmcKwIsSIBKAov5IM ZXE2Yj2OXaz/SvM02TpJcCZQ3nWvGUMnFw15hNJ8nkjY30JUU1QosAKR1UOATo3kIb8A hP4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :references:in-reply-to:date:cc:to:from:subject:message-id :dkim-signature; bh=m+wdxi5MN8DBGBoeFXvvoseu/fmM/uh7e5tPhVSbrG4=; b=uxkOjkOBqjDob97h8VlyXWTLVm+unaD9wcHS2zklAaj0+rdKM057lv8mb4j7HxUKnu vO+nCC+AvfisSmWbvW5KhBGyNxshZzGBFxQ5O7vXnRuMpXh+sYYGbM+dxl3MENLKVKDx qR+rdX+v4wvMpttEuxqZr6yapKIZG06uVrFIc9r2o8en3cZebNIwpaXSES0CRGcgW7gG PzmeoQvBe5JbJYMvkhEpLi9SYTEtBi3xLnlVDHonkDj/sajVyELRQMFIWNXT57JPVi7U nFTcFNBHjxlkP2nHL2YvXRMImMsfhHlq+3IYIbac25pvmIgBN64IOU/LKO3VvBq2hV4Z 1yog== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=TFOtig7k; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q3si4602462pld.438.2021.04.13.02.33.12; Tue, 13 Apr 2021 02:33:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=TFOtig7k; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240984AbhDMHxd (ORCPT + 99 others); Tue, 13 Apr 2021 03:53:33 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:31498 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S238431AbhDMHx1 (ORCPT ); Tue, 13 Apr 2021 03:53:27 -0400 Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 13D7XIZY012031; Tue, 13 Apr 2021 03:53:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : subject : from : to : cc : date : in-reply-to : references : content-type : content-transfer-encoding : mime-version; s=pp1; bh=m+wdxi5MN8DBGBoeFXvvoseu/fmM/uh7e5tPhVSbrG4=; b=TFOtig7klfEXQbImLmgkgm5U+HgyKVZ0GmiHLVdyqDwoXL8UfSFpqgn8izxWwdMJ7l9b stpFD0MK79x0v6LhJDyf1410gsNybHWwfHstC0VaKsdYyTyr4OdsA8P2htdmlCiLLg3X pdThUec/ay1zJOLsdp3pVasLjxZKAc2KuL6BgU+2xDDyEd/EwVDRj4ULdKDaimXoM6Ft oLNNoBgfevaJaRzINfhSAPMDW2KJ7ApCQKHPz0KG3ZZLXHrpXZiZ+U211Ri+A6TwJVLW UWtiIukD7znTAFYEH5sWKqSzt9reW3SmLatWp+driK5kLt9CqVrTCMQIuq0MiZW4yjIa kQ== Received: from ppma06ams.nl.ibm.com (66.31.33a9.ip4.static.sl-reverse.com [169.51.49.102]) by mx0b-001b2d01.pphosted.com with ESMTP id 37vk4j924s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Apr 2021 03:53:05 -0400 Received: from pps.filterd (ppma06ams.nl.ibm.com [127.0.0.1]) by ppma06ams.nl.ibm.com (8.16.0.43/8.16.0.43) with SMTP id 13D7l4VO027204; Tue, 13 Apr 2021 07:53:04 GMT Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by ppma06ams.nl.ibm.com with ESMTP id 37u39hjg8k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Apr 2021 07:53:03 +0000 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 13D7r1io51118380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 13 Apr 2021 07:53:01 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0AF8C11C050; Tue, 13 Apr 2021 07:53:01 +0000 (GMT) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 85CA811C04C; Tue, 13 Apr 2021 07:53:00 +0000 (GMT) Received: from sig-9-145-159-22.de.ibm.com (unknown [9.145.159.22]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 13 Apr 2021 07:53:00 +0000 (GMT) Message-ID: <34568cb081b9e93eedac32da8af42fa42c60b254.camel@linux.ibm.com> Subject: Re: [PATCH 0/1] Use of =?UTF-8?Q?=2Fsys=2Fbus=2Fpci=2Fdevices=2F=E2=80=A6=2Findex?= for non-SMBIOS platforms From: Niklas Schnelle To: Leon Romanovsky Cc: Narendra K , Viktor Mihajlovski , Stefan Raspl , Peter Oberparleiter , linux-netdev@vger.kernel.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org Date: Tue, 13 Apr 2021 09:53:00 +0200 In-Reply-To: References: <20210412135905.1434249-1-schnelle@linux.ibm.com> <88c62c2789d5798338736308672867f30d617794.camel@linux.ibm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-14.el8) X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: rCfqPn2tzn16YmHXAMDDSwV-cO1bgyM_ X-Proofpoint-GUID: rCfqPn2tzn16YmHXAMDDSwV-cO1bgyM_ Content-Transfer-Encoding: 8bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-04-13_03:2021-04-13,2021-04-13 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 mlxscore=0 lowpriorityscore=0 priorityscore=1501 spamscore=0 suspectscore=0 bulkscore=0 mlxlogscore=999 impostorscore=0 phishscore=0 clxscore=1015 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2104130052 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2021-04-13 at 10:32 +0300, Leon Romanovsky wrote: > On Tue, Apr 13, 2021 at 08:57:19AM +0200, Niklas Schnelle wrote: > > On Tue, 2021-04-13 at 08:39 +0300, Leon Romanovsky wrote: > > > On Mon, Apr 12, 2021 at 03:59:04PM +0200, Niklas Schnelle wrote: > > > > Hi Narendra, Hi All, > > > > > > > > According to Documentation/ABI/testing/sysfs-bus-pci you are responsible > > > > for the index device attribute that is used by systemd to create network > > > > interface names. > > > > > > > > Now we would like to reuse this attribute for firmware provided PCI > > > > device index numbers on the s390 architecture which doesn't have > > > > SMBIOS/DMI nor ACPI. All code changes are within our architecture > > > > specific code but I'd like to get some Acks for this reuse. I've sent an > > > > RFC version of this patch on 15th of March with the subject: > > > > > > > > s390/pci: expose a PCI device's UID as its index > > > > > > > > but got no response. Would it be okay to re-use this attribute for > > > > essentially the same purpose but with index numbers provided by > > > > a different platform mechanism? I think this would be cleaner than > > > > further proliferation of /sys/bus/pci/devices//xyz_index > > > > attributes and allows re-use of the existing userspace infrastructure. > > > > > > I'm missing an explanation that this change is safe for systemd and > > > they don't have some hard-coded assumption about the meaning of existing > > > index on s390. > > > > > > Thanks > > > > Sure, good point. So first off yes this change does create new index > > based names also on existing systemd versions, this is known and > > intended and we'll certainly closely collaborate with any distributions > > wishing to backport this change. > > > > As for being otherwise safe or having unintended consequences, Viktor > > (see R-b) and I recently got the following PR merged in that exact area > > of systemd to fix how hotplug slot derived interface names are > > generated: > > https://github.com/systemd/systemd/pull/19017 > > In working on that we did also analyse the use of the index attribute > > for hidden assumptions and tested with this attribute added. Arguably, > > as the nature of that PR shows we haven't had a perfect track record of > > keeping this monitored but will in the future as PCI based NICs become > > increasingly important for our platform. We also have special NIC > > naming logic in the same area for our channel based platform specific > > NICs which was also contributed by Viktor. > > Thanks, this PR is exciting to read, very warm words were said about > kernel developers :). Can you please summarize that will be the breakage > in old systemd if this index will be overloaded? > > Thanks ;-) yeah, maybe us working closely across kernel and systemd will help improve relations. In principle the same happens on existing and new systemd i.e. we get new eno… interface names. Due to the way naming priorities work this will become the dominant interface name but thanks to altname support in current kernels we expect all old settings, routing rules etc. to remain working with the old name. This only happens however if the Linux instance is running with active UID Uniqueness Checking, this is a Hypervisor/Platform setting that enforces that no PCI device can be attached if one with the same UID is already attached. So far this setting was hidden inside the kernel but I recently committed a change to expose it to userspace here: https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/commit/?h=features&id=408f2c9c15682fc21b645fdec1f726492e235c4b That said, we're also still open for other approaches for example as floated by Lennart in this comment: https://github.com/systemd/systemd/pull/18829#discussion_r584794766 But this of course also depends on whether the kernel community is open to reusing the index attribute or has other preferences. > > > Thanks, > > Niklas > >