Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1519691 > unrolled thread

question about xt_find_table_lock

Back to article view | Back to linux.kernel

Contents

  question about xt_find_table_lock Julia Lawall <julia.lawall@lip6.fr> - 2016-11-11 12:00 +0100
    Re: question about xt_find_table_lock Florian Westphal <fw@strlen.de> - 2016-11-11 12:30 +0100
      Re: question about xt_find_table_lock Julia Lawall <julia.lawall@lip6.fr> - 2016-11-11 13:00 +0100

#1519691 — question about xt_find_table_lock

The function xt_find_table_lock defined in net/netfilter/x_tables.c is
preceeded by a comment that says that it returns ERR_PTR() on error.  But
looking at the definition, I only see occurrences of return NULL and
returns of pointers that have previously been dereferenced.  Is it the
code or the documentation that is incorrect?  The call sites seem to be
using IS_ERR_OR_NULL.  Is there a plan to return ERR_PTR values in the
future?

julia

[toc] | [next] | [standalone]

#1519707

Julia Lawall <julia.lawall@lip6.fr> wrote:
> The function xt_find_table_lock defined in net/netfilter/x_tables.c is
> preceeded by a comment that says that it returns ERR_PTR() on error.  But
> looking at the definition, I only see occurrences of return NULL and
> returns of pointers that have previously been dereferenced.  Is it the
> code or the documentation that is incorrect?  The call sites seem to be
> using IS_ERR_OR_NULL.  Is there a plan to return ERR_PTR values in the
> future?

It used to return ERR_PTR, see:

commit 7926dbfa4bc14e27f4e18a6184a031a1c1e077dc
netfilter: don't use mutex_lock_interruptible()

So the comment isn't correct anymore and callers could test vs NULL.

[toc] | [prev] | [next] | [standalone]

#1519736

On Fri, 11 Nov 2016, Florian Westphal wrote:

> Julia Lawall <julia.lawall@lip6.fr> wrote:
> > The function xt_find_table_lock defined in net/netfilter/x_tables.c is
> > preceeded by a comment that says that it returns ERR_PTR() on error.  But
> > looking at the definition, I only see occurrences of return NULL and
> > returns of pointers that have previously been dereferenced.  Is it the
> > code or the documentation that is incorrect?  The call sites seem to be
> > using IS_ERR_OR_NULL.  Is there a plan to return ERR_PTR values in the
> > future?
>
> It used to return ERR_PTR, see:
>
> commit 7926dbfa4bc14e27f4e18a6184a031a1c1e077dc
> netfilter: don't use mutex_lock_interruptible()
>
> So the comment isn't correct anymore and callers could test vs NULL.

Thanks for the quick feedback.

julia

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web