question about xt_find_table_lock

question about xt_find_table_lock

[Julia Lawall]

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

Re: question about xt_find_table_lock

[Florian Westphal]

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.

Re: question about xt_find_table_lock

[Julia Lawall]

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