Re: [PATCH RFC] iptables-restore: new option to change the commit timing

[Hiroshi KIHIRA <hiro@dump-Storage.net>]

(11/09/09 0:22), Jan Engelhardt wrote:
>>> What would probably be most desirable is that iptables-restore keeps
>>> copies in memory of each table it attempted to touch,
>>> for the eventual case of a rollback.
>>
>> Unfortunately, keeping a copy into userland memory is not enough to
>> guarantee a rollback is possible in kernel land.
>>
>> You might be in an OOM situation preveting new (large) memory
>> allocations.
>
> If restoring the old table fails, no big deal, since we are already
> in an inconsistent state anyway — caused by the rejection of the new
> table —, so there is no additional loss AFAICS.

If memory allocation failed while reading the input,iptables-restore
simply dies without any modification in the kernel space. But if the
OOM situation happened while committing the new or old table, an
inconsistent state will occur.

I believe that the rollback function is useful for many cases except
the memory allocation failure and the problem in kernel space. and
I try to implement it. in the next patch.

I think that 2 handles per tables are needed for rollback. One of them
is used for backup, and the other is for modification.
The backup handle is used if iptc_commit for modified handle failed.
It should succeed, because the handle keeps the table data previously
applied in the kernel space.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html