Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp133734yba; Mon, 20 May 2019 06:15:25 -0700 (PDT) X-Google-Smtp-Source: APXvYqxpizGzdQ5By5lwTj0lByQS/Qvgjh9Nub/rrJF53cYsXthzRkXKYV4qPojz6tz7xhK5lYE6 X-Received: by 2002:a62:7796:: with SMTP id s144mr23201906pfc.260.1558358125181; Mon, 20 May 2019 06:15:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558358125; cv=none; d=google.com; s=arc-20160816; b=ZSdKT1FDhocQEBXJhpwXEQqqyfw0NIBY9QJ2++15ungljwD8YxW6fn635i019j5tnp FViO9gRjOToZIetZryOKgFwyaKRyt6tTLWHMkVh7JglfBY0fqbdodkE5TdJ362D0VUeJ Od4djy0895AqTr7OUrI6ijAYz2oLav0XSmVSv4oYEUTpSdoi2Y3EuklvvIvv7Ovw4tCF djh141OP9kd+PDYroXur3RbRwYGDiDNQRcX6X+t6r8ETFp/5aHHgYaRMsCK/76WoC9YQ Lcw8P59egi1kTCwWuM1LdcPGMMSnHUMEmuJ3vgwriz1Pv6eSjR+IpAborONH1PCOiTpc wOMA== 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:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id; bh=y5RnlwgXgtcEOd+FL8AfoAJbEGyoQwEcqWceARm5kaw=; b=e1EBDYn0+RHgSGcf47GhZ+pzEPIdqSg15NIfVle7LZAf2Qz9AH58JuoHJloyQXmS2o PmjWLuDcoifQOZp7bFg8jod5ZboU6rA/3jHZycdk9arvFGYuMfdwmjACPVdqzenleATh RFUmzhmjT2BFo9qkL7vBNM8N11GtDThbt9rP5Z7Gn7TW0XD5Fy38FNudYOnklB9Qf5Ec BcedDaMcYfx6VQxvXSuENX9bsB52HQX/X2NLgfkTHqkfB61Iu1aKRlszHKGwLLYwZFzC cXReq4ftZ858FbqRXrejkRUlsuRUeSEqKB1GDGcRVUIt1wt7KU0lr9NjAK6V1ruR72YS cnfQ== 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 x26si18730918pfm.241.2019.05.20.06.15.09; Mon, 20 May 2019 06:15:25 -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; 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 S1731113AbfETJWZ (ORCPT + 99 others); Mon, 20 May 2019 05:22:25 -0400 Received: from mx2.suse.de ([195.135.220.15]:38788 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729598AbfETJWZ (ORCPT ); Mon, 20 May 2019 05:22:25 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 07D5DAF5F; Mon, 20 May 2019 09:22:24 +0000 (UTC) Message-ID: <1558343365.12672.2.camel@suse.com> Subject: Re: [RFC PATCH] usb: host: xhci: allow __GFP_FS in dma allocation From: Oliver Neukum To: Christoph Hellwig , Jaewon Kim Cc: linux-mm@kvack.org, gregkh@linuxfoundation.org, Jaewon Kim , m.szyprowski@samsung.com, ytk.lee@samsung.com, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Date: Mon, 20 May 2019 11:09:25 +0200 In-Reply-To: <20190520055657.GA31866@infradead.org> References: <20190520055657.GA31866@infradead.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.6 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On So, 2019-05-19 at 22:56 -0700, Christoph Hellwig wrote: > Folks, you can't just pass arbitary GFP_ flags to dma allocation > routines, beause very often they are not just wrappers around > the page allocator. > > So no, you can't just fine grained control the flags, but the > existing code is just as buggy. > > Please switch to use memalloc_noio_save() instead. > Hi, we actually do. It is just higher up in the calling path: int usb_reset_device(struct usb_device *udev) { int ret; int i; unsigned int noio_flag; struct usb_port *port_dev; struct usb_host_config *config = udev->actconfig; struct usb_hub *hub = usb_hub_to_struct_hub(udev->parent); if (udev->state == USB_STATE_NOTATTACHED || udev->state == USB_STATE_SUSPENDED) { dev_dbg(&udev->dev, "device reset not allowed in state %d\n", udev->state); return -EINVAL; } if (!udev->parent) { /* this requires hcd-specific logic; see ohci_restart() */ dev_dbg(&udev->dev, "%s for root hub!\n", __func__); return -EISDIR; } port_dev = hub->ports[udev->portnum - 1]; /* * Don't allocate memory with GFP_KERNEL in current * context to avoid possible deadlock if usb mass * storage interface or usbnet interface(iSCSI case) * is included in current configuration. The easist * approach is to do it for every device reset, * because the device 'memalloc_noio' flag may have * not been set before reseting the usb device. */ noio_flag = memalloc_noio_save(); So, do we need to audit the mem_flags again? What are we supposed to use? GFP_KERNEL? Regards Oliver