netdev - Re: [Patch net] sched, cls: check if we could overwrite actions when changing a filter

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: <CAM_iQpVqQbXcm0gGxe_JMURPtGYH+iOi8UGgvis5je6g9zbiKQ@mail.gmail.com>
Date:	Thu, 17 Apr 2014 13:48:21 -0700
From:	Cong Wang <xiyou.wangcong@...il.com>
To:	Jamal Hadi Salim <jhs@...atatu.com>
Cc:	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Cong Wang <cwang@...pensource.com>
Subject: Re: [Patch net] sched, cls: check if we could overwrite actions when
 changing a filter

On Thu, Apr 17, 2014 at 4:50 AM, Jamal Hadi Salim <jhs@...atatu.com> wrote:
> On 04/16/14 17:10, Cong Wang wrote:
>>
>> Why? Since actions are inside it, I should be able to change any
>> part of it, right?
>>
>
> The challenge is in the semantics. You are making change to the
> graph _not_ to the filter. There are dependencies in a graph. IOW,
> I doubt what you are doing could be made generic and safe without
> it being a two step operation since we have multiple tables to deal
> with.
> Example - what would you do if you wanted to change the graph
> so that you add something in the middle or remove something at
> the end?


Actions attached to a filter are at the end of the graph, they should
be able to be added/removed together.

>
>
>>> If otoh you wanted to replace the filter + action graph with a backup
>>> rule, then just add it lower in the priority list and delete the
>>> existing one etc.
>>>
>>
>> This is not atomic, is it?
>>
>
> It avoids the need for atomicity. Backup rule will never be used
> as long as the active is still in use.
> If you can do the two steps in the kernel as i described, then
> you can achieve your purpose but i worry it will complicate code
> for a corner use case (which has a work around already).
>

This is a workaround, not a fix. What if I have multiple threads
trying to append an action at the same time? This workaround
can't guarantee the correctness.

My case is a perfectly valid use, we have to fix it, maybe in
another way.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html