public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniele Nicolodi <daniele@grinta.net>
To: SF Markus Elfring <elfring@users.sourceforge.net>,
	linux-media@vger.kernel.org,
	Alexey Khoroshilov <khoroshilov@ispras.ru>,
	Hans Verkuil <hans.verkuil@cisco.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH 1/4] [media] bt8xx: One function call less in bttv_input_init() after error detection
Date: Sat, 10 Dec 2016 14:29:55 -0700	[thread overview]
Message-ID: <ecf01283-e2eb-ecef-313f-123ba41c0336@grinta.net> (raw)
In-Reply-To: <e20a6835-a404-e894-d0d0-a408bfcd7fb6@users.sourceforge.net>

On 10/12/16 13:48, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.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

  reply	other threads:[~2016-12-10 21:39 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-10 20:45 [PATCH 0/4] [media] bt8xx: Fine-tuning for three functions SF Markus Elfring
2016-12-10 20:48 ` [PATCH 1/4] [media] bt8xx: One function call less in bttv_input_init() after error detection SF Markus Elfring
2016-12-10 21:29   ` Daniele Nicolodi [this message]
2016-12-10 22:10     ` SF Markus Elfring
2016-12-11 21:52       ` Daniele Nicolodi
2016-12-12  7:33         ` SF Markus Elfring
2016-12-12  7:39           ` Daniele Nicolodi
2016-12-12 17:15             ` SF Markus Elfring
2016-12-12 17:56               ` Daniele Nicolodi
2016-12-12 18:03             ` Clarification for acceptance statistics? SF Markus Elfring
2016-12-12 21:02               ` Daniele Nicolodi
2016-12-12 22:11                 ` SF Markus Elfring
2016-12-12 23:19                   ` Daniele Nicolodi
2016-12-12 19:11             ` [media] bt8xx: One function call less in bttv_input_init() after error detection Dan Carpenter
2016-12-10 20:50 ` [PATCH 2/4] [media] bt8xx: Delete two error messages for a failed memory allocation SF Markus Elfring
2016-12-10 20:51 ` [PATCH 3/4] [media] bt8xx: Delete unnecessary variable initialisations in ca_send_message() SF Markus Elfring
2016-12-10 20:53 ` [PATCH 4/4] [media] bt8xx: Less function calls in dst_ca_ioctl() after error detection SF Markus Elfring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ecf01283-e2eb-ecef-313f-123ba41c0336@grinta.net \
    --to=daniele@grinta.net \
    --cc=elfring@users.sourceforge.net \
    --cc=hans.verkuil@cisco.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=khoroshilov@ispras.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox