linux-kernel - Re: question about xt_find_table

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 11 Nov 2016 12:23:07 +0100
From:   Florian Westphal <fw@...len.de>
To:     Julia Lawall <julia.lawall@...6.fr>
Cc:     pablo@...filter.org, kaber@...sh.net, kadlec@...ckhole.kfki.hu,
        davem@...emloft.net, netfilter-devel@...r.kernel.org,
        coreteam@...filter.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, christophe.jaillet@...adoo.fr
Subject: Re: question about xt_find_table_lock

Julia Lawall <julia.lawall@...6.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.