Date:   Fri, 27 Jan 2023 14:48:35 -0800
From:   Ira Weiny <ira.weiny@intel.com>
To:     Al Viro <viro@zeniv.linux.org.uk>, Ira Weiny <ira.weiny@intel.com>
CC:     "Fabio M. De Francesco" <fmdefrancesco@gmail.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        Alexander Potapenko <glider@google.com>,
        "Andrey Konovalov" <andreyknvl@gmail.com>,
        Tony Luck <tony.luck@intel.com>,
        "Bagas Sanjaya" <bagasdotme@gmail.com>,
        David Sterba <dsterba@suse.com>,
        Kees Cook <keescook@chromium.org>,
        "Matthew Wilcox (Oracle)" <willy@infradead.org>,
        <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Helge Deller <deller@gmx.de>
Subject: Re: [PATCH] mm/highmem: Align-down to page the address for
 kunmap_flush_on_unmap()
Message-ID: <63d454c3ddda7_7f63c294c9@iweiny-mobl.notmuch>
References: <20230126143346.12086-1-fmdefrancesco@gmail.com>
 <63d2d97bce4c7_63e3f29442@iweiny-mobl.notmuch>
 <Y9LoVRYumhvgjsw5@ZenIV>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Y9LoVRYumhvgjsw5@ZenIV>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?xtLnieDSVVoRrgzI4c4jiQELSwBjKphuCMqsd4l8F6dUVWIundVr3cZuoE6T?=
 =?us-ascii?Q?TmDKR3HJscjLtZ8KExtZhIhiXHa2h1VxZVdOxyewDlj/BauxqFR1JfPL9WcJ?=
 =?us-ascii?Q?kFpmll5odSPtzaVC87qu5ILzZdRuBedBmVjrvEZNL2E3TJ4SxmGEczQpo0NR?=
 =?us-ascii?Q?JcnWpnbFfUqIMzJrShcTl0LuwgSvmGJmN/3eMa5o5aRm2s6UvWIW7Ck6BUw3?=
 =?us-ascii?Q?5zOjLcbpon8/qNvne2p9KDCyu9NXaxAZdKtvpicy9wb5BTg/AEgwlj344L5E?=
 =?us-ascii?Q?SOYX0waB5DJjWfClHbZU3CpiaJ2FEsUqkeeCsU0IjVahXKWFeuW1Yz0qEGR6?=
 =?us-ascii?Q?08TnlOjgDo6NZQEXTf1kutZ+W4dWGqDo4yCmBEtCOqQcMXI5fLQjVpCuXCTQ?=
 =?us-ascii?Q?XnrDpWVykVE8x0TUSn6ug0rjZiMfPSANEbzWKapqh5xch3UvUgpTckXsLfym?=
 =?us-ascii?Q?cJvVrKpbm2V84+c0NBJArSQyVDlEuwzar20LR6VYzR8JCXim9UdT08SK0iow?=
 =?us-ascii?Q?soUjiR+qhN1HdFbuqvt+pJ1/b//JJeMH9v87Gjko9Y9EWzhSAWN4jJLSA6G6?=
 =?us-ascii?Q?ToewDQ7VWow489qtWOe8fKUedQVSwMmS1I1ArUqFlGIBwVFW2u3GMm2D8vPg?=
 =?us-ascii?Q?IshDjEyS2p7NjbPP3YacggYtSUZ28P5gafPXxECkI2o0URQ6KiUfSuYlvSLb?=
 =?us-ascii?Q?N03GWFTsnOJxCmNU1XKNzKfUHzuuzQGlCbgX/4bAfdnBHKJkMDDF7i6L/t0K?=
 =?us-ascii?Q?eECj0sL7NA4FoL0msqmMRjESgho32zzb/f2OvC2+vY/QchB0JcrG5s1Wq8yy?=
 =?us-ascii?Q?impQEvKifrqkGu0ATReW9FbF7Qd1jMEBbmzmB00Ius4unH456iB6Vc5W+6Kl?=
 =?us-ascii?Q?EoRqbkr2lvXNFmX71mIU6pU1Am+O/p2cQJrQIj5X+t+AMo9ivper5E+fYoVi?=
 =?us-ascii?Q?++u2NUCO/bwLqSB+xtrTC3nQpdPMOZPtupKlabvn649ZpcAaHZk4T2lNTROw?=
 =?us-ascii?Q?wZxTiP7ZV79Isk49EE9ZoWxVTyVrgmXtebasQuiuxMn7GdNIqBaJrp0v4Ezs?=
 =?us-ascii?Q?iZSnJ1hIFaT2sNnpwsHxFCKEd8k6k8ARB78pHMK+wAsnQqdB5vh3i6BAYmMu?=
 =?us-ascii?Q?eFX6aod58YtcoD4oCdcE8AC6l7W+kXZP+PRIqo+z16RqTSHOZlgDpEf7eUwp?=
 =?us-ascii?Q?Ozr7KNk8PhrvUiT9pcJLbbWSTLhrdsuJzovIYGyUx+WTs/1vYynhYR/6LsZa?=
 =?us-ascii?Q?IYGrD7UrUaMH2ENeqNx7tx3iYQ7uktuKZQ6CqGnsCiSudUczGKbKhbQQVcWD?=
 =?us-ascii?Q?tnKc4yEbfQmPmNVOamfP/WzdOUv5XSdMKn7OOa3LuNk8f6xuBxmachH5qU6D?=
 =?us-ascii?Q?XH/o4QiSx3zvO1mQjAw30CeCcw8B2GvEnif4L8RqC/m8fQkO1xfiaZ2fLAuK?=
 =?us-ascii?Q?s6OiSYDap24DwMtaBrEcVi3KtsqBygLKumGQ/tnUB5nn2CKY2+GUbaSR9F0F?=
 =?us-ascii?Q?yj3HsNuYctQTJnqDXwTgWoSK5OXdNsRil4B33tdzVQTC2oLjBtXHSOWQanGI?=
 =?us-ascii?Q?LPcURJWzqv3QWOGx1dh/keVlw9cNif14jWegpY8S?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 24037af5-17b2-4665-d88f-08db00b8a1e6
X-MS-Exchange-CrossTenant-AuthSource: SA1PR11MB6733.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2023 22:48:39.5174
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: tnAAwT30Rbi1hfDb2vV604sv/HlCZG/H1z2flzBkAuySxpEAAsmWJPcrOALwJcL518jM8rZ8md2xCwXmlEaG4g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR11MB7751
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Al Viro wrote:
> On Thu, Jan 26, 2023 at 11:50:19AM -0800, Ira Weiny wrote:

[snip]

> 
> > > 2) I'm not sure whether or not the "Fixes" tag is appropriate in this
> > > patch. Can someone either confirm or deny it?
> > 
> > This 'fixes' looks correct to me.  I don't know how many folks are running
> > highmem with parisc but if they are I am sure they would appreciate the
> > extra knowledge.
> 
> parisc doesn't have highmem.  That's not what flush_kernel_dcache_page_addr()
> call is about; if you look at the kmap() there you'll see that it does
> *not* create any new mapping - it simply returns page_address().  It's
> really about D-cache flushing there; kunmap() and its ilk serve as
> convenient points for doing the flush.
> 
> Not sure about the "fixes" tag, TBH - AFAICS, currently all users supply
> page-aligned addresses anyway.

Not all users supply page-aligned addresses.  Partly because
kunmap_local() was documented to not require it.  But more importantly
because those of us doing the conversions were focused on what would
happen in the highmem case.  So we did not catch this side
effect/requirement in flush_kernel_dcache_page_addr().  :-/

kunmap_atomic:

 * @__addr can be any address within the mapped page, so there is no need
 * to subtract any offset that has been added. In contrast to kunmap(),
 * this function takes the address returned from kmap_atomic(), not the
 * page passed to it. The compiler will warn you if you pass the page.

kunmap_local:

 * @__addr can be any address within the mapped page.  Commonly it is the
 * address return from kmap_local_page(), but it can also include offsets.

> Their life would be easier if they could
> just pass any pointer within the page in questions and it's easy to overlook
> this corner case and assume that kunmap_local() would handle that as it
> is, but it's more of a "bug waiting to happen, better get rid of the
> corner case and explicitly document that property of kunmap_local()" than
> "there's a broken caller in the current mainline kernel, need to fix
> that".
 
FWIW there are callers like this in mainline.  Here is an example.

commit 8aec120a9ca80c14ce002505cea1e1639f8e9ea5                                           
Author: Christoph Hellwig <hch@lst.de>                                                    
Date:   Tue Jul 27 07:56:45 2021 +0200                                                    
                                                                             
    block: use bvec_kmap_local in t10_pi_type1_{prepare,complete}                         
                                                                     
    Using local kmaps slightly reduces the chances to stray writes, and                   
    the bvec interface cleans up the code a little bit.                      
                                                              
    Signed-off-by: Christoph Hellwig <hch@lst.de>                                         
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>                          
    Link: https://lore.kernel.org/r/20210727055646.118787-15-hch@lst.de 
    Signed-off-by: Jens Axboe <axboe@kernel.dk>                                           


> Anyway, I would rather keep the sysv etc. series independent from that;
> for now dir_put_page() explicitly rounds down there.  Once those series
> *and* your patch are both merged we can do a quick followup removing the
> explicit round-downs, marked as dependent upon your patch.

This seems reasonable.

Again, thanks for all your help Al!
Ira