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: <1016.1177055893@redhat.com>
Date:	Fri, 20 Apr 2007 08:58:13 +0100
From:	David Howells <dhowells@...hat.com>
To:	"Aubrey Li" <aubreylee@...il.com>
Cc:	"Robin Getz" <rgetz@...ckfin.uclinux.org>, uaca@...mni.uv.es,
	bryan.wu@...log.com, "Alan Cox" <alan@...rguk.ukuu.org.uk>,
	waltje@...lt.nl.mugnet.org, netdev@...r.kernel.org,
	"Andrew Morton" <akpm@...l.org>,
	"Linux Kernel" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] CONFIG_PACKET_MMAP should depend on MMU 

Aubrey Li <aubreylee@...il.com> wrote:

> The patch works properly on my side. But
> 1) I'm not sure why you re-wrote alloc/free_pg_vec function, doesn't
> the current implement work for NOMMU? I know you want to allocate the
> entire data buffer as one contiguous lump, but is it really necessary?

Yes.  It's not possible to map the whole buffer otherwise.  Think about it!
mmap() returns _one_ reference address.  In MMU-mode, the non-contiguous
physical buffers can be made to appear virtually contiguous by fudging the
page tables and using the MMU.  This is not possible in NOMMU-mode.  The app
will expect the buffer to be one contiguous lump in its address space, and
will not be able to locate the other segments of the buffer.

Actually, what I said is not quite true.  It is possible to map the whole
buffer otherwise: I could lift the restriction that requires that you map the
whole buffer or not at all, and then userspace could stitch the whole lot
together itself.  This would then require userspace to be bimodal.

> 2) So the mapped pages doesn't count into NR_FILE_MAPPED, is it a problem?

Not really, no - there are no pagetables.

Furthermore, issuing the PACKET_RX_RING sockopt does the entire allocation.
Any subsequent mmaps on it have little effect.

We could do that accounting though if you think it'd be better.  I don't
suppose it hurts.

David
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ