linux-kernel - Re: [PATCH 13/14] vme: tsi148: Improve 17 size determinations

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] [day] [month] [year] [list]

Date:   Wed, 30 Aug 2017 22:56:54 +0200
From:   SF Markus Elfring <elfring@...rs.sourceforge.net>
To:     Martyn Welch <martyn@...chs.me.uk>,
        devel <devel@...verdev.osuosl.org>
Cc:     Aaron Sierra <asierra@...-inc.com>,
        Alessio Igor Bogani <alessio.bogani@...ttra.eu>,
        Arnd Bergmann <arnd@...db.de>,
        Augusto Mecking Caringi <augustocaringi@...il.com>,
        Baoyou Xie <baoyou.xie@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Manohar Vanga <manohar.vanga@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org
Subject: Re: [PATCH 13/14] vme: tsi148: Improve 17 size determinations

>>>> @@ -2363,5 +2364,5 @@ static int tsi148_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>>>>              master_num--;
>>>>
>>>>              tsi148_device->flush_image =
>>>> -                    kmalloc(sizeof(struct vme_master_resource), GFP_KERNEL);
>>>> +                    kmalloc(sizeof(*tsi148_device->flush_image), GFP_KERNEL);
>>>
>>> This line is now a tiny bit too long
>>
>> Can you eventually tolerate a line length of 81 characters at such a source code place?
>>
> 
> I think there's some irony here. On the one hand you are submitting
> patches that correct coding style issues, on the other you are asking
> whether we can ignore the coding style...

I test somehow how strict you would like to handle the length limit there.

I imagine that the affected source code formatting could also become different
if the involved variable name would be shorter.


>> * It seems that you would not like to perform such a tweak yourself.
> 
> To be honest, it is quicker and easier in this instance to do just that.

Interesting …


> So that's now done.

Thanks that you picked some of my ideas up.


> Patches now in my testing branch:
> 
> https://gitlab.collabora.com/martyn/linux/commits/vme-testing

I am curious on how the shown change possibilities will evolve from
this repository.


>> * Do you expect a resend for the complete patch series?
>>
> 
> Unless the maintainer has commented that they have accepted patches x,
> y and z, then sending the entire series again is generally the right
> thing to do.

Would you like to respond further to Greg's comments (from 2017-08-26)
for this patch series?

Regards,
Markus