From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (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 4A7A52C375E for ; Tue, 2 Jun 2026 14:36:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780411017; cv=none; b=cfeSalZY9x7vfnaiTtFRXYX8O+nFkRE7r+d6J2pImet+jeEQA+bVXJrNWxineQhgKM25chztMWzyWWMZrSvDmASqSyL5qz3e5Doa0wjD8DqJQ+AaZX9BCxePMV5iigGEsgzgSZHQBNTbBYbo/ZSHVHw44Gu5aDmKrLoNpo8p0Sg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780411017; c=relaxed/simple; bh=8TDuoVkcu9gdj2cfN4RmPownLIzXANuybmdd+isc9jU=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=b1k7FCIcJ4JktGW2t58bYlpRFrZuXTdxSQjTlBE5ufTDtQSTn1vSxcw2IwtUjHXO/dsgDNuHggguzPw+Z1Bi0oKqwHGRPe9LO8NqpGEkhha6JG8+SbVLVeJG7T3PtPn7nepsl9mvzlpVhw+bOjm9bRSrXHuE6bDn5mn8FD2cNKw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=GUGlmAHr; arc=none smtp.client-ip=209.85.128.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="GUGlmAHr" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-490af320e2aso15662385e9.2 for ; Tue, 02 Jun 2026 07:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780411015; x=1781015815; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=oBKguW3D/kCt3h7s27Q2mTTVZ4PVa9W86O/GL4rWP8g=; b=GUGlmAHrvVc3fq031mJgqqEIFJKfvtTXQETReE4nuRe/VFEp9bUzqc8WAob0z7YTZ7 vbRnAsManh3TzXC5eZluDDXcp/+DAIRI2y3CVSqyzXEcsAGpg6VYFMF5b5Oi4QSB0SQy aCUg7lglQBpfA7x77KKiFngT9EfYyf7HLalVUKRIjwKEJTwg/9JaHbsAwehwS3VevPAt l8RCk9z0PVLTNo91SfnKg7R13WN1yTOkBL/D/If+8ylOhIAZT/c+vvdHeam9G9Fw8+So RVHT8fZI8OmEXhHwg4mIAPIW53EP96AjTjCIsXBpONtroGpYF5PASIilUv1pmH63xzh0 S45w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780411015; x=1781015815; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=oBKguW3D/kCt3h7s27Q2mTTVZ4PVa9W86O/GL4rWP8g=; b=UOMbJX2Tuc1khIOswWe9aQng5GnQFyArL6s7xdrnx7NoaL4Ck8HsswRJiXb+e7+QGq KrYXwnkGt4SzdHARZZB/vErRF9LKU0omxUxl4s+/ka3/cTj3B43cV47KLsd++rWLhrFT rVrRFSrnC0wm6tUfa7FALms3Yko62bgt+fDfCkSBx6v4bBvGPvCUBzTZldvyMc8Z8LPe u3qDqm8KQBI10UV6FUMAD3TxaysJT3WZXiAbMfgLT94OwHVsS1T/ORp5LNxPDU9Op9X/ 0UCMru8qbZUf1QdE7JYk+XakeZoO5p+Mpn/pyUIBhEUsO2h2KNd3u6Xbrcug5Snziync m71Q== X-Forwarded-Encrypted: i=1; AFNElJ8QU4M2VRW/M4WojTe4dz/5tOi6XIIuqBKOKbB1Mw/2Ko/SuP0N/re3daIwISdn0hs0ZRWP8U7EBQZ1g0o=@vger.kernel.org X-Gm-Message-State: AOJu0YzV/33YaHjlVKN0lnz9OJbJlSaxBWM27RwmJq6HcnPC6hWoJzDq qgmDYdJRmQWgSL4wjMgCEkwDqmR9uU/ZkgSGRS8MECsQqAv1DV2c6XCv X-Gm-Gg: Acq92OF5XzcXpqyGqnWK7cXh6IvC5AycFTvT65pRbGXaKwlqk9mRDB4gP4MbVUUCuBf AEKFOcEakyvGR1P0nQVObqiajOkegA+02tvN6jcYf3ZIyxY0BrSwupCe+WImVuAE3M4DOm6K5Tk ojW/tG87PgfUgJlMGa3NUEkeCtrBiQ/Hv79kGibDpnSneuDoPjJ1HM1hD10SD+XkFayMNYkIeLs DFHnmojcVV8uyTTQ2DxJMD7CA82ERW5Pek5mMZIr+J7kgHK+ZaDhc9cIgf/JP/l8iUjdEvXF12c ldaYocWTANINq2bT3Ux+CTuiaU4TkymHjw1OJx2EHJpAokmgnTMuFGky+m89O45UGBZE8OYYmPS +/n7wffPSJb0SqDOKSt4BYGM6ObZ9X1ivyzKWfBe8xfQD/Co5iPyWE2T6sMO0/lsujH3Mhvabob 1m/cIAMrI6Fz/zFmWwd3bC1rkuCXaSCAO6ZkKbLFn8hVuylqilMNtR3Iq242+ohZ0w9NK35Sw= X-Received: by 2002:a05:600c:190b:b0:48f:f64c:c2fe with SMTP id 5b1f17b1804b1-490a298f29bmr88226445e9.22.1780411014496; Tue, 02 Jun 2026 07:36:54 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4909c121d63sm101418795e9.29.2026.06.02.07.36.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2026 07:36:54 -0700 (PDT) Date: Tue, 2 Jun 2026 15:36:52 +0100 From: David Laight To: Heiko Carstens Cc: Alexander Gordeev , Sven Schnelle , Vasily Gorbik , Christian Borntraeger , Juergen Christ , linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org Subject: Re: [PATCH v5 1/7] s390/percpu: Infrastructure for more efficient this_cpu operations Message-ID: <20260602153652.6c2c02bc@pumpkin> In-Reply-To: <20260602135436.10415A71-hca@linux.ibm.com> References: <20260526055702.1429061-1-hca@linux.ibm.com> <20260526055702.1429061-2-hca@linux.ibm.com> <403de21c-957e-41ca-8c03-0bd110c49ec3-agordeev@linux.ibm.com> <20260601132750.9109A3b-hca@linux.ibm.com> <491a0085-9ba1-431b-9752-c1ac3fd602be-agordeev@linux.ibm.com> <20260601150813.9109C90-hca@linux.ibm.com> <20260602143209.1ce024e3@pumpkin> <20260602135436.10415A71-hca@linux.ibm.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 2 Jun 2026 15:54:36 +0200 Heiko Carstens wrote: > On Tue, Jun 02, 2026 at 02:32:09PM +0100, David Laight wrote: > > On Mon, 1 Jun 2026 17:08:13 +0200 > > Heiko Carstens wrote: > > > It is: the check makes sure this is an AG instruction, which adds the > > > percpu offset from lowcore - by checking that the displacement is > > > correct, as well as that the base register is zero. > > > > > > There could be a different AG instruction within the inline assembly, > > > for whatever reason. > > > > Do you actually even need to check the instruction? > > > > This sequence can only work for simple per-cpu accesses, so I don't > > see a reason to let the specified register point anywhere other than the > > base of the per-cpu data. > > > > That means the process switch code can just load the register with the > > base of the per-cpu data for the new cpu. > > If that happens before the 'AG' is executed it won't matter. > > > > The only reason would be to support non-offsettable memory accesses. > > But it looks like the 'laag %r5,%r2,0(%r4)' in the example has an > > offset (of zero). > > Probably only stops you doing a direct access of an array. > > > > That would mean that needs_fixup goes in the bin and percpu_exit() becomes: > > ... > > reg = regs->percpu_register; > > if (likely(!reg)) > > return; > > lc->percpu_register = reg; > > regs->gprs[reg] = lc->percpu_offset > > } > > > > I guess I'm missing something? > > The percpu register (in the above example %r4) first contains the base address > of a percpu variable. To get the actual percpu address of the variable the > percpu_offset of the corresponding cpu has to be added to that address, which > is what the AG instruction is doing. I knew my brain was fading. I'm sure it should be possible to get the linker to put the offset of the variable from the base on the per-cpu data area into the laag instruction. (Looks like it has a 20bit offset field.) Although I've no idea how per-cpu data works in loadable modules. That might mean you need lc->percpu_address as well as lc->percpu_offset. (If it isn't there already.) -- David > > What you propose would make a CPU's percpu_offset the address of any percpu > variable, which most likely would result in a crash.