From owner-svn-src-all@freebsd.org Fri Nov 15 20:03:59 2019 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 624C31AF42D; Fri, 15 Nov 2019 20:03:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47F8SG3HjHz40vh; Fri, 15 Nov 2019 20:03:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id xAFK3oGh029300 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 15 Nov 2019 22:03:53 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua xAFK3oGh029300 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id xAFK3neI029299; Fri, 15 Nov 2019 22:03:49 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 15 Nov 2019 22:03:49 +0200 From: Konstantin Belousov To: Scott Long Cc: Alexander Motin , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r354703 - head/sys/dev/ioat Message-ID: <20191115200349.GI2707@kib.kiev.ua> References: <201911140439.xAE4dngZ032224@repo.freebsd.org> <20191114101149.GA2707@kib.kiev.ua> <475757c6-3707-540b-0316-cbef278043c2@FreeBSD.org> <20191115091837.GD2707@kib.kiev.ua> <842A5858-39B8-4196-8A94-018FA37DE75E@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <842A5858-39B8-4196-8A94-018FA37DE75E@samsco.org> User-Agent: Mutt/1.12.2 (2019-09-21) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 47F8SG3HjHz40vh X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_FIVE(0.00)[5]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(0.00)[ip: (-2.71), ipnet: 2001:470::/32(-4.62), asn: 6939(-3.49), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 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: Fri, 15 Nov 2019 20:03:59 -0000 On Fri, Nov 15, 2019 at 11:09:12AM -0700, Scott Long wrote: > > > > On Nov 15, 2019, at 2:18 AM, Konstantin Belousov wrote: > > > > On Thu, Nov 14, 2019 at 09:41:36AM -0500, Alexander Motin wrote: > >> On 14.11.2019 05:11, Konstantin Belousov wrote: > >>> On Thu, Nov 14, 2019 at 04:39:49AM +0000, Alexander Motin wrote: > >>>> Author: mav > >>>> Date: Thu Nov 14 04:39:48 2019 > >>>> New Revision: 354703 > >>>> URL: https://svnweb.freebsd.org/changeset/base/354703 > >>>> > >>>> Log: > >>>> Pass more reasonable WAIT flags to bus_dma(9) calls. > >>>> > >>>> MFC after: 2 weeks > >>>> > >>>> Modified: > >>>> head/sys/dev/ioat/ioat.c > >>>> > >>>> Modified: head/sys/dev/ioat/ioat.c > >>>> ============================================================================== > >>>> --- head/sys/dev/ioat/ioat.c Thu Nov 14 04:34:58 2019 (r354702) > >>>> +++ head/sys/dev/ioat/ioat.c Thu Nov 14 04:39:48 2019 (r354703) > >>>> @@ -555,13 +555,14 @@ ioat3_attach(device_t device) > >>>> &ioat->comp_update_tag); > >>>> > >>>> error = bus_dmamem_alloc(ioat->comp_update_tag, > >>>> - (void **)&ioat->comp_update, BUS_DMA_ZERO, &ioat->comp_update_map); > >>>> + (void **)&ioat->comp_update, BUS_DMA_ZERO | BUS_DMA_WAITOK, > >>>> + &ioat->comp_update_map); > >>> For waitok, you need to provide locking function in the tag. > >> > >> I'm sorry, but why? It is alloc(), not load(). For load() it makes > >> sense since it calls back, but this is just a form of malloc(), isn't > >> it? I've looked through the both x86 implementations and found nothing > >> suspicious. > > > > I see. Still, if you (or somebody else) ever decided to use WAITOK loads, > > it would be much safer to provide the lock function now. > > > > Loads are always non-blocking, and the WAITOK flag is not part of that > API. A load may defer its callback, and the asynchronous execution of that > callback is why we have the loaned lock. If a blocking alloc is performed in > a context where the caller holds a lock, then it’s the caller’s responsibility > to indicate NOWAIT and deal with the possible failure. Just like with > malloc and contigmalloc, the API does not, nor will it ever, drop and > require locks on behalf of the caller. The API tried to enforce the practice > that static resource allocation should happen at initialization time when > locks don’t need to be held. I only mean that if waitable loads are to be used, now or in future, then the locking function should be supplied. Also I mean that it is easy to forget to supply it because bounce busdma on amd64 and modern DMA engines never delay loading. > > It’s unfortunate that the NOWAIT flag is overloaded for different meanings > in the load functions vs the alloc functions. Maybe this is what is causing > confusion? > > TL;DR: ALexander’s change is correct. > > Scott >