On Tue, Jun 25, 2019 at 01:52:32PM +0200, Kristian Evensen wrote: > Hi, > > I am sorry for the trouble that my change has caused. I do not know > what the correct action would be, but I am just trying to figure out > what is going on. In your first email, you wrote: > > > this patch is giving me some trouble as it breaks deletion of conntrack > > entries in software that doesn't set the version flag to anything else > > but 0. > > I might be a bit slow, but I have some trouble understanding this > sentence. Is what you are saying that software that sets version to > anything but 0 breaks? According to the discussion triggered by the > patch adding the feature that we fix here (see the thread [PATCH > 07/31] netfilter: ctnetlink: Support L3 protocol-filter on flush), > using the version field is the correct solution. Pablo wrote: > > > The version field was meant to deal with this case. > > > > It has been not unused so far because we had no good reason. > > So I guess Nicholas worry was correct, that there are applications > that leave version uninitialized and they trigger the regression. I > will let others decide if not setting version counts as a regression > or incorrect API usage. If an uninitialized version counts as a > regression, I am fine with reverting and will try to come up with > another approach. However, I guess we now might have users that depend > on the new behavior of flush as well. What kind of application is leaving this uninitialized? The software you're pointing to is using libnetfilter_conntrack.
