Re: [PATCH 1/1] NET: ipv6, fix potential null dereference

[Jiri Slaby <jirislaby@gmail.com>]

On 01/10/2010 11:47 AM, Alexey Dobriyan wrote:
> On Sun, Jan 10, 2010 at 11:38:57AM +0100, Jiri Slaby wrote:
>> On 01/10/2010 11:35 AM, Alexey Dobriyan wrote:
>>>> Stanse found a potential null dereference
>>>
>>> Nobody learns from Coverity, it seems. :^)
>>
>> If it is known, why the test is still there?
>>
>> I don't have access to the Coverity results anyway.
> 
> Well, when Coverity first exposed their database there were innumerable
> "potential NULL dereference" defects and people fixed them by moving
> stuff and most were bogus and there were flamewars and there were second
> wave and so on...

Well, it is a clear error. Either the check is superfluous, or there is
a potential NULL dereference.

And until people start to look at the reports for their stuff
themselves, they will get bogus fixes from others. And they have to nack
them, indeed.

While we are at it, could anybody look at (watch `task'):
int xprt_reserve_xprt(struct rpc_task *task)
{
        struct rpc_rqst *req = task->tk_rqstp; <---- here
        struct rpc_xprt *xprt = req->rq_xprt;

        if (test_and_set_bit(XPRT_LOCKED, &xprt->state)) {
                if (task == xprt->snd_task)
                        return 1;
                if (task == NULL)  <------- here
                        return 0;

And this (I checked 2.6.28, where netdev_priv was dev->priv):
static void __devexit de_remove_one (struct pci_dev *pdev)
{
        struct net_device *dev = pci_get_drvdata(pdev);
        struct de_private *de = netdev_priv(dev);

        BUG_ON(!dev);

I know, currently netdev_priv returns dev+offset, but will this hold in
the future?

>>> snmp6_unregister_dev() always called with valid idev.
> 
> irda patch is not right too: calling tty->ops->hook with NULL tty is
> impossible.

Yup, I somehow messed with tty->driver_data being NULL.

thanks,
-- 
js