All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Florian Westphal <fw@strlen.de>,
	Marcelo Ricardo Leitner <mleitner@redhat.com>,
	netfilter-devel@vger.kernel.org
Subject: Re: [PATCH v4 2/3] Do error handling if __build_packet_message fails
Date: Thu, 6 Nov 2014 03:19:21 +0100	[thread overview]
Message-ID: <20141106021921.GB23131@breakpoint.cc> (raw)
In-Reply-To: <20141106010717.GA5205@salvia>

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> On Tue, Nov 04, 2014 at 08:11:20PM +0100, Florian Westphal wrote:
> > Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > > BTW, we should also signal the userspace when we fail to build the
> > > message via:
> > > 
> > > nfnetlink_set_err(net, 0, group, -ENOBUFS);
> > > 
> > > so it knows that we're losing log messages for whatever reason.
> > > Basically, userspace hits -ENOBUFS when calling recv(), which means
> > > netlink is losing messages. I don't think we really need the
> > > statistics.
> > 
> > Not sure if this is a good idea.
> > 
> > a) __build_packet_message must never fail.
> > If it does, the kernel has a size accoutning bug somewhere.
> > b) I see no meaningful way for userspace to handle this error;
> > there is nothing it can do about it.
> > c) If it happens, it might be that some userspace logging daemon
> > suddently dies because it sees an unexpected 'fatal' error.
> 
> userspace should be handling -ENOBUFS already, netlink reports this if
> the buffer overruns.

You're right.

> I would remove those printk there to
> report OOM, there's nothing userspace can do with that.

Agreed.

  reply	other threads:[~2014-11-06  2:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-29 12:51 [PATCH v4 1/3] netfilter: log: protect nf_log_register against double registering Marcelo Ricardo Leitner
2014-10-29 12:51 ` [PATCH v4 2/3] Do error handling if __build_packet_message fails Marcelo Ricardo Leitner
2014-11-04 16:47   ` Pablo Neira Ayuso
2014-11-04 18:01     ` Marcelo Ricardo Leitner
2014-11-04 18:26       ` Pablo Neira Ayuso
2014-11-04 18:52         ` Marcelo Ricardo Leitner
2014-11-04 19:04           ` Pablo Neira Ayuso
2014-11-04 19:08             ` Marcelo Ricardo Leitner
2014-11-04 19:11         ` Florian Westphal
2014-11-06  1:07           ` Pablo Neira Ayuso
2014-11-06  2:19             ` Florian Westphal [this message]
2014-10-29 12:51 ` [PATCH v4 3/3] Make use of pr_fmt where applicable Marcelo Ricardo Leitner
2014-11-04 16:50   ` Pablo Neira Ayuso
2014-11-04 17:11     ` Marcelo Ricardo Leitner
2014-10-30 16:31 ` [PATCH v4 1/3] netfilter: log: protect nf_log_register against double registering Pablo Neira Ayuso

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=20141106021921.GB23131@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=mleitner@redhat.com \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    /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.