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

[Pablo Neira Ayuso <pablo@netfilter.org>]

[-- Attachment #1: Type: text/plain, Size: 2420 bytes --]

On Tue, Apr 06, 2021 at 08:51:30PM +0930, Simon Lees wrote:
> 
> 
> 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.

Thanks for explaining, then I think we can go for the "restrict
position" fix which aligns with the -M, -t, ..., correct?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]