linux-kernel - Re: [PATCH] scsi: wd719x Replace GFP_KERNEL with GFP_ATOMIC in wd719x_chip

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 for Android: free password hash cracker in your pocket

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

Message-ID: <e7ed2d3c-26f4-1b43-ecfe-2e77d94372b1@interlog.com>
Date:   Mon, 14 Jan 2019 11:31:21 -0500
From:   Douglas Gilbert <dgilbert@...erlog.com>
To:     Christoph Hellwig <hch@...radead.org>, wangbo <wdjjwb@....com>
Cc:     linux-kernel@...r.kernel.org, martin.petersen@...cle.com,
        linux-scsi@...r.kernel.org, wang.bo116@....com.cn,
        Ondrej Zary <linux@...nbow-software.org>
Subject: Re: [PATCH] scsi: wd719x Replace GFP_KERNEL with GFP_ATOMIC in
 wd719x_chip_init

On 2019-01-14 10:29 a.m., Christoph Hellwig wrote:
> On Mon, Jan 14, 2019 at 11:24:49PM +0800, wangbo wrote:
>> wd719x_host_reset get spinlock first then call wd719x_chip_init,
>> so replace GFP_KERNEL with GFP_ATOMIC in wd719x_chip_init.
> 
> Please move the allocation outside the lock instead.  GFP_ATOMIC
> DMA allocations are generally a bad idea and should be avoided where
> we can.
> 
> More importantly we should never actually trigger the allocation
> under the lock as far as fw_virt will always be set already
> in that case.
> 
> So I think you can safely move the request firmware + allocation
> + memcpy from wd719x_chip_init to wd719x_board_found, but I'd rather
> have Ondrej review that plan.

Further to this, the result of holding a lock (probably with _irqsave()
tacked onto it) during a GFP_KERNEL is a message like this in the log:
    hrtimer: interrupt took 1084 ns

It is not always easy to find since it is a "_once" message. The sg v3
driver (the one in production) produces these. I have been able to stamp
them out by taking care in the sg v4 driver (in testing) around
allocations. It also meant adding a new state in my state machine to
fend off "bad things" happening to that object while it is unlocked.
So there may be a cost to dropping the lock.

Doug Gilbert