From: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>,
Ira Weiny <ira.weiny@intel.com>
Cc: Benjamin LaHaise <bcrl@kvack.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Kees Cook <keescook@chromium.org>,
Dan Williams <dan.j.williams@intel.com>,
Matthew Wilcox <willy@infradead.org>, Jan Kara <jack@suse.cz>,
Jeff Layton <jlayton@kernel.org>,
Chuck Lever <chuck.lever@oracle.com>,
Jens Axboe <axboe@kernel.dk>,
Pavel Begunkov <asml.silence@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Tom Rix <trix@redhat.com>,
linux-aio@kvack.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
nvdimm@lists.linux.dev, io-uring@vger.kernel.org,
linux-riscv@lists.infradead.org, llvm@lists.linux.dev
Subject: Re: [PATCH] fs: Replace kmap{,_atomic}() with kmap_local_page()
Date: Fri, 01 Jul 2022 12:10:33 +0200 [thread overview]
Message-ID: <3187836.aeNJFYEL58@opensuse> (raw)
In-Reply-To: <8735fmqcfz.fsf@email.froward.int.ebiederm.org>
On giovedì 30 giugno 2022 19:38:08 CEST Eric W. Biederman wrote:
> "Fabio M. De Francesco" <fmdefrancesco@gmail.com> writes:
>
> > The use of kmap() and kmap_atomic() are being deprecated in favor of
> > kmap_local_page().
> >
> > With kmap_local_page(), the mappings are per thread, CPU local and not
> > globally visible. Furthermore, the mappings can be acquired from any
> > context (including interrupts).
> >
> > Therefore, use kmap_local_page() in exec.c because these mappings are
per
> > thread, CPU local, and not globally visible.
> >
> > Tested with xfstests on a QEMU + KVM 32-bits VM booting a kernel with
> > HIGHMEM64GB enabled.
>
> Can someone please refresh my memory on what is going on.
>
> I remember there were limitations that kmap_atomic had that are hard to
> meet so something I think it was kmap_local was invented and created
> to be the kmap_atomic replacement.
Please read highmem.rst. I've updated that document weeks ago:
https://docs.kernel.org/vm/highmem.html?highlight=highmem
Currently it contains many more information I can ever place here in order
to answer your questions.
Believe me, this is not by any means a way to elude your questions. I'm
pretty sure that by reading that document you'll have a clear vision on
what is going on :-)
>
> What are the requirements on kmap_local? In copy_strings
> kmap is called in contexts that can sleep in page faults
No problems with kmap_local_page() with regard to page faults (again,
please read the above-mentioned document).
From that document...
"It’s valid to take pagefaults in a local kmap region []".
"Each call of kmap_atomic() in the kernel creates a non-preemptible section
and disable pagefaults. This could be a source of unwanted latency.
Therefore users should prefer kmap_local_page() instead of kmap_atomic().".
> so any
> nearly any requirement except a thread local use is invalidated.
>
> As you have described kmap_local above it does not sound like kmap_local
> is safe in this context,
Sorry, probably I should add that taking page faults is allowed. Would you
prefer I send a v2 and add this information?
Thanks,
Fabio
> but that could just be a problem in description
> that my poor memory does is not recalling the necessary details to
> correct.
>
> Eric
>
> > Suggested-by: Ira Weiny <ira.weiny@intel.com>
> > Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
> > ---
> > fs/exec.c | 14 +++++++-------
> > 1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/fs/exec.c b/fs/exec.c
> > index 0989fb8472a1..4a2129c0d422 100644
> > --- a/fs/exec.c
> > +++ b/fs/exec.c
> > @@ -583,11 +583,11 @@ static int copy_strings(int argc, struct
user_arg_ptr argv,
> >
> > if (kmapped_page) {
> >
flush_dcache_page(kmapped_page);
> > - kunmap(kmapped_page);
> > + kunmap_local(kaddr);
> >
put_arg_page(kmapped_page);
> > }
> > kmapped_page = page;
> > - kaddr = kmap(kmapped_page);
> > + kaddr =
kmap_local_page(kmapped_page);
> > kpos = pos & PAGE_MASK;
> > flush_arg_page(bprm, kpos,
kmapped_page);
> > }
> > @@ -601,7 +601,7 @@ static int copy_strings(int argc, struct
user_arg_ptr argv,
> > out:
> > if (kmapped_page) {
> > flush_dcache_page(kmapped_page);
> > - kunmap(kmapped_page);
> > + kunmap_local(kaddr);
> > put_arg_page(kmapped_page);
> > }
> > return ret;
> > @@ -883,11 +883,11 @@ int transfer_args_to_stack(struct linux_binprm
*bprm,
> >
> > for (index = MAX_ARG_PAGES - 1; index >= stop; index--) {
> > unsigned int offset = index == stop ? bprm->p &
~PAGE_MASK : 0;
> > - char *src = kmap(bprm->page[index]) + offset;
> > + char *src = kmap_local_page(bprm->page[index]) +
offset;
> > sp -= PAGE_SIZE - offset;
> > if (copy_to_user((void *) sp, src, PAGE_SIZE - offset)
!= 0)
> > ret = -EFAULT;
> > - kunmap(bprm->page[index]);
> > + kunmap_local(src);
> > if (ret)
> > goto out;
> > }
> > @@ -1680,13 +1680,13 @@ int remove_arg_zero(struct linux_binprm *bprm)
> > ret = -EFAULT;
> > goto out;
> > }
> > - kaddr = kmap_atomic(page);
> > + kaddr = kmap_local_page(page);
> >
> > for (; offset < PAGE_SIZE && kaddr[offset];
> > offset++, bprm->p++)
> > ;
> >
> > - kunmap_atomic(kaddr);
> > + kunmap_local(kaddr);
> > put_arg_page(page);
> > } while (offset == PAGE_SIZE);
>
WARNING: multiple messages have this Message-ID (diff)
From: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>,
Ira Weiny <ira.weiny@intel.com>
Cc: Benjamin LaHaise <bcrl@kvack.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Kees Cook <keescook@chromium.org>,
Dan Williams <dan.j.williams@intel.com>,
Matthew Wilcox <willy@infradead.org>, Jan Kara <jack@suse.cz>,
Jeff Layton <jlayton@kernel.org>,
Chuck Lever <chuck.lever@oracle.com>,
Jens Axboe <axboe@kernel.dk>,
Pavel Begunkov <asml.silence@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Tom Rix <trix@redhat.com>,
linux-aio@kvack.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
nvdimm@lists.linux.dev, io-uring@vger.kernel.org,
linux-riscv@lists.infradead.org, llvm@lists.linux.dev
Subject: Re: [PATCH] fs: Replace kmap{,_atomic}() with kmap_local_page()
Date: Fri, 01 Jul 2022 12:10:33 +0200 [thread overview]
Message-ID: <3187836.aeNJFYEL58@opensuse> (raw)
In-Reply-To: <8735fmqcfz.fsf@email.froward.int.ebiederm.org>
On giovedì 30 giugno 2022 19:38:08 CEST Eric W. Biederman wrote:
> "Fabio M. De Francesco" <fmdefrancesco@gmail.com> writes:
>
> > The use of kmap() and kmap_atomic() are being deprecated in favor of
> > kmap_local_page().
> >
> > With kmap_local_page(), the mappings are per thread, CPU local and not
> > globally visible. Furthermore, the mappings can be acquired from any
> > context (including interrupts).
> >
> > Therefore, use kmap_local_page() in exec.c because these mappings are
per
> > thread, CPU local, and not globally visible.
> >
> > Tested with xfstests on a QEMU + KVM 32-bits VM booting a kernel with
> > HIGHMEM64GB enabled.
>
> Can someone please refresh my memory on what is going on.
>
> I remember there were limitations that kmap_atomic had that are hard to
> meet so something I think it was kmap_local was invented and created
> to be the kmap_atomic replacement.
Please read highmem.rst. I've updated that document weeks ago:
https://docs.kernel.org/vm/highmem.html?highlight=highmem
Currently it contains many more information I can ever place here in order
to answer your questions.
Believe me, this is not by any means a way to elude your questions. I'm
pretty sure that by reading that document you'll have a clear vision on
what is going on :-)
>
> What are the requirements on kmap_local? In copy_strings
> kmap is called in contexts that can sleep in page faults
No problems with kmap_local_page() with regard to page faults (again,
please read the above-mentioned document).
From that document...
"It’s valid to take pagefaults in a local kmap region []".
"Each call of kmap_atomic() in the kernel creates a non-preemptible section
and disable pagefaults. This could be a source of unwanted latency.
Therefore users should prefer kmap_local_page() instead of kmap_atomic().".
> so any
> nearly any requirement except a thread local use is invalidated.
>
> As you have described kmap_local above it does not sound like kmap_local
> is safe in this context,
Sorry, probably I should add that taking page faults is allowed. Would you
prefer I send a v2 and add this information?
Thanks,
Fabio
> but that could just be a problem in description
> that my poor memory does is not recalling the necessary details to
> correct.
>
> Eric
>
> > Suggested-by: Ira Weiny <ira.weiny@intel.com>
> > Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
> > ---
> > fs/exec.c | 14 +++++++-------
> > 1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/fs/exec.c b/fs/exec.c
> > index 0989fb8472a1..4a2129c0d422 100644
> > --- a/fs/exec.c
> > +++ b/fs/exec.c
> > @@ -583,11 +583,11 @@ static int copy_strings(int argc, struct
user_arg_ptr argv,
> >
> > if (kmapped_page) {
> >
flush_dcache_page(kmapped_page);
> > - kunmap(kmapped_page);
> > + kunmap_local(kaddr);
> >
put_arg_page(kmapped_page);
> > }
> > kmapped_page = page;
> > - kaddr = kmap(kmapped_page);
> > + kaddr =
kmap_local_page(kmapped_page);
> > kpos = pos & PAGE_MASK;
> > flush_arg_page(bprm, kpos,
kmapped_page);
> > }
> > @@ -601,7 +601,7 @@ static int copy_strings(int argc, struct
user_arg_ptr argv,
> > out:
> > if (kmapped_page) {
> > flush_dcache_page(kmapped_page);
> > - kunmap(kmapped_page);
> > + kunmap_local(kaddr);
> > put_arg_page(kmapped_page);
> > }
> > return ret;
> > @@ -883,11 +883,11 @@ int transfer_args_to_stack(struct linux_binprm
*bprm,
> >
> > for (index = MAX_ARG_PAGES - 1; index >= stop; index--) {
> > unsigned int offset = index == stop ? bprm->p &
~PAGE_MASK : 0;
> > - char *src = kmap(bprm->page[index]) + offset;
> > + char *src = kmap_local_page(bprm->page[index]) +
offset;
> > sp -= PAGE_SIZE - offset;
> > if (copy_to_user((void *) sp, src, PAGE_SIZE - offset)
!= 0)
> > ret = -EFAULT;
> > - kunmap(bprm->page[index]);
> > + kunmap_local(src);
> > if (ret)
> > goto out;
> > }
> > @@ -1680,13 +1680,13 @@ int remove_arg_zero(struct linux_binprm *bprm)
> > ret = -EFAULT;
> > goto out;
> > }
> > - kaddr = kmap_atomic(page);
> > + kaddr = kmap_local_page(page);
> >
> > for (; offset < PAGE_SIZE && kaddr[offset];
> > offset++, bprm->p++)
> > ;
> >
> > - kunmap_atomic(kaddr);
> > + kunmap_local(kaddr);
> > put_arg_page(page);
> > } while (offset == PAGE_SIZE);
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2022-07-01 10:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-30 16:35 [PATCH] fs: Replace kmap{,_atomic}() with kmap_local_page() Fabio M. De Francesco
2022-06-30 16:35 ` Fabio M. De Francesco
2022-06-30 17:38 ` Eric W. Biederman
2022-06-30 17:38 ` Eric W. Biederman
2022-07-01 10:10 ` Fabio M. De Francesco [this message]
2022-07-01 10:10 ` Fabio M. De Francesco
2022-07-08 20:18 ` Ira Weiny
2022-07-08 20:18 ` Ira Weiny
2022-07-09 18:30 ` Fabio M. De Francesco
2022-07-09 18:30 ` Fabio M. De Francesco
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3187836.aeNJFYEL58@opensuse \
--to=fmdefrancesco@gmail.com \
--cc=aou@eecs.berkeley.edu \
--cc=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=bcrl@kvack.org \
--cc=chuck.lever@oracle.com \
--cc=dan.j.williams@intel.com \
--cc=ebiederm@xmission.com \
--cc=io-uring@vger.kernel.org \
--cc=ira.weiny@intel.com \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=keescook@chromium.org \
--cc=linux-aio@kvack.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=llvm@lists.linux.dev \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=nvdimm@lists.linux.dev \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=tglx@linutronix.de \
--cc=trix@redhat.com \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.