linux-kernel - Re: [PATCH v2 03/19] scsi: libsas: Introduce a

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210112171253.ues2euwoszf7mz4z@linutronix.de>
Date:   Tue, 12 Jan 2021 18:12:53 +0100
From:   "Sebastian A. Siewior" <bigeasy@...utronix.de>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     "Ahmed S. Darwish" <a.darwish@...utronix.de>,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        John Garry <john.garry@...wei.com>,
        Jason Yan <yanaijie@...wei.com>,
        Daniel Wagner <dwagner@...e.de>,
        Artur Paszkiewicz <artur.paszkiewicz@...el.com>,
        Jack Wang <jinpu.wang@...ud.ionos.com>,
        linux-scsi@...r.kernel.org, intel-linux-scu@...el.com,
        LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v2 03/19] scsi: libsas: Introduce a _gfp() variant of
 event notifiers

On 2021-01-12 15:45:12 [+0000], Christoph Hellwig wrote:
> What is the problem with simply adding a gfp_t argument to the existing
> calls?  The end result of this series looks fine, but the way we get
> there looks extremely cumbersome.

Maybe I don't understand you fully but if you want to avoid adding the
two _gftp functions (+ remove the other & rename at the end of series)
and passing the gfp_t argument right away then this what I had in my
inbox at the very beginning.
It was one big patch with a long description of the relevant code paths
and why it is the way it is. Since the two functions are used by many
drivers you had to patch all at once. So I suggested to split in smaller
chunks to make it easier to review (and bisect) and at the end the old
functions can be removed once all users are gone (and rename if the
maintainer wishes).
Once we had the individual patches for driver/folder it was easier to
review them. Then we also identified the first few patches which got the
Fixes: tag because in_interrupt() didn't take disabled interrupts into
account.

Sebastian