linux-kernel - Re: [RFC PATCH 1/1] s390/cio: make ccw_device_dma

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 13 Oct 2021 09:29:37 +0200
From:   Vineeth Vijayan <vneethv@...ux.ibm.com>
To:     Halil Pasic <pasic@...ux.ibm.com>
Cc:     Peter Oberparleiter <oberpar@...ux.ibm.com>,
        Heiko Carstens <hca@...ux.ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Christian Borntraeger <borntraeger@...ibm.com>,
        Michael Mueller <mimu@...ux.ibm.com>,
        Cornelia Huck <cohuck@...hat.com>,
        Pierre Morel <pmorel@...ux.ibm.com>,
        linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, bfu@...hat.com
Subject: Re: [RFC PATCH 1/1]  s390/cio: make ccw_device_dma_* more robust

On Tue, 2021-10-12 at 23:32 +0200, Halil Pasic wrote:
> On Tue, 12 Oct 2021 15:36:36 +0200
> Vineeth Vijayan <vneethv@...ux.ibm.com> wrote:
> 
> > Looks good. Thanks.
> > Acked-by: Vineeth Vijayan <vneethv@...ux.ibm.com>
> 
> Can I convince you to upgrade to Reviewed-by?
You got it.

Reviewed-by: Vineeth Vijayan <vneethv@...ux.ibm.com>
> 
> > Some minor questions below.
> > 
> > On Mon, 2021-10-11 at 13:59 +0200, Halil Pasic wrote:
> > > Since commit 48720ba56891 ("virtio/s390: use DMA memory for ccw
> > > I/O
> > > and
> > > classic notifiers") we were supposed to make sure that
> > > virtio_ccw_release_dev() completes before the ccw device and the
> > > attached dma pool are torn down, but unfortunately we did
> > > not.  Before
> > > that commit it used to be OK to delay cleaning up the memory
> > > allocated
> > > by virtio-ccw indefinitely (which isn't really intuitive for guys
> > > used
> > > to destruction happens in reverse construction order), but now we
> > > trigger a BUG_ON if the genpool is destroyed before all memory
> > > allocated
> > > form it.  
> > allocated from it ?
> 
> Yes. And I think I should add "is deallocated." to the end as well,
> because we don't destroy memory, we deallocate it ;)