From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ECE1E1D130E for ; Wed, 24 Jun 2026 16:25:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.89.141.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782318313; cv=none; b=hr50QCcd34iZWpAbgBRkmyDLAl/tOmObRoOVq7xobRYvwM5yH8a6EDCQzytDH7ofEfvu/QuKUkcDafLV+MtJ/ljS1nYrg5RYTR5IID6336wcEajGjlc5xx0L+utIqBpM4yc2IyNS4T84yQmZIcuDLv1kNURhIHs2hMdn6DhjdiQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782318313; c=relaxed/simple; bh=klsrEbiYJ2AQXsle5ITijp8PeFZH6eqEN+MSZ0+z374=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MLDU2nqjnLak/QofAlZDVUj0X9P5/ybKotEhdsJO+JVVmDc862uija7GQqz5oaYZHaqr/CHAUYaWCQsVpMZ8xbF2AMIDwbW3dQObap6hF1PjGd1EcjQbSnvpMflhVJTWQx6gr0lJ9tooM5btMlBWWY7Z0DcmTHoKnOX/u2jGHus= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk; spf=none smtp.mailfrom=ftp.linux.org.uk; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b=NLbxJyaA; arc=none smtp.client-ip=62.89.141.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=ftp.linux.org.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b="NLbxJyaA" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Cb2alktzfubcSNde4z8h1xqg1tsdbNhFY46rOZE5YGc=; b=NLbxJyaArQ9vLrtV30brbCX9/7 4Y8a1nwpN8Q9r6vrTpLuZSJb3FDdLE2Z52zLHkXD8dAyLWUmYdDQSiE5eshHpXVZXdTFxMeIT1dHq f7LxgpyhTC0uak1gSgB/oK2qZsWq53rGBSckaJoa+t3QKorqopiH8Ia+9aLmhTm606PpY5WcIkHWs 6RmvvmlxiLMKNUSAk6juL9ipHXrmT85cEHCYUCDEWJ1TcOewqHEsl3tMiub9B0GRFBYf80BmmM7sj YHfHwJqRxavxhcyekAhORtdk+5uJYoq3hzEPvTYuAwH1PtpsXqePSU9+WEhNm3twKVIqlhhzmxk/1 KlCsQUZQ==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.99.4 #2 (Red Hat Linux)) id 1wcQPT-00000009Jdo-1krb; Wed, 24 Jun 2026 16:25:09 +0000 Date: Wed, 24 Jun 2026 17:25:07 +0100 From: Al Viro To: Ben Dooks Cc: Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [PATCH] lib/iomem_copy: fix __iomem casts Message-ID: <20260624162507.GJ2636677@ZenIV> References: <20260622124857.379868-1-ben.dooks@codethink.co.uk> <20260623234720.GG2636677@ZenIV> 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-Disposition: inline In-Reply-To: Sender: Al Viro On Wed, Jun 24, 2026 at 11:17:17AM +0100, Ben Dooks wrote: > On 24/06/2026 00:47, Al Viro wrote: > > On Mon, Jun 22, 2026 at 01:48:57PM +0100, Ben Dooks wrote: > > > The iomem_copy.c code discards __iomem address space when using > > > the IS_ALIGNED() macro. It would make more sense to fix this in > > > one place by aing a PTR_ALIGNED_LONG() macro and then doing the > > > necessary casts there before invoking IS_ALIGNED(). > > > > > > As part of this, also force the pointer to an unsigned long as > > > pointers are generally not signed, although there is no warning > > > as yet on treating pointers as signed. > > > > > +#define PTR_ALIGNED_LONG(__ptr) IS_ALIGNED((__force unsigned long)__ptr, sizeof(long)) > > > > Casting to unsigned long is fine (indeed, casting a pointer to long had > > been very odd in the first place), but... why __force? Casts to unsigned long > > (de facto uintptr_t) do *not* require __force - they are explicitly allowed, > > unless you pass -Wcast-from-as in sparse arguments. -Wall does not turn > > those on; -Wsparse-all would, but kbuild doesn't pass that. > > Trying to get rid of the address space warning, which requires the > __force part. It does not require __force - not with the type we are casting to being unsigned long. As the examples you've quoted demonstrate. See evaluate_cast() in sparse evaluate.c: if ((ttype == &ulong_ctype || ttype == uintptr_ctype) && !Wcast_from_as) tas = &bad_address_space; with if (!tas && valid_as(sas)) warning(expr->pos, "cast removes address space '%s' of expression", show_as(sas)); several lines below. And yes, it is deliberate.