Received: by 10.223.176.46 with SMTP id f43csp604337wra; Fri, 26 Jan 2018 04:06:09 -0800 (PST) X-Google-Smtp-Source: AH8x226IePA3PdZYTtocNp8TRjeqNxibdCYQNjneyfjp2Ohq2pCg58ij5Be7JK9EbUj9CsZWrhRQ X-Received: by 10.99.106.69 with SMTP id f66mr6364421pgc.283.1516968369641; Fri, 26 Jan 2018 04:06:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516968369; cv=none; d=google.com; s=arc-20160816; b=ZD3rbPTtrqEr3GR9iQkvwCpfRuUaUnwEfIfB8Kz4Q8whVhhmDtlXnPXlpmuvSTB+zR P1Y/ipnzOnWhXc7FXsFOEy1lKkSEvfnUD/hXWf72NpSKgek10q4xBwcxp8/K8WkWciim rBaH018s+0XAx+WjSxcukbdChpOy2rxWeVr/XSBXbaM0RCc2flJo7gd38JgZBKqn7e+D E3t8Yr2LEmR4rtzsrTMhv+jo76NS6nxHDmLWrPeRftI/JZYXksmoBM4Mu8Yu8IFqzgH7 D5Bppjrz57nceBPEERRwn7nTdIo2S5UWCplhX0zshLsQjeBxchMR/iJBbHCdPKCZZEFY ry+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=sKmY/LUYPeShDpHkGfNQLPaHqr0zwyIBKXLdrfBXjLc=; b=kttrlpxxHHwaMkvz59Gsj5TUfgzte1Icf6yKwlMozxnYFzH3HEQ/XnXSsOyhLOlnwe XTZNELRc6R5Yj3eNbjkuzBU/Itd2ZvhyHlYHgvHLvzCtiu0mAoZN6j+/O0ukAh4jlxNP oBddSZ4Mb4n23SyEksbGwCXy85S4wms0c7ACYnIwJQZgY1AVm1JnzIz4h0eA0zeO+rts o2ZE0W7iD71HdfGFz1lDR0gGfJzlazlQgRsONKVZV0EXy3otTs2hpPEDznlCsyhZnMBw UCwMMsMxJodBBhGSmnQWwdD+Gnkk+AcmDS28/Oh9Lzi0AzYnSeIU+yuJUg8jT6wgShnl L2Uw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n17si6286713pfj.302.2018.01.26.04.05.53; Fri, 26 Jan 2018 04:06:09 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751838AbeAZMF1 (ORCPT + 99 others); Fri, 26 Jan 2018 07:05:27 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:36722 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751765AbeAZMF0 (ORCPT ); Fri, 26 Jan 2018 07:05:26 -0500 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.87 #1 (Red Hat Linux)) id 1ef2l0-0001N4-Jp; Fri, 26 Jan 2018 12:05:22 +0000 Date: Fri, 26 Jan 2018 12:05:22 +0000 From: Al Viro To: Jia-Ju Bai Cc: 3chas3@gmail.com, linux-atm-general@lists.sourceforge.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] atm: firestream: Replace GFP_ATOMIC with GFP_KERNEL in fs_send Message-ID: <20180126120522.GX13338@ZenIV.linux.org.uk> References: <1516953627-30983-1-git-send-email-baijiaju1990@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1516953627-30983-1-git-send-email-baijiaju1990@gmail.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 26, 2018 at 04:00:27PM +0800, Jia-Ju Bai wrote: > After checking all possible call chains to fs_send() here, > my tool finds that fs_send() is never called in atomic context. > And this function is assigned to a function pointer "dev->ops->send", > which is only called by vcc_sendmsg() (net/atm/common.c) > through vcc->dev->ops->send(), and vcc_sendmsg() calls schedule(), > it indicates that fs_send() can call functions which may sleep. > Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL. > > This is found by a static analysis tool named DCNS written by myself. The trouble is, places like net/atm/raw.c:65: vcc->send = atm_send_aal0; net/atm/raw.c:74: vcc->send = vcc->dev->ops->send; net/atm/raw.c:83: vcc->send = vcc->dev->ops->send; mean extra call chains. It's *not* just vcc_sendmsg(), and e.g. ret = ATM_SKB(skb)->vcc->send(ATM_SKB(skb)->vcc, skb) ? DROP_PACKET : 1; bh_unlock_sock(sk_atm(vcc)); in pppoatm_send() definitely is called under a spinlock. Looking through the driver (in advanced bitrot, as usual for drivers/atm), I'd say that submit_queue() is fucked in head in the "queue full" case. And judging by the history, had been thus since the original merge...