From owner-svn-src-all@FreeBSD.ORG Sun Jan 25 17:20:44 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89B969EA; Sun, 25 Jan 2015 17:20:44 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EB55DCE4; Sun, 25 Jan 2015 17:20:43 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t0PHKaED094515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Jan 2015 19:20:36 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t0PHKaED094515 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t0PHKat0094514; Sun, 25 Jan 2015 19:20:36 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 25 Jan 2015 19:20:36 +0200 From: Konstantin Belousov To: Warner Losh Subject: Re: svn commit: r277643 - in head/sys: arm/arm dev/mem i386/i386 mips/mips sparc64/sparc64 Message-ID: <20150125172036.GB42409@kib.kiev.ua> References: <201501241251.t0OCpGa8053192@svn.freebsd.org> <1422111397.1038.53.camel@freebsd.org> <20150124154240.GV42409@kib.kiev.ua> <20150124155117.GW42409@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers , Ian Lepore X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 17:20:44 -0000 On Sun, Jan 25, 2015 at 10:07:00AM -0700, Warner Losh wrote: > > > On Jan 24, 2015, at 8:51 AM, Konstantin Belousov 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.