Received: by 10.192.165.156 with SMTP id m28csp1405833imm; Wed, 18 Apr 2018 09:08:17 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+7B53kZdHFQhhJtz0rKcbSQi0CgMeLTkKJnJMRe5SncFIgxAJwZIEMgOW+wEu0mC+gu5sD X-Received: by 10.99.148.1 with SMTP id m1mr2218185pge.140.1524067697594; Wed, 18 Apr 2018 09:08:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524067697; cv=none; d=google.com; s=arc-20160816; b=HGE/GUjatyFmBJvRcknR8g6oZU7qT3O/Uql7+wABJzXARo+ftTdQecJYweyB0vHvMg Rxtjsuj3N1n5eACyUWzyR6ekZms1UJfSd3tBu9oqME77Fcd34BZFT/4noh0/NMoz6kv8 l8QYS+p1HoRtBaQDzT30tObtPF7k6ptslcDtX7NmBnaVfq3/8X138a8RFXIEdJjHPSEk dkVDpJGu29ykQkCPcYjOCE2N3JDFD7ug7zy7lElFcGlYDjwqah769+/HviLSP7kZIEYv SfriNZYPfzThcOXxfeuF08hPWaaiA1hDroElkeDYu2HfrydEr5DiW811cGHI2RZmqHeY cZOA== 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=lciFgC29b6fvIkURenqc3Z/pbJED3oRhetDXQh6AT90=; b=YiKj+LgIcntMPAhcgPUzqcyBjXSDDNE6qW+2oSrx0Dsdu4lmuc6RJ0bo0GqjE9h/kt INlYGU6MpM9E/emzGLNAkSwsUGlhqJc5qXOvt2jnagrl60l8jieezkODBDfmq1zordXY KwWzxggsogh9Lqihw7SBsFMjybgiAk3avy2aO+/6rD/mssw4HvTg4fkA97rtBeTQZQ+5 H3UlaPodMHC033nOXSRjrGreBkJjk/gTr42uIdvebUFCUXV8+a6QZLFgNuZrjJF+ypzD 0qzUfTFU0SVS0TO8MlKHiLwE0fJGxiiSiUemf0Aj3lp4nXggcEz/aUoryVsedttto3/a VXZQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=BsL3LfvV; 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 u9-v6si1552081plz.10.2018.04.18.09.08.03; Wed, 18 Apr 2018 09:08:17 -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=BsL3LfvV; 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 S1753165AbeDRQGA (ORCPT + 99 others); Wed, 18 Apr 2018 12:06:00 -0400 Received: from mail-pf0-f195.google.com ([209.85.192.195]:33095 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753126AbeDRQF5 (ORCPT ); Wed, 18 Apr 2018 12:05:57 -0400 Received: by mail-pf0-f195.google.com with SMTP id f15so1138970pfn.0; Wed, 18 Apr 2018 09:05:57 -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=lciFgC29b6fvIkURenqc3Z/pbJED3oRhetDXQh6AT90=; b=BsL3LfvVa0ojaAKSrubY5+s8oirI3UjTiBJtpVyTfagHs+hzfH8oEbwNmcIeYd5v0a suuF0dAlnwfHFiotKEGy3wheS8UZ5ocBoyvnIjWso3y6rfRfwulUaElRmqBcZTcnmuAr tBHSI/iOTbRjqp1pYDYn86tyy/8LK0JKV8MpcDLZj/Qh3GtzPsNidA7sPUstXesyfuls 1soL4HYPWJeOUQhAZx4SGA3VXg2G76JfDcMCyPbAaNwCU9kNLboFA3T3R/0k/uz0q13F dYfKdU40KPmcm7L0kk0pg8R1utzgkoileFzRBhgQ91BKYVStY1GFOLdwZ16RpEGo8CJQ fpKA== 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=lciFgC29b6fvIkURenqc3Z/pbJED3oRhetDXQh6AT90=; b=emCx1MnGtHbVfX33ewJSfed9956F4ktarYv6oloJvFdlUPSaRjrfoWY/Tj6EO5HZ49 Wm2Q1nThFpPHrD2EMcAcG0euhu+bHR3WpuueYYdu83rWh3vdA0G52qFJwMA8W/Totgy8 c6ovWZJIzwGDcDoT872HmB5i5zFmB+FMv7K3BHEotvi06VYfy/fpyCjBzr65k/AAnbg6 SDbtLiPyTU44vjyESct5idIL7TDg2TIRTAWduZ/To8NuN/Q9PqDvK96T2OWnvtCAnDBv BeoulqpXv9V1VayoS7rKhuP7KMCAeW/rdRoJmxzekzJjKBJWpcj0KyjGxz2+wnq5yahZ EZ/A== X-Gm-Message-State: ALQs6tD5zt2zj+7rwAAkmKTIJWwNE++YhSmrKWm4lEvg677eh2RrCN84 PYJMOXluZFw6VV7wLw8VNqZ7xRu0 X-Received: by 10.101.83.139 with SMTP id x11mr2246591pgq.15.1524067556639; Wed, 18 Apr 2018 09:05:56 -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 a15sm5381110pgd.25.2018.04.18.09.05.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Apr 2018 09:05:55 -0700 (PDT) Subject: Re: [PATCH] net: don't use kvzalloc for DMA memory To: Mikulas Patocka , "David S. Miller" , Eric Dumazet Cc: Joby Poriyath , Ben Hutchings , netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: From: Eric Dumazet Message-ID: <3e65977e-53cd-bf09-bc4b-0ce40e9091fe@gmail.com> Date: Wed, 18 Apr 2018 09:05:54 -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: 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 07:34 AM, Mikulas Patocka wrote: > The patch 74d332c13b21 changes alloc_netdev_mqs to use vzalloc if kzalloc > fails (later patches change it to kvzalloc). > > The problem with this is that if the vzalloc function is actually used, > virtio_net doesn't work (because it expects that the extra memory should > be accessible with DMA-API and memory allocated with vzalloc isn't). > > This patch changes it back to kzalloc and adds a warning if the allocated > size is too large (the allocation is unreliable in this case). > > Signed-off-by: Mikulas Patocka > Fixes: 74d332c13b21 ("net: extend net_device allocation to vmalloc()") > > --- > net/core/dev.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > Index: linux-2.6/net/core/dev.c > =================================================================== > --- linux-2.6.orig/net/core/dev.c 2018-04-16 21:08:36.000000000 +0200 > +++ linux-2.6/net/core/dev.c 2018-04-18 16:24:43.000000000 +0200 > @@ -8366,7 +8366,8 @@ struct net_device *alloc_netdev_mqs(int > /* ensure 32-byte alignment of whole construct */ > alloc_size += NETDEV_ALIGN - 1; > > - p = kvzalloc(alloc_size, GFP_KERNEL | __GFP_RETRY_MAYFAIL); > + WARN_ON(alloc_size > PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER); > + p = kzalloc(alloc_size, GFP_KERNEL | __GFP_RETRY_MAYFAIL); > if (!p) > return NULL; > > Since when a net_device needs to be in DMA zone ??? I would rather fix virtio_net, this looks very suspect to me. Each virtio_net should probably allocate the exact amount of DMA-memory it wants, instead of expecting core networking stack to have a huge chunk of DMA-memory for everything.