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: <ecf01283-e2eb-ecef-313f-123ba41c0336@grinta.net>
Date:   Sat, 10 Dec 2016 14:29:55 -0700
From:   Daniele Nicolodi <daniele@...nta.net>
To:     SF Markus Elfring <elfring@...rs.sourceforge.net>,
        linux-media@...r.kernel.org,
        Alexey Khoroshilov <khoroshilov@...ras.ru>,
        Hans Verkuil <hans.verkuil@...co.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org
Subject: Re: [PATCH 1/4] [media] bt8xx: One function call less in
 bttv_input_init() after error detection

On 10/12/16 13:48, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@...rs.sourceforge.net>
> Date: Sat, 10 Dec 2016 09:29:24 +0100
> 
> The kfree() function was called in one case by the
> bttv_input_init() function during error handling
> even if the passed variable contained a null pointer.

kfree() is safe to call on a NULL pointer.

Despite that, you have found several instances of similar constructs:

{
	a = kmalloc(...)
	b = kmalloc(...)

	if (!a || !b)
		goto out;

	...

out:
	kfree(a);
	kfree(b);
}

and similar patches you submitted to change those construct to something
different have been rejected because they are seen as unnecessary
changes that make the code harder to read.

Didn't it occur to you that maybe those constructs are fine the way they
are and this is the idiomatic way to write that kind of code? Why are
you submitting patches implementing changes that have already been rejected?

Submitting mechanical patches that fix trivial style issues (existing
and widely acknowledged ones) is a fine way to learn how to work on
kernel development. They constitute additional work load on the
maintainers that need to review and merge them. Thus, hopefully, they
are only a way for new developers to familiarize themselves with the
process and then move to some more constructive contributions.

Judging from your recent submissions, it seems that this process is not
working well for you. I'm probably not the only one that is wonderign
what are you trying to obtain with your patch submissions, other than
having your name in the git log.

Cheers,
Daniele

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ