Roman Zippel wrote:
>
> Hi,
>
> On Wed, 6 Feb 2002, Andrew Morton wrote:
>
> > Any filesystem which implements its own mmap() method, and which
> > does not call generic_file_mmap() needs to be changed to clear
> > VM_IO inside its mmap function. All in-kernel filesystems are
> > OK, as is XFS. And the only breakage this can cause to out-of-kernel
> > filesystems is failure to include mappings in core files, and
> > inability to use PEEKUSR.
>
> You forgot shared memory via mm/shmem.c and ipc/shm.c.
> Another possibility is to test whether the driver provides a nopage
> function, as i/o areas are usually mapped with io_remap_page_range. The
> only exception I found are drivers under drivers/sgi/char, which use some
> really dirty tricks in their nopage function.
ugh. This just isn't working out.
Sure, inverting the default value of VM_IO is much safer, because
the penalty for getting it wrong is broken coredumps and ptrace,
rather than kernel crashes.
But there are still many areas which need changing, and thinking
about. Stuff like ftape_mmap, sound_mmap, packet_mmap, mmap_mem,
mmap_zero, ...
I'm wondering if we can automagically determine whether the
mapping is safe to peek and coredump within the mmap and mremap
functions themselves? All this would take is the ability to
determine that the entire vma is backed by valid page structs.
Is there a fast and portable way of doing this?
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Feb 07 2002 - 21:01:06 EST