linux-kernel - Re: [PATCH] mtd: nand: Fix memory allocation in nanddev_bbt

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: <fa05e203-430c-6ec4-55e9-a7f9f548e481@kontron.de>
Date:   Thu, 29 Nov 2018 18:11:11 +0000
From:   Schrempf Frieder <frieder.schrempf@...tron.de>
To:     Boris Brezillon <boris.brezillon@...tlin.com>
CC:     Miquel Raynal <miquel.raynal@...tlin.com>,
        Richard Weinberger <richard@....at>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        "David Woodhouse" <dwmw2@...radead.org>,
        Brian Norris <computersforpeace@...il.com>,
        Marek Vasut <marek.vasut@...il.com>,
        "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mtd: nand: Fix memory allocation in nanddev_bbt_init()

On 28.11.18 16:28, Boris Brezillon wrote:
> On Wed, 28 Nov 2018 15:19:37 +0000
> Schrempf Frieder <frieder.schrempf@...tron.de> wrote:
> 
>> On 28.11.18 16:02, Boris Brezillon wrote:
>>> On Wed, 28 Nov 2018 14:55:45 +0000
>>> Schrempf Frieder <frieder.schrempf@...tron.de> wrote:
>>>    
>>>> Hi Boris,
>>>>
>>>> On 28.11.18 15:41, Boris Brezillon wrote:
>>>>> On Tue, 27 Nov 2018 07:44:52 +0000
>>>>> Schrempf Frieder <frieder.schrempf@...tron.de> wrote:
>>>>>       
>>>>>> Fix the size of the buffer allocated to store the in-memory BBT.
>>>>>> This bug was previously hidden by a different bug, that was fixed in
>>>>>> d098093ba06e.
>>>>>>
>>>>>> Fixes: 9c3736a3de21 ("mtd: nand: Add core infrastructure to deal with NAND devices")
>>>>>> Cc: <stable@...r.kernel.org>
>>>>>> Signed-off-by: Frieder Schrempf <frieder.schrempf@...tron.de>
>>>>>
>>>>> Looks like your From header does not match the SoB tag
>>>>> ('Frieder Schrempf' vs 'Schrempf Frieder') and checkpatch does not like
>>>>> that. I'll fix it when applying, but maybe you should fix
>>>>> your .gitconfig to make them match.
>>>>
>>>> Actually the From header in my local patch is correct (<first name>
>>>> <last name>, Frieder Schrempf) as it comes from my git config. But since
>>>> our company was renamed and our mail servers were transferred, our
>>>> e-mails are sent with From=<last name> <first name>.
>>>>
>>>> It seems like git send-email or patchwork or whatever uses the
>>>> information from the e-mail header instead of what is in the patch.
>>>>
>>>> I will try to raise this issue with our IT department as this would be
>>>> best fixed on their side.
>>>
>>> There's another solution: make git send-email add a From header in the
>>> message body.
>>>
>>> git config --global sendemail.from "Schrempf Frieder <frieder.schrempf@...tron.de>"
>>
>> I don't get it. How would that change things? My From still wouldn't
>> match my SoB tags.
> 
> When there's a From line in the message Body, git am will use this one
> instead of the one in the header section.

Ok, now I got it. I didn't know that git send-email adds the From tag in 
the body if sendemail.from differs from the author, but that makes sense 
indeed.

I just checked and with my old mail setup, the SMTP server was 
respecting my sender address from the client (send-email, thunderbird).

The new setup uses DavMail Gateway to send via the companies Exchange 
server and it just ignores my sender from the client and sends with the 
reversed name as stored in the Exchange server.

I don't like sending mail with reversed names (people start calling me 
by my last name), but using a different SMTP server would likely cause 
trouble with some recipients using SPF for spam detection.

So I guess I have to convince our IT to change the names, if even 
possible...
Oh, why do such small things always cause so much trouble?