Hi Pablo, > I think I found the problem, we have an underflow triggering the > allocation of a huge bitmask, see patch: > > http://patchwork.ozlabs.org/patch/705279/ thanks a lot, the patch really fixed the problem! > BTW, if you have some spare cycles, I would really appreciate if you > can send a shell test, similar to: > > nftables/tests/shell/testcases/sets/0012add_delete_many_elements_0 > nftables/tests/shell/testcases/sets/0013add_delete_many_elements_0 > > It would be great to cover intervals and maps too. I don't know how to contribute them properly, so I have attached four tests to this mail. They are based on sets/0013add_delete_many_elements_0, as sets/0012add_delete_many_elements_0 fails (it seems like adding and deleting elements simultaneously causes the whole ruleset to be empty). maps/map_add_many_elements_0 adds scalar map elements and works always, so the issue seems to have been in the interval code exclusively. maps/interval_map_add_many_elements_0 does the same with interval maps - fails under unpatched master, passes with your patch maps/interval_map_create_once_0 is the same with only one call to nft, works under both revisions (!) maps/interval_map_overlap_0 is for the interval bug, see below > So nft doesn't complain on exact overlaps to keep it consistent with > non-interval sets. Probably you refering to this? No, adding two disjoint intervels led to an error that they would overlap. Your patch seems to have fixed that as well. See the maps/interval_map_overlap_0 test. It only adds two map elements, in two calls to nft. In the unpatched version it doesn't crash due to memory, but complains about overlap. In the patched version it works. Thanks again for the fast fix.
Attachment:
tests.tar
Description: Unix tar archive
