From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from imap5.colo.codethink.co.uk (imap5.colo.codethink.co.uk [78.40.148.171]) (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 971F53630BA for ; Mon, 29 Jun 2026 11:14:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=78.40.148.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782731652; cv=none; b=d/cWf/RMfHi021cG6KZHLKssXTcyHe8n+VXx5hAc9KNPnzc+sOMn7TjlBjIBZZj5eYattqeu4U/zi2WGWtPF1M5tHtX+iOBU//IG4YnTXD40BKys16mK5jEdv2LoKn6PKfqal5+bl9B/0WfOKlIQ+V0aRRIgyz3MmwaV6eC8tfo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782731652; c=relaxed/simple; bh=W1j49UuCt7lgYkSEGou/paUO4WnFHF1bWpi/fF/jNGg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=hEAIf3cb96Zk59gGY/OP+8CgFVEODK2vGL5lAelIHFz7ehh0qtYJXLjAU4xNU/Y5Wg+T486fX+6IZjZ0zkC8nTQPbCHxHPMsN6yi2iCIDW2sKpglhsJTVKA7ySXUsyHs0Hq2jhRiX6XkCnU6wCVnG+6Mog2OyGG060ANIzRFXSE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=codethink.co.uk; spf=pass smtp.mailfrom=codethink.co.uk; dkim=pass (2048-bit key) header.d=codethink.co.uk header.i=@codethink.co.uk header.b=t9FNPFhB; arc=none smtp.client-ip=78.40.148.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=codethink.co.uk Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=codethink.co.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=codethink.co.uk header.i=@codethink.co.uk header.b="t9FNPFhB" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codethink.co.uk; s=imap5-20230908; h=Sender:Content-Transfer-Encoding: In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date:Message-ID: Reply-To; bh=V91Yumt8SkyFW9a7Ms+Kk5NwAK3kkQ5JRfZoIIF9meI=; b=t9FNPFhBQaf2qyBw r2TRVMz10Pq0DrGHe//3NUTwfzAiuu/8j7SywBHnNeG89QJmTCDFRe2otgRYqAFaex/EGC91viMl3 XQKsYjm1ChlP23/wKHQZTrpBmdoFAplIMx4oLKcJ+ArW8cIHXc9z0VUZDv/gSTF108c3kORnxxY8p 1hgy3rPr8+uso71JemiXcvXjFR3LBFG1R8XDRrHuDNO1I4aOCFQ4znv/PQi9MKaISFH04nkaVfVnN kILqTjjojahgt4EKt8zV8MVknnp9wnPjtml0I8Kve5HfSAUu8nfa0/ZQTsC/7EXvAwLX3z19QZPGg InvIhlM+kh1pYqXI3w==; Received: from [167.98.27.226] (helo=[10.35.6.194]) by imap5.colo.codethink.co.uk with esmtpsa (Exim 4.94.2 #2 (Debian)) id 1we9wF-000Pt1-C9; Mon, 29 Jun 2026 12:14:07 +0100 Message-ID: <1bf23afc-0403-4152-ae8c-fd695bdf5b7e@codethink.co.uk> Date: Mon, 29 Jun 2026 12:14:05 +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] lib/iomem_copy: fix __iomem casts To: Al Viro Cc: Andrew Morton , linux-kernel@vger.kernel.org References: <20260622124857.379868-1-ben.dooks@codethink.co.uk> <20260623234720.GG2636677@ZenIV> <20260624162507.GJ2636677@ZenIV> Content-Language: en-GB From: Ben Dooks Organization: Codethink Limited. In-Reply-To: <20260624162507.GJ2636677@ZenIV> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: ben.dooks@codethink.co.uk On 24/06/2026 17:25, Al Viro wrote: > 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. Ah we should also have checked for intptr or long type there, the original code had long which causes sparse to complain here. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html