Messages in this thread | | | From | "Longpeng (Mike, Cloud Infrastructure Service Product Dept.)" <> | Subject | RE: [RFC PATCH 0/5] madvise MADV_DOEXEC | Date | Tue, 13 Jul 2021 00:57:59 +0000 |
| |
Hi Matthew,
> -----Original Message----- > From: Matthew Wilcox [mailto:willy@infradead.org] > Sent: Monday, July 12, 2021 9:30 AM > To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.) > <longpeng2@huawei.com> > Cc: Steven Sistare <steven.sistare@oracle.com>; Anthony Yznaga > <anthony.yznaga@oracle.com>; linux-kernel@vger.kernel.org; > linux-mm@kvack.org; Gonglei (Arei) <arei.gonglei@huawei.com> > Subject: Re: [RFC PATCH 0/5] madvise MADV_DOEXEC > > On Mon, Jul 12, 2021 at 09:05:45AM +0800, Longpeng (Mike, Cloud > Infrastructure Service Product Dept.) wrote: > > Let me describe my use case more clearly (just ignore if you're not > > interested in it): > > > > 1. Prog A mmap() 4GB memory (anon or file-mapping), suppose the > > allocated VA range is [0x40000000,0x140000000) > > > > 2. Prog A specifies [0x48000000,0x50000000) and > > [0x80000000,0x100000000) will be shared by its child. > > > > 3. Prog A fork() Prog B and then Prog B exec() a new ELF binary. > > > > 4. Prog B notice the shared ranges (e.g. by input parameters or ...) > > and remap them to a continuous VA range. > > This is dangerous. There must be an active step for Prog B to accept Prog A's > ranges into its address space. Otherwise Prog A could almost completely fill > Prog B's address space and so control where Prog B places its mappings. It > could also provoke a latent bug in Prog B if it doesn't handle address space > exhaustion gracefully. > > I had a proposal to handle this. Would it meet your requirements? > https://lore.kernel.org/lkml/20200730152250.GG23808@casper.infradead.org/
I noticed your proposal of project Sileby and I think it can meet Steven's requirement, but I not sure whether it's suitable for mine because there's no sample code yet, is it in progress ?
According to the abstract of Sileby, I have two questions: 1. Would you plan to support the file-mapping memory sharing ? e.g. Prog A's 4G memory is backend with 2M hugetlb. 2. Does each mshare fd only containe one sharing VMA ? For large memory process (1T~4T in our env), maybe there is hundreds of memory ranges need to be shared, this will take too much fd space if so ?
| |