linux-kernel - Re: [PATCH] CONFIG_PACKET

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: <6d6a94c50704200139vb9b24f6y77a6d23544c8f7b9@mail.gmail.com>
Date:	Fri, 20 Apr 2007 16:39:52 +0800
From:	"Aubrey Li" <aubreylee@...il.com>
To:	"David Howells" <dhowells@...hat.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

On 4/20/07, David Howells <dhowells@...hat.com> wrote:
> 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.

Great explanation, thanks, :-)

>
> 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.
>
as checked in packet_set_ring, buffer size must be a multiple of PAGE_SIZE,
--------------------packet_set_ring------------------------
if (unlikely(req->tp_block_size & (PAGE_SIZE - 1)))

So why not use __get_free_pages rather than kmalloc, so that we have
pagetables to count?

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