Re: [PATCH 1/2] ebtables: processing '--concurrent' beofore other arguments

[Simon Lees <sflees@suse.de>]

[-- Attachment #1.1: Type: text/plain, Size: 2412 bytes --]



On 4/6/21 7:22 PM, Pablo Neira Ayuso wrote:
> Hi,
> 
> On Tue, Apr 06, 2021 at 05:29:11PM +0930, Simon Lees wrote:
>>
>>
>> On 4/6/21 12:27 PM, Firo Yang wrote:
>>> The 04/03/2021 20:22, Pablo Neira Ayuso wrote:
>>>> On Sat, Apr 03, 2021 at 08:15:17PM +0200, Pablo Neira Ayuso wrote:
>>>>> Hi,
>>>>>
>>>>> On Thu, Apr 01, 2021 at 12:07:40PM +0800, Firo Yang wrote:
>>>>>> Our customer reported a following issue:
>>>>>> If '--concurrent' was passed to ebtables command behind other arguments,
>>>>>> '--concurrent' will not take effect sometimes; for a simple example,
>>>>>> ebtables -L --concurrent. This is becuase the handling of '--concurrent'
>>>>>> is implemented in a passing-order-dependent way.
>>>>>>
>>>>>> So we can fix this problem by processing it before other arguments.
>>>>>
>>>>> Would you instead make a patch to spew an error if --concurrent is the
>>>>> first argument?
>>>>
>>>> Wrong wording:
>>>>
>>>> Would you instead make a patch to spew an error if --concurrent is
>>>> _not_ the first argument?
>>>
>>> Hi Pablo, I think it would make more sense if we don't introduce this
>>> inconvenice to users. If you insist, I would go create the patch as you
>>> intended.
>>
>> Agreed, that also wouldn't be seen as a workable solution for us "SUSE"
>> as our customers who may have scripts or documented processes where
>> --concurrent is not first and such a change would be considered a
>> "Change in behavior" as such we can't ship it in a bugfix or minor
>> version update, only in the next major update and we don't know when
>> that will be yet.
>>
>> Sure this is probably only a issue for enterprise distro's but such a
>> change would likely inconvenience other users as well.
> 
> --concurrent has never worked away from the early positions ever.
> 
> What's the issue?

We had a customer complaining about the change in ordering causing
different results with one way working and the other not, looking back
at the report a second time I don't think they were ever using the "non
working way" in production but just to debug the other issue.

-- 
Simon Lees (Simotek)                            http://simotek.net

Emergency Update Team                           keybase.io/simotek
SUSE Linux                           Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]