[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 22/33] linux-user: Split out mmap_h_lt_g
From: |
Ilya Leoshkevich |
Subject: |
Re: [PATCH v3 22/33] linux-user: Split out mmap_h_lt_g |
Date: |
Wed, 14 Feb 2024 15:24:38 +0100 |
User-agent: |
Evolution 3.50.3 (3.50.3-1.fc39) |
On Tue, 2024-02-13 at 09:54 -1000, Richard Henderson wrote:
> On 1/29/24 05:26, Ilya Leoshkevich wrote:
> > On Tue, Jan 02, 2024 at 12:57:57PM +1100, Richard Henderson wrote:
> > > Work much harder to get alignment and mapping beyond the end
> > > of the file correct. Both of which are excercised by our
> > > test-mmap for alpha (8k pages) on any 4k page host.
> > >
> > > Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
> > > ---
> > > linux-user/mmap.c | 156 +++++++++++++++++++++++++++++++++++++--
> > > -------
> > > 1 file changed, 125 insertions(+), 31 deletions(-)
> >
> > [...]
> >
> > > + if (fileend_adj) {
> > > + void *t = mmap(p, len - fileend_adj, host_prot,
> > > + (flags & ~MAP_FIXED_NOREPLACE) |
> > > MAP_FIXED,
> > > + fd, offset);
> > > + assert(t != MAP_FAILED);
> >
> > Is it possible to recover here? Of course, we are remapping the
> > memory
> > we've mapped a few lines earlier, but asserting the syscall result
> > looks a bit odd.
> >
>
> Can you think of a failure mode? I couldn't.
> That's why I added the assert.
>
> I suppose there's the always present threat of running out of vmas...
Right, and this should be easy to trigger by using ulimit -v.
>
>
> r~
>