Date: Tue, 7 May 2019 21:24:57 -0400 From: Tycho Nightingale <tychon@freebsd.org> To: cem@freebsd.org Cc: src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r346645 - in head/sys: compat/linuxkpi/common/include/linux compat/linuxkpi/common/src sys Message-ID: <6991C64C-D105-423F-B66A-4E2B2924565F@freebsd.org> In-Reply-To: <CAG6CVpUeq0%2BckY2-r_K7Yj4e78T1WPjrtYUrbUC0NTkt%2Bg0Hiw@mail.gmail.com> References: <201904242030.x3OKUkgN073331@repo.freebsd.org> <CAG6CVpUeq0%2BckY2-r_K7Yj4e78T1WPjrtYUrbUC0NTkt%2Bg0Hiw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, > On May 7, 2019, at 9:13 PM, Conrad Meyer <cem@freebsd.org> wrote: >=20 > Hi Tycho, >=20 > On Wed, Apr 24, 2019 at 1:31 PM Tycho Nightingale <tychon@freebsd.org> = wrote: >>=20 >> Author: tychon >> Date: Wed Apr 24 20:30:45 2019 >> New Revision: 346645 >> URL: https://svnweb.freebsd.org/changeset/base/346645 >>=20 >> Log: >> LinuxKPI should use bus_dma(9) to be compatible with an IOMMU >>=20 >> Reviewed by: hselasky, kib >> Tested by: greg@unrelenting.technology >> Sponsored by: Dell EMC Isilon >> Differential Revision: https://reviews.freebsd.org/D19845 >> ... >> Modified: head/sys/compat/linuxkpi/common/src/linux_pci.c >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> --- head/sys/compat/linuxkpi/common/src/linux_pci.c Wed Apr 24 = 19:56:02 2019 (r346644) >> +++ head/sys/compat/linuxkpi/common/src/linux_pci.c Wed Apr 24 = 20:30:45 2019 (r346645) >> ... >> +linux_dma_map_phys(struct device *dev, vm_paddr_t phys, size_t len) >> +{ >> ... >> + nseg =3D -1; >> + mtx_lock(&priv->dma_lock); >> + if (_bus_dmamap_load_phys(priv->dmat, obj->dmamap, phys, len, >> + BUS_DMA_NOWAIT, &seg, &nseg) !=3D 0) { >> + bus_dmamap_destroy(priv->dmat, obj->dmamap); >> + mtx_unlock(&priv->dma_lock); >> + uma_zfree(linux_dma_obj_zone, obj); >> + return (0); >> + } >> + mtx_unlock(&priv->dma_lock); >> + >> + KASSERT(++nseg =3D=3D 1, ("More than one segment (nseg=3D%d)", = nseg)); >=20 > This construct is a bit odd. Coverity produces the (perhaps spurious) > warning (CID 1401319) that the KASSERT (which can be compiled out in > !INVARIANTS builds) has a side effect (++nseg). While true, nseg is > never used afterwards, so perhaps we can use the equivalent expression > with no side effect instead? I.e., something like: >=20 > KASSERT(nseg =3D=3D 0, ("More than one segment (nseg=3D%d)", nseg + = 1)); >=20 > Does that make sense? It is a false positive of sorts, but performing > side effects in compiled-out assert is a pretty strong antipattern so > I'd just as soon "fix" the warning. The construct is indeed a little odd and mimics how other callers of = _bus_dmamap_load_phys() handle the bizarre way nseg is treated. There = isn=E2=80=99t any reason for it and in hindsight I prefer your version = =E2=80=94 especially if it eliminates this Coverity issue. Tycho=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6991C64C-D105-423F-B66A-4E2B2924565F>