Received: by 10.192.165.156 with SMTP id m28csp1667195imm; Wed, 18 Apr 2018 13:40:18 -0700 (PDT) X-Google-Smtp-Source: AIpwx48JYiTrF9dVAUwwKsQgQZ9HVI+lx9DGnYPptnpgv5zPEAPiTUYk1zfKSexwjP+yjDOF7D3s X-Received: by 2002:a17:902:bd8d:: with SMTP id q13-v6mr3425588pls.330.1524084018910; Wed, 18 Apr 2018 13:40:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524084018; cv=none; d=google.com; s=arc-20160816; b=fs2tSZ6SASHXFw+Ljh9HSSFjf+ZECkamRLN5Iqm0caNEcXcGpIun35xAcQsX/VfO8g 4Auo6hx4SnnALZFjaStM2NZwKJY8bVOIeeFRYhxgcjah0E7E7dWxxjqkMqs1jNOnlj77 5cpxGtj6lVFgXUX6iQ7u2G1PTGojy4WYcG/e6Wyo1++5v3wG3mquxHAuqW+4QhaUYcS5 CajNeMP3o7sn13RYU3HjcF/W7MYVieG67cHygfnV01gMFuxSGYdLmS43CQGBvglZbQFN tJ8J8LoFCf6mKIlF5gGZ7A9trIzhybytyOIk4Dl9PL95Hq+lHGwQW6TmkdJUD5y+JySr dCNg== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=SxjprHvTjj5c6dKt7bUHuVVtFFJkZQbPJQkVhat74vw=; b=Z4rpSmuHsVSLAyV1sJUli5kJK6x9AAOsqKq3LMMN/tc8oF9gFIWaIONNNpUymaXCMj ccjfXtDdxAlMhn0e9FQazGeoocsh94+BPwUaDBTuzXV/8okYtpwCBVpWCkVPi1/GdwYq us3Re3vCeargxSPwRhvhaljwL3r4mnSYn0cPr1yUsj6aWBdYKX4ZFBELgUw4y1zikvFX Q8pQ0mPa/dWJX6TIXXlSNy89LBMEDjbh114HpXulMDA7ivVuCX0S5tpDlRgFMK21vq7O +adk5KZ+gw7Y0Q0QgVg0Jqr2NsjmmkNoGBULmyAccUnay89g9ChaeMqGfoa2McQfOHps fseg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ksYUnOxU; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 196si1636561pgb.674.2018.04.18.13.40.05; Wed, 18 Apr 2018 13:40:18 -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=pass header.i=@gmail.com header.s=20161025 header.b=ksYUnOxU; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752699AbeDRUis (ORCPT + 99 others); Wed, 18 Apr 2018 16:38:48 -0400 Received: from mail-pl0-f67.google.com ([209.85.160.67]:43453 "EHLO mail-pl0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750872AbeDRUiq (ORCPT ); Wed, 18 Apr 2018 16:38:46 -0400 Received: by mail-pl0-f67.google.com with SMTP id a39-v6so1801164pla.10; Wed, 18 Apr 2018 13:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=SxjprHvTjj5c6dKt7bUHuVVtFFJkZQbPJQkVhat74vw=; b=ksYUnOxUsc/xIuCYk81nf7EFJVR/rhiCNs4DIGVCFclNbF+ipnsvfeJkhWp+Z66EOh 1f8XaqojRghavd0oN5dgexJ/yxQbh2O9yPg4nosfNVdGgReG4i7PB9ITrjKuUPxZueG1 /+wAUkVLBkHBsB3keQQh2xeeuQkWM0k/nuObShjpSWStVZgAaiJrpvX30Cj0acSqy1zJ WmLUJa5BXIoA/L5ZaBm0G67XGyByVXLXQCLRmD5IhBhfLXhc7uaW4Hn9BMbr19fKMEbZ rwy6Hm+gLu//bM8xgA2WPVoWNK3d7l/6PGluXxxJz5/8EW3JvQpO/eqQRkNo/AAmXlJE EcfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SxjprHvTjj5c6dKt7bUHuVVtFFJkZQbPJQkVhat74vw=; b=LQ95Dbo77GyZTEONz5Oh8URk7vddKNDFLGFP3PfZtEXIfLRW2ZN0tSnILTAxla7AbG owYniUmxAc8+Lk2fRPJoRK9YgFhJL6hzqU14DSXE1Akvk8GETv+/T3DGL5NkTYLEG2I/ MMo2tA5mEMzfEEOYlO6HOJvd5wxFuljqDRNOK9pZ4NqoyYGQY6a3Q5FyTGNIqmKK0QNi grIZjLxGAAgbHfpV/LRuazRRSBvgjeM5BYCZffXwND0x+XQ7BeNfchaGRF40HE3ShkIF bf22nmhqYh5CTJC+VVbH+fBMNoArcH5wfh6NqheS4Jh47ZYWv3L0YQIuZ2/fiHGzRDaV n7xA== X-Gm-Message-State: ALQs6tCiNxPMUIusMHTMwYKRtQRM4qPyywcuBiMjkuPBC6RiBNBlIFgQ YB4sfv6NNU0V0SmQEPLHH8UyoIi5 X-Received: by 2002:a17:902:6ac3:: with SMTP id i3-v6mr3416185plt.142.1524083926103; Wed, 18 Apr 2018 13:38:46 -0700 (PDT) Received: from ?IPv6:2620:15c:2c1:103:dcd8:b5d5:bf84:baad? ([2620:15c:2c1:103:dcd8:b5d5:bf84:baad]) by smtp.gmail.com with ESMTPSA id s7sm3761601pfm.114.2018.04.18.13.38.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Apr 2018 13:38:44 -0700 (PDT) Subject: Re: [PATCH] net: don't use kvzalloc for DMA memory To: "Michael S. Tsirkin" , Eric Dumazet Cc: Mikulas Patocka , "David S. Miller" , Eric Dumazet , Joby Poriyath , Ben Hutchings , netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <3e65977e-53cd-bf09-bc4b-0ce40e9091fe@gmail.com> <20180418204229-mutt-send-email-mst@kernel.org> From: Eric Dumazet Message-ID: Date: Wed, 18 Apr 2018 13:38:43 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180418204229-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/18/2018 10:55 AM, Michael S. Tsirkin wrote: > Imagine you want to pass some data to card. > Natural thing is to just put it in a variable and start DMA. > However DMA API disallows stack access nowdays, > so it's natural to put this within struct device. > > See e.g. > > commit a725ee3e44e39dab1ec82cc745899a785d2a555e > Author: Andy Lutomirski > Date: Mon Jul 18 15:34:49 2016 -0700 > > virtio-net: Remove more stack DMA > Andy just moved the problem to another one, since at that time we already had vmalloc() fallback for at least 2 years. Note that my original patch had : p = kzalloc(alloc_size, GFP_KERNEL | __GFP_NOWARN | __GFP_REPEAT); if (!p) p = vzalloc(alloc_size); So really, normal (less than PAGE_SIZE) allocations would have almost-zero-chance to end up to vmalloc(one_page)