On Mon, Mar 02, 2015 at 11:51:41AM +0000, Patrick McHardy wrote:
> I'm looking at the nftables transaction code and wondering about the
> semantics of GET operations intermixed with ADD/DEL operations:
>
> AFAIK there are currently some inconsistencies:
>
> - new sets get marked as inactive and invisible to GET until the
> transaction is supported. So
>
> ADD set
> GET set
>
> will return ENOENT.
These two follow different paths.
The ADD is included in the batch, the GET doesn't. So we won't see the
object until we have finish processing a full batch.
ADD set
--------> batch OK, commit
GET set
> - Rule GET operations OTOH don't care about the activeness of the rule
> at all, so
>
> DEL rule
> GET rule
>
> will return the rule even though it is actually deleted.
>
> ADD rule
> GET rule
> transaction fail
>
> Will equally return the rule even though it will afterwards not be
> present.
>
> So the general question is how to properly handle this. GET operations
> should obviously take activeness into account and not return deleted
> objects.
You have DUMP_INTR if a get happens while updating any of the lists.
> The next question would be how to handle failed transactions. We should
> obviously only return new objects if the transaction actually succeeds,
> so I guess this means handling GET requests in the commit path.
Userspace will notice the interference via the netlink flag and will
retry from scratch.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
