From mboxrd@z Thu Jan 1 00:00:00 1970 From: KOVACS Krisztian Subject: Re: xt_owner-xt_socket plans Date: Mon, 21 Jan 2008 15:41:24 +0100 Message-ID: <20080121144124.GA373@sch.bme.hu> References: <479461C2.1060703@balabit.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Laszlo Attila Toth , Patrick McHardy , Netfilter Developer Mailing List , KOVACS Krisztian To: Jan Engelhardt Return-path: Received: from centaur.sch.bme.hu ([152.66.208.5]:55496 "EHLO centaur.sch.bme.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754283AbYAUOl1 (ORCPT ); Mon, 21 Jan 2008 09:41:27 -0500 Content-Disposition: inline In-Reply-To: Sender: netfilter-devel-owner@vger.kernel.org List-ID: Hi, On h, jan 21, 2008 at 02:23:25 +0100, Jan Engelhardt wrote: > On January 21 2008 10:11, Laszlo Attila Toth wrote: > >Jan Engelhardt wrote: > >> I just remembered that xt_socket (from tproxy) does an (explicit) socket > >> lookup. xt_owner on the other hand, takes the socket pointer from the skb -- > >> which of course only works in the output path. > >> > >> xt_owner is still in the 2.6.25 development queue, and because the two > >> modules are similar, I thought that maybe xt_owner could be merged with > >> xt_socket (doing a rename to xt_socket in the current net-2.6.25), > >> because they are quite close in their task. > >> > >> That would also allow xt_owner to be used in the input path. > >> > >> Opinions? > > > > Hello, > > > > That sounds great. > > > > Note that the socket match depends on tproxy core, also the tproxy would be > > partially merged into the net-2.25 tree. [...] > > Here is what I had in mind, please have a look. > http://dev.computergmbh.de/gitweb.cgi?p=linux;h=dev-xtsocket;a=shortlog This won't work: + sk = nf_tproxy_get_v4(iph->protocol, iph->saddr, iph->daddr, + hp->source, hp->dest, in, false); + if (sk != NULL) + nf_tproxy_put_sock(sk); + return sk; socket_mt_get() returns a struct sock * without holding a reference for that pointer. -- KOVACS Krisztian