Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp7094010ybi; Thu, 1 Aug 2019 03:07:04 -0700 (PDT) X-Google-Smtp-Source: APXvYqzX94x+2knuF/rbtWOmDKnOVBnVwRwTU17bqLTX3fWNlzMzUIy5wbkBW/7K4QV3lG1DYSdj X-Received: by 2002:a17:90a:db52:: with SMTP id u18mr7803489pjx.107.1564654024297; Thu, 01 Aug 2019 03:07:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564654024; cv=none; d=google.com; s=arc-20160816; b=guO6CyBDIUY8y/ZkmEh3mCofCHjtWfnqrRPCX/sIAtOOczKU2pQniRjgydoTMbLhPk SynYQvgJow0VzMj7D2W95Yz7ww+VzoCH/kDH4lf2WDP7QWbraNrWSPAZU+BXSwAFBX39 EAR7i0Mlf9u+idlb3gNySmVQefGzsGvqZLmYSABf/LijpNtN8BEX13qpyDzEBDEty47H f6lem3//r+Jzo0ONPNbVdxuC8Wxbot6XA0z3fsWKHMxhL2JCTmoODR54Mp3IQb+pEZiN IzAw3s8sJHUYiKsCZr9PGhpefFA83YV9ntjkk63rMbzA+iebKOQQETVXJAgw+IrsDA1f WeRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :references:subject:cc:to:mime-version:user-agent:reply-to:from:date :message-id:dkim-signature; bh=dq2P+/tLnoednMG8zhzVQMUzH/VeX5hFM/9G4yMQw70=; b=Ri5O2rRr9ErF3b/CqZSEAz9rOgiLEW7JPtUsjo3U2njknJxA82s5wRvr+wK+B0NsTk Rj3QzafPdUeTiKwdH6IVB/dyEBgO020d3KjXGY01ffaWKHCBFSwB2eq/zx1ZVBeBt2LZ N6K7NEphYYuCWMU1K3hWZy56UbPys2UJkh8+3c76GLt3tmsvCvp0Mr+O8xM0cpbWoNNp x8x57iqDkH3vnoWUuVcLuDA86sDo4G54k/NtbeXE5KhQh4A6uMD/igp+l6XxelgL+Zni 2Hkrsg+4zI5Eh2NDVUPzLiJTS+w2LJebyKR7Qlt6vXgUbpOz8ytOz2muA4IbmfN+OfBZ 4rfA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@bfs.de header.s=dkim201901 header.b=B5kLBbIB; 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 b61si32164706plb.401.2019.08.01.03.06.48; Thu, 01 Aug 2019 03:07:04 -0700 (PDT) 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; dkim=fail header.i=@bfs.de header.s=dkim201901 header.b=B5kLBbIB; 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 S1729091AbfHAKGN (ORCPT + 99 others); Thu, 1 Aug 2019 06:06:13 -0400 Received: from mx01-fr.bfs.de ([193.174.231.67]:19567 "EHLO mx01-fr.bfs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725379AbfHAKGN (ORCPT ); Thu, 1 Aug 2019 06:06:13 -0400 Received: from mail-fr.bfs.de (mail-fr.bfs.de [10.177.18.200]) by mx01-fr.bfs.de (Postfix) with ESMTPS id 609B02035E; Thu, 1 Aug 2019 12:06:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bfs.de; s=dkim201901; t=1564653965; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dq2P+/tLnoednMG8zhzVQMUzH/VeX5hFM/9G4yMQw70=; b=B5kLBbIBcuuJ7Me4hRA6QS7biC+bydX+j1MCtN42RX31i4l96jV3gUe2J0jNm0Xu3NlJ8t Cu9ARd5Q9MM1Pm8ZIpqRxBnOXM3BJBH65g6eeeLZd5meQZd0nu7Q/ZsihW9MUvFskcdZRL JayzNzB6180FxxzR+AYV44nBPm1s6KC96bn+snss045nfDYw2468AIB2VxSKPQnfyohoDW WNVNRrBwZpFJ9Klp6JSd9p+T+4A9HtgItNQujd/VXqZNOOaC0FQzCGbdAKOFqHCbq6e53e Zchxsv9Pqqh4peaYxfowuXM2/7ZV6YAVxKzOz65EriJkcX02k00Vj3kTKyo1dg== Received: from [134.92.181.33] (unknown [134.92.181.33]) by mail-fr.bfs.de (Postfix) with ESMTPS id E1D87BEEBD; Thu, 1 Aug 2019 12:06:04 +0200 (CEST) Message-ID: <5D42B98B.40900@bfs.de> Date: Thu, 01 Aug 2019 12:06:03 +0200 From: walter harms Reply-To: wharms@bfs.de User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.16) Gecko/20101125 SUSE/3.0.11 Thunderbird/3.0.11 MIME-Version: 1.0 To: Christophe JAILLET CC: jikos@kernel.org, benjamin.tissoires@redhat.com, linux-usb@vger.kernel.org, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org Subject: Re: [PATCH] HID: usbhid: Use GFP_KERNEL instead of GFP_ATOMIC when applicable References: <20190801074759.32738-1-christophe.jaillet@wanadoo.fr> In-Reply-To: <20190801074759.32738-1-christophe.jaillet@wanadoo.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.10 Authentication-Results: mx01-fr.bfs.de X-Spamd-Result: default: False [-3.10 / 7.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[wharms@bfs.de]; BAYES_HAM(-3.00)[100.00%]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_ENVRCPT(0.00)[wanadoo.fr]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; DKIM_SIGNED(0.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; FREEMAIL_TO(0.00)[wanadoo.fr]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 01.08.2019 09:47, schrieb Christophe JAILLET: > There is no need to use GFP_ATOMIC when calling 'usb_alloc_coherent()' > here. These calls are done from probe functions and using GFP_KERNEL should > be safe. > The memory itself is used within some interrupts, but it is not a > problem, once it has been allocated. > > Signed-off-by: Christophe JAILLET > --- > drivers/hid/usbhid/usbkbd.c | 4 ++-- > drivers/hid/usbhid/usbmouse.c | 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/hid/usbhid/usbkbd.c b/drivers/hid/usbhid/usbkbd.c > index d5b7a696a68c..63e8ef8beb45 100644 > --- a/drivers/hid/usbhid/usbkbd.c > +++ b/drivers/hid/usbhid/usbkbd.c > @@ -239,11 +239,11 @@ static int usb_kbd_alloc_mem(struct usb_device *dev, struct usb_kbd *kbd) > return -1; > if (!(kbd->led = usb_alloc_urb(0, GFP_KERNEL))) > return -1; > - if (!(kbd->new = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &kbd->new_dma))) > + if (!(kbd->new = usb_alloc_coherent(dev, 8, GFP_KERNEL, &kbd->new_dma))) > return -1; > if (!(kbd->cr = kmalloc(sizeof(struct usb_ctrlrequest), GFP_KERNEL))) > return -1; > - if (!(kbd->leds = usb_alloc_coherent(dev, 1, GFP_ATOMIC, &kbd->leds_dma))) > + if (!(kbd->leds = usb_alloc_coherent(dev, 1, GFP_KERNEL, &kbd->leds_dma))) > return -1; > the kernel style is usually: kbd->new = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &kbd->new_dma); if (!kbd->new) return -1; in usbmouse.c this is done, any reason for the change here ? re, wh > return 0; > diff --git a/drivers/hid/usbhid/usbmouse.c b/drivers/hid/usbhid/usbmouse.c > index 073127e65ac1..c89332017d5d 100644 > --- a/drivers/hid/usbhid/usbmouse.c > +++ b/drivers/hid/usbhid/usbmouse.c > @@ -130,7 +130,7 @@ static int usb_mouse_probe(struct usb_interface *intf, const struct usb_device_i > if (!mouse || !input_dev) > goto fail1; > > - mouse->data = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &mouse->data_dma); > + mouse->data = usb_alloc_coherent(dev, 8, GFP_KERNEL, &mouse->data_dma); > if (!mouse->data) > goto fail1; >