Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755532Ab2BFQ4N (ORCPT ); Mon, 6 Feb 2012 11:56:13 -0500 Received: from mail-ww0-f44.google.com ([74.125.82.44]:40247 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754852Ab2BFQ4L (ORCPT ); Mon, 6 Feb 2012 11:56:11 -0500 Message-ID: <1328547366.2220.83.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> Subject: Re: [patch v1, kernel version 3.2.1] rtnetlink workaround around the skb buff size issue From: Eric Dumazet To: David Miller Cc: steweg@ynet.sk, gregory.v.rose@intel.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Date: Mon, 06 Feb 2012 17:56:06 +0100 In-Reply-To: <20120206.101517.1598607878740481170.davem@davemloft.net> References: <20120203.192933.510206531351047222.davem@davemloft.net> <20120206.101517.1598607878740481170.davem@davemloft.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.2- Content-Transfer-Encoding: 8bit Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 919 Lines: 27 Le lundi 06 février 2012 à 10:15 -0500, David Miller a écrit : > From: Štefan Gula > Date: Mon, 6 Feb 2012 09:53:28 +0100 > > > If I try to request for it, it will eventually fail with a lot of > > records even with filtering... > > Then the user can loop increasing the buffer size until the netlink > request succeeds. > > It is not a problem. Actually we always truncate message in netlink_recvmsg() We could use a MSG_NOPARTIAL flag in netlink_recvmsg() so that user can avoid the MSG_PEEK operation to fetch next message length. (Ie not consume/copy skb if user buffer is too small to hold full message, and only return the needed length) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/