linux-kernel - [PATCH RFC 0/3] scsi: mpt: Refactor and port to 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-next>] [day] [month] [year] [list]

Date:   Thu,  3 Sep 2020 16:28:29 +0100
From:   Alex Dewar <alex.dewar90@...il.com>
To:     unlisted-recipients:; (no To-header on input)
Cc:     Sathya Prakash <sathya.prakash@...adcom.com>,
        Sreekanth Reddy <sreekanth.reddy@...adcom.com>,
        Suganath Prabu Subramani 
        <suganath-prabu.subramani@...adcom.com>,
        MPT-FusionLinux.pdl@...adcom.com, linux-scsi@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: [PATCH RFC 0/3] scsi: mpt: Refactor and port to dma_* interface

Hi all,

I started porting over the mpt code from using the old pci_* compat
functions to their dma_* counterparts, but realised that there are many
functions which have a sleepFlags argument, which is actually almost
never actually needed: almost all of the functions are always called
with sleepFlag == CAN_SLEEP anyway. The first patch fixes these cases
and could be applied by itself as a general tidy-up.

The other two patches are functional changes and so I added the RFC tag
just to be extra cautious. Both of these patches involve changing some
allocations from GFP_ATOMIC to GFP_KERNEL so I wanted to make sure that
I wasn't introducing bugs. (Related question: Can you sleep in an ioctl
context....?)

Any feedback would be greatly appreciated!

Best,
Alex