Received: by 10.192.165.156 with SMTP id m28csp1454689imm; Wed, 18 Apr 2018 09:52:52 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/EuUfWganvI2A/+bBXor//luB0G6x6IgtAkvJSMlIFcAIyPELG41LQZ9fVrtXlIU3xuqPk X-Received: by 10.98.89.70 with SMTP id n67mr2673668pfb.150.1524070371975; Wed, 18 Apr 2018 09:52:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524070371; cv=none; d=google.com; s=arc-20160816; b=Ccd851cGmFipVaV45Ojm10DCjFUg34RVTa9kuvzob8FcRqwrUmZW9qFXau3O010HcS kK7qWkXPomyCfaKCGX+A4DoYmqCW4W4rktq67pGlWJ+5RaBOFkHoMRji3hjHgocYFU5y xK5IpwvC0adakgoqWuVcmZ6AqY0BZvmZMRVFKb4WZLHUbhLmiLC59A1Dx0Zs8pKj4cRy 8z2TRF4r4jB7OpohNrfq+IqpwtS12vwCLRnSWqKNHHWUdoZGJQnCat0LX3jtlzerp0oQ iRzGUUAIdaH6NUpu4tCSzOfPvTwil0WgYIP8qhKCDmFOq9D09fgbD6lbxazNHcsBJn7X PTeg== 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=mWaf025QgN7FmqqvevEfZ3Ybg2RYpIbK0eWViyDkgso=; b=NbCouPihfReRt0LbX/UtZdtSrfFLBADr3Bu8CeQTy8nRoA0r3OPnyYKwnR1VZl2WBQ i/nIslTqEld8Mll4iHlORsqabfCZ1b3l6acCcPj2ceOxgYCssmwdWV2QtPGUFZB8p6V4 rF6loVwXwt/Y0IpZ9U8X0WN+KL7hFgwvV063D96TzP/avkjnjXyAczkVMKf1S91r81c5 L2iXTphidO1oIGqj4hsKEFvz/yDPRpFhWm85UZfetWAFouZdqOX/7yB8AHJEawAGK6cr 8dTfG+y8IFzngT6Yxr0bnB5qKPWrhgmD9jvKjxYAOOV5VoKgmp0Viog/RWxYSht4azOL 8AKQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=C+KCBHNw; 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 e5-v6si1505457pls.579.2018.04.18.09.52.37; Wed, 18 Apr 2018 09:52:51 -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=C+KCBHNw; 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 S1752100AbeDRQv3 (ORCPT + 99 others); Wed, 18 Apr 2018 12:51:29 -0400 Received: from mail-pl0-f67.google.com ([209.85.160.67]:41769 "EHLO mail-pl0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751232AbeDRQv1 (ORCPT ); Wed, 18 Apr 2018 12:51:27 -0400 Received: by mail-pl0-f67.google.com with SMTP id bj1-v6so1461931plb.8; Wed, 18 Apr 2018 09:51:27 -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=mWaf025QgN7FmqqvevEfZ3Ybg2RYpIbK0eWViyDkgso=; b=C+KCBHNwz7a6yFnajZH+H1mdoyoWxe07TvtF605+DjiKbuykS97eSvjYJMlQJ97hD0 0JFZX65zEZqG9SSiPckAW1Q4I9WXCL3ONFj6mqRAqkk3G2+txspvQQgfPwUXKEnar3WW dWGZ/4i25QOxHMUf+SPsgxRoTmNKETT/A/szwbXxeszPZ/XZQwE0ixqct4bgOBGwRV7M ZEn8Extkj3SLDkpAQnVKZ9uLr+1EdPS8VY7/dbH8/VWApOWYEkVm8XRkmrjEuWrPJTbC vJ8ah/dKnIwG5o0P71V9dPuZIv14/7SOrZ1ayr8fkLpFVtFUddKdk3nb9QSSyEgL0Tp+ BKvA== 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=mWaf025QgN7FmqqvevEfZ3Ybg2RYpIbK0eWViyDkgso=; b=L6e1sSv1T8FcfjkjzABmy8BfodppNf6l570tspxVqV4C8Kd0fMaLGldvAGlwY4cHeK ALYTQnGg5RYeXOxNci2USdftiY8QeiZHyklojec42gjdoA1pfAzEuMHJrTTGv4HKfAS6 KodIn7Jd0u+GHjUvU75p5l40uHC43v/5oITTSBHflfeFhoMowoaob5iy35HWIwstc4+I WY/qvo8DCcJ7mAD2w7Uc4GvOOXgvdxFwRAfWHLJBXs8g/e9tKACKtcc/QYe8LNE7JD6V 1hE6T+6VQDAHJdfd4uqp6EOQuBS1yRY8b2PY5tlNqmjI2k0PCicC+yS2w1uKL6UNv4Jy g4aw== X-Gm-Message-State: ALQs6tCNnt88xWas9ApKCvA1zg7orI+Hrv1xQ+HLRiavuzWcMuQKahAJ 6qEsUfMqkXz3JGoQUT4tLQg= X-Received: by 2002:a17:902:a506:: with SMTP id s6-v6mr2775687plq.191.1524070287145; Wed, 18 Apr 2018 09:51:27 -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 g11sm3127740pgu.56.2018.04.18.09.51.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Apr 2018 09:51:26 -0700 (PDT) Subject: Re: [PATCH] net: don't use kvzalloc for DMA memory To: Mikulas Patocka , Eric Dumazet Cc: "David S. Miller" , Eric Dumazet , Joby Poriyath , Ben Hutchings , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "Michael S. Tsirkin" , Jason Wang , virtualization@lists.linux-foundation.org References: <3e65977e-53cd-bf09-bc4b-0ce40e9091fe@gmail.com> From: Eric Dumazet Message-ID: <5f4e1286-b79f-0b9f-9a30-47d7654f3889@gmail.com> Date: Wed, 18 Apr 2018 09:51:25 -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 09:44 AM, Mikulas Patocka wrote: > > > On Wed, 18 Apr 2018, Eric Dumazet wrote: > >> >> >> 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. > > The structure net_device is followed by arbitrary driver-specific data > (accessible with the function netdev_priv). And for virtio-net, these > driver-specific data must be in DMA memory. I get that, but how is the original xenvif problem will be solved ? Your patch would add a bug in some other driver(s) I suggest that virtio_net clearly identifies which part needs a specific allocation and does its itself, instead of abusing the netdev_priv storage. Ie use a pointer to a block of memory, allocated by virtio_net, for virtio_net.