[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <bad5dc54-f614-430a-a6a2-e96fea6ce1ec@lucifer.local>
Date: Wed, 22 Mar 2023 18:36:59 +0000
From: Lorenzo Stoakes <lstoakes@...il.com>
To: David Hildenbrand <david@...hat.com>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Baoquan He <bhe@...hat.com>,
Uladzislau Rezki <urezki@...il.com>,
Matthew Wilcox <willy@...radead.org>,
Liu Shixin <liushixin2@...wei.com>,
Jiri Olsa <jolsa@...nel.org>, Jens Axboe <axboe@...nel.dk>,
Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH v6 4/4] mm: vmalloc: convert vread() to vread_iter()
On Wed, Mar 22, 2023 at 06:02:34PM +0100, David Hildenbrand wrote:
> On 22.03.23 15:55, Lorenzo Stoakes wrote:
> > Having previously laid the foundation for converting vread() to an iterator
> > function, pull the trigger and do so.
> >
> > This patch attempts to provide minimal refactoring and to reflect the
> > existing logic as best we can, for example we continue to zero portions of
> > memory not read, as before.
> >
> > Overall, there should be no functional difference other than a performance
> > improvement in /proc/kcore access to vmalloc regions.
> >
> > Now we have eliminated the need for a bounce buffer in read_kcore_iter(),
> > we dispense with it, and try to write to user memory optimistically but
> > with faults disabled via copy_page_to_iter_nofault(). We already have
> > preemption disabled by holding a spin lock.
> >
> > If this fails, we fault in and retry a single time. This is a conservative
> > approach intended to avoid spinning on vread_iter() if we repeatedly
> > encouter issues reading from it.
>
> I have to ask again: Can you comment why that is ok? You might end up
> signaling -EFAULT to user space simply because swapping/page
> migration/whatever triggered at the wrong time.
>
> That could break existing user space or which important part am I missing?
>
Actually you're right, this is not ok. I was being mistakenly overcautious
about spinning but in actual fact I don't think this would be an issue
here.
I will respin with a while loop so under no odd timing circumstance do we
break userland.
> --
> Thanks,
>
> David / dhildenb
>
Powered by blists - more mailing lists