linux-kernel - Re: exfat: add missing brelse() calls on error paths

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <015e5093-d139-6bee-ca45-4cb0e871e65d@web.de>
Date:   Wed, 10 Jun 2020 22:00:24 +0200
From:   Markus Elfring <Markus.Elfring@....de>
To:     Matthew Wilcox <willy@...radead.org>, linux-fsdevel@...r.kernel.org
Cc:     kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org,
        Namjae Jeon <namjae.jeon@...sung.com>,
        Sungjong Seo <sj1557.seo@...sung.com>,
        Pali Rohár <pali@...nel.org>,
        Tetsuhiro Kohada <kohada.t2@...il.com>,
        Wei Yongjun <weiyongjun1@...wei.com>,
        Dan Carpenter <dan.carpenter@...cle.com>
Subject: Re: exfat: add missing brelse() calls on error paths

> You're nitpicking commit messages.

I am occasionally trying to achieve corresponding improvements.

> This is exactly the kind of thing which drives people away.

Would you like to follow official patch process documentation?

> Dan's commit message is fine.

I have got the impression that he indicates another deviation from
a well-known requirement. I am curious under which circumstances
such a patch review concern will be taken into account finally.

> It's actually hilarious because your emails are so unclear that I
> can't understand them.

I find such feedback surprising and interesting.
I hope that we can reduce understanding difficulties together.

> I have no idea what "collateral evolution" means

This term expresses the situation that a single change can trigger
further changes.

Examples for programmers:
A)
* You add an argument to an used function.
* How many function calls will need related adjustments?

B)
* Some function calls can fail.
* How do you think about to complete error detection and the
  corresponding exception handling?

> and yet you use it in almost every email.

You exaggerate here.

> Why can't you use the same terminology the rest of us use?

I got also used to some wording approaches.
Which terminology variation do you prefer?

Regards,
Markus