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;
From:   "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To:     Jeff Moyer <jmoyer@redhat.com>, Al Viro <viro@zeniv.linux.org.uk>
Cc:     Benjamin LaHaise <bcrl@kvack.org>, linux-aio@kvack.org,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        "Venkataramanan, Anirudh" <anirudh.venkataramanan@intel.com>,
        Ira Weiny <ira.weiny@intel.com>
Subject: Re: [PATCH v2] fs/aio: Replace kmap{,_atomic}() with kmap_local_page()
Date:   Thu, 12 Jan 2023 21:42:33 +0100
Message-ID: <3477941.iIbC2pHGDl@suse>
In-Reply-To: <Y77dkghufF6GVq1Y@ZenIV>
References: <20230109175629.9482-1-fmdefrancesco@gmail.com>
 <x498ri9ma5n.fsf@segfault.boston.devel.redhat.com> <Y77dkghufF6GVq1Y@ZenIV>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk

On mercoled=EC 11 gennaio 2023 17:02:26 CET Al Viro wrote:
> On Wed, Jan 11, 2023 at 09:13:40AM -0500, Jeff Moyer wrote:
> > Hi, Al,
> >=20
> > Al Viro <viro@zeniv.linux.org.uk> writes:
> > > On Mon, Jan 09, 2023 at 06:56:29PM +0100, Fabio M. De Francesco wrote:
> > >> -	ring =3D kmap_atomic(ctx->ring_pages[0]);
> > >> +	ring =3D kmap_local_page(ctx->ring_pages[0]);
> > >>=20
> > >>  	ring->nr =3D nr_events;	/* user copy */
> > >>  	ring->id =3D ~0U;
> > >>  	ring->head =3D ring->tail =3D 0;
> > >>=20
> > >> @@ -575,7 +575,7 @@ static int aio_setup_ring(struct kioctx *ctx,
> > >> unsigned int nr_events)> >>=20
> > >>  	ring->compat_features =3D AIO_RING_COMPAT_FEATURES;
> > >>  	ring->incompat_features =3D AIO_RING_INCOMPAT_FEATURES;
> > >>  	ring->header_length =3D sizeof(struct aio_ring);
> > >>=20
> > >> -	kunmap_atomic(ring);
> > >> +	kunmap_local(ring);
> > >>=20
> > >>  	flush_dcache_page(ctx->ring_pages[0]);
> > >=20
> > > I wonder if it would be more readable as memcpy_to_page(), actually...
> >=20
> > I'm not sure I understand what you're suggesting.
>=20
> 	memcpy_to_page(ctx->ring_pages[0], 0, &(struct aio_ring){
> 			.nr =3D nr_events, .id =3D ~0U, .magic =3D=20
AIO_RING_MAGIC,
> 			.compat_features =3D AIO_RING_COMPAT_FEATURES,
> 			.in_compat_features =3D=20
AIO_RING_INCOMPAT_FEATURES,
> 			.header_length =3D sizeof(struct aio_ring)},
> 			sizeof(struct aio_ring));
>=20
> instead of the lines from kmap_atomic to flush_dcache_page...

Actually, I'd prefer Ira's solution for readability, but I have nothing=20
against yours. I will send you the code in the way you rewrote it.

> > >>  	return 0;
> > >>=20
> > >> @@ -678,9 +678,9 @@ static int ioctx_add_table(struct kioctx *ctx,=20
struct
> > >> mm_struct *mm)> >>=20
> > >>  					 * we are protected from=20
page migration
> > >>  					 * changes ring_pages by -
>ring_lock.
> > >>  					 */
> > >>=20
> > >> -					ring =3D kmap_atomic(ctx-
>ring_pages[0]);
> > >> +					ring =3D kmap_local_page(ctx-
>ring_pages[0]);
> > >>=20
> > >>  					ring->id =3D ctx->id;
> > >>=20
> > >> -					kunmap_atomic(ring);
> > >> +					kunmap_local(ring);
> > >=20
> > > Incidentally, does it need flush_dcache_page()?
> >=20
> > Yes, good catch.

Yes, I missed it :-(

However, with the use of memcpy_to_page() we no longer need that explicit c=
all=20
to flush_dcache_page().

Thank you,

=46abio