Re: tcp hang when socket fills up ?

On Wed, 18 Apr 2018, Dominique Martinet wrote: > Jozsef Kadlecsik wrote on Wed, Apr 18, 2018: > > Thanks for the testing! One more line is required, however: we have to get > > the assured bit set for the connection, see the new patch below. > > I think it actually wa

Re: tcp hang when socket fills up ?

On Wed, 18 Apr 2018, Dominique Martinet wrote: > Dominique Martinet wrote on Wed, Apr 18, 2018: > > Jozsef Kadlecsik wrote on Wed, Apr 18, 2018: > > > Yes, the state transition is wrong for simultaneous open, because the > > > tcp_conntracks table is not (cannot

Re: tcp hang when socket fills up ?

Hi, On Tue, 17 Apr 2018, Florian Westphal wrote: > Dominique Martinet wrote: > > [ CC Jozsef ] > > > Could it have something to do with the way I setup the connection? > > I don't think the "both remotes call connect() with carefully selected > > source/dest port" is a

Re: [PATCH RFC 0/4] net: add bpfilter

Hi David, On Mon, 19 Feb 2018, Florian Westphal wrote: > David Miller wrote: > > > > Florian, first of all, the whole "change the iptables binary" idea is > > a non-starter. For the many reasons I have described in the various > > postings I have made today. > > > > It

Re: [PATCH v3 11/21] clusterip: exit_net cleanup check added

Hello Vasily, On Mon, 6 Nov 2017, Vasily Averin wrote: > Be sure that configs list initialized in net_init hook was return > to initial state. What is the goal of the patch series you sent in the third version in a row? - If the deinitializations are missing from the files, the patches do

Re: [PATCH] netfilter: ipset: use swap macro instead of _manually_ swapping values

Hi, On Mon, 30 Oct 2017, Gustavo A. R. Silva wrote: > Make use of the swap macro and remove unnecessary variables tmp. > This makes the code easier to read and maintain. > > This code was detected with the help of Coccinelle. > > Signed-off-by: Gustavo A. R. Silva >

Re: [PATCH] netfilter: ipset: ip_set_bitmap_ipmac: use swap macro in bitmap_ipmac_create

Hi, On Sat, 28 Oct 2017, Gustavo A. R. Silva wrote: > Make use of the swap macro and remove unnecessary variable tmp. > This makes the code easier to read and maintain. > > This code was detected with the help of Coccinelle. > > Signed-off-by: Gustavo A. R. Silva

Re: [PATCH] netfilter: ipset: Convert timers to use timer_setup()

truct ip_set, which is used instead of the struct > timer_list .data field. Please add the same changes to net/netfilter/ipset/ip_set_list.c too, in order to handle all ipset modules in a single patch. I don't see a way either to avoid the introduction of the new pointer. Acked-by: Jozsef

RE: [PATCH] netfilter: fix stringop-overflow warning with UBSAN

Hi, [Sorry, at holiday I just cursory watched the mailing lists.] On Tue, 1 Aug 2017, David Laight wrote: > From: Arnd Bergmann > > Sent: 31 July 2017 11:09 > > Using gcc-7 with UBSAN enabled, we get this false-positive warning: > > > > net/netfilter/ipset/ip_set_core.c: In function

Re: [PATCH] netfilter: ipset: ipset list may return wrong member count for set with timeout

Hi, Your patch is applied in the ipset git tree and I'm going to push it for kernel inclusion. I modified the comment part: the elements counter can still be incorrect in the case of a huge set, because elements might time out during the listing. Thanks for your patience! Best regards,

Re: [PATCH nf-next] ipset: remove unused function __ip_set_get_netlink

Hi Pablo, On Fri, 14 Apr 2017, Pablo Neira Ayuso wrote: > On Mon, Apr 10, 2017 at 03:52:37PM -0400, Aaron Conole wrote: > > There are no in-tree callers. > > @Jozsef, let me know if I should just take this to save you a pull > request. Just take it, thank you. Acked-by: Joz

Re: [PATCH] netfilter: ipset: Null pointer exception in ipset list:set

Hi, On Wed, 15 Feb 2017, Vishwanath Pai wrote: > If we use before/after to add an element to an empty list it will cause > a kernel panic. > > $> cat crash.restore > create a hash:ip > create b hash:ip > create test list:set timeout 5 size 4 > add test b before a > > $> ipset -R <

Re: [PATCH 1/3] netfilter: ipset: use setup_timer() and mod_timer().

On Sat, 14 May 2016, Muhammad Falak R Wani wrote: > Use setup_timer() and instead of init_timer(), being the preferred way > of setting up a timer. > > Also, quoting the mod_timer() function comment: > -> mod_timer() is a more efficient way to update the expire field of an >active timer (if

Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet

On Mon, 28 Mar 2016, Eric Dumazet wrote: > On Mon, 2016-03-28 at 22:20 +0200, Jan Engelhardt wrote: > > On Monday 2016-03-28 21:29, David Miller wrote: > > >>> > > @@ -3716,6 +3716,8 @@ void tcp_parse_options(const struct sk_buff > > >>> > > *skb, > > >>> > > length--; > > >>> > >

Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet

ing wrote: > > > > > > On 2016/3/28 6:25, Jozsef Kadlecsik wrote: > > > On Mon, 28 Mar 2016, Jozsef Kadlecsik wrote: > > > > > > > On Sun, 27 Mar 2016, Baozeng Ding wrote: > > > > > > > > > The following program triggers stac

Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet

On Mon, 28 Mar 2016, Jozsef Kadlecsik wrote: > On Sun, 27 Mar 2016, Baozeng Ding wrote: > > > The following program triggers stack-out-of-bounds in tcp_packet. The > > kernel version is 4.5 (on Mar 16 commit > > 09fd671ccb2475436bd5f597f751ca4a7d177aea). > > Un

Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet

On Sun, 27 Mar 2016, Baozeng Ding wrote: > The following program triggers stack-out-of-bounds in tcp_packet. The > kernel version is 4.5 (on Mar 16 commit > 09fd671ccb2475436bd5f597f751ca4a7d177aea). > Uncovered with syzkaller. Thanks. > >

Re: [PATCH v2] netfilter: fix race condition in ipset save, swap and delete

Hi, On Mon, 14 Mar 2016, Vishwanath Pai wrote: > I have updated the patch according to comments by Jozsef. Renamed > ref_kernel to ref_netlink, renamed _put/_get functions and updated the > description in commit log. Patch is applied to the ipset git tree - you use some older kernel tree and I

Re: [PATCH] netfilter: fix race condition in ipset save and delete

Hi, On Sat, 12 Mar 2016, Vishwanath Pai wrote: > netfilter: fix race condition in ipset save and delete > > This fix adds a new reference counter (ref_kernel) for the struct ip_set. > The other reference counter (ref) is used to track references from the > userspace and we need a separate

Re: unused code in net/netfilter/ipset/ip_set_bitmap_ipmac.c

Hi, On Mon, 29 Feb 2016, Julia Lawall wrote: > The file net/netfilter/ipset/ip_set_bitmap_ipmac.c seems to contain a lot > of static functions that are not used in the file: > > bitmap_ipmac_add_timeout > bitmap_ipmac_do_add > bitmap_ipmac_do_del > bitmap_ipmac_do_head > bitmap_ipmac_do_list >

Re: [PATCH 00/10] Netfilter fixes for net

On Fri, 13 Nov 2015, Josh Boyer wrote: > On Wed, Nov 11, 2015 at 12:33 PM, Pablo Neira Ayuso <pa...@netfilter.org> > wrote: > > Jozsef Kadlecsik (3): > > netfilter: ipset: Fix extension alignment > > netfilter: ipset: Fix hash:* type expiration > &

Re: Linux 4.2.4

On Sun, 25 Oct 2015, Gerhard Wiesinger wrote: > On 25.10.2015 20:46, Jozsef Kadlecsik wrote: > > Hi, > > > > On Sun, 25 Oct 2015, Gerhard Wiesinger wrote: > > > > > On 25.10.2015 10:46, Willy Tarreau wrote: > > > > ipset *triggered* the problem

Re: Linux 4.2.4

On Sun, 25 Oct 2015, Gerhard Wiesinger wrote: > On 25.10.2015 21:08, Gerhard Wiesinger wrote: > > On 25.10.2015 20:46, Jozsef Kadlecsik wrote: > > > Hi, > > > > > > On Sun, 25 Oct 2015, Gerhard Wiesinger wrote: > > > > > > > On 25.10.20

Re: Linux 4.2.4

Hi, On Sun, 25 Oct 2015, Gerhard Wiesinger wrote: > On 25.10.2015 10:46, Willy Tarreau wrote: > > ipset *triggered* the problem. The whole stack dump would tell more. > > OK, find the stack traces in the bug report: > https://bugzilla.redhat.com/show_bug.cgi?id=1272645 > > Kernel 4.1.10

Re: [PATCH v2] netfilter: ipset: Fix sleeping memory allocation in atomic context

On Thu, 15 Oct 2015, Eric Dumazet wrote: > On Thu, 2015-10-15 at 23:20 +0300, Nikolay Borisov wrote: > > > While GFP_ATOMIC does indeed look the correct solution for this particular > > case I was wondering whether something like (GFP_KERNEL & ~__GFP_WAIT) > > wouldn't also make the cut without

Re: [PATCH v3] netfilter: ipset: Fix sleeping memory allocation in atomic context

allows initiating direct reclaim thus > potentially sleeping in the allocation path. > > To fix the issue change the allocation type to GFP_ATOMIC, to > correctly reflect that it is occuring in an atomic context. > > Fixes: 00590fdd5be0 ("netfilter: ipset: Introduce RCU locking in

Re: [PATCH] Fix sleeping memory allocation in atomic context

iating direct reclaim thus > potentially sleeping in the allocation path, this leads to the > aforementioned splat. > > To fix it change that particular allocation type to GFP_ATOMIC, to > correctly reflect that it is happening in an atomic context. Good catch, Pablo please

Re: [PATCH] Fix sleeping memory allocation in atomic context

On Thu, 15 Oct 2015, Nikolay Aleksandrov wrote: > On 10/15/2015 10:57 AM, Nikolay Borisov wrote: > > Ipset 6.26 produces the following splat: > > > [snip] > > > > The call chain leading to this as follow: > > call_add -> list_set_uadt -> list_set_uadd -> kzalloc(, GFP_KERNEL). > > And since

Re: [PATCH v2] netfilter: ipset: Fix sleeping memory allocation in atomic context

; >> [] SYSC_sendto+0x134/0x180 > > >> [] ? mntput+0x21/0x30 > > >> [] ? __kfree_skb+0x3f/0xa0 > > >> [] SyS_sendto+0xe/0x10 > > >> [] system_call_fastpath+0x16/0x1b > > >> > > >> The call chain leading to this

Re: [PATCH v2 net-next] netfilter: ipset: Fixing unnamed union init

On Sat, 22 Aug 2015, Elad Raz wrote: In continue to proposed Vinson Lee's post [1], this patch fixes compilation issues founded at gcc 4.4.7. The initialization of .cidr field of unnamed unions causes compilation error in gcc 4.4.x. There's already a (couple of weeks old) patch in the -mm

Re: Fw: [Fwd: [Bug 5644] New: NFS v3 TCP 3-way handshake incorrect, iptables blocks access]

Hi, On Fri, 25 Nov 2005, Jozsef Kadlecsik wrote: On Thu, 24 Nov 2005, Olaf Kirch wrote: On Thu, Nov 24, 2005 at 03:08:27PM +0100, Harald Welte wrote: Jozsef Kadlecsik doesn't recall those patches/changes (even though he's our Mr. TCP state tracking and is indicated as the author of one