All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
	coreteam@netfilter.org, netfilter-devel@vger.kernel.org,
	linux-kernel@vger.kernel.org, sameo@linux.intel.com,
	aloisio.almeida@openbossa.org, lauro.venancio@openbossa.org,
	davem@davemloft.net, kadlec@blackhole.kfki.hu, kaber@trash.net
Subject: Re: [PATCH 4/4] netfilter: Fix format string of nfnetlink_queue proc file
Date: Fri, 13 Mar 2015 15:22:07 +0100	[thread overview]
Message-ID: <5502F28F.9050601@nod.at> (raw)
In-Reply-To: <20150313135329.GA6054@salvia>

Am 13.03.2015 um 14:53 schrieb Pablo Neira Ayuso:
> On Fri, Mar 13, 2015 at 02:43:54PM +0100, Richard Weinberger wrote:
>> Am 13.03.2015 um 13:15 schrieb Pablo Neira Ayuso:
>>> On Fri, Mar 13, 2015 at 12:31:16PM +0100, Richard Weinberger wrote:
>>>> The printed values are all of type unsigned integer, therefore use
>>>> %u instead of %d. Otherwise an user can face negative values.
>>>>
>>>> Fixes:
>>>> $ cat /proc/net/netfilter/nfnetlink_queue
>>>>     0  29508   278 2 65531     0 2004213241 -2129885586  1
>>>>     1 -27747     0 2 65531     0     0        0  1
>>>>     2 -27748     0 2 65531     0     0        0  1
>>>
>>> I guess you want to access stats on dropped packets.
>>
>> Correct. :)
>>
>>> I prefer if you extend nfnetlink_queue to provide statistics through
>>> nfnetlink_queue, so you don't have to manually parse this text-based
>>> /proc entry and we can deprecate this interface. That shouldn't have
>>> been there in first place.
>>
>> You mean statistics via netlink attributes? I can add that!
> 
> Add a new NFQNL_CFG_CMD_STATS command to request the statistics. If
> NLM_F_DUMP is set, then we'll basically provide the full list of
> instances. Otherwise, in case you want to retrieve stats for a
> specific netlink socket, you can use the netlink portID as index.
> And you'll have to add attributes for this new command, yes.

This was my plan. Thanks for the pointer!

>> But I think we should also fix the format string of the proc file
>> as the fix is easy and non-intrusive.
> 
> Unfortunately we don't know how many people are relying on that
> output, I prefer to remain conservative and provide a proper netlink
> interface for this.

I understand your concerns but an application which is able to parse positive
and negative numbers can also parse pure positives.
Just made a small test application, glibc's %d in sscanf() can also deal with UINT_MAX.
And I don't expect that applications to check whether the returned values from
/proc/net/netfilter/nfnetlink_queue are between INT_MIN and INT_MAX.

That said, I'd have assumed that an user would report negative values as plain kernel bug.

Thanks,
//richard

  reply	other threads:[~2015-03-13 14:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-13 11:31 net: portid signedness and format string fixes Richard Weinberger
2015-03-13 11:31 ` [PATCH 1/4] netlink: Fix portid type in netlink_notify Richard Weinberger
2015-03-13 11:31 ` [PATCH 2/4] nfc: Fix portid type in urelease_work Richard Weinberger
2015-03-13 11:31 ` [PATCH 3/4] netfilter: Fix portid types Richard Weinberger
2015-03-13 13:01   ` Pablo Neira Ayuso
2015-03-13 13:19     ` Richard Weinberger
2015-03-13 11:31 ` [PATCH 4/4] netfilter: Fix format string of nfnetlink_queue proc file Richard Weinberger
2015-03-13 12:15   ` Pablo Neira Ayuso
2015-03-13 13:43     ` Richard Weinberger
2015-03-13 13:53       ` Pablo Neira Ayuso
2015-03-13 14:22         ` Richard Weinberger [this message]
2015-03-16 13:11           ` Pablo Neira Ayuso
2015-04-09 21:58             ` Richard Weinberger
2015-04-09 21:58               ` Richard Weinberger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5502F28F.9050601@nod.at \
    --to=richard@nod.at \
    --cc=aloisio.almeida@openbossa.org \
    --cc=coreteam@netfilter.org \
    --cc=davem@davemloft.net \
    --cc=kaber@trash.net \
    --cc=kadlec@blackhole.kfki.hu \
    --cc=lauro.venancio@openbossa.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=sameo@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.