Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sat, 21 Jan 2023 00:05:58 -0800
From:   Ira Weiny <ira.weiny@intel.com>
To:     Helge Deller <deller@gmx.de>, Al Viro <viro@zeniv.linux.org.uk>,
        "Matthew Wilcox" <willy@infradead.org>
CC:     "Fabio M. De Francesco" <fmdefrancesco@gmail.com>,
        Christoph Hellwig <hch@infradead.org>,
        <linux-kernel@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>,
        Ira Weiny <ira.weiny@intel.com>, <linux-parisc@vger.kernel.org>
Subject: Re: [PATCH v3 4/4] fs/sysv: Replace kmap() with kmap_local_page()
Message-ID: <63cb9ce63db7e_c68ad29473@iweiny-mobl.notmuch>
References: <20230119153232.29750-1-fmdefrancesco@gmail.com>
 <20230119153232.29750-5-fmdefrancesco@gmail.com>
 <Y8oWsiNWSXlDNn5i@ZenIV>
 <Y8oYXEjunDDAzSbe@casper.infradead.org>
 <Y8ocXbztTPbxu3bq@ZenIV>
 <Y8oem+z9SN487MIm@casper.infradead.org>
 <Y8ohpDtqI8bPAgRn@ZenIV>
 <Y8os8QR1pRXyu4N8@ZenIV>
 <99978295-6643-0cf2-8760-43e097f20dad@gmx.de>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <99978295-6643-0cf2-8760-43e097f20dad@gmx.de>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?1zj88QdZ9A+PVaaMf562CUO3KQUeoDBIrOKqyQgEBQ4SGPbxEKfUmDVqWNCS?=
 =?us-ascii?Q?A74glklj1wYy3bsWZl+SirMoAwnM8vuoAgdDQaHBeyqAtNoz9ryXhjFtvuBL?=
 =?us-ascii?Q?szi0I+yeSfm0GF2oMGYQ8Xm/Xn7Fi858sTVyysWowaTg2jfmW/3epkPHLFVh?=
 =?us-ascii?Q?iFoVIGKiaHdM4CL569a7IOfDVM43Gg6TkRPfZyw/gh++qS5KBucfBjPOKYFW?=
 =?us-ascii?Q?gde4BC3lzY5UF+P0gXwdzF1XgkUfmERqZCj83i84e3mnrywIJ+rjzRWnvLa+?=
 =?us-ascii?Q?Z7grI+XJ/kF1aDRvmAPd3p5tuZrytWOATwECNgAfJBMJVIm7BRsFuE8vR9tJ?=
 =?us-ascii?Q?q1jYP/ULPxCZ1nkYGBD0Rfi0rI66Jm7vEVzc4hLfA8Eg3cGH/cC+V7NEO84/?=
 =?us-ascii?Q?rUgN8xiH4LIhPGoMZ2bP+x/KqF2DObKqx3uhOgsRN2Ajx4asWp/NGRVM9Kua?=
 =?us-ascii?Q?iQr+yC5FoJD/2aDkgrbFMJUdHqmwIIfXTMz3IhMfoafxBASCgot831leyajp?=
 =?us-ascii?Q?qY0WW5RI62HpvJ+HUeKynMRFr1cnSHt92P62Vo8SO3pKdqxuTQy/Y+Dt5rhx?=
 =?us-ascii?Q?F6LFGn2C0V+fukaFKhgNK24wWFlTJIf6cdRNjLZNBSUvwBVF+4TvISWPyNKn?=
 =?us-ascii?Q?jy+sy7yt9X766QqSVCPe0PAaEG/I7dYkU3bafAygxuN4zeASjvMskUuIh/1B?=
 =?us-ascii?Q?Ifjq+sYVlLlDk4ALs/0kRvhEuS9Gr3umLKlkTPS2+8dwx0VFc0q22m/i27KQ?=
 =?us-ascii?Q?0ylsS0T7nOLcLQ+h4ygpph9FGs0K4nqGtdLyI46BlOmaBd+SD0CsJNDgrVKB?=
 =?us-ascii?Q?XdbNqszC5p24LZiBOxj6AYu8+R7W7b0BkbV495gU7jcO14I0zqGeYg9KgJ/m?=
 =?us-ascii?Q?aSSNqRFLa+/geSPPqvlfuJ/zpKO7zy6LUq3dmSfNQl4BMxFIgMS+j+JYHxA6?=
 =?us-ascii?Q?jmdbH83VV6iLyrLpL5ebBZ6blfQ6Fpu6IcDBaTOo4FzTv6t+ekcmtZi2Vi6U?=
 =?us-ascii?Q?0s3ZTy4CvTnlwF0XBJsuxvuo7wnvnmm89M/eXw3AP5/f8sgGaNnSY2lJGrL2?=
 =?us-ascii?Q?Bokv70AJA2Ba1CuywQFxv1U1HG2tfJEugrhNGLHR8owJOpew7ZZT+6Pgk2AU?=
 =?us-ascii?Q?2yQROgxHNr32ljHXt8VjT3YDFjpK852CH2HE0YOqZ/EpCOkbGLUe/yPZ/C5G?=
 =?us-ascii?Q?WmbMYTExAy2lJJW56xgTx5weyHiS2QbS0QPmQgF31HZai3B2EUe39NuuJ+Iq?=
 =?us-ascii?Q?Iyum7+qaGYQa8ESljpmWe3eJ1uuc1ll5P/g7Itcr2rYa8FXpL6vEi+z/ICqE?=
 =?us-ascii?Q?d0r78MKSgCXUvq6BgzcGdnl4QSq1EYt/g4filutSP/OQT1FtnAtqgeDWzeHJ?=
 =?us-ascii?Q?f5mZndNwNqr6Aqwh1xr/hrOSjLO2NprC9xPIVXZm8cV2im4LZv33DGIJUttk?=
 =?us-ascii?Q?J6Alhioh8pc30JZ5TVmTW2ksCEb0kfNgrowCUXJTd3Gn5x9HtE6+WN6Pqu1R?=
 =?us-ascii?Q?P/xt+cXSWzbljjxEDz0/Xs5o75LA/SiA4ksxiJFJfK/hx/fxHFl45Z2W1y22?=
 =?us-ascii?Q?OcRKw0RY+IsuJAh3NiMX1Wn6IYlJveW31mMg9uZ1?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 5efa22c9-7e51-4b38-f14b-08dafb8655f4
X-MS-Exchange-CrossTenant-AuthSource: SA1PR11MB6733.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2023 08:06:01.4370
 (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: JHAsXq/VN0f+aDTio6/sGqUOrfgTi5Ooclg6qCc6VBlITe/5RUjBQL/7iUfm2UiI0qcqlVpYIjILwWbxRPEhqQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR11MB5222
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,
        URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Helge Deller wrote:
> On 1/20/23 06:56, Al Viro wrote:
> > On Fri, Jan 20, 2023 at 05:07:48AM +0000, Al Viro wrote:
> >> On Fri, Jan 20, 2023 at 04:54:51AM +0000, Matthew Wilcox wrote:
> >>
> >>>> Sure, but... there's also this:
> >>>>
> >>>> static inline void __kunmap_local(const void *addr)
> >>>> {
> >>>> #ifdef ARCH_HAS_FLUSH_ON_KUNMAP
> >>>>          kunmap_flush_on_unmap(addr);
> >>>> #endif
> >>>> }
> >>>>
> >>>> Are you sure that the guts of that thing will be happy with address that is not
> >>>> page-aligned?  I've looked there at some point, got scared of parisc (IIRC)
> >>>> MMU details and decided not to rely upon that...
> >>>
> >>> Ugh, PA-RISC (the only implementor) definitely will flush the wrong
> >>> addresses.  I think we should do this, as having bugs that only manifest
> >>> on one not-well-tested architecture seems Bad.
> >>>
> >>>   static inline void __kunmap_local(const void *addr)
> >>>   {
> >>>   #ifdef ARCH_HAS_FLUSH_ON_KUNMAP
> >>> -       kunmap_flush_on_unmap(addr);
> >>> +       kunmap_flush_on_unmap(PAGE_ALIGN_DOWN(addr));
> >>>   #endif
> >>>   }
> >>
> >> PTR_ALIGN_DOWN(addr, PAGE_SIZE), perhaps?
> >
> > 	Anyway, that's a question to parisc folks; I _think_ pdtlb
> > quietly ignores the lower bits of address, so that part seems
> > to be safe, but I wouldn't bet upon that.
> 
> No, on PA2.0 (64bit) CPUs the lower bits of the address of pdtlb
> encodes the amount of memory (page size) to be flushed, see:
> http://ftp.parisc-linux.org/docs/arch/parisc2.0.pdf (page 7-106)
> So, the proposed page alignment with e.g. PTR_ALIGN_DON() is needed.
> 
> Helge

I'm not sure I completely understand.

First, arn't PAGE_ALIGN_DOWN(addr) and PTR_ALIGN_DOWN(addr, PAGE_SIZE) the
same?

align.h
#define PTR_ALIGN_DOWN(p, a)    ((typeof(p))ALIGN_DOWN((unsigned long)(p), (a)))

mm.h:
#define PAGE_ALIGN_DOWN(addr) ALIGN_DOWN(addr, PAGE_SIZE)

Did parisc redefine it somewhere I'm not seeing?

Second, if the lower bits encode the amount of memory to be flushed is it
required to return the original value returned from page_address()?

Ira