linux-kernel - Re: [PATCH] firewire: sbp2: Replace GFP_ATOMIC with GFP_KERNEL in sbp2_scsi

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: <20180723142418.4aef4910@kant>
Date:   Mon, 23 Jul 2018 14:24:18 +0200
From:   Stefan Richter <stefanr@...6.in-berlin.de>
To:     Jia-Ju Bai <baijiaju1990@...il.com>
Cc:     linux1394-devel@...ts.sourceforge.net,
        linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: Re: [PATCH] firewire: sbp2: Replace GFP_ATOMIC with GFP_KERNEL in
 sbp2_scsi_queuecommand()

Adding Cc: LSML

On Jul 23 Jia-Ju Bai wrote:
> sbp2_scsi_queuecommand() is only set to .queuecommand of 
> "struct scsi_host_template", and this function pointer is never called
> in atomic context.

As far as I remember, scsi_host_template::queuecommand() can be invoked
from either process context or tasklet context, predominantly the latter.

I haven't followed recent developments of the block and scsi stack, hence
don't know if this has changed fundamentally.

But even if it is purely process context now and no spinlocks held, the
memory allocation must be done so that the kernel does not go into memory
reclaim. Otherwise this could deadlock.

> sbp2_scsi_queuecommand() calls kzalloc() with GFP_ATOMIC,
> which is not necessary.
> GFP_ATOMIC can be replaced with GFP_KERNEL.
> 
> This is found by a static analysis tool named DCNS written by myself.

I doubt that static analysis, even if very sophisticated, can detect
deadlock scenarios such as I noted.

> I also manually check the kernel code before reporting it.

What does it mean?  Did you run-time test it, for which actual SBP-2
hardware is required?  (Such a test could detect GFP-KERNEL use in atomic
context, but would not reliably detect memory reclaim related deadlocks.)

> Signed-off-by: Jia-Ju Bai <baijiaju1990@...il.com>
> ---
>  drivers/firewire/sbp2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/firewire/sbp2.c b/drivers/firewire/sbp2.c
> index 6bac03999fd4..a7cd9d87eb02 100644
> --- a/drivers/firewire/sbp2.c
> +++ b/drivers/firewire/sbp2.c
> @@ -1463,7 +1463,7 @@ static int sbp2_scsi_queuecommand(struct Scsi_Host *shost,
>  	struct sbp2_command_orb *orb;
>  	int generation, retval = SCSI_MLQUEUE_HOST_BUSY;
>  
> -	orb = kzalloc(sizeof(*orb), GFP_ATOMIC);
> +	orb = kzalloc(sizeof(*orb), GFP_KERNEL);
>  	if (orb == NULL)
>  		return SCSI_MLQUEUE_HOST_BUSY;
>  

NACK for GFP_KERNEL, but I am curious whether a weaker GFP set than ATOMIC
is possible in scsi_host_template::queuecommand.
-- 
Stefan Richter
-======---=- -=== =-===
http://arcgraph.de/sr/