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

[Ian Lepore]

On Sat, 2015-01-24 at 17:42 +0200, 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.

I had planned to look into this today or tomorrow, so no need to revert.
I'll study the other implementations and see what works well for arm.

-- Ian