svn commit: r277643 - in head/sys: arm/arm dev/mem i386/i386 mips/mips sparc64/sparc64

[Alan Cox]

On 01/24/2015 09:42, Konstantin Belousov wrote:
> On Sat, Jan 24, 2015 at 07:56:37AM -0700, Ian Lepore wrote:
>> On Sat, 2015-01-24 at 12:51 +0000, Konstantin Belousov wrote:
>>> Author: kib
>>> Date: Sat Jan 24 12:51:15 2015
>>> New Revision: 277643
>>> URL: https://svnweb.freebsd.org/changeset/base/277643
>>>
>>> Log:
>>>   Remove Giant from /dev/mem and /dev/kmem.  It is definitely not needed
>>>   for i386, and from the code inspection, nothing in the
>>>   arm/mips/sparc64 implementations depends on it.
>>>   
>> I'm not sure I agree with that.  On arm the memrw() implementation uses
>> a single statically-allocated page of kva space into which it maps each
>> physical page in turn in the main loop.  What prevents preemption or
>> multicore access to /dev/mem from trying to use that single page for
>> multiple operations at once?
> I see, thank you for noting this.
>
> But, I do not think that Giant is a solution for the problem. uiomove()
> call accesses userspace, which may fault and cause sleep. If the
> thread sleeps, the Giant is automatically dropped, so there is no real
> protection.
>
> I think dump exclusive sx around whole memrw() should be enough.
>
> I can revert the commit for now, or I can leave it as is while
> writing the patch with sx and waiting for somebody review.  What
> would you prefer ?
>
> P.S. mips uses uiomove_fromphys(), avoiding transient mapping,
> and sparc allocates KVA when needed.
>
>

While we're here, it's worth noting that the arm version of /dev/mem is
not functionally equivalent to that of amd64 or i386.  Arm disallows
access to non-DRAM addresses through /dev/mem.