Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Reply-To: dgilbert@interlog.com
Subject: Re: [PATCH] scsi: wd719x Replace GFP_KERNEL with GFP_ATOMIC in
 wd719x_chip_init
To:     Christoph Hellwig <hch@infradead.org>, wangbo <wdjjwb@163.com>
Cc:     linux-kernel@vger.kernel.org, martin.petersen@oracle.com,
        linux-scsi@vger.kernel.org, wang.bo116@zte.com.cn,
        Ondrej Zary <linux@rainbow-software.org>
References: <1547479489-11560-1-git-send-email-wdjjwb@163.com>
 <20190114152943.GA10454@infradead.org>
From:   Douglas Gilbert <dgilbert@interlog.com>
Message-ID: <e7ed2d3c-26f4-1b43-ecfe-2e77d94372b1@interlog.com>
Date:   Mon, 14 Jan 2019 11:31:21 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <20190114152943.GA10454@infradead.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-CA
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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