linux-kernel - Re: Move to unshared VMAs in NOMMU mode?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0703152043290.24211@blonde.wat.veritas.com>
Date:	Thu, 15 Mar 2007 21:20:12 +0000 (GMT)
From:	Hugh Dickins <hugh@...itas.com>
To:	David Howells <dhowells@...hat.com>
cc:	bryan.wu@...log.com, Robin Holt <holt@....com>,
	"Kawai, Hidehiro" <hidehiro.kawai.ez@...achi.com>,
	Andrew Morton <akpm@...l.org>,
	kernel list <linux-kernel@...r.kernel.org>,
	Pavel Machek <pavel@....cz>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	sugita <yumiko.sugita.yf@...achi.com>,
	Satoshi OSHIMA <soshima@...hat.com>, haoki@...hat.com,
	Robin Getz <rgetz@...ckfin.uclinux.org>
Subject: Re: Move to unshared VMAs in NOMMU mode?

On Fri, 9 Mar 2007, David Howells wrote:
> 
> I've been considering how to deal with the SYSV SHM problem, and I think we
> may have to move to unshared VMAs in NOMMU mode to deal with this.  Currently,
> what we have is each mm_struct has in its arch-specific context argument a
> list of VMLs.  Take the FRV context for example:
>... 
> Another way of dealing with the nattch count on NOMMU systems is to do it
> through the VML list, but that then needs more special casing in the SHM
> driver and perhaps others.
> 
> Thoughts?

Thoughts are in regrettably short supply at my end.

I do appreciate all the trouble you've taken to explain it,
in terms I'd understand.  And the way you've taken on board
my anxiety about vma assumptions diverging between NO/MMU.

But if "the SYSV SHM problem" you mention at the beginning
is just the "nattch" problem you mention at the end, I doubt
that's worth such a redesign as you're considering here.

Actually, I'm rather surprised SHM needs any such nattch count,
I'd expect it to deducible from file->f_count and mode&SHM_DEST
(but haven't investigated whether that really works out at all).

If you just need a little CONFIG_MMU in ipc/shm.c to solve your
problem, I don't think more is justified.

Your struct vm_region idea does look more to my taste than what
you presently have; yet if you pursue it, I think it would just
make divergence worse wouldn't it?  NOMMU wanting vma to contain
a pointer to vm_region, MMU wanting vm_region embedded in vma.

I don't really understand why NOMMU chooses to share vmas, or
vm_regions, rather than just sharing the data which they indicate.
Just because you can use less memory that way?  But no need to
justify it now, I'm unlikely to study it in detail.

Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/