t; skb_dst(skb) for NULL after skb_dst_force() and drop the packet
> in cast the dst_entry was cleared.
>
> Fixes: 222d7dbd258d ("net: prevent dst uses after free")
> Reported-by: Tobias Hommel
> Reported-by: Kristian Evensen
> Reported-by: Wolfgang Walter
> Signed-off-by: S
ng) so that we can check
how often that happens here?
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
eturn atomic_inc_not_zero(>__refcnt);
}
Am Freitag, 7. September 2018, 22:22:39 schrieb Wolfgang Walter:
> Am Freitag, 31. August 2018, 08:50:24 schrieb Steffen Klassert:
> > On Thu, Aug 30, 2018 at 08:53:50PM +0200, Wolfgang Walter wrote:
> > > Hello,
> > >
> >
Am Freitag, 31. August 2018, 08:50:24 schrieb Steffen Klassert:
> On Thu, Aug 30, 2018 at 08:53:50PM +0200, Wolfgang Walter wrote:
> > Hello,
> >
> > kernels > 4.12 do not work on one of our main routers. They crash as soon
> > as ipsec-tunnels are configured an
Hello,
didn't respond as I've been on vacation.
Am Freitag, 31. August 2018, 08:50:24 schrieb Steffen Klassert:
> On Thu, Aug 30, 2018 at 08:53:50PM +0200, Wolfgang Walter wrote:
> > Hello,
> >
> > kernels > 4.12 do not work on one of our main routers. They crash as s
y run 4.9 on the machine with the problem and 4.14
on most other routers.
I also tested 4.18.5 and it still shows this bug.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
; 4.12 from debian, they also crash.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
Am Mittwoch, 20. Januar 2016, 17:58:52 schrieb Nicolas Dichtel:
> Le 20/01/2016 15:00, Wolfgang Walter a écrit :
> > Hello,
> >
> > we tried 4.4 on our routers. We found one problem: 4.4 stops routing GRE
> > packets (ipv4 in GRE/ipv4) here. 4.4.15 works fine.
Am Mittwoch, 4. November 2015, 04:40:51 schrieb Eric Dumazet:
> On Wed, 2015-11-04 at 13:19 +0100, Wolfgang Walter wrote:
> > Today I found a problem: on a router forwarding GRE-packets (ipv4) (it is
> > not the endpount) the interface (intel igb) stops sending packets after
> &g
Am Dienstag, 3. November 2015, 05:07:33 schrieb Eric Dumazet:
> On Tue, 2015-11-03 at 13:57 +0100, Wolfgang Walter wrote:
> > Am Montag, 19. Oktober 2015, 20:40:17 schrieb Eric Dumazet:
> > > From: Eric Dumazet <eduma...@google.com>
> > >
> > > Tom He
Am Mittwoch, 4. November 2015, 07:13:07 schrieb Eric Dumazet:
> On Wed, 2015-11-04 at 15:09 +0100, Wolfgang Walter wrote:
> > Yes, maybe igb has a problem sending a gro-packet if it is an isatap in
> > gre.
> We might detect this condition properly from igb ndo_featu
cks = {
> @@ -292,6 +302,8 @@ static struct packet_offload ipv6_packet_offload
> __read_mostly = { static const struct net_offload sit_offload = {
> .callbacks = {
> .gso_segment= ipv6_gso_segment,
> + .gro_receive= ipv6_gro_receive,
> +
This patch reverts 19424e052fb44da2f00d1a868cbb51f3e9f4bbb5 ("sit:
> > Add gro callbacks to sit_offload") because it generates packets
> > that cannot be handled even by our own GSO.
> >
> > Reported-by: Wolfgang Walter <li...@stwm.de>
> &g
types of production-like loads with it for 14+ hours without hanging.
>
> Just got up, and yes - my systems survived the night as well, no issues.
>
> Greg, any chance you can drop this into the pending 4.1.10? Otherwise people
> will get another broken release.
>
ries though.
After that the router completely hangs: networking stops working and we need to
restart it.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@
Am Montag, 20. Juli 2015, 14:14:59 schrieb Herbert Xu:
On Fri, Jul 17, 2015 at 05:38:30PM +0200, Wolfgang Walter wrote:
eth1 stops sending with the patch after some time
disabling gro on eth0 helps
disabling tso or gso on eth0 and/or eth1 or both does not help
eth0 and eth1 are both
Am Freitag, 17. Juli 2015, 09:56:51 schrieb Herbert Xu:
On Thu, Jul 16, 2015 at 12:58:45PM +0200, Wolfgang Walter wrote:
Am Donnerstag, 16. Juli 2015, 08:23:50 schrieb Herbert Xu:
On Wed, Jul 15, 2015 at 02:25:59PM +0200, Wolfgang Walter wrote:
Yes. Switching TSO off and leaving GRO
Am Donnerstag, 16. Juli 2015, 08:23:50 schrieb Herbert Xu:
On Wed, Jul 15, 2015 at 02:25:59PM +0200, Wolfgang Walter wrote:
Yes. Switching TSO off and leaving GRO on works, too.
OK, could you please try this patch?
Patch works here.
Thanks,
Wolfgang
---8---
We need to set
Am Mittwoch, 15. Juli 2015, 17:50:20 schrieb Herbert Xu:
On Wed, Jul 15, 2015 at 02:34:41AM +0200, Wolfgang Walter wrote:
I wonder if the router may treat all ipv6-tcp connections of a host as a
single flow as all those ipv6-packets are embedded in ipv4-packets with
the
ipv4-address
with IPv6 support but IPv6 is disabled via kernel command
line. The router is not a tunnel endpoint, it only forwards the ISATAP-
packets. MTU is 1500 on both interfaces. Netfilter conntrack is not used and
disabling netfilter has no effect.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt
Am Mittwoch, 15. Juli 2015, 08:08:49 schrieben Sie:
On Wed, Jul 15, 2015 at 12:16:30AM +0200, Wolfgang Walter wrote:
Hello,
I upgraded routers from 3.14.x to 4.1.2. Forwarding ISATAP-packets (IPv4
packets with IPv6 payload) is very slow with 4.1 if GRO is enabled
(youtube
for example
Am Mittwoch, 6. Mai 2015, 11:15:18 schrieben Sie:
(Cc'ing netdev.)
On Sat, May 2, 2015 at 5:29 AM, Wolfgang Walter li...@stwm.de wrote:
Am Samstag, 2. Mai 2015, 02:16:36 schrieb Wolfgang Walter:
Hello,
kernel 4.0 (and 4.0.1) crashes immediately when I use traceroute6 with an
isatap
this in the lans of our
student halls.
I think flow control should be completely disabled by default if the switch
does not advertise it. It still can be forced with ethtool.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
--
To unsubscribe from this list: send the line
2007 14:34 schrieb Ilpo Järvinen:
On Mon, 3 Dec 2007, Wolfgang Walter wrote:
with kernel 2.6.23.8 we saw a
KERNEL: assertion ((int)tcp_packets_in_flight(tp) = 0) failed at
net/ipv4/tcp_input.c (1292)
Is this the only message? Are there any Leak printouts?
Any tweaking done to TCP
Am Montag, 3. Dezember 2007 14:34 schrieb Ilpo Järvinen:
On Mon, 3 Dec 2007, Wolfgang Walter wrote:
with kernel 2.6.23.8 we saw a
KERNEL: assertion ((int)tcp_packets_in_flight(tp) = 0) failed at
net/ipv4/tcp_input.c (1292)
Is this the only message? Are there any Leak printouts?
No.
4
Hello,
with kernel 2.6.23.8 we saw a
KERNEL: assertion ((int)tcp_packets_in_flight(tp) = 0) failed at
net/ipv4/tcp_input.c (1292)
Regards,
Wolfgang Walter
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
--
To unsubscribe from this list: send the line unsubscribe
that).
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
echo-reply packet (which has
the same source-address as the fragmentation needed) but only the outgoing
esp-packet (and the echo-reply reaches HB, by the way).
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
-
To unsubscribe from this list: send the line
Am Mittwoch, 12. September 2007 21:55 schrieb J. Bruce Fields:
On Wed, Sep 12, 2007 at 09:40:57PM +0200, Wolfgang Walter wrote:
On Wednesday 12 September 2007, J. Bruce Fields wrote:
On Wed, Sep 12, 2007 at 04:14:06PM +0200, Neil Brown wrote:
So it is in 2.6.21 and later and should
2.6.22.6 which changes the test to
svsk-sk_inuse = 0 which was probably meant. The patched kernel runs fine
here. Unused sockets get closed (after 6 to 12 minutes)
Signed-off-by: Wolfgang Walter [EMAIL PROTECTED]
--- ../linux-2.6.22.6/net/sunrpc/svcsock.c 2007-08-27 18:10:14.0
+0200
Am Mittwoch, 12. September 2007 15:37 schrieb J. Bruce Fields:
On Wed, Sep 12, 2007 at 02:07:10PM +0200, Wolfgang Walter wrote:
as already described old temporary sockets (client is gone) of lockd
aren't closed after some time. So, with enough clients and some time
gone, there are 80 open
not matter - SK_CLOSED may be set at any time.
svc_age_temp_sockets only detaches the socket, sets SK_CLOSED and then
enqueues it. If SK_BUSY is set its already enqueued and svc_sock_enqueue
ensures that it is not enqueued twice.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des
On Wednesday 12 September 2007, J. Bruce Fields wrote:
On Wed, Sep 12, 2007 at 09:40:57PM +0200, Wolfgang Walter wrote:
On Wednesday 12 September 2007, J. Bruce Fields wrote:
On Wed, Sep 12, 2007 at 04:14:06PM +0200, Neil Brown wrote:
So it is in 2.6.21 and later and should probably go
On Friday 07 September 2007, J. Bruce Fields wrote:
On Fri, Sep 07, 2007 at 05:49:55PM +0200, Wolfgang Walter wrote:
Hello,
3) For unknown reason these sockets then remain open. In the morning
when people start their workstation again we therefor not only get a
lot of these messages
in
svc_tcp_accept.
I already posted this patch on netdev@vger.kernel.org:
Signed-off-by: Wolfgang Walter [EMAIL PROTECTED]
--- linux-2.6.22.6/net/sunrpc/svcsock.c 2007-08-27 18:10:14.0 +0200
+++ linux-2.6.22.6w/net/sunrpc/svcsock.c2007-09-03 18:27:30.0
+0200
@@ -1090,7
Am Freitag, 7. September 2007 18:19 schrieben Sie:
On Fri, Sep 07, 2007 at 05:49:55PM +0200, Wolfgang Walter wrote:
Hello,
we upgraded the kernel of a nfs-server from 2.6.17.11 to 2.6.22.6. Since
then we get the message
lockd: too many open TCP sockets, consider increasing the number
be
printk(KERN_NOTICE
%s: last TCP connect from %s\n,
serv-sv_name, __svc_print_addr(sin, buf, sizeof(buf)));
Signed-off-by: Wolfgang Walter [EMAIL PROTECTED]
--- linux-2.6.22.6/net/sunrpc/svcsock.c 2007-08-27 18:10:14.0 +0200
+++ linux-2.6.22.6w/net/sunrpc
is found. But this route is via eth2.
Please note that if you set /proc/sys/net/ipv4/conf/eth3/rp_filter to 0 you
probably want to check the src address of incoming packets on eth3 for not
being ones from your eth1.
Greetings,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen
38 matches
Mail list logo
