From owner-svn-src-head@freebsd.org Fri Nov 15 09:18:51 2019 Return-Path: Delivered-To: svn-src-head@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 C46A41C16E9; Fri, 15 Nov 2019 09:18:51 +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 47Dt7v2B6sz47D5; Fri, 15 Nov 2019 09:18:50 +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 xAF9Ibc3076305 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 15 Nov 2019 11:18:40 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua xAF9Ibc3076305 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id xAF9Ib55076304; Fri, 15 Nov 2019 11:18:37 +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 11:18:37 +0200 From: Konstantin Belousov To: Alexander Motin Cc: 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: <20191115091837.GD2707@kib.kiev.ua> References: <201911140439.xAE4dngZ032224@repo.freebsd.org> <20191114101149.GA2707@kib.kiev.ua> <475757c6-3707-540b-0316-cbef278043c2@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475757c6-3707-540b-0316-cbef278043c2@FreeBSD.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: 47Dt7v2B6sz47D5 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.99 / 15.00]; NEURAL_HAM_MEDIUM(-0.99)[-0.988,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2019 09:18:51 -0000 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. I know that it is quite hard to reproduce this issue with modern hardware and bounce busdma on amd64. In reverse, it is quite easy to get it with either i386 PAE or DMAR busdma.