From: Claudio Imbrenda <imbrenda@linux.ibm.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
akpm@linux-foundation.org, jack@suse.cz, kirill@shutemov.name,
david@redhat.com, aarcange@redhat.com, linux-mm@kvack.org,
frankja@linux.ibm.com, sfr@canb.auug.org.au, jhubbard@nvidia.com,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
peterz@infradead.org, sean.j.christopherson@intel.com,
Ulrich.Weigand@de.ibm.com
Subject: Re: [PATCH v1 1/1] fs/splice: add missing callback for inaccessible pages
Date: Thu, 30 Apr 2020 19:19:42 +0200 [thread overview]
Message-ID: <20200430191942.3ae9155f@p-imbrenda> (raw)
In-Reply-To: <172c51f7-7dd6-7dd0-153f-aedd4b10a9f3@intel.com>
On Wed, 29 Apr 2020 16:52:46 -0700
Dave Hansen <dave.hansen@intel.com> wrote:
> On 4/29/20 3:53 PM, Claudio Imbrenda wrote:
> >> Actually, that's the problem. You've gone through all these
> >> careful checks and made the page inaccessible. *After* that
> >> process, how do you keep the page from being hit by an I/O device
> >> before it's made accessible again? My patch just assumes that
> >> *all* pages have gone through that process and passed those
> >> checks.
> > I don't understand what you are saying here.
> >
> > we start with all pages accessible, we mark pages as inaccessible
> > when they are imported in the secure guest (we use the PG_arch_1
> > bit in struct page). we then try to catch all I/O on inaccessible
> > pages and make them accessible so that I/O devices are happy.
>
> The catching mechanism is incomplete, that's all I'm saying.
well, sendto in the end does a copy_from_user or a get_user_pages_fast,
both are covered (once we fix the make_accessible to work on FOLL_GET
too).
> Without looking too hard, and not even having the hardware, I've found
> two paths where the "catching" was incomplete:
>
> 1. sendfile(), which you've patched
> 2. sendto(), which you haven't patched
>
> > either your quick and dirty patch was too dirty (e.g. not accounting
> > for possible races between make_accessible/make_inaccessible), or
> > some of the functions in the trace you provided should do
> > pin_user_page instead of get_user_page (or both)
>
> I looked in the traces for any races. For sendto(), at least, the
> make_accessible() never happened before the process exited. That's
> entirely consistent with the theory that it entirely missed being
> caught. I can't find any evidence that there were races.
>
> Go ahead and try it. You have the patch! I mean, I found a bug in
> about 10 minutes in one tiny little VM.
I tried your patch, but I could not reproduce the problem. I have a
Debian 10 x86_64 with the latest kernel from master and your patch on
top. is there anything I'm missing? which virtual devices are you using?
any particular .config options?
I could easily get the mm_make_accessible tracepoints, but I never
manage to trigger the mm_accessible_error ones.
are you using transparent hugepages by any chance? the
infrastructure for inaccessible pages is meant only for small pages,
since on s390x only small pages can ever be used for secure
guests and therefore become inaccessible.
> And, yes, you need to get rid of the FOLL_PIN check unless you want to
> go change a big swath of the remaining get_user_pages*() sites.
next prev parent reply other threads:[~2020-04-30 17:20 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-28 22:50 Claudio Imbrenda
2020-04-29 0:25 ` Dave Hansen
2020-04-29 16:07 ` Dave Hansen
2020-04-29 17:31 ` Christian Borntraeger
2020-04-29 17:55 ` Dave Hansen
2020-04-29 22:53 ` Claudio Imbrenda
2020-04-29 23:52 ` Dave Hansen
2020-04-30 17:19 ` Claudio Imbrenda [this message]
2020-04-30 17:30 ` Dave Hansen
2020-04-30 18:12 ` Christian Borntraeger
2020-04-30 19:02 ` Christian Borntraeger
2020-04-30 19:54 ` Christian Borntraeger
2020-04-30 22:26 ` John Hubbard
2020-04-30 19:32 ` Dave Hansen
2020-04-30 19:38 ` Christian Borntraeger
2020-04-30 20:01 ` Dave Hansen
2020-04-30 20:03 ` Christian Borntraeger
2020-04-30 19:45 ` Christian Borntraeger
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=20200430191942.3ae9155f@p-imbrenda \
--to=imbrenda@linux.ibm.com \
--cc=Ulrich.Weigand@de.ibm.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=borntraeger@de.ibm.com \
--cc=dave.hansen@intel.com \
--cc=david@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=jack@suse.cz \
--cc=jhubbard@nvidia.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=sean.j.christopherson@intel.com \
--cc=sfr@canb.auug.org.au \
/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