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
| ||
|
Message-ID: <9561.1176209728@redhat.com> Date: Tue, 10 Apr 2007 13:55:28 +0100 From: David Howells <dhowells@...hat.com> To: Robin Getz <rgetz@...ckfin.uclinux.org> Cc: bryan.wu@...log.com, "Alan Cox" <alan@...rguk.ukuu.org.uk>, waltje@...lt.nl.mugnet.org, "Aubrey Li" <aubreylee@...il.com>, 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 Robin Getz <rgetz@...ckfin.uclinux.org> wrote: > David - I know you have been reworking the noMMU vma handling - is there a > solution to vm_insert_page? The reason vm_insert_page() is being called, I imagine, is because packet_mmap() has to insert mappings to an already existing buffer. All it does is munge the PTEs in that virtual region to point to the buffer. As long as the buffer is completely contiguous (which I don't know for certain), then this function can be trivially reduced in NOMMU-mode to something that just returns the address of the requested part of the buffer. No remapping would be required. However... If the buffer is *not* completely contiguous, then you can still perform mmaps of it - but only where the desired part _is_ contiguous. Alternatively, you can arrange for the buffer to be completely contiguous upfront. Looking at alloc_pg_vec() in af_packet.c, I will place my bets on the latter case. I don't know that this is a problem; it depends on how things work, and that I don't know offhand. If someone can give me a simple test program, I would be able to evaluate it better. David - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists