linux-kernel - Re: [media] bt8xx: One function call less in bttv_input

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:   Mon, 12 Dec 2016 08:33:43 +0100
From:   SF Markus Elfring <elfring@...rs.sourceforge.net>
To:     Daniele Nicolodi <daniele@...nta.net>
Cc:     linux-media@...r.kernel.org,
        Alexey Khoroshilov <khoroshilov@...ras.ru>,
        Hans Verkuil <hans.verkuil@...co.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org
Subject: Re: [media] bt8xx: One function call less in bttv_input_init() after
 error detection

>> I would prefer a safer coding style for the corresponding
>> exception handling.
> 
> Can you please point out what is wrong in the current code

Is it useful to reconsider the software situation that another memory
allocation is attempted when it could be determined that a previous one
failed already?
Are two successful allocations finally needed to achieve the desired task?

> and how the changes you propose fix the problem?

I suggest to check return values immediately after each function call.
An error situation can be detected earlier then and only the required
clean-up functionality will be executed at the end.

> No one has expressed acceptance for the kind of change you propose with
> this patch, or to previous patches you proposed changing similar constructs.

I got a mixed impression from the acceptance statistics about my
published patches.

> The fact that you propose over and over again a class of changes that
> has been already vocally rejected would suggest otherwise.

I dare to propose another look at results from source code search patterns.

> The major achievement you obtained so far is that one of the maintainers
> of a large fraction of the kernel refuses to look at your patch submissions.

It can happen that some patterns are occasionally "too special"
to grow the popularity for such change possibilities and desired software
improvements quickly.
There are also different views about affected implementation details
by the software development community, aren't there?

Regards,
Markus