Re: [2.4 PATCH] ethernet (net/ethernet/eth.c): eth_header() may produce invalid packets (with dest. addr. = 00:00:00:00:00:00)

On Wed, Jan 10, 2007 at 12:53:31PM +0100, Christian Praehauser wrote: Hello, and sorry for bothering you with a patch you've already seen ;-). I had not seen it yet, so I'm fine with it :-) From: Christian Praehauser, Department of Computer Sciences, University of Salzburg This patch

planned driver updates for 2.4.35

Hi David, As stated with the 2.4.34 announcement, I planned to perform a few updates in two network drivers for 2.4.35 : - e1000: the cards equipped with the not-so old 82546EB chips have completely disappeared from the earth surface, and people replacing hardware are experiencing

Re: [PATCH] sky2: flow control off

Hi Stephen, On Fri, Feb 02, 2007 at 03:34:25PM -0800, Stephen Hemminger wrote: Turn flow control off for sky2. When flow control is on, the transmitter may get randomly stuck. Perhaps there is hardware problem, but until Marvell provides errata information for workaround, it should default to

Re: [PATCH-2.4] forcedeth update to 0.50

On Wed, May 31, 2006 at 07:50:32AM +0200, Manfred Spraul wrote: Hi Willy, Willy Tarreau wrote: I started from the latest backport you sent in september (0.42) and incrementally applied 2.6 updates. I stopped at 0.50 which provides VLAN support, because after this one, there are some 2.4

Re: [PATCH-2.4] forcedeth update to 0.50

On Wed, May 31, 2006 at 09:50:38PM +0200, Manfred Spraul wrote: Marcelo Tosatti wrote: Since v2.4.33 should be out RSN, my opinion is that applying the one-liner to fix the bringup problem for now is more prudent.. It's attached. Untested, but it should work. Just the relevant hunk

Re: [Patch] 2.4.32 - Neighbour Cache (ARP) State machine bug Fixed

Hi, On Tue, Feb 07, 2006 at 12:57:43AM -0700, Pradeep Vincent wrote: In 2.4.21, arp code uses gc_timer to check for stale arp cache entries. In 2.6, each entry has its own timer to check for stale arp cache. 2.4.29 to 2.4.32 kernels (atleast) use neither of these timers. This causes problems

SKGE backport to 2.4 : success

Hi Stephen, In my own kernels, I've added your backport of SKGE to 2.4 that I found here : http://developer.osdl.org/shemminger/releases/skge-sky2-backport.tar.bz2 It seems to work pretty well compared to the original syskonnect driver (up to and including 8.36). Several people around me

Re: SKGE backport to 2.4 : success

On Mon, Nov 06, 2006 at 10:56:09AM -0800, Stephen Hemminger wrote: On Sat, 4 Nov 2006 22:08:55 +0100 Willy Tarreau [EMAIL PROTECTED] wrote: Hi Stephen, I don't know if you received my mail since I got no reply. Thanks in advance for your comments, Willy On Sat, Oct 28, 2006

Re: [IPv4] fib: Fix out of bound access of fib_props[]

On Sat, Mar 24, 2007 at 08:33:39PM -0700, David Miller wrote: From: Thomas Graf [EMAIL PROTECTED] Date: Sat, 24 Mar 2007 16:34:36 +0100 Fixes a typo which caused fib_props[] to have the wrong size and makes sure the value used to index the array which is provided by userspace via netlink

Re: [IPv4] fib: Fix out of bound access of fib_props[]

On Sat, Apr 14, 2007 at 04:26:55PM +0200, Willy Tarreau wrote: On Sat, Mar 24, 2007 at 08:33:39PM -0700, David Miller wrote: From: Thomas Graf [EMAIL PROTECTED] Date: Sat, 24 Mar 2007 16:34:36 +0100 Fixes a typo which caused fib_props[] to have the wrong size and makes sure the value

Re: [IPv4] fib: Fix out of bound access of fib_props[]

On Mon, Apr 16, 2007 at 10:14:17AM +0200, Thomas Graf wrote: * Willy Tarreau [EMAIL PROTECTED] 2007-04-14 17:48 Finally, I think I have the correct fix below. Please someone confirm or tell me I'm nuts. Looks good, same is needed for DECnet Thank you Thomas. The DECnet stuff was already

Re: 2.6.16, sk98lin out of date

On Mon, Feb 13, 2006 at 02:03:14PM -0500, Lee Revell wrote: On Mon, 2006-02-13 at 12:06 +0100, Mws wrote: hi, as i do have the same problem i may help you out. at first, syskonnect did send their kernel diffs/patches but they we're rejected caused by coding style, indention and some

Re: Linux v2.6.16-rc6

On Sat, Mar 11, 2006 at 06:39:04PM -0800, David S. Miller wrote: From: Michal Piotrowski [EMAIL PROTECTED] Date: Sun, 12 Mar 2006 02:51:40 +0100 I have noticed this warnings TCP: Treason uncloaked! Peer 82.113.55.2:11759/50967 shrinks window 148470938:148470943. Repaired. TCP: Treason

Re: 2.4.32: unresolved symbol unregister_qdisc

On Sun, Apr 09, 2006 at 08:29:12PM -0700, Randy.Dunlap wrote: On Sun, 9 Apr 2006 23:20:01 -0400 (EDT) George P Nychis wrote: On Sun, 9 Apr 2006 22:49:50 -0400 (EDT) George P Nychis wrote: On Sun, 9 Apr 2006 22:05:33 -0400 (EDT) George P Nychis wrote: On Sun, 9 Apr

[PATCH-2.6] e1000: fix media_type - phy_type thinko

Recent patch cb764326dff0ee51aca0d450e1a292de65661055 introduced a thinko in e1000_main.c : e1000_media_type_copper is compared to hw.phy_type instead of hw.media_type. Original patch proposed by Jesse Brandeburg was correct, but what has been merged is not. --- drivers/net/e1000/e1000_main.c

Re: [PATCH] sky2: flow control off

Hi Stephen, First, thanks for this detailed explanation. On Mon, Feb 05, 2007 at 09:22:53AM -0800, Stephen Hemminger wrote: Here is what I saw. The transmitter on the Marvell Yukon II (88e8053) hangs when doing transmit flow control under load. There appears to be a bug or race condition

Re: [PATCH 2.4 0/3] e1000: update to 7.3.20

Hi Auke, On Mon, Feb 05, 2007 at 05:01:02PM -0800, Kok, Auke wrote: Willy, Please pull: git-pull git://lost.foo-projects.org/~ahkok/git/linux-2.4 e1000 to receive an update for the e1000 driver. This updates the e1000 driver in the 2.4 kernel to version 7.3.20-k4, roughly the

Re: [PATCH] tcp_cubic: use 32 bit math

On Wed, Mar 07, 2007 at 07:10:47PM -0800, Stephen Hemminger wrote: David Miller wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Wed, 7 Mar 2007 17:07:31 -0800 The basic calculation has to be done in 32 bits to avoid doing 64 bit divide by 3. The value x is only 22bits max so

Re: [PATCH] tcp_cubic: use 32 bit math

On Wed, Mar 07, 2007 at 07:51:35PM -0800, David Miller wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Wed, 07 Mar 2007 19:10:47 -0800 David Miller wrote: What about Willy Tarreau's supposedly even faster variant? Or does this incorporate that set of improvements? That's

Re: [PATCH] tcp_cubic: use 32 bit math

lookups only. * Avg err ~= 0.613% */ static uint32_t ncubic_tab0(uint64_t a) { uint32_t b; uint32_t shift; /* * cbrt(x) MSB values for x MSB values in [0..63]. * Precomputed then refined by hand - Willy Tarreau * * For x in [0..63

Re: [PATCH] tcp_cubic: use 32 bit math

Hi Stephen, On Wed, Mar 21, 2007 at 11:54:19AM -0700, Stephen Hemminger wrote: On Tue, 13 Mar 2007 21:50:20 +0100 Willy Tarreau [EMAIL PROTECTED] wrote: [...] ( cut my boring part ) Here are the results classed by speed : /* Sample output on a Pentium-M 600 MHz : Function

Re: Network performance degradation from 2.6.11.12 to 2.6.16.20

Hi Andi, On Mon, Jun 19, 2006 at 05:24:31PM +0200, Andi Kleen wrote: If you use pmtmr try to reboot with kernel option clock=tsc. That's dangerous advice - when the system choses not to use TSC it often has a reason. On my Opteron AMD system i normally can route 400 kpps, but with

Re: [PATCH] getsockopt() early argument sanity checking

On Sun, Aug 20, 2006 at 03:05:32AM +0400, Solar Designer wrote: Willy, I propose the attached patch (extracted from 2.4.33-ow1) for inclusion into 2.4.34-pre. (2.6 kernels could benefit from the same change, too, but at the moment I am dealing with proper submission of generic changes

Re: [PATCH] getsockopt() early argument sanity checking

On Sun, Aug 20, 2006 at 02:05:20AM +0200, Michael Buesch wrote: On Sunday 20 August 2006 01:48, Willy Tarreau wrote: On Sun, Aug 20, 2006 at 03:05:32AM +0400, Solar Designer wrote: Willy, I propose the attached patch (extracted from 2.4.33-ow1) for inclusion into 2.4.34-pre

Re: [PATCH] getsockopt() early argument sanity checking

On Sun, Aug 20, 2006 at 10:34:43AM +0200, Andi Kleen wrote: On Sunday 20 August 2006 01:05, Solar Designer wrote: I propose the attached patch (extracted from 2.4.33-ow1) for inclusion into 2.4.34-pre. (2.6 kernels could benefit from the same change, too, but at the moment I am dealing

Re: [PATCH] getsockopt() early argument sanity checking

Hi David, On Sun, Aug 20, 2006 at 12:44:27PM -0700, David Miller wrote: From: Willy Tarreau [EMAIL PROTECTED] Date: Sun, 20 Aug 2006 02:43:07 +0200 On Sun, Aug 20, 2006 at 02:05:20AM +0200, Michael Buesch wrote: Not to me. It heavily violates codingstyle and screws brains

Re: TCP SACK issue, hung connection, tcpdump included

Hi, [CCing netdev as it's where people competent on the subject are] On Sun, Jul 29, 2007 at 06:59:26AM +0100, Darryl L. Miles wrote: CLIENT = Linux 2.6.20.1-smp [Customer build] SERVER = Linux 2.6.9-55.ELsmp [Red Hat Enterprise Linux AS release 4 (Nahant Update 5)] The problems start

Re: TCP SACK issue, hung connection, tcpdump included

On Sun, Jul 29, 2007 at 11:26:00AM +0300, Ilpo Järvinen wrote: On Sun, 29 Jul 2007, Willy Tarreau wrote: On Sun, Jul 29, 2007 at 06:59:26AM +0100, Darryl L. Miles wrote: CLIENT = Linux 2.6.20.1-smp [Customer build] SERVER = Linux 2.6.9-55.ELsmp [Red Hat Enterprise Linux AS release 4

Re: TCP SACK issue, hung connection, tcpdump included

On Sun, Jul 29, 2007 at 12:28:04PM +0300, Ilpo Järvinen wrote: (...) Limitation for 48 byte segments? You have to be kidding... :-) But yes, it seems that one of the directions is dropping packets for some reason though I would not assume MTU limitation... Or did you mean some other

[PATCH] e100 module loads 1/2 times

Hi Auke, Jesse, for a long time, I've been annoyed by version 3.5.17 of the e100 driver which refuses to load on first time and only loads on second time. Since I always had the original 2.3.43 driver in kernel 2.4, I did not care that much. Recently, I encountered real troubles with 2.3.43 in a

Re: Marvell 88E8056 gigabit ethernet controller

On Sat, Aug 18, 2007 at 04:45:26AM -0700, Kevin E wrote: --- Willy Tarreau [EMAIL PROTECTED] wrote: No Stephen, look again, he says that moving the video card into the broken system does not change anything. Correct, I've used three different video cards in the broken machine. I've

Re: [2.6.20.17 review 35/58] forcedeth bug fix: realtek phy

On Wed, Aug 22, 2007 at 11:56:42AM -0400, Chuck Ebbert wrote: On 08/22/2007 05:39 AM, Willy Tarreau wrote: This patch contains errata fixes for the realtek phy. It only renamed the defines to be phy specific. Signed-off-by: Ayaz Abdulla [EMAIL PROTECTED] Signed-off-by: Greg Kroah

[PATCH] fix realtek phy id in forcedeth

it is. Please apply to mainline then stable. Thanks, Willy -- From a0e2922b99eedd9863232368ea2afe072c52783e Mon Sep 17 00:00:00 2001 From: Willy Tarreau [EMAIL PROTECTED] Date: Thu, 23 Aug 2007 21:35:41 +0200 Subject: [PATCH] fix realtek phy id in forcedeth As noticed by Chuck Ebbert, commit

Re: 2.6.22.5 forcedeth timeout hang

On Thu, Aug 23, 2007 at 06:48:23PM -0500, Mr. Berkley Shands wrote: 100% reproducible hang on xmit timeout. Just do a make -j4 modules on an nfs mounted kernel source. Most likely you also had the problem with 2.6.22.2 (maybe you have not tested this one, though). There were bug fixes for

Re: [PATCH] e100 module loads 1/2 times

On Tue, Aug 28, 2007 at 02:43:23PM -0700, Brandeburg, Jesse wrote: Willy Tarreau wrote: --- e100-3.5.17/src/e100.c.orig 2007-08-13 08:53:18 +0200 +++ e100-3.5.17/src/e100.c 2007-08-13 09:24:56 +0200 @@ -2934,13 +2934,13 @@ printk(KERN_INFO PFX %s\n, DRV_COPYRIGHT

Re: sk98lin for 2.6.23-rc1

On Tue, Sep 11, 2007 at 05:03:57PM +0200, Adrian Bunk wrote: On Tue, Sep 11, 2007 at 10:29:47AM -0400, Bill Davidsen wrote: So if you want people to try a new driver, I think it really has to have some benefits to the users, in terms of performance, reliability, or features. Cleaner

Re: bnx2 dirver's firmware images

On Tue, Sep 18, 2007 at 12:21:50PM -0700, David Miller wrote: From: Michael Chan [EMAIL PROTECTED] Date: Tue, 18 Sep 2007 13:05:51 -0700 The bnx2 firmware changes quite frequently. A new driver quite often requires new firmware to work correctly. Splitting them up makes things

Re: bnx2 dirver's firmware images

On Tue, Sep 18, 2007 at 02:31:34PM -0700, David Miller wrote: From: Willy Tarreau [EMAIL PROTECTED] Date: Tue, 18 Sep 2007 23:30:25 +0200 On Tue, Sep 18, 2007 at 12:21:50PM -0700, David Miller wrote: From: Michael Chan [EMAIL PROTECTED] Date: Tue, 18 Sep 2007 13:05:51 -0700

FWD: 2.4.35 e1000 problems

Hi, Dmitry, I've forwarded your mail to the netdev mailing list and to the e1000 maintainers. Auke, does it sound like a known problem ? Maybe someone has seen it in 2.6 ? Just for the record, e1000 in 2.4.35 is 7.3.20-k4. Dmitry, if you have time for a test, I think it would be good if you

Re: ISNs and 2.6.22, Was: Re: haproxy linux firewall (netfilter)

On Sat, Oct 20, 2007 at 07:23:25PM +0200, Krzysztof Oledzki wrote: (...) So it seems that ISNs are not randomly incremented but rather randomly generated. Adding netdev@vger.kernel.org to the CC list. Eh, I was little to hurry this time. There were not randomly generated but incremented

Re: [PATCH 2/2] [e1000 VLAN] Disable vlan hw accel when promiscuous mode

On Mon, Nov 12, 2007 at 02:57:16PM -0800, David Miller wrote: From: Chris Friesen [EMAIL PROTECTED] Date: Mon, 12 Nov 2007 16:43:24 -0600 David Miller wrote: When you select VLAN, you by definition are asking for non-VLAN traffic to be elided. It is like plugging the ethernet cable

Re: [PATCH 2/2] [e1000 VLAN] Disable vlan hw accel when promiscuous mode

On Mon, Nov 12, 2007 at 03:19:23PM -0800, David Miller wrote: From: Willy Tarreau [EMAIL PROTECTED] Date: Tue, 13 Nov 2007 00:15:16 +0100 I can say that sometimes you'd like to be aware that one of your VLANs is wrong and you'd simply like to sniff the wire to guess the correct tag

Re: questions on NAPI processing latency and dropped network packets

On Wed, Jan 16, 2008 at 07:58:36AM +0100, Jarek Poplawski wrote: On Wed, Jan 16, 2008 at 11:17:08AM +1100, Herbert Xu wrote: ... Well people are always going to operate on this model for commercial reasons. FWIW I used to work for a company that stuck to a specific version of the Linux

Re: [PATCH] Add IPv6 support to TCP SYN cookies

Hi Andi, Alan, I've run extensive tests with/without syn cookies recently. On Tue, Feb 05, 2008 at 05:39:12PM +0100, Andi Kleen wrote: On Tue, Feb 05, 2008 at 03:42:13PM +, Alan Cox wrote: Syncookies are discouraged these days. They disable too many valuable TCP features (window

Re: [PATCH] Add IPv6 support to TCP SYN cookies

On Wed, Feb 06, 2008 at 12:52:17AM +0300, Evgeniy Polyakov wrote: Hi Alan. On Tue, Feb 05, 2008 at 09:20:17PM +, Alan Cox ([EMAIL PROTECTED]) wrote: Most (if not all) distributions have them enabled and window growing works just fine. Actually I do not see any reason why connection

Re: [RFC] [PATCH] net: socket: Fix the wrong returns for recvmsg and sendmsg

On Tue, Jun 02, 2015 at 02:43:54PM +0800, Junling Zheng wrote: On 2015/6/2 14:27, Greg KH wrote: On Mon, Jun 01, 2015 at 10:23:57PM -0700, David Miller wrote: From: Junling Zheng zhengjunl...@huawei.com Date: Tue, 2 Jun 2015 12:05:32 +0800 So, the problem commit is 281c9c36 (net:

Re: Fw: [Bug 99161] New: 2.6.32.66 PPC Oops in tcp_send_fin

Hi Eric, On Fri, May 29, 2015 at 08:52:11AM -0700, Eric Dumazet wrote: On Fri, 2015-05-29 at 08:12 -0700, Stephen Hemminger wrote: I think 2.6.32 is so old no one will care. A few will still, but at least we must ensure the old guy finishes his days nicely :-) (...) I guess a backport went

Re: 2.6.32.66 tcp regression OOPs

Hi, On Mon, Jun 01, 2015 at 09:00:21AM +0200, Frans Klaver wrote: [cc: Willy Tarreau] On Mon, Jun 1, 2015 at 3:26 AM, starlight.201...@binnacle.cx wrote: Hello, Apoligies if I have submitted to the wrong lists. Encountered a regression in 2.6.32.66 relative to 2.6.32.65

Re: 2.6.32.66 tcp regression OOPs

On Mon, Jun 01, 2015 at 11:32:19AM -0400, starlight.201...@binnacle.cx wrote: Hi, I found the patch late yesterday and applied it. Running fine now for 12 hours under active load. Thank you. Recommend the patch be rolled into the tarball, or a notation added to the release page as this

Re: [PATCH 4/6] net: mvneta: Handle per-cpu interrupts

Hi Maxime, On Fri, Jul 03, 2015 at 04:25:49PM +0200, Maxime Ripard wrote: Now that our interrupt controller is allowing us to use per-CPU interrupts, actually use it in the mvneta driver. This involves obviously reworking the driver to have a CPU-local NAPI structure, and report for

Re: [PATCH 6/6] net: mvneta: Statically assign queues to CPUs

Hi Thomas, On Fri, Jul 03, 2015 at 04:46:24PM +0200, Thomas Petazzoni wrote: Maxime, On Fri, 3 Jul 2015 16:25:51 +0200, Maxime Ripard wrote: +static void mvneta_percpu_enable(void *arg) +{ + struct mvneta_port *pp = arg; + + enable_percpu_irq(pp-dev-irq, IRQ_TYPE_NONE); +}

Re: [PATCH][kernel 2.6.32] Bond interface can't send gratuitous ARP

Hi Qingjie, On Mon, Jul 27, 2015 at 09:05:29AM +0800, ? wrote: Hi, Bond interface worked as Active-Backup mode. If the bond interface was added in bridge, then it's just a port of bridge. It doesn' have IP address. When bond slave changing, the current code bond_send_gratuitous_arp

Please backport commit to 3.12+

Hi, We recently faced the issue described in the patch below on 3.14.56. This fix was merged in 4.2-rc7. I checked Davem's queue and stable queue and it's not there yet. Could we please have it in 3.12 and above ? (feature was introduced in 3.11). I can confirm that it properly fixes the problem

Re: "ss -p" segfaults (updated to 4.2)

On Mon, Oct 12, 2015 at 09:50:19AM -0700, Stephen Hemminger wrote: > Applied, and did some editing on commit msg Thank you Stephen! Willy -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: "ss -p" segfaults (updated to 4.2)

if (!(u = malloc(sizeof(*u break; Also patched some other situations (strcpy and sprintf uses) that potentially produce the same results. Signed-off-by: Jose P Santos <j...@openmailbox.org> [ wt: made Jose's patch slightly simpler, all credits to him for the diag ] Signed

Re: NFS/TCP/IPv6 acting strangely in 4.2

Hi, On Wed, Sep 16, 2015 at 06:53:57AM +, Damien Thébault wrote: > On Fri, 2015-09-11 at 12:38 +0100, Russell King - ARM Linux wrote: > > I have a recent Marvell Armada 388 board here which uses the mvneta > > driver. I'm seeing some weird effects with NFS with it acting as a > > client. >

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

eed to add any new socket options nor anything. Please let me know what you think about it (patch attached), if it's accepted it's trivial to adapt haproxy to this new behaviour. Thanks! Willy >From 7b79e362479fa7084798e6aa41da2a2045f0d6bb Mon Sep 17 00:00:00 2001 From: Willy Tarreau <w...@

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

On Tue, Dec 15, 2015 at 10:21:52AM -0800, Eric Dumazet wrote: > On Tue, 2015-12-15 at 18:43 +0100, Willy Tarreau wrote: > > > Ah ? but what does it bring in this case ? I'm not seeing it used > > anywhere on a listening socket. The code took care of not breaking > > th

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

On Tue, Dec 15, 2015 at 09:10:24AM -0800, Eric Dumazet wrote: > On Tue, 2015-12-15 at 17:14 +0100, Willy Tarreau wrote: > > Hi Eric, > > > > On Wed, Nov 11, 2015 at 05:09:01PM -0800, Eric Dumazet wrote: > > > On Wed, 2015-11-11 at 10:43 -0800, Eric Dumazet wrote: &g

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

Hi Eric, On Wed, Dec 16, 2015 at 08:38:14AM +0100, Willy Tarreau wrote: > On Tue, Dec 15, 2015 at 01:21:15PM -0800, Eric Dumazet wrote: > > On Tue, 2015-12-15 at 20:44 +0100, Willy Tarreau wrote: > > > > > Thus do you think it's worth adding a new option as Tolga pr

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

On Tue, Dec 15, 2015 at 01:21:15PM -0800, Eric Dumazet wrote: > On Tue, 2015-12-15 at 20:44 +0100, Willy Tarreau wrote: > > > Thus do you think it's worth adding a new option as Tolga proposed ? > > > I thought we tried hard to avoid adding the option but determined

Re: [PATCH] unix: properly account for FDs passed over unix sockets

On Thu, Dec 31, 2015 at 03:08:53PM +0900, Tetsuo Handa wrote: > Willy Tarreau wrote: > > On Wed, Dec 30, 2015 at 09:58:42AM +0100, Hannes Frederic Sowa wrote: > > > The MSG_PEEK code should not be harmful and the patch is good as is. I > > > first understood from t

Re: [PATCH] unix: properly account for FDs passed over unix sockets

On Tue, Dec 29, 2015 at 03:48:45PM +0100, Hannes Frederic Sowa wrote: > On 28.12.2015 15:14, Willy Tarreau wrote: > >It is possible for a process to allocate and accumulate far more FDs than > >the process' limit by sending them over a unix socket then closing them > >to keep

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

On Mon, Dec 21, 2015 at 12:38:27PM -0800, Tom Herbert wrote: > On Fri, Dec 18, 2015 at 11:00 PM, Willy Tarreau <w...@1wt.eu> wrote: > > On Fri, Dec 18, 2015 at 06:38:03PM -0800, Eric Dumazet wrote: > >> On Fri, 2015-12-18 at 19:58 +0100, Willy Tarreau wrote: > >>

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

Hi Josh, On Fri, Dec 18, 2015 at 08:33:45AM -0800, Josh Snyder wrote: > I was also puzzled that binding succeeded. Looking into the code paths > involved, in inet_csk_get_port, we quickly goto have_snum. From there, we end > up dropping into tb_found. Since !hlist_empty(>owners), we end up

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

On Fri, Dec 18, 2015 at 06:38:03PM -0800, Eric Dumazet wrote: > On Fri, 2015-12-18 at 19:58 +0100, Willy Tarreau wrote: > > Hi Josh, > > > > On Fri, Dec 18, 2015 at 08:33:45AM -0800, Josh Snyder wrote: > > > I was also puzzled that binding succeeded. Looking into

[PATCH] unix: properly account for FDs passed over unix sockets

-privileged processes from having more FDs in flight than their configured FD limit. Reported-by: socketp...@gmail.com Suggested-by: Linus Torvalds <torva...@linux-foundation.org> Signed-off-by: Willy Tarreau <w...@1wt.eu> --- It would be nice if (if accepted) it would be backporte

Re: [PATCH] unix: properly account for FDs passed over unix sockets

On Wed, Dec 30, 2015 at 09:58:42AM +0100, Hannes Frederic Sowa wrote: > The MSG_PEEK code should not be harmful and the patch is good as is. I > first understood from the published private thread, that it is possible > for a program to exceed the rlimit of fds. But the DoS is only by > keeping

[PATCH 3.10 128/143] VSOCK: do not disconnect socket when peer has shutdown SEND only

vmware.com> Cc: Jorgen Hansen <jhan...@vmware.com> Cc: Adit Ranadive <ad...@vmware.com> Cc: netdev@vger.kernel.org Signed-off-by: David S. Miller <da...@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> Signed-off-by: Willy Tarreau <w...@1wt.

Re: [PATCH v2] unix: properly account for FDs passed over unix sockets

On Tue, Feb 02, 2016 at 09:32:56PM +0100, Hannes Frederic Sowa wrote: > But "struct pid *" in unix_skb_parms should be enough to get us to > corresponding "struct cred *" so we can decrement the correct counter > during skb destruction. > > So: > > We increment current task's unix_inflight and

Re: [PATCH v2] unix: properly account for FDs passed over unix sockets

On Tue, Feb 02, 2016 at 12:53:20PM -0800, Linus Torvalds wrote: > On Tue, Feb 2, 2016 at 12:49 PM, Willy Tarreau <w...@1wt.eu> wrote: > > On Tue, Feb 02, 2016 at 12:44:54PM -0800, Linus Torvalds wrote: > >> > >> Umm. I think the "struct cred" may ch

Re: [PATCH v2] unix: properly account for FDs passed over unix sockets

On Tue, Feb 02, 2016 at 12:44:54PM -0800, Linus Torvalds wrote: > On Tue, Feb 2, 2016 at 12:32 PM, Hannes Frederic Sowa > wrote: > > But "struct pid *" in unix_skb_parms should be enough to get us to > > corresponding "struct cred *" so we can decrement the correct

Re: struct pid memory leak

Hi Eric, Dmitry, On Fri, Jan 22, 2016 at 08:50:01AM -0800, Eric Dumazet wrote: > CC netdev, as it looks some af_unix issue ... > > On Fri, 2016-01-22 at 16:08 +0100, Dmitry Vyukov wrote: > > Hello, > > > > The following program causes struct pid memory leak: > > > > // autogenerated by

Re: struct pid memory leak

On Sat, Jan 23, 2016 at 07:14:33PM +0100, Dmitry Vyukov wrote: > I've attached my .config. > Also run this program in a parallel loop. I think it's leaking not > every time, probably some race is involved. Thank you. Just in order to confirm, am I supposed to see the messages you quoted in dmesg

Re: struct pid memory leak

On Sat, Jan 23, 2016 at 07:46:45PM +0100, Dmitry Vyukov wrote: > On Sat, Jan 23, 2016 at 7:40 PM, Willy Tarreau <w...@1wt.eu> wrote: > > On Sat, Jan 23, 2016 at 07:14:33PM +0100, Dmitry Vyukov wrote: > >> I've attached my .config. > >> Also run this program in a pa

Re: struct pid memory leak

On Sat, Jan 23, 2016 at 06:50:11PM -0800, Eric Dumazet wrote: > On Sat, Jan 23, 2016 at 6:38 PM, Willy Tarreau <w...@1wt.eu> wrote: > > On Sun, Jan 24, 2016 at 03:11:45AM +0100, Willy Tarreau wrote: > >> It doesn't report this on 3.10. > > > > To be more precise

Re: struct pid memory leak

On Sun, Jan 24, 2016 at 03:11:45AM +0100, Willy Tarreau wrote: > It doesn't report this on 3.10. To be more precise, kmemleak reports the issue on 3.13 and not on 3.12. I'm not sure if it's reliable enough to run a bisect though. Willy

Re: Mis-backport in af_unix patch for Linux 3.10.95

ly due to the patch being mis-applied. In unix_stream_recvmsg(), it's still used as well. Does the attached patch seem better to you (not compile-tested) ? Greg/Ben, both 3.2.76 and 3.14.59 are OK regarding this, it seems like only 3.10.95 was affected. Thanks, Willy >From 77f6e82adf349cbccf7e2

Re: [PATCH net] af_unix: fix struct pid memory leak

Hi Eric, On Sun, Jan 24, 2016 at 01:53:50PM -0800, Eric Dumazet wrote: > From: Eric Dumazet > > Dmitry reported a struct pid leak detected by a syzkaller program. > > Bug happens in unix_stream_recvmsg() when we break the loop when a > signal is pending, without properly

Re: [PATCH v2 net-next 0/8] API set for HW Buffer management

ere, we don't really care about a possible 1% performance drop. I'll try to provide more results as time permits. In the mean time if you want (or plan to submit a next batch), feel free to add a Tested-by: Willy Tarreau <w...@1wt.eu>. cheers, Willy

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

Hi Eric, On Thu, Mar 24, 2016 at 07:13:33AM -0700, Eric Dumazet wrote: > On Thu, 2016-03-24 at 07:12 +0100, Willy Tarreau wrote: > > Hi, > > > > On Wed, Mar 23, 2016 at 10:10:06PM -0700, Tolga Ceylan wrote: > > > I apologize for not properly following up on th

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

On Thu, Mar 24, 2016 at 04:54:03PM -0700, Tom Herbert wrote: > On Thu, Mar 24, 2016 at 4:40 PM, Yann Ylavic wrote: > > I'll learn how to do this to get the best performances from the > > server, but having to do so to work around what looks like a defect > > (for

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

Hi Eric, On Thu, Mar 24, 2016 at 11:49:41PM -0700, Eric Dumazet wrote: > Everything is possible, but do not complain because BPF went in the > kernel before your changes. Don't get me wrong, I'm not complaining, I'm more asking for help to try to elaborate the alternate solution. I understood

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

Hi Eric, (just lost my e-mail, trying not to forget some points) On Thu, Mar 24, 2016 at 07:45:44AM -0700, Eric Dumazet wrote: > On Thu, 2016-03-24 at 15:22 +0100, Willy Tarreau wrote: > > Hi Eric, > > > But that means that any software making use of SO_REUSEPORT needs to >

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

On Thu, Mar 24, 2016 at 09:33:11AM -0700, Eric Dumazet wrote: > > --- a/net/ipv4/inet_hashtables.c > > +++ b/net/ipv4/inet_hashtables.c > > @@ -189,6 +189,8 @@ static inline int compute_score(struct sock *sk, struct > > net *net, > > return -1; > >

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

On Thu, Mar 24, 2016 at 10:01:37AM -0700, Eric Dumazet wrote: > On Thu, 2016-03-24 at 17:50 +0100, Willy Tarreau wrote: > > On Thu, Mar 24, 2016 at 09:33:11AM -0700, Eric Dumazet wrote: > > > > --- a/net/ipv4/inet_hashtables.c > > > > +++ b/net/ipv4/inet_hash

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

On Thu, Mar 24, 2016 at 07:00:11PM +0100, Willy Tarreau wrote: > Since it's not about > load distribution and that processes are totally independant, I don't see > well how to (ab)use BPF to achieve this. > > The pattern is : > > t0 : unprivileged processes 1 and 2 are

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

On Thu, Mar 24, 2016 at 11:20:49AM -0700, Tolga Ceylan wrote: > I would appreciate a conceptual description on how this would work > especially for a common scenario > as described by Willy. My initial impression was that a coordinator > (master) process takes this > responsibility to adjust BPF

Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode

Hi, On Wed, Mar 23, 2016 at 10:10:06PM -0700, Tolga Ceylan wrote: > I apologize for not properly following up on this. I had the > impression that we did not want to merge my original patch and then I > also noticed that it fails to keep the hash consistent. Recently, I > read the follow ups on

Re: [PATCH 3.2 085/115] veth: don???t modify ip_summed; doing so treats packets with bad checksums as good.

On Sat, Apr 30, 2016 at 03:43:51PM -0700, Ben Greear wrote: > On 04/30/2016 03:01 PM, Vijay Pandurangan wrote: > > Consider: > > > > - App A sends out corrupt packets 50% of the time and discards inbound > > data. (...) > How can you make a generic app C know how to do this? The path could be,

Re: [PATCH] nf_conntrack: avoid kernel pointer value leak in slab name

On Sat, May 14, 2016 at 02:31:04PM -0700, Linus Torvalds wrote: > On Sat, May 14, 2016 at 11:24 AM, Linus Torvalds > wrote: > > > > > > - net->ct.slabname = kasprintf(GFP_KERNEL, "nf_conntrack_%p", net); > > + net->ct.slabname = kasprintf(GFP_KERNEL,

Re: [PATCH] nf_conntrack: avoid kernel pointer value leak in slab name

On Sat, May 14, 2016 at 03:21:31PM -0700, Linus Torvalds wrote: > On Sat, May 14, 2016 at 2:33 PM, Willy Tarreau <w...@1wt.eu> wrote: > > > > Why simply not cast the atomic to (unsigned long long) instead of (u64) > > so that %llu always matches ? > > Yes, that

Re: [PATCH net] net: mvneta: set real interrupt per packet for tx_done

some users for testing. I also remember that on more recent kernels by then (>=3.13) we observed a slightly better performance with this value set to zero. Acked-by: Willy Tarreau <w...@1wt.eu> Willy

[PATCH 3.10 257/319] net: sctp, forbid negative length

ft.net> Cc: linux-s...@vger.kernel.org Cc: netdev@vger.kernel.org Acked-by: Neil Horman <nhor...@tuxdriver.com> Signed-off-by: David S. Miller <da...@davemloft.net> Signed-off-by: Willy Tarreau <w...@1wt.eu> --- net/sctp/socket.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) dif

Re: [PATCH net-next 3/3] net/tcp-fastopen: Add new API support

On Mon, Jan 23, 2017 at 11:01:21PM +0100, Willy Tarreau wrote: > On Mon, Jan 23, 2017 at 10:37:32PM +0100, Willy Tarreau wrote: > > On Mon, Jan 23, 2017 at 01:28:53PM -0800, Wei Wang wrote: > > > Hi Willy, > > > > > > True. If you call connect() multiple

Re: [PATCH net-next 3/3] net/tcp-fastopen: Add new API support

On Mon, Jan 23, 2017 at 01:28:53PM -0800, Wei Wang wrote: > Hi Willy, > > True. If you call connect() multiple times on a socket which already has > cookie without a write(), the second and onward connect() call will return > EINPROGRESS. > It is basically because the following code block in

Re: [PATCH net-next 3/3] net/tcp-fastopen: Add new API support

On Mon, Jan 23, 2017 at 10:37:32PM +0100, Willy Tarreau wrote: > On Mon, Jan 23, 2017 at 01:28:53PM -0800, Wei Wang wrote: > > Hi Willy, > > > > True. If you call connect() multiple times on a socket which already has > > cookie without a write(), the second and onward

Re: [PATCH net-next 3/3] net/tcp-fastopen: Add new API support

Hi Wei, first, thanks a lot for doing this, it's really awesome! I'm testing it on 4.9 on haproxy and I met a corner case : when I perform a connect() to a server and I have nothing to send, upon POLLOUT notification since I have nothing to send I simply probe the connection using connect()

Re: [PATCH net-next 3/3] net/tcp-fastopen: Add new API support

On Mon, Jan 23, 2017 at 02:57:31PM -0800, Wei Wang wrote: > Yes. That seems to be a valid fix to it. > Let me try it with my existing test cases as well to see if it works for > all scenarios I have. Perfect. Note that since the state 2 is transient I initially thought about abusing the flags

Re: [PATCH net-next 3/3] net/tcp-fastopen: Add new API support

On Mon, Jan 23, 2017 at 10:59:22AM -0800, Wei Wang wrote: > This patch adds a new socket option, TCP_FASTOPEN_CONNECT, as an > alternative way to perform Fast Open on the active side (client). Wei, I think that nothing prevents from reusin the original TCP_FASTOPEN sockopt instead of adding a new

  1   2   >