From: Lorenzo Stoakes <lstoakes@gmail.com>
To: David Hildenbrand <david@redhat.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Baoquan He <bhe@redhat.com>, Uladzislau Rezki <urezki@gmail.com>,
linux-fsdevel@vger.kernel.org, Jiri Olsa <olsajiri@gmail.com>,
Will Deacon <will@kernel.org>, Mike Galbraith <efault@gmx.de>,
Mark Rutland <mark.rutland@arm.com>,
wangkefeng.wang@huawei.com, catalin.marinas@arm.com,
ardb@kernel.org,
Linux regression tracking <regressions@leemhuis.info>,
regressions@lists.linux.dev, Matthew Wilcox <willy@infradead.org>,
Liu Shixin <liushixin2@huawei.com>, Jens Axboe <axboe@kernel.dk>,
Alexander Viro <viro@zeniv.linux.org.uk>,
stable@vger.kernel.org
Subject: Re: [PATCH] fs/proc/kcore: reinstate bounce buffer for KCORE_TEXT regions
Date: Tue, 1 Aug 2023 17:33:18 +0100 [thread overview]
Message-ID: <dc30a97b-853e-4d2a-b171-e68fb3ab026c@lucifer.local> (raw)
In-Reply-To: <0af1bc20-8ba2-c6b6-64e6-c1f58d521504@redhat.com>
On Tue, Aug 01, 2023 at 11:05:40AM +0200, David Hildenbrand wrote:
> On 31.07.23 23:50, Lorenzo Stoakes wrote:
> > Some architectures do not populate the entire range categorised by
> > KCORE_TEXT, so we must ensure that the kernel address we read from is
> > valid.
> >
> > Unfortunately there is no solution currently available to do so with a
> > purely iterator solution so reinstate the bounce buffer in this instance so
> > we can use copy_from_kernel_nofault() in order to avoid page faults when
> > regions are unmapped.
> >
> > This change partly reverts commit 2e1c0170771e ("fs/proc/kcore: avoid
> > bounce buffer for ktext data"), reinstating the bounce buffer, but adapts
> > the code to continue to use an iterator.
> >
> > Fixes: 2e1c0170771e ("fs/proc/kcore: avoid bounce buffer for ktext data")
> > Reported-by: Jiri Olsa <olsajiri@gmail.com>
> > Closes: https://lore.kernel.org/all/ZHc2fm+9daF6cgCE@krava
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
> > ---
> > fs/proc/kcore.c | 26 +++++++++++++++++++++++++-
> > 1 file changed, 25 insertions(+), 1 deletion(-)
> >
> > diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
> > index 9cb32e1a78a0..3bc689038232 100644
> > --- a/fs/proc/kcore.c
> > +++ b/fs/proc/kcore.c
> > @@ -309,6 +309,8 @@ static void append_kcore_note(char *notes, size_t *i, const char *name,
> > static ssize_t read_kcore_iter(struct kiocb *iocb, struct iov_iter *iter)
> > {
> > + struct file *file = iocb->ki_filp;
> > + char *buf = file->private_data;
> > loff_t *fpos = &iocb->ki_pos;
> > size_t phdrs_offset, notes_offset, data_offset;
> > size_t page_offline_frozen = 1;
> > @@ -554,11 +556,22 @@ static ssize_t read_kcore_iter(struct kiocb *iocb, struct iov_iter *iter)
> > fallthrough;
> > case KCORE_VMEMMAP:
> > case KCORE_TEXT:
> > + /*
> > + * Sadly we must use a bounce buffer here to be able to
> > + * make use of copy_from_kernel_nofault(), as these
> > + * memory regions might not always be mapped on all
> > + * architectures.
> > + */
> > + if (copy_from_kernel_nofault(buf, (void *)start, tsz)) {
> > + if (iov_iter_zero(tsz, iter) != tsz) {
> > + ret = -EFAULT;
> > + goto out;
> > + }
> > /*
> > * We use _copy_to_iter() to bypass usermode hardening
> > * which would otherwise prevent this operation.
> > */
>
> Having a comment at this indentation level looks for the else case looks
> kind of weird.
Yeah, but having it indented again would be weird and seem like it doesn't
apply to the block below, there's really no good spot for it and
checkpatch.pl doesn't mind so I think this is ok :)
>
> (does that comment still apply?)
Hm good point, actually, now we're using the bounce buffer we don't need to
avoid usermode hardening any more.
However since we've established a bounce buffer ourselves its still
appropriate to use _copy_to_iter() as we know the source region is good to
copy from.
To make life easy I'll just respin with an updated comment :)
>
>
> --
> Cheers,
>
> David / dhildenb
>
next prev parent reply other threads:[~2023-08-01 17:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-31 21:50 Lorenzo Stoakes
2023-07-31 22:11 ` Jiri Olsa
2023-08-01 8:27 ` Will Deacon
2023-08-01 9:05 ` David Hildenbrand
2023-08-01 16:33 ` Lorenzo Stoakes [this message]
2023-08-01 16:34 ` David Hildenbrand
2023-08-01 16:39 ` Lorenzo Stoakes
2023-08-01 18:14 ` David Hildenbrand
2023-08-01 15:57 ` Baoquan He
2023-08-01 16:01 ` Baoquan He
2023-08-01 16:22 ` Lorenzo Stoakes
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=dc30a97b-853e-4d2a-b171-e68fb3ab026c@lucifer.local \
--to=lstoakes@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=axboe@kernel.dk \
--cc=bhe@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=david@redhat.com \
--cc=efault@gmx.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liushixin2@huawei.com \
--cc=mark.rutland@arm.com \
--cc=olsajiri@gmail.com \
--cc=regressions@leemhuis.info \
--cc=regressions@lists.linux.dev \
--cc=stable@vger.kernel.org \
--cc=urezki@gmail.com \
--cc=viro@zeniv.linux.org.uk \
--cc=wangkefeng.wang@huawei.com \
--cc=will@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox