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]
Message-ID: <alpine.DEB.2.10.1411301846560.2522@hadrien>
Date:	Sun, 30 Nov 2014 18:47:29 +0100 (CET)
From:	Julia Lawall <julia.lawall@...6.fr>
To:	Lino Sanfilippo <LinoSanfilippo@....de>
cc:	SF Markus Elfring <elfring@...rs.sourceforge.net>,
	Olof Johansson <olof@...om.net>, netdev@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>,
	kernel-janitors@...r.kernel.org
Subject: Re: [PATCH 1/1] net-PA Semi: Deletion of unnecessary checks before
 the function call "pci_dev_put"



On Sun, 30 Nov 2014, Lino Sanfilippo wrote:

> On 29.11.2014 19:00, SF Markus Elfring wrote:
>
> >  out:
> > -	if (mac->iob_pdev)
> > -		pci_dev_put(mac->iob_pdev);
> > -	if (mac->dma_pdev)
> > -		pci_dev_put(mac->dma_pdev);
> > +	pci_dev_put(mac->iob_pdev);
> > +	pci_dev_put(mac->dma_pdev);
> >
> >  	free_netdev(dev);
> >  out_disable_device:
> >
>
> Hi,
>
> I know there has been some criticism about those kind of "code
> improvements" already but i would like to point out just one more thing:
>
> Some of those NULL pointer checks on input parameters may have been
> added subsequently to functions. So there may be older kernel versions
> out there in which those checks dont exists in some cases. If some of
> the now "cleaned up" code is backported to such a kernel chances are
> good that those missing checks are overseen. And then neither caller nor
> callee is doing the NULL pointer check.
>
> Quite frankly i would vote for the opposite approach: Never rely on the
> callee do to checks for NULL and do it always in the caller. An
> exception could be for calls on a fast path. But most of those checks
> are done on error paths anyway.

I have heard of at least one case where the problem you are raising
happened in practice...

julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ