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

[Konstantin Belousov]

On Sun, Jan 25, 2015 at 10:07:00AM -0700, Warner Losh wrote:
> 
> > On Jan 24, 2015, at 8:51 AM, Konstantin Belousov <kostikbel at gmail.com> wrote:
> > 
> > On Sat, Jan 24, 2015 at 05:42:40PM +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.
> > 
> > Like this.
> 
> So why a sx lock and not a mutex?
I explained this above.  uiomove() needs to sleep on fault.