netdev - Re: [PATCH net-next 0/5] mlx4 misc fixes and improvements

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, 19 Sep 2016 08:32:49 +0300
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     David Miller <davem@...emloft.net>
Cc:     Tariq Toukan <ttoukan.linux@...il.com>,
        Tariq Toukan <tariqt@...lanox.com>,
        Linux Netdev List <netdev@...r.kernel.org>,
        Eran Ben Elisha <eranbe@...lanox.com>
Subject: Re: [PATCH net-next 0/5] mlx4 misc fixes and improvements

On Mon, Sep 19, 2016 at 5:00 AM, David Miller <davem@...emloft.net> wrote:
> From: Tariq Toukan <ttoukan.linux@...il.com>
> Date: Sun, 18 Sep 2016 10:27:23 +0300
>
>> Hi Dave,
>>
>> On 16/09/2016 2:21 AM, David Miller wrote:
>>> From: Tariq Toukan <tariqt@...lanox.com>
>>> Date: Mon, 12 Sep 2016 16:20:11 +0300
>>>
>>>> This patchset contains some bug fixes, a cleanup, and small
>>>> improvements
>>>> from the team to the mlx4 Eth and core drivers.
>>>>
>>>> Series generated against net-next commit:
>>>> 02154927c115 "net: dsa: bcm_sf2: Get VLAN_PORT_MASK from b53_device"
>>>>
>>>> Please push the following patch to -stable  >= 4.6 as well:
>>>> "net/mlx4_core: Fix to clean devlink resources"
>>> Again, coding style fixes and optimizations like branch prediction
>>> hints are not bug fixes and therefore not appropriate for 'net'.
>> Yes, I know. Please notice that it was submitted to net-next this
>> time.
>
> This is completely incompatible with a request for one of the changes
> to go into -stable.
>
> If the change is not in 'net', it can't go to -stable.

Dave,

So when we're pretty late in the 4.8-rc cycle, a fix for a problem
which was not introduced in 4.8-rc1 was targeted to net-next (4.9) and
not net.

This indeed creates a small mess when the fix needs to go to -stable as well.

I guess the correct thing to do next time, would be to either send to
net and ask you to take it to stable as part of picking the patch --
or send to net-next, and later send you a request to put it to stable
-- or, wait a bit and send it to net of the next kernel along with
stable request... we will pick one of these three way of doings next
(...) time.

So, at this point, I think it would be just correct to take the series
to net-next, and on a future point we'll issue a request to push the
patch into stable.

Or.

Or.