From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63F5FC282C2 for ; Wed, 13 Feb 2019 17:58:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 39599222B2 for ; Wed, 13 Feb 2019 17:58:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ibnkF7C/" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391736AbfBMR62 (ORCPT ); Wed, 13 Feb 2019 12:58:28 -0500 Received: from mail-pl1-f196.google.com ([209.85.214.196]:38889 "EHLO mail-pl1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729522AbfBMR62 (ORCPT ); Wed, 13 Feb 2019 12:58:28 -0500 Received: by mail-pl1-f196.google.com with SMTP id e5so1539376plb.5 for ; Wed, 13 Feb 2019 09:58:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=lASZGxHTWd4HSfbtlzj3tjKbGIpnX7V2/yDv3yKqG9U=; b=ibnkF7C/RQUPiYdvHtpah07S9tuW3mrEBy/Hd/1MFjxCVVoyk1upTcV0upsmi4U6WX vIRO7VhgNDhEKpHx4iECPPhvorznD7JOkZtytQ99DLEVGZ9O29UZgEx/B/dGpqbWGkUk v+VBjH8fLMXCsBs8/GQdt0QuXv73NHjbSTUMpoJneirGNPmpslzKo8CxLC9BuOS/5ggj OjAQOJEWvQciJDTGHJ1AJw141pamwOS/EssQXJrgkzzQScwg6/rOXgaExS6F+AX4acwG s/PxIsTzp7GBPJb5vT8F0dL2wjWkHhHdddsrNJ7QcxGIcgtbxk/wnOc/n6xC1RGkyMCI E9cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lASZGxHTWd4HSfbtlzj3tjKbGIpnX7V2/yDv3yKqG9U=; b=LmnOfzGb18ezFgkKhoAtt+nLatglkibSlKKLI/E0LC+SBBrA1SOUwfNqu+FkTMvCsd kvChRQF3ot9Com6JMJQQd897OEXzkLEHhe6zhBTAF/dGB5xgt0zq1H2TYniJdl0c8y6e lOmsJpK0w5ZBcsf9pmW5k45lcoRF0DIhgF+aL9pDRTjbSJlYlj5v/5aIivSxt+KkbD/f r39T6gj2R4knT3UyRAu19gQsTLBujXV9BvSfFU/6YtUAzeHaAJhuGVzdq5KK8Rvaqv1D zVqzpFDIYONx4cVDJNTPfZNlNTeUYq2Jo8lp1fiNCk+UjYRzjv4GxnvArzbS+xykIhZd Ujqg== X-Gm-Message-State: AHQUAubyeYoH6Zda+venPnBvNi8dJrgdNxdOkq4R1H4ISQP7RgjGWX3k S5EhEX31NL3e3YXmAYVe7NM= X-Google-Smtp-Source: AHgI3IZJBj34j1vrTS5Bcl4ajr9/WIPDU7SVoEqeAgCQ8UvmIcXge6m51wLhrXRG2khMJOAbrxRXNg== X-Received: by 2002:a17:902:8602:: with SMTP id f2mr1675808plo.263.1550080707903; Wed, 13 Feb 2019 09:58:27 -0800 (PST) Received: from [192.168.86.235] (c-73-241-150-70.hsd1.ca.comcast.net. [73.241.150.70]) by smtp.gmail.com with ESMTPSA id m20sm19333831pgv.93.2019.02.13.09.58.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 09:58:27 -0800 (PST) Subject: Re: [PATCH iproute2] lib/libnetlink: ensure a minimum of 32KB for the buffer used in rtnl_recvmsg() To: Phil Sutter , Eric Dumazet , David Ahern , Stephen Hemminger , netdev , Hangbin Liu References: <20190213015841.140383-1-edumazet@google.com> <20190213174622.GD19329@orbyte.nwl.cc> From: Eric Dumazet Message-ID: <46cf7507-699a-1822-9797-ce352a6fc767@gmail.com> Date: Wed, 13 Feb 2019 09:58:26 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190213174622.GD19329@orbyte.nwl.cc> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 02/13/2019 09:46 AM, Phil Sutter wrote: > Hi Eric, > > On Tue, Feb 12, 2019 at 05:58:41PM -0800, Eric Dumazet wrote: >> In the past, we tried to increase the buffer size up to 32 KB in order >> to reduce number of syscalls per dump. >> >> Commit 2d34851cd341 ("lib/libnetlink: re malloc buff if size is not enough") >> brought the size back to 4KB because the kernel can not know the application >> is ready to receive bigger requests. >> >> See kernel commits 9063e21fb026 ("netlink: autosize skb lengthes") and >> d35c99ff77ec ("netlink: do not enter direct reclaim from netlink_dump()") >> for more details. > > Wouldn't it be better if the kernel recognized MSG_TRUNC and allocated a > buffer large enough to hold the full message in that case? I have no > idea how hard that would be to implement, but calling recvmsg() with > MSG_TRUNC set and not getting the full message length in return is not > quite what one expects after reading recvmsg(2). > I am not sure what you are suggesting. The buffer is already in the kernel, this is the skb in the receive queue. Its size is unknown... We only can guess. We can not change old kernels, and new iproute2/ss commands need to work with old kernels. We can not change MSG_TRUNC semantic. Adding another MSG_be_gentle_do_not_consume_skb_if_user_size_is_too_small wont solve the issue for old kernels.