gt;
> Fix this by checking whether the timer already started.
>
> Signed-off-by: Tan Hu
> Reviewed-by: Jiang Biao
v3 looks good to me,
Acked-by: Julian Anastasov
Simon and Pablo, this can be applied to ipvs/nf tree...
> ---
> v2: fix use-after-free in CONN_ONE_PAC
x this by checking whether the timer already started.
>
> Signed-off-by: Tan Hu
> Reviewed-by: Jiang Biao
> ---
> v2: fix use-after-free in CONN_ONE_PACKET case suggested by Julian Anastasov
>
> net/netfilter/ipvs/ip_vs_core.c | 15 +++
> 1 file changed
to some path (via alive ISP), use route lookup just
to select alive path for the first packet in connection. So, what
we balance are connections, not packets (which does not work with
different ISPs). Probe GWs to keep only alive routes in the table.
Regards
--
Julian Anastasov
Hello,
On Thu, 21 Jun 2018, Grant Taylor wrote:
> On 06/21/2018 01:57 PM, Julian Anastasov wrote:
> > Hello,
>
> > http://ja.ssi.bg/dgd-usage.txt
>
> "DGD" or "Dead Gateway Detection" sounds very familiar. I referenced it in an
>
Hello,
On Wed, 20 Jun 2018, Grant Taylor wrote:
> On 06/20/2018 01:00 PM, Julian Anastasov wrote:
> > You can also try alternative routes.
>
> "Alternative routes"? I can't say as I've heard that description as a
> specific technique / feature / capabili
tool puts only alive routes in service after doing health
checks of all near gateways.
Regards
--
Julian Anastasov
ountering
pmtu exception")
Fixes: 7343ff31ebf0 ("ipv6: Don't create clones of host routes.")
Signed-off-by: Julian Anastasov
---
net/ipv6/route.c | 3 ---
1 file changed, 3 deletions(-)
Note: I failed to build 2.6.38 kernel for the test but I think
commit 7343ff31ebf0 looks as the
Hello,
On Tue, 5 Jun 2018, Martin KaFai Lau wrote:
> On Sat, May 05, 2018 at 03:58:25PM +0300, Julian Anastasov wrote:
> > So, except the RTF_LOCAL check in __ip6_rt_update_pmtu
> > we should have no other issues.
> Hi Julian,
>
> Do you have a chance
* - it can be for SYN state
* - it can be when cp was dropped on load
*/
cp->state == IP_VS_TCP_S_SYN_RECV) {
IP_VS_DBG(4, "del conn template\n");
ip_vs_conn_expire_now(cp_c);
}
}
It is not perfect, i.e. it does not know if there was
some conn that was established in the past:
- CONN1: SYN, SYN+ACK, ESTABLISH, FIN, FIN+ACK, expire
- CONN2: expire in SYN state, drop tpl before persistent timeout
But it should work in the general case.
Anyways, give me some days to think more on this issue.
Regards
--
Julian Anastasov <j...@ssi.bg>
1
> Code: 08 5b 41 5c 41 5d 41 5e 41 5f 5d c3 0f 0b 48 89 df e8 d2 8f 48 fa eb de
> 55 48 89 fe 48 c7 c7 60 65 64 88 48 89 e5 e8 91 dd f3 f9 <0f> 0b 90 90 90 90
> 90 90 90 90 90 90 90 55 48 89 e5 41 57 41 56
> RIP: fortify_panic+0x13/0x20 lib/string.c:1051 RSP: 8801c976f800
> ---[ end trace 624046f2d9af7702 ]---
Just to let you know that I tested a patch with
the syzbot, will do more tests before submitting...
Regards
--
Julian Anastasov <j...@ssi.bg>
Hello,
On Mon, 7 May 2018, Martin KaFai Lau wrote:
> On Sat, May 05, 2018 at 03:58:25PM +0300, Julian Anastasov wrote:
> >
> > So, except the RTF_LOCAL check in __ip6_rt_update_pmtu
> > we should have no other issues. Only one minor bit is s
e_pmtu(rt6, mtu);
+ /* update rt6_ex->stamp for cache */
rt6_update_exception_stamp_rt(rt6);
+ }
} else if (daddr) {
Regards
--
Julian Anastasov <j...@ssi.bg>
Hello,
On Wed, 2 May 2018, David Ahern wrote:
> On 5/2/18 12:41 AM, Julian Anastasov wrote:
> > Allow some non-cached routes to use non-expired fnhe:
> >
> > 1. ip_del_fnhe: moved above and now called by find_exception.
> > The 4.5+ commit deed49df7390 exp
Hello,
On Wed, 2 May 2018, Martin KaFai Lau wrote:
> On Wed, May 02, 2018 at 09:38:43AM +0300, Julian Anastasov wrote:
> >
> > - initial traffic for port 21 does not use GSO. But after
> > every packet IPVS calls maybe_update_pmtu (rt->dst.ops->update_pmtu
on local routes with
oif")
Fixes: deed49df7390 ("route: check and remove route cache when we get route")
Cc: David Ahern <dsah...@gmail.com>
Cc: Xin Long <lucien@gmail.com>
Signed-off-by: Julian Anastasov <j...@ssi.bg>
---
net/ipv4/route.c | 118 +
mtu && !skb_is_gso(skb) &&
-!ip_vs_iph_icmp(ipvsh))) {
+ if (unlikely(__mtu_check_toobig(skb, mtu))) {
icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED,
htonl(mtu));
IP_VS_DBG(1, "frag needed for %pI4\n",
Regards
--
Julian Anastasov <j...@ssi.bg>
appspotmail.com>
> Cc: Simon Horman <ho...@verge.net.au>
> Cc: Julian Anastasov <j...@ssi.bg>
> Cc: Pablo Neira Ayuso <pa...@netfilter.org>
> Signed-off-by: Cong Wang <xiyou.wangc...@gmail.com>
Thanks!
Acked-by: Julian Anastasov <j...@ssi.bg>
&
m>
> Cc: Simon Horman <ho...@verge.net.au>
> Cc: Julian Anastasov <j...@ssi.bg>
> Cc: Pablo Neira Ayuso <pa...@netfilter.org>
> Signed-off-by: Cong Wang <xiyou.wangc...@gmail.com>
Thanks!
Acked-by: Julian Anastasov <j...@ssi.bg>
> ---
>
unsigned short hdr_len = (th->doff << 2) +
> + skb_network_header_len(skb);
> +
> + if (mtu > hdr_len && mtu - hdr_len < skb_shinfo(skb)->gso_size)
> + skb_decrease_gso_size(skb_shinfo(skb),
>
Hello,
On Thu, 12 Apr 2018, Stephen Suryaputra wrote:
> Thanks for the feedbacks. Please see the detail below:
>
> On Wed, Apr 11, 2018 at 3:37 PM, Julian Anastasov <j...@ssi.bg> wrote:
> [snip]
> >> - __IP_INC_STATS(net, IPSTATS_MIB_INHDRERRORS);
&g
tree, so all these
lockups around start_sync_thread should be resolved soon...
> > IPVS: sync thread started: state = BACKUP, mcast_ifn = lo, syncid = 0, id =
> > 0
> > IPVS: stopping backup sync thread 4546 ...
> >
> >
> > IPVS: stopping backup sync thread 4559 ...
> > WARNING: possible recursive locking detected
Regards
--
Julian Anastasov <j...@ssi.bg>
instead of just
'skb_dst(skb)->dev'.
> icmp_send(skb, ICMP_TIME_EXCEEDED, ICMP_EXC_TTL, 0);
> return false;
> }
The patch probably has other errors, for example,
using rt->dst.dev (lo) when rt->dst.error != 0 in ip_error,
may be 'dev' should be used instead...
Regards
--
Julian Anastasov <j...@ssi.bg>
1 +
> net/netfilter/ipvs/ip_vs_csh.c | 339
> +
> net/netfilter/ipvs/ip_vs_sh.c | 32 +---
> 5 files changed, 381 insertions(+), 31 deletions(-)
> create mode 100644 net/netfilter/ipvs/ip_vs_csh.c
Regards
--
Julian Anastasov <j...@ssi.bg>
ldn't matter.
>
> Signed-off-by: Vincent Bernat <vinc...@bernat.im>
Looks good to me, thanks! Simon, please apply, if possible
with the extra space removed, see below...
Acked-by: Julian Anastasov <j...@ssi.bg>
> ---
> net/netfilter/ipvs/ip_vs_dh.c| 3 ++-
>
ask' part is not needed, still,
it does not generate extra code. I see that other code uses
hash_32(val, bits) from include/linux/hash.h but note that it
used different ratio before Linux 4.7, in case someone backports
this patch on old kernels. So, I don't have preference what should
be used, may be return hash_32(ntohl(addr_fold), IP_VS_DH_TAB_BITS)
is better.
Regards
--
Julian Anastasov <j...@ssi.bg>
e_halt+0x6/0x10
> arch/x86/include/asm/irqflags.h:54
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug report.
> Note: all commands must start from beginning of the line in the email body.
Regards
--
Julian Anastasov <j...@ssi.bg>
sock_release+0x8d/0x1e0 net/socket.c:595
> > start_sync_thread+0x2213/0x2b70 net/netfilter/ipvs/ip_vs_sync.c:1924
> > do_ip_vs_set_ctl+0x1139/0x1cc0 net/netfilter/ipvs/ip_vs_ctl.c:2389
Regards
--
Julian Anastasov <j...@ssi.bg>
Convert ip_vs_ftp_ops
The IPVS patches 4-6 look good to me,
Acked-by: Julian Anastasov <j...@ssi.bg>
> net/l2tp/l2tp_core.c|1 +
> net/mpls/af_mpls.c |1 +
> net/netfilter/ipvs/ip_vs_core.c |2 ++
> net/netfilter/ipvs/ip_vs_ftp.c
es: 621e84d6f373 ("dev: introduce skb_scrub_packet()")
Signed-off-by: Julian Anastasov <j...@ssi.bg>
I guess, DaveM can apply it directly as a bugfix
to the net tree.
> ---
> include/linux/skbuff.h | 7 +++
> net/core/skbuff.c | 1 +
> 2 files changed, 8 ins
ns...@linux-vs.org>
> Cc: Simon Horman <ho...@verge.net.au>
> Cc: Julian Anastasov <j...@ssi.bg>
> Cc: Pablo Neira Ayuso <pa...@netfilter.org>
> Cc: Jozsef Kadlecsik <kad...@blackhole.kfki.hu>
> Cc: Florian Westphal <f...@strlen.de>
> Cc: "David
size=4096)
> Prot LocalAddress:Port Scheduler Flags
> -> RemoteAddress:Port Forward Weight ActiveConn InActConn
> TCP 0A010102:0050 wlc
>
> Signed-off-by: KUWAZAWA Takuya <albatro...@gmail.com>
Looks good to me
Acked-by: Julian Anastasov <j...@ssi.bg>
ue was reported only once to us from the regression rack only
> so the exact steps to reproduce is unknown.
OK, lets see, may be others can explain what happens.
Regards
--
Julian Anastasov <j...@ssi.bg>
write DST_METRICS_REFCOUNTED flag
and later to see this flag in __dst_destroy_metrics_generic
So, I'm not sure where exactly is the bug with the
metrics.
May be I'm missing some posting but I don't see if
the patch was tested successfully.
Regards
--
Julian Anastasov <j...@ssi.bg>
IT
> packet
> netfilter: ipvs: do not create conn for ABORT packet in
> sctp_conn_schedule
>
> net/netfilter/ipvs/ip_vs_proto_sctp.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
Patchset looks ok to me,
Acked-by: Julian Anastasov <j...@ssi.bg>
if (NEIGH_VAR(neigh->parms, MCAST_PROBES) +
NEIGH_VAR(neigh->parms, APP_PROBES)) {
- unsigned long next, now = jiffies;
+ unsigned long next;
atomic_set(>probes,
NEIGH_VAR(neigh->parms, UCAST_PROBES));
Regards
--
Julian Anastasov <j...@ssi.bg>
Hello,
On Wed, 16 Aug 2017, Julian Anastasov wrote:
> I thought about this, it is possible in
> neigh_event_send:
>
> if (neigh->used != now)
> neigh->used = now;
> else if (neigh->nud_state == NUD_INCOMPLET
Hello,
On Tue, 15 Aug 2017, Eric Dumazet wrote:
> On Tue, 2017-08-15 at 22:45 +0300, Julian Anastasov wrote:
> > Hello,
> >
> > On Tue, 15 Aug 2017, Eric Dumazet wrote:
> >
> > > Please try this :
> > > diff --git a/net/core/n
event_send. Now we risk to enter the
'if (!(neigh->nud_state & (NUD_STALE | NUD_INCOMPLETE))) {' block...
> write_lock_bh(>lock);
>
> rc = 0;
> - if (neigh->nud_state & (NUD_CONNECTED | NUD_DELAY | NUD_PROBE))
> - goto out_unlock_bh;
> if (neigh->dead)
> goto out_dead;
Regards
--
Julian Anastasov <j...@ssi.bg>
d free it. This patch refactors and shares common code
> between neigh_forced_gc and the newly added neigh_remove_one.
>
> A similar issue exists for IPv6 Neighbor Cache entries, and is fixed
> in a similar manner by this patch.
>
> Signed-off-by: Sowmini Varadhan <sowmini.
d...@oracle.com>
Change looks ok to me but with some non-fatal
warnings, see below.
Reviewed-by: Julian Anastasov <j...@ssi.bg>
> ---
> v2: kbuild-test-robot compile error
> v3: do not export_symbol neigh_remove_one (David Miller comment)
> v4: rearrange locki
Hello,
On Wed, 31 May 2017, Sowmini Varadhan wrote:
> On (06/01/17 00:41), Julian Anastasov wrote:
> >
> > So, we do not hold reference to neigh while accessing
> > its fields. I suspect we need to move the table lock from
> > neigh_remove_one here, f
eached,
so such solution is not good enough.
Regards
--
Julian Anastasov <j...@ssi.bg>
ar, no reference to other objects)
>
> I tried to make this patch as small as possible to ease its backport,
> instead of being super clean. Note that we believe that only ipv4 dst
> need to take care of the metric refcount. But if this is wrong,
> this patch adds the basic in
included in kernel. I see
that GARP replies can not work for 1394, is_garp will be
cleared. May be 'tha' check should be moved in if expression,
for example:
if (is_garp && ar_op == htons(ARPOP_REPLY) && tha)
is_garp = !memcmp(tha, sha, dev->addr_len);
> + !memcmp(tha, sha, dev->addr_len);
> +
> + return is_garp;
> +}
Regards
--
Julian Anastasov <j...@ssi.bg>
(addr_type == RTN_UNICAST ||
(addr_type < 0 &&
inet_addr_type_dev_table(net, dev, sip) == RTN_UNICAST)
n = __neigh_lookup(_tbl, , dev, 1);
As result, we will avoid the unneeded
inet_addr_type_dev_table() call for ARP requests (non-GARP)
which are too common to see. May be there is another way
to make this code more nice...
Regards
--
Julian Anastasov <j...@ssi.bg>
Hello,
On Mon, 15 May 2017, Cong Wang wrote:
> On Mon, May 15, 2017 at 1:37 PM, Julian Anastasov <j...@ssi.bg> wrote:
> > Any user that does not set FIB_LOOKUP_NOREF
> > will need nh_dev refcounts. The assumption is that the
> > NHs are accessed, who k
Hello,
On Mon, 15 May 2017, Ihar Hrachyshka wrote:
> On Mon, May 15, 2017 at 1:05 PM, Julian Anastasov <j...@ssi.bg> wrote:
> >
> > It seems arp_accept value currently has influence on
> > the locktime for GARP requests. My understanding is that
>
Hello,
On Mon, 15 May 2017, Cong Wang wrote:
> On Fri, May 12, 2017 at 2:27 PM, Julian Anastasov <j...@ssi.bg> wrote:
> > Now the main question: is FIB_LOOKUP_NOREF used
> > everywhere in IPv4? I guess so. If not, it means
> > someone can walk its
kernel
> layer. This would require tracking timestamps for state transitions
> separately from timestamps when actual updates are received. This would
> probably involve changes in neighbour struct. Therefore, the patch
> doesn't tackle the issue of the first gratuitous APR ignored, le
Hello,
On Fri, 12 May 2017, Cong Wang wrote:
> On Thu, May 11, 2017 at 11:39 PM, Julian Anastasov <j...@ssi.bg> wrote:
> >
> > fib_flush will unlink the FIB infos at NETDEV_UNREGISTER
> > time, so we can not see them in any hash tables later on
d?) but as we don't set nh_dev to NULL this is not
needed.
What more? What about nh_pcpu_rth_output and
nh_rth_input holding routes? We should think about
them too. I should think more if nh_oif trick can work
for them, may be not because nh_oif is optional...
May be we should purge them somehow?
Regards
--
Julian Anastasov <j...@ssi.bg>
Hello,
On Wed, 10 May 2017, Cong Wang wrote:
> On Wed, May 10, 2017 at 12:38 AM, Julian Anastasov <j...@ssi.bg> wrote:
> >
> > During NETDEV_UNREGISTER packets for dev should not
> > be flying but packets for other devs can walk the nextho
place that holds
routes without listening for NETDEV_UNREGISTER? On fib_flush
the infos are unlinked from trees, so after a grace period packets
should not see/hold such infos. If we hold routes somewhere for
long time, problem can happen also for routes with single nexthop.
Regards
--
Julian Anastasov <j...@ssi.bg>
please keep me posted as this is merged?
Sure. Thanks for the confirmation! I'll do some
tests and will post official patch in few days.
Regards
--
Julian Anastasov <j...@ssi.bg>
Hello,
On Mon, 24 Apr 2017, Paolo Abeni wrote:
> Hi,
>
> The problem with the patched code is that it tries to resolve ipv6
> addresses that are not created/validated by the kernel.
OK. Simon, please apply to ipvs tree.
Acked-by: Julian Anastasov <j...@s
an happen also for TCP or remote clients when the
real server sends the reply traffic via the director.
So, better to be more precise for the reply traffic.
As replies are not expected for DR/TUN connections, better
to not touch them.
Reported-by: Nick Moriarty <nick.moria...@york.ac.uk
ted even when dests are missing.
We may use retc = 10 there. Not fatal but may eat memory for
conns that will not be used.
Regards
--
Julian Anastasov <j...@ssi.bg>
tp->dst_pending_confirm concurrently with the
sending. My idea was only when skb was used to confirm
neighbour only then to clear the indication. I guess, your
patch is ok because we should be locking the socket
everywhere.
Regards
--
Julian Anastasov <j...@ssi.bg>
Restore the lost masking of TOS in input route code to
allow ip rules to match it properly.
Problem [1] noticed by Shmulik Ladkani <shmulik.ladk...@gmail.com>
[1] http://marc.info/?t=137331755300040=1=2
Fixes: 89aef8921bfb ("ipv4: Delete routing cache.")
Signed-off-by: Jul
Avoid matching of random stack value for uid when rules
are looked up on input route or when RP filter is used.
Problem should affect only setups that use ip rules with
uid range.
Fixes: 622ec2c9d524 ("net: core: add UID to flows, rules, and routes")
Signed-off-by: Julian Anastasov &l
ot;net: Add optional SKB arg to dst_ops->neigh_lookup().")
Signed-off-by: Julian Anastasov <j...@ssi.bg>
---
net/xfrm/xfrm_policy.c | 29 +
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
inde
d description and add sync_refresh_period,
> sync_retries
> ipvs: Document sysctl sync_qlen_max and sync_sock_size
> ipvs: Document sysctl sync_ports
> ipvs: Document sysctl pmtu_disc
All patches look ok to me, thanks!
Acked-by: Julian Anastasov <j...@ssi.bg>
ackets that exceed
the PMTU, irrespective of the forwarding method. For TUN method
the flag can be disabled to fragment such packets."
> Documentation/networking/ipvs-sysctl.txt | 68
>
> 1 file changed, 60 insertions(+), 8 deletions(-)
Regards
--
Julian Anastasov <j...@ssi.bg>
orenko <vfedore...@yandex-team.ru>
> Reviewed-by: Konstantin Khlebnikov <khlebni...@yandex-team.ru>
Looks good to me, thanks!
Acked-by: Julian Anastasov <j...@ssi.bg>
> ---
> net/netfilter/ipvs/ip_vs_xmit.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 delet
Hello,
On Fri, 3 Feb 2017, Steffen Klassert wrote:
> On Thu, Feb 02, 2017 at 01:04:34AM +0200, Julian Anastasov wrote:
> >
> > For now I installed common handler, just like
> > xfrm_neigh_lookup. BTW this function has problem from
> > commit f894
After the dst->pending_confirm flag was removed, we do not
need anymore to provide dst arg to dst_neigh_output.
So, rename it to neigh_output as before commit 5110effee8fd
("net: Do delayed neigh confirmation.").
Signed-off-by: Julian Anastasov <j...@ssi.bg>
---
drivers/n
.
Signed-off-by: Julian Anastasov <j...@ssi.bg>
Acked-by: Eric Dumazet <eduma...@google.com>
---
drivers/net/vrf.c | 5 -
include/linux/skbuff.h | 12
include/net/sock.h | 14 ++
net/ipv4/ip_output.c | 5 -
net/ipv6/ip6_output.c | 1 +
5 files
ot;ipv4: Cache output routes in fib_info nexthops.")
Signed-off-by: Julian Anastasov <j...@ssi.bg>
Acked-by: Eric Dumazet <eduma...@google.com>
---
net/ipv4/ip_output.c | 6 ++
net/ipv4/ping.c | 3 ++-
net/ipv4/raw.c| 6 +-
net/ipv4/udp.c| 3 ++-
<yuehaib...@huawei.com>
Fixes: 5110effee8fd ("net: Do delayed neigh confirmation.")
Fixes: f2bb4bedf35d ("ipv4: Cache output routes in fib_info nexthops.")
Signed-off-by: Julian Anastasov <j...@ssi.bg>
Acked-by: Eric Dumazet <eduma...@google.com>
Acked-
Klassert.
Signed-off-by: Julian Anastasov <j...@ssi.bg>
---
include/net/arp.h | 16
include/net/dst.h | 7 +++
include/net/dst_ops.h | 2 ++
include/net/ndisc.h| 17 +
net/ipv4/route.c | 19 +++
net/ipv6/route.c
lled. For now
I just removed the dst->pending_confirm flag and left all
dst_confirm() calls there. Any better idea?
- Now may be old function neigh_output() should be restored
instead of dst_neigh_output?
Julian Anastasov (7):
sock: add sk_dst_pending_confirm flag
net: add dst_pending_confirm flag to
called for received packets.
Signed-off-by: Julian Anastasov <j...@ssi.bg>
Acked-by: Eric Dumazet <eduma...@google.com>
---
include/net/sock.h | 12
net/core/sock.c| 2 ++
2 files changed, 14 insertions(+)
diff --git a/include/net/sock.h b/include/net/sock.h
index 94e6
es: f2bb4bedf35d ("ipv4: Cache output routes in fib_info nexthops.")
Signed-off-by: Julian Anastasov <j...@ssi.bg>
Acked-by: Eric Dumazet <eduma...@google.com>
---
include/net/dst.h | 14 ++
net/core/dst.c| 1 -
2 files changed, 2 insertions(+), 13 deletion
fee8fd ("net: Do delayed neigh confirmation.")
Fixes: f2bb4bedf35d ("ipv4: Cache output routes in fib_info nexthops.")
Tested-by: YueHaibing <yuehaib...@huawei.com>
Signed-off-by: Julian Anastasov <j...@ssi.bg>
Acked-by: Eric Dumazet <eduma...@google.com>
---
net/ip
Hello,
On Fri, 3 Feb 2017, Steffen Klassert wrote:
> On Thu, Feb 02, 2017 at 01:04:34AM +0200, Julian Anastasov wrote:
> >
> > It may sounds good. But only dst->path->ops->confirm_neigh
> > points to real IPv4/IPv6 function. And also, I guess, t
Hello,
On Wed, 1 Feb 2017, Steffen Klassert wrote:
> On Tue, Jan 31, 2017 at 11:57:05PM +0200, Julian Anastasov wrote:
> >
> > +static void xfrm_confirm_neigh(const struct dst_entry *dst, const void
> > *daddr)
> > +{
> > + const s
ot;ipv4: Cache output routes in fib_info nexthops.")
Signed-off-by: Julian Anastasov <j...@ssi.bg>
Acked-by: Eric Dumazet <eduma...@google.com>
---
net/ipv4/ip_output.c | 6 ++
net/ipv4/ping.c | 3 ++-
net/ipv4/raw.c| 6 +-
net/ipv4/udp.c| 3 ++-
aibing <yuehaib...@huawei.com>
Fixes: 5110effee8fd ("net: Do delayed neigh confirmation.")
Fixes: f2bb4bedf35d ("ipv4: Cache output routes in fib_info nexthops.")
Tested-by: YueHaibing <yuehaib...@huawei.com>
Signed-off-by: Julian Anastasov <j...@ssi.bg>
<yuehaib...@huawei.com>
Fixes: 5110effee8fd ("net: Do delayed neigh confirmation.")
Fixes: f2bb4bedf35d ("ipv4: Cache output routes in fib_info nexthops.")
Signed-off-by: Julian Anastasov <j...@ssi.bg>
Acked-by: Eric Dumazet <eduma...@google.com>
Acked-
Add confirm_neigh method to dst_ops and use it from IPv4 and IPv6
to lookup and confirm the neighbour. Its usage via the new helper
dst_confirm_neigh() should be restricted to MSG_PROBE users for
performance reasons.
Signed-off-by: Julian Anastasov <j...@ssi.bg>
Acked-by: Eric Dumazet
called for received packets.
Signed-off-by: Julian Anastasov <j...@ssi.bg>
Acked-by: Eric Dumazet <eduma...@google.com>
---
include/net/sock.h | 12
net/core/sock.c| 2 ++
2 files changed, 14 insertions(+)
diff --git a/include/net/sock.h b/include/net/sock.h
index 7144
ls but I'm not sure dst_neigh_output() was called. For now
I just removed the dst->pending_confirm flag and left all
dst_confirm() calls there. Any better idea?
- Now may be old function neigh_output() should be restored
instead of dst_neigh_output?
Julian Anastasov (7):
sock: add
.
Signed-off-by: Julian Anastasov <j...@ssi.bg>
Acked-by: Eric Dumazet <eduma...@google.com>
---
drivers/net/vrf.c | 5 -
include/linux/skbuff.h | 12
include/net/sock.h | 14 ++
net/ipv4/ip_output.c | 5 -
net/ipv6/ip6_output.c | 1 +
5 files
es: f2bb4bedf35d ("ipv4: Cache output routes in fib_info nexthops.")
Signed-off-by: Julian Anastasov <j...@ssi.bg>
Acked-by: Eric Dumazet <eduma...@google.com>
---
include/net/dst.h | 14 ++
net/core/dst.c| 1 -
2 files changed, 2 insertions(+), 13 deletion
Hello,
On Mon, 30 Jan 2017, David Miller wrote:
> From: Julian Anastasov <j...@ssi.bg>
> >
> > So, the following solution is to avoid using
> > dst->pending_confirm.
>
> For the most part this series looks good to me, nice work.
OK, I
.
Signed-off-by: Julian Anastasov <j...@ssi.bg>
---
drivers/net/vrf.c | 5 -
include/linux/skbuff.h | 12
include/net/sock.h | 14 ++
net/ipv4/ip_output.c | 5 -
net/ipv6/ip6_output.c | 1 +
5 files changed, 35 insertions(+), 2 deletions(-)
diff
<yuehaib...@huawei.com>
Fixes: 5110effee8fd ("net: Do delayed neigh confirmation.")
Fixes: f2bb4bedf35d ("ipv4: Cache output routes in fib_info nexthops.")
Signed-off-by: Julian Anastasov <j...@ssi.bg>
---
include/net/sctp/sctp.h| 6 ++
include/net/sc
Add confirm_neigh method to dst_ops and use it from IPv4 and IPv6
to lookup and confirm the neighbour. Its usage via the new helper
dst_confirm_neigh() should be restricted to MSG_PROBE users for
performance reasons.
Signed-off-by: Julian Anastasov <j...@ssi.bg>
---
include/net/arp.h
called for received packets.
Signed-off-by: Julian Anastasov <j...@ssi.bg>
---
include/net/sock.h | 12
net/core/sock.c| 2 ++
2 files changed, 14 insertions(+)
diff --git a/include/net/sock.h b/include/net/sock.h
index 7144750..e113786 100644
--- a/include/net/sock.h
+++ b/i
es: f2bb4bedf35d ("ipv4: Cache output routes in fib_info nexthops.")
Signed-off-by: Julian Anastasov <j...@ssi.bg>
---
include/net/dst.h | 14 ++
net/core/dst.c| 1 -
2 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/include/net/dst.h b/include/net/dst
ot;ipv4: Cache output routes in fib_info nexthops.")
Signed-off-by: Julian Anastasov <j...@ssi.bg>
---
net/ipv4/ip_output.c | 6 ++
net/ipv4/ping.c | 3 ++-
net/ipv4/raw.c| 6 +-
net/ipv4/udp.c| 3 ++-
net/ipv6/ip6_output.c | 6 ++
net/ipv6/raw.c
led to understand the CXGB* code, I see dst_confirm()
calls but I'm not sure dst_neigh_output() was called. For now
I just removed the dst->pending_confirm flag and left all
dst_confirm() calls there. Any better idea?
- Now may be old function neigh_output() should be restored
instead of dst_neigh_o
fee8fd ("net: Do delayed neigh confirmation.")
Fixes: f2bb4bedf35d ("ipv4: Cache output routes in fib_info nexthops.")
Signed-off-by: Julian Anastasov <j...@ssi.bg>
---
net/ipv4/tcp_input.c | 12 +++-
net/ipv4/tcp_metrics.c | 7 ++-
net/ipv4/tcp_output.c | 2 +
ed
> shortly in a separate patch. refcount_t is the new kernel type for
> holding reference counts, and provides overflow protection and a
> constrained interface relative to atomic_t (the type currently being
> used for kernel reference counts).
>
> Per Julian Anastasov: "The problem
ere".
- "dest lives in trash with[out] reference" in __ip_vs_del_dest
When sending v2 for net-next please also CC:
Simon Horman <ho...@verge.net.au>
Pablo Neira Ayuso <pa...@netfilter.org>
lvs-de...@vger.kernel.org
I'll ack the next version after some tests...
Regards
--
Julian Anastasov <j...@ssi.bg>
st_trash_expire() should be updated. Let me know if
this holds your work, I can provide such patch to fix it.
Regards
--
Julian Anastasov <j...@ssi.bg>
Hello,
On Fri, 20 Jan 2017, YueHaibing wrote:
> Sorry for so late reply.
> I have test your new patch, It works well in my scene.
Thanks! I'll prepare 2nd version in the following days...
Regards
--
Julian Anastasov <j...@ssi.bg>
Hello,
On Wed, 21 Dec 2016, Neil Horman wrote:
> On Sun, Dec 18, 2016 at 10:56:32PM +0200, Julian Anastasov wrote:
> > - tp->af_specific->sctp_xmit(head, tp);
> > + confirm = tp->dst_pending_confirm;
> > + if (confirm)
> > + head->
tional cache line. My preliminary analyze pointed
sk_omem_alloc as good candidate for moving to next cache
line. I know how critical is to properly place the new flags,
so I really need recommendations about this.
Regards
--
Julian Anastasov <j...@ssi.bg>
called for received packets.
Signed-off-by: Julian Anastasov <j...@ssi.bg>
---
include/net/sock.h | 14 +-
net/core/sock.c| 2 ++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 282d065..e83bb01 100644
--- a/inclu
1 - 100 of 255 matches
Mail list logo