On Sat, Apr 17, 2021 at 10:26:30PM -0400, Matt Corallo wrote:
> Sure, there are better ways to handle the reassembly cache overflowing, but
> that is pretty unrelated to the fact that waiting 30 full seconds for a
> fragment to come in doesn't really make sense in today's networks (the 30
> second
On Sat, Apr 17, 2021 at 12:42:39AM -0700, Keyu Man wrote:
> How about at least allow the existing queue to finish? Currently a tiny new
> fragment would potentially invalid all previous fragments by letting them
> timeout without allowing the fragments to come in to finish the assembly.
Because th
On Sat, Apr 17, 2021 at 06:44:40AM +0200, Eric Dumazet wrote:
> On Sat, Apr 17, 2021 at 2:31 AM David Ahern wrote:
> >
> > [ cc author of 648700f76b03b7e8149d13cc2bdb3355035258a9 ]
>
> I think this has been discussed already. There is no strategy that
> makes IP reassembly units immune to DDOS at
Hi Daniel,
On Tue, Apr 06, 2021 at 07:04:58PM +0900, Daniel Palmer wrote:
> Hi Willy,
>
> I've been messing with the SSD202D (sibling of the MSC313E) recently
> and the ethernet performance was awful.
> I remembered this revert and reverted it and it makes the ethernet
> work pretty well.
OK, th
On Fri, Mar 19, 2021 at 12:04:47PM +0800, Sieng Piaw Liew wrote:
> Remove this trivial bit of inefficiency from the rx receive loop,
> results in increase of a few Mbps in iperf3. Tested on Intel Core2
> platform.
>
> Signed-off-by: Sieng Piaw Liew
> ---
> drivers/net/ethernet/atheros/atl1c/atl1
Hi,
On Wed, Mar 10, 2021 at 07:16:34PM +0100, Henneberg - Systemdesign wrote:
> Hi,
>
> I have a question regarding the implementation of ioctl TIOCOUTQ for
> various sockets compared to the tty implementation.
>
> For several sockets, e. g. AF_BLUETOOTH it is done like this
>
> af_bluetooth.c:
Hi,
On Tue, Mar 09, 2021 at 08:55:10AM +, claudiu.bez...@microchip.com wrote:
> Hi Andreas,
>
> On 08.03.2021 21:30, Andreas Schwab wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > One of the changes to the macb driver between
C313E.
Cc: Nicolas Ferre
Cc: Claudiu Beznea
Cc: Daniel Palmer
Cc: Alexandre Belloni
Link: https://lore.kernel.org/netdev/20201206092041.ga10...@1wt.eu/
Signed-off-by: Willy Tarreau
---
drivers/net/ethernet/cadence/macb.h | 2 --
drivers/net/ethernet/cadence/macb_main.c
On Mon, Dec 07, 2020 at 03:40:42PM -0800, Jakub Kicinski wrote:
> Thanks for the report, I remember that one. In hindsight maybe we
> should have punted it to 5.11...
Well, not necessarily as it was simple, well documented and *appeared*
to work fine.
> Let's revert ASAP, 5.10 is going to be LTS,
Hi Jakub,
Two months ago I implemented a small change in the macb driver to
support the two Tx descriptors that AT91RM9200 supports. I implemented
this using the only compatible device I had which is the MSC313E-based
Breadbee board. Since then I've met situations where the chip would stop
sending
Hi Alexandre!
On Fri, Nov 13, 2020 at 11:03:59AM +0100, Alexandre Belloni wrote:
> I think I'm the only one booting recent linux kernels on at91rm9200 and
> I'm currently stuck home while the board is at the office. I'll try to
> test as soon as possible, which may not be before 2021... At least I
Hi Claudiu,
first, thanks for your feedback!
On Wed, Oct 14, 2020 at 04:08:00PM +, claudiu.bez...@microchip.com wrote:
> > @@ -3994,11 +3996,10 @@ static netdev_tx_t at91ether_start_xmit(struct
> > sk_buff *skb,
> > struct net_device *dev)
> > {
> >
On Tue, Oct 13, 2020 at 05:03:58PM -0700, Jakub Kicinski wrote:
> On Sun, 11 Oct 2020 11:09:41 +0200 Willy Tarreau wrote:
> > while running some tests on my Breadbee board, I noticed poor network
> > Tx performance. I had a look at the driver (macb, at91ether variant)
>
just
to prepare the code for the third one. The third one implements the
queue. Packets are added at the tail of the queue, the queue is
stopped at 2 packets and the interrupt releases 0, 1 or 2 depending
on what the transmit status register reports.
Thanks,
Willy
Willy Tarreau (3):
macb: add RM9
Cc: Daniel Palmer
Signed-off-by: Willy Tarreau
---
drivers/net/ethernet/cadence/macb.h | 6 ++---
drivers/net/ethernet/cadence/macb_main.c | 28 ++--
2 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.h
b/drivers/net/ethern
Transmit Buffer Register Empty replaces TXERR on RM9200 and signals the
sender may try to send again becase the last queued frame is no longer
in queue (being transmitted or already transmitted).
Cc: Nicolas Ferre
Cc: Claudiu Beznea
Cc: Daniel Palmer
Signed-off-by: Willy Tarreau
---
drivers
76 Mbps with this patch. And tests
on a single TCP stream with an MTU of 576 jump from 10kpps to 15kpps. With
1500 byte packets it's now possible to reach line rate versus 75 Mbps
before.
Cc: Nicolas Ferre
Cc: Claudiu Beznea
Cc: Daniel Palmer
Signed-off-by: Willy Tarreau
---
driver
("random32: remove net_rand_state from the latent
> > entropy gcc plugin")
> > Cc: Linus Torvalds
> > Cc: Willy Tarreau
> > Cc: Emese Revfy
> > Signed-off-by: Thibaut Sautereau
>
> Yes, that looks correct. Thank you!
>
> Acked-by: Kees Cook
&
On Fri, Oct 02, 2020 at 05:16:11PM +0200, Thibaut Sautereau wrote:
> From: Thibaut Sautereau
>
> Commit f227e3ec3b5c ("random32: update the net random state on interrupt
> and activity") broke compilation and was temporarily fixed by Linus in
> 83bdc7275e62 ("random32: remove net_rand_state from
On Fri, Oct 02, 2020 at 11:26:00AM +0200, Eric Dumazet wrote:
> 2) Idle cpus can be put in a power conserving state.
> It takes time to exit from these states, as you noticed.
> These delays can typically be around 50 usec, or more.
This is often the case in my experience. I'm even used to sta
On Mon, Sep 14, 2020 at 06:16:40PM +0200, Sedat Dilek wrote:
> On Mon, Sep 14, 2020 at 4:53 PM Amit Klein wrote:
> >
> > Hi
> >
> > Is this patch being pushed to any branch? I don't see it deployed anywhere
> > (unless I'm missing something...).
> >
>
> It's here:
>
> [1]
> https://git.kernel.
On Tue, Sep 01, 2020 at 04:41:13PM +0200, Sedat Dilek wrote:
> I have tested with the patchset from [1].
> ( Later I saw, you dropped "WIP: tcp: reuse incoming skb hash in
> tcp_conn_request()". )
Yes because it's a bit out of the cope of this series and makes sense
even without these patches, thu
On Tue, Sep 01, 2020 at 01:10:18PM +, David Laight wrote:
> From: Willy Tarreau
> > Sent: 01 September 2020 07:43
> ...
> > +/*
> > + * Generate some initially weak seeding values to allow
> > + * the prandom_u32() engine to be started.
> > + */
> >
Hi Eric,
On Tue, Sep 01, 2020 at 12:24:38PM +0200, Eric Dumazet wrote:
> There is not much entropy here really :
>
> 1) dev & txq are mostly constant on a typical host (at least the kind of
> hosts that is targeted by
> Amit Klein and others in their attacks.
>
> 2) len is also known by the at
On Tue, Sep 01, 2020 at 10:46:16AM +0200, Sedat Dilek wrote:
> Will you push the updated patchset to your prandom Git - for easy fetching?
Yeah if you want, feel free to use this one :
https://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/prandom.git/log/?h=20200901-siphash-noise
Willy
On Tue, Sep 01, 2020 at 10:33:40AM +0200, Yann Ylavic wrote:
> On Tue, Sep 1, 2020 at 8:45 AM Willy Tarreau wrote:
> >
> > +/*
> > + * Generate some initially weak seeding values to allow
> > + * the prandom_u32() engine to be started.
> > + */
> >
fix.
Whether to reinstate a weaker PRNG for uses which can tolerate it
is an open question.
Commit f227e3ec3b5c ("random32: update the net random state on interrupt
and activity") was an earlier attempt at a solution. This patch replaces
it.
Reported-by: Amit Klein
Cc: Willy Tarreau
1):
random32: make prandom_u32() output unpredictable
Willy Tarreau (1):
random32: add noise from network and scheduling activity
drivers/char/random.c | 1 -
include/linux/prandom.h | 55 -
kernel/time/timer.c | 9 +-
lib/random32.c
Cc: Linus Torvalds
Cc: ty...@mit.edu
Cc: Florian Westphal
Cc: Marc Plumb
Tested-by: Sedat Dilek
Signed-off-by: Willy Tarreau
---
include/linux/prandom.h | 19 +++
kernel/time/timer.c | 2 ++
lib/random32.c | 5 +
net/core/dev.c | 4
4 files changed
Hi Amit,
On Thu, Aug 27, 2020 at 02:06:39AM +0300, Amit Klein wrote:
> Hi
>
> Is there an ETA for this patch then?
No particular ETA on my side, I was waiting for potential criticisms
before going further. I suspect that if nobody complains anymore, it's
an implicit voucher and I'll have to clea
On Thu, Aug 20, 2020 at 08:58:38AM +0200, Willy Tarreau wrote:
> I've just pushed a new branch "20200820-siphash-noise" that I also
> rebased onto latest master. It's currently running make allmodconfig
> here, so that will take a while, but I think it's OK as ran
On Thu, Aug 20, 2020 at 08:08:43AM +0200, Willy Tarreau wrote:
> On Thu, Aug 20, 2020 at 06:42:23AM +0200, Sedat Dilek wrote:
> > On Thu, Aug 20, 2020 at 6:33 AM Willy Tarreau wrote:
> > >
> > > On Thu, Aug 20, 2020 at 05:05:49AM +0200, Sedat Dilek wrote:
> > &g
On Thu, Aug 20, 2020 at 06:42:23AM +0200, Sedat Dilek wrote:
> On Thu, Aug 20, 2020 at 6:33 AM Willy Tarreau wrote:
> >
> > On Thu, Aug 20, 2020 at 05:05:49AM +0200, Sedat Dilek wrote:
> > > We have the same defines for K0 and K1 in include/linux/prandom.h and
> >
On Thu, Aug 20, 2020 at 05:05:49AM +0200, Sedat Dilek wrote:
> We have the same defines for K0 and K1 in include/linux/prandom.h and
> lib/random32.c?
> More room for simplifications?
Definitely, I'm not surprized at all. As I said, the purpose was to
discuss around the proposal, not much more. If
Hi,
so as I mentioned, I could run several test on our lab with variations
around the various proposals and come to quite positive conclusions.
Synthetic observations: the connection rate and the SYN cookie rate do not
seem to be affected the same way by the prandom changes. One explanation
is th
On Fri, Aug 14, 2020 at 05:32:32PM +0200, Sedat Dilek wrote:
> commit 94c7eb54c4b8e81618ec79f414fe1ca5767f9720
> "random32: add a tracepoint for prandom_u32()"
>
> ...I gave Willy's patches a try and used the Linux Test Project (LTP)
> for testing.
Just FWIW today I could run several relevant tes
On Thu, Aug 13, 2020 at 09:53:11AM +0200, Sedat Dilek wrote:
> On Wed, Aug 12, 2020 at 5:21 AM Willy Tarreau wrote:
> >
> > On Tue, Aug 11, 2020 at 12:51:43PM +0200, Sedat Dilek wrote:
> > > Can you share this "rebased to mainline" version of George's patch
On Tue, Aug 11, 2020 at 12:51:43PM +0200, Sedat Dilek wrote:
> Can you share this "rebased to mainline" version of George's patch?
You can pick it from there if that helps, but keep in mind that
it's just experimental code that we use to explain our ideas and
that we really don't care a single sec
On Tue, Aug 11, 2020 at 05:26:49AM +, George Spelvin wrote:
> On Mon, Aug 10, 2020 at 11:04:55PM +0200, Willy Tarreau wrote:
> > What could be improved is the way the input values are mixed (just
> > added hence commutative for now). I didn't want to call a siphash
> &
On Tue, Aug 11, 2020 at 03:47:24AM +, George Spelvin wrote:
> On Mon, Aug 10, 2020 at 01:47:00PM +0200, Willy Tarreau wrote:
> > except that I retrieve it only on 1/8 calls
> > and use the previous noise in this case.
>
> Er... that's quite different. I was saying
Linus, George, Florian,
would something in this vein be OK in your opinion ?
- update_process_times still updates the noise
- we don't touch the fast_pool anymore
- we don't read any TSC on hot paths
- we update the noise in xmit from jiffies and a few pointer values instead
I've applied it on t
On Mon, Aug 10, 2020 at 10:45:26AM -0700, Linus Torvalds wrote:
> On Mon, Aug 10, 2020 at 9:59 AM Willy Tarreau wrote:
> >
> > I took what we were already using in add_interrupt_randomness() since
> > I considered that if it was acceptable there, it probably was elsewhere.
&
On Mon, Aug 10, 2020 at 09:31:48AM -0700, Linus Torvalds wrote:
> On Mon, Aug 10, 2020 at 4:47 AM Willy Tarreau wrote:
> >
> > Doing testing on real hardware showed that retrieving the TSC on every
> > call had a non negligible cost, causing a loss of 2.5% on the accept
On Mon, Aug 10, 2020 at 02:03:02PM +0200, Florian Westphal wrote:
> As this relates to networking, you could also hook perturbation into rx/tx
> softirq processing. E.g. once for each new napi poll round or only once
> for each softnet invocation, depending on cost.
I was wondering what/where to
On Mon, Aug 10, 2020 at 12:01:11PM +, David Laight wrote:
> > /*
> > * On 32-bit machines, we use HSipHash, a reduced-width version of SipHash.
> > * This is weaker, but 32-bit machines are not used for high-traffic
> > @@ -375,6 +377,12 @@ static u32 siprand_u32(struct siprand_state *s)
>
Hi George,
On Sun, Aug 09, 2020 at 06:30:17PM +, George Spelvin wrote:
> Even something simple like buffering 8 TSC samples, and adding them
> at 32-bit offsets across the state every 8th call, would make a huge
> difference.
Doing testing on real hardware showed that retrieving the TSC on ev
On Sun, Aug 09, 2020 at 06:30:17PM +, George Spelvin wrote:
> I'm trying to understand your attack scenario. I'm assuming that an
> attacker can call prandom_u32() locally.
Well, first, I'm mostly focusing on remote attacks, because if the
attacker has a permanent local access, he can as well
On Sun, Aug 09, 2020 at 05:06:39PM +, George Spelvin wrote:
> On Sun, Aug 09, 2020 at 11:38:05AM +0200, Willy Tarreau wrote:
> > So I gave it a quick test under Qemu and it didn't show any obvious
> > performance difference compared to Tausworthe, which is a good thing,
>
Hi George,
On Sun, Aug 09, 2020 at 06:57:44AM +, George Spelvin wrote:
> +/*
> + * This is the core CPRNG function. As "pseudorandom", this is not used
> + * for truly valuable things, just intended to be a PITA to guess.
> + * For maximum speed, we do just two SipHash rounds per word. This
Hi Florian,
On Sat, Aug 08, 2020 at 09:18:27PM +0200, Florian Westphal wrote:
> > struct rnd_state {
> > - __u32 s1, s2, s3, s4;
> > + siphash_key_t key;
> > + uint64_t counter;
> > };
>
> Does the siphash_key really need to be percpu?
I don't think so, I was really exploring a quick and
On Sat, Aug 08, 2020 at 11:19:01AM -0700, Linus Torvalds wrote:
> On Sat, Aug 8, 2020 at 10:45 AM Willy Tarreau wrote:
> >
> >
> > WIP: random32: use siphash with a counter for prandom_u32
>
> siphash is good.
>
> But no:
>
> > --- a/drivers/cha
On Sat, Aug 08, 2020 at 10:07:51AM -0700, Andy Lutomirski wrote:
>
> > On Aug 8, 2020, at 8:29 AM, George Spelvin wrote:
> >
>
> > And apparently switching to the fastest secure PRNG currently
> > in the kernel (get_random_u32() using ChaCha + per-CPU buffers)
> > would cause too much performan
he appended patch. Note that for now I've commented out all the reseeding
code because I just wanted to test the impact.
In my perf measurements I've had some erratic behaviors, one test showing
almost no loss, and another one showing a lot, which didn't make sense, so
I&#x
On Fri, Aug 07, 2020 at 03:45:48PM -0700, Marc Plumb wrote:
> Willy,
>
>
> On 2020-08-07 3:19 p.m., Willy Tarreau wrote:
> > On Fri, Aug 07, 2020 at 12:59:48PM -0700, Marc Plumb wrote:
> > >
> > > If I can figure the state out once,
> > Yes but ho
On Fri, Aug 07, 2020 at 12:59:48PM -0700, Marc Plumb wrote:
>
> On 2020-08-07 10:43 a.m., Willy Tarreau wrote:
> >
> > > Which means that it's 2^32 effort to brute force this (which Amit called
> > > "no
> > > biggie for modern machines")
Hi Andy,
On Fri, Aug 07, 2020 at 10:55:11AM -0700, Andy Lutomirski wrote:
> >> This is still another non-cryptographic PRNG.
> >
> > Absolutely. During some discussions regarding the possibility of using
> > CSPRNGs, orders around hundreds of CPU cycles were mentioned for them,
> > which can defi
On Fri, Aug 07, 2020 at 09:52:14AM -0700, Marc Plumb wrote:
> On 2020-08-07 12:03 a.m., Willy Tarreau wrote:
>
> > Just to give a heads up on this, here's what I'm having pending regarding
> > MSWS:
> >
> >struct rnd_state {
> >
On Thu, Aug 06, 2020 at 10:18:55AM -0700, Marc Plumb wrote:
> Willy,
>
>
> On 2020-08-05 11:30 p.m., Willy Tarreau wrote:
> > On Wed, Aug 05, 2020 at 03:21:11PM -0700, Marc Plumb wrote:
> > > There is nothing wrong with perturbing net_rand_state, the sin is doing it
On Wed, Aug 05, 2020 at 03:21:11PM -0700, Marc Plumb wrote:
> There is nothing wrong with perturbing net_rand_state, the sin is doing it
> with the raw entropy that is also the seed for your CPRNG. Use the output of
> a CPRNG to perturb the pool all you want, but don't do things that bit by
> bit r
Hi Mark,
On Wed, Aug 05, 2020 at 09:06:40AM -0700, Marc Plumb wrote:
> Just because you or I don't have a working exploit doesn't mean that someone
> else isn't more clever.
I agree on the principle, but it can be said from many things, including
our respective inability to factor large numbers f
Hi Ted,
On Wed, Aug 05, 2020 at 11:34:32AM -0400, ty...@mit.edu wrote:
> That being said, it certainly is a certificational / theoretical
> weakness, and if the bright boys and girls at Fort Meade did figure
> out a way to exploit this, they are very much unlikely to share it at
> an open Crypto c
Hi Marc,
On Tue, Aug 04, 2020 at 05:52:36PM -0700, Marc Plumb wrote:
> Seeding two PRNGs with the same entropy causes two problems. The minor one
> is that you're double counting entropy. The major one is that anyone who can
> determine the state of one PRNG can determine the state of the other.
>
Hi Jeroen,
On Thu, Jul 16, 2020 at 05:38:57PM +0200, Jeroen Baten wrote:
> Hi,
>
> I have been working on a Linux desktop for the last 20 odd years.
> Currently running Ubuntu 20.04.
>
> Yesterday I enabled the option "Flow control" on my TP-Link TL-SG1024DE.
>
> Subsequently I was forced to en
On Fri, Sep 20, 2019 at 11:43:50PM +, Swarm wrote:
> First time emailing to this mailing list so please let me know if I made a
> mistake in how I sent it. I'm trying to receive a notification from the
> kernel once it verifies an ACK packet in a handshake. Problem is, there is no
> API or kern
Hi Roobesh,
On Wed, Jan 23, 2019 at 08:07:48AM +, Mohandass, Roobesh wrote:
> Hi Willy/Florian/Lukas,
>
> disabling nf_conntrack_tcp_loose (solved the problem) and for last 24 hours,
> we are not evening seeing a single wrong connection data by send-proxy.
>
> Worth a note in your document
Hi Lukas,
On Sat, Jan 12, 2019 at 07:01:34PM +0100, Lukas Tribus wrote:
> > Roobesh, do you use the destination address only for logging or
> > anywhere else in the request path ? And could you check if you have
> > nf_conntrack_tcp_loose set as Florian suggests ? I really think he
> > figured it
Hi Florian!
Sorry for the lag, I was busy with other issues.
On Sat, Jan 12, 2019 at 05:04:00PM +0100, Florian Westphal wrote:
> Lukas Tribus wrote:
> > The application (haproxy) needs to know the original destination IP
> > address, however it does not know whether -j REDIRECT was used or not.
On Wed, Jan 09, 2019 at 08:55:14AM -0500, Willem de Bruijn wrote:
> > In other words: because the socket needs to be ESTABLISHED for
> > MSG_ZEROCOPY to work, and because remote party can send FIN and move
> > the socket to CLOSE_WAIT, a sending party must implement a fallback
> > from EINVAL retur
On Thu, Dec 13, 2018 at 02:17:20PM +0100, Marek Majkowski wrote:
> > splice code will be expensive if less than 1MB is present in receive queue.
>
> I'm not sure what you are suggesting. I'm just shuffling data between
> two sockets. Is there a better buffer size value? Is it possible to
> keep sp
Hi Eric!
On Thu, Dec 13, 2018 at 05:37:11AM -0800, Eric Dumazet wrote:
> Maybe mlx5 driver is in LRO mode, packing TCP payload in 4K pages ?
I could be wrong but I don't think so : I remember having been used to
LRO on myri10ge a decade ago giving me good performance which would
degrade with conc
Hi Marek,
On Thu, Dec 13, 2018 at 12:25:20PM +0100, Marek Majkowski wrote:
> Hi!
>
> I'm basically trying to do TCP splicing in Linux. I'm focusing on
> performance of the simplest case: receive data from one TCP socket,
> write data to another TCP socket. I get poor performance with splice.
>
>
On Sat, Dec 08, 2018 at 10:14:47PM +0200, Ilias Apalodimas wrote:
> On Sat, Dec 08, 2018 at 09:11:53PM +0100, Jesper Dangaard Brouer wrote:
> > >
> > > I want to make sure you guys thought about splice() stuff, and
> > > skb_try_coalesce(), and GRO, and skb cloning, and ...
> >
> > Thanks for th
On Fri, Nov 09, 2018 at 06:30:14PM +0100, Johannes C. Schulz wrote:
> Hello Willy, hello Stephen
>
> Thankyou for your reply.
> But I'm not able to maintain or code these modules. I'm just a bloody
> user/webdev.
That's what we've all claimed before taking over something many years
ago you know :
On Fri, Nov 09, 2018 at 02:23:27PM +0100, Johannes C. Schulz wrote:
> Hello all!
>
> I like to please you to bring back IPX and NCPFS modules to the kernel.
> Whyever my admins using Novell-shares on our network which I'm not be
> able to use anymore - I'm forced to use cifs instead (and the admin
On Wed, Aug 29, 2018 at 11:42:44AM +, Nathaniel Munk wrote:
> As you can see from the attached log
You apparently forgot to attach the log.
Willy
On Sat, Aug 18, 2018 at 09:10:25PM +0200, Andrew Lunn wrote:
> On Sat, Aug 18, 2018 at 01:39:50PM -0400, Robert P. J. Day wrote:
> >
> > (i'm sure this has been explained many times before, so a link
> > covering this will almost certainly do just fine.)
> >
> > i want to loop one physical et
On Tue, Jun 05, 2018 at 02:33:03PM +0200, Bjørn Mork wrote:
> > I do have IPv6 at home (a /48, waste of addressing space, I'd be fine
> > with less),
>
> Any reason you would want less? Any reason the ISP should give you
> less?
What I mean is that *if* the availability of /48 networks was an is
On Sun, Jun 03, 2018 at 03:41:08PM -0700, Eric Dumazet wrote:
>
>
> On 06/03/2018 01:37 PM, Tom Herbert wrote:
>
> > This is not an inconsequential mechanism that is being proposed. It's
> > a modification to IP protocol that is intended to work on the
> > Internet, but it looks like the draft h
On Sat, Jun 02, 2018 at 12:17:12PM -0400, Sam Patton wrote:
> As far as application examples, check out this simple netcat-like
> program I use for testing:
>
> https://github.com/EnIP/enhancedip/blob/master/userspace/netcat/netcat.c
>
> Lines 61-67 show how to connect directly via an EnIP addres
Hello Sam,
On Fri, Jun 01, 2018 at 09:48:28PM -0400, Sam Patton wrote:
> Hello!
>
> If you do not know what Enhanced IP is, read this post on netdev first:
>
> https://www.spinics.net/lists/netdev/msg327242.html
>
>
> The Enhanced IP project presents:
>
> Enhanced IP v1.4
>
> Th
Adding Greg here.
Greg, apparently a backport of 46f1c52e66db is needed in 4.9 according
to the thread below. It was merged in 4.13 so 4.14 already has it.
Willy
On Thu, May 17, 2018 at 02:09:03PM -0400, David Miller wrote:
> From: Guillaume Nault
> Date: Thu, 17 May 2018 19:41:47 +0200
>
> >
Hi David,
regarding the patch below, I'm not certain whether you planned to take
it since it's marked "not applicable" on patchwork, but I suspect it's
only because it doesn't apply to mainline.
However, please note that there are two typos in commit IDs referenced in
the commit message that migh
Hi Eric,
On Mon, Jan 29, 2018 at 06:04:30AM -0800, Eric Dumazet wrote:
> > If these 4 bytes matter, why not use
> > cmpq with an immediate value instead, which saves 2 extra bytes ? :
> >
> > - the mov above is 11 bytes total :
> >
> >0: 48 8b 84 d6 78 56 34mov0x12345678(%rsi,%rdx,
Hi,
[ replaced stable@ and greg@ by netdev@ as my question below is not
relevant to stable ]
On Mon, Jan 29, 2018 at 02:48:54AM +0100, Daniel Borkmann wrote:
> From: Eric Dumazet
>
> [ upstream commit 84ccac6e7854ebbfb56d2fc6d5bef9be49bb304c ]
>
> Saves 4 bytes replacing following instructio
Hi Eric,
On Mon, Jan 22, 2018 at 10:16:06AM -0800, Eric Dumazet wrote:
> On Mon, 2018-01-22 at 09:28 -0800, Ben Greear wrote:
> > My test case is to have 6 processes each create 5000 TCP IPv4 connections
> > to each other
> > on a system with 16GB RAM and send slow-speed data. This works fine on
On Sun, Jan 07, 2018 at 12:17:11PM -0800, Linus Torvalds wrote:
> We need to fix the security problem, but we need to do it *without*
> these braindead arguments that performance is somehow secondary.
OK OK. At least we should have security by default and let people trade
it against performance if
On Sun, Jan 07, 2018 at 11:47:07AM -0800, Linus Torvalds wrote:
> And the whole "normal people won't even notice" is pure garbage too.
> Don't spread that bullshit when you see actual normal people
> complaining.
>
> Performance matters. A *LOT*.
Linus, no need to explain that to me, I'm precisel
On Sat, Jan 06, 2018 at 07:38:14PM -0800, Alexei Starovoitov wrote:
> yep. plenty of unknowns and what's happening now is an overreaction.
To be fair there's overreaction on both sides. The vast majority of
users need to get a 100% safe system and will never notice any
difference. A few of us are
On Sat, Jan 06, 2018 at 06:38:59PM +, Alan Cox wrote:
> Normally people who propose security fixes don't have to argue about the
> fact they added 30 clocks to avoid your box being 0wned.
In fact it depends, because if a fix makes the system unusable for its
initial purpose, this fix will simp
Guys,
Chris reported the bug below and confirmed that reverting commit
9704f81 (ipv6: grab rt->rt6i_ref before allocating pcpu rt) seems to
have fixed the issue for him. This patch is a94b9367 in mainline.
I personally have no opinion on the patch, just found it because it
was the only one touchi
Hi Arnd,
On Tue, Dec 19, 2017 at 09:18:35PM +0100, Arnd Bergmann wrote:
> On Tue, Dec 19, 2017 at 5:59 PM, Gregory CLEMENT
> wrote:
> > Hello,
> >
> > here it is a small series of fixes found on the mvneta driver. They
> > had been already used in the vendor kernel and are now ported to
> > mainl
Hi Andrew,
On Fri, Nov 17, 2017 at 03:06:23PM +0100, Andrew Lunn wrote:
> > Usually it's better to apply LRU or random here in my opinion, as the
> > new entry is much more likely to be needed than older ones by definition.
>
> Hi Willy
>
> I think this depends on why you need to discard. If it
Hi Stephen,
On Thu, Nov 16, 2017 at 04:27:18PM -0800, Stephen Hemminger wrote:
> On Thu, 16 Nov 2017 21:21:55 +0100
> Vincent Bernat wrote:
>
> > ? 16 novembre 2017 20:23 +0100, Andrew Lunn :
> >
> > > struct net_bridge_fdb_entry is 40 bytes.
> > >
> > > My WiFi access point which is also a 5
Hi Sarah,
On Thu, Nov 16, 2017 at 01:20:18AM -0800, Sarah Newman wrote:
> I note that anyone who would run up against a too-low limit on the maximum
> number of fdb entries would also be savvy enough to fix it in a matter of
> minutes.
I disagree on this point. There's a huge difference between e
On Tue, Oct 31, 2017 at 09:14:45AM -0700, Kees Cook wrote:
> diff --git a/net/socket.c b/net/socket.c
> index c729625eb5d3..34183f4fbdf8 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -2188,6 +2188,7 @@ static int ___sys_recvmsg(struct socket *sock, struct
> user_msghdr __user *msg,
>
On Mon, Aug 28, 2017 at 11:47:41PM -0400, Harsha Chenji wrote:
> So I have ubuntu 12.04 x32 in a VM with syncookies turned off. I tried
> to do a syn flood (with netwox) on 3 different processes. Each of them
> returns a different value with netstat -na | grep -c RECV :
>
> nc -l returns 16 (
On Sun, Aug 06, 2017 at 07:39:57AM +, maowenan wrote:
>
>
> > -Original Message-
> > From: Willy Tarreau [mailto:w...@1wt.eu]
> > Sent: Saturday, August 05, 2017 2:19 AM
> > To: Neal Cardwell
> > Cc: maowenan; David Miller; netdev@vger.kernel.org;
On Fri, Aug 04, 2017 at 02:01:34PM -0400, Neal Cardwell wrote:
> On Fri, Aug 4, 2017 at 1:10 PM, Willy Tarreau wrote:
> > Hi Neal,
> >
> > On Fri, Aug 04, 2017 at 12:59:51PM -0400, Neal Cardwell wrote:
> >> I have attached patches for this fix rebased on to v3.
Hi Neal,
On Fri, Aug 04, 2017 at 12:59:51PM -0400, Neal Cardwell wrote:
> I have attached patches for this fix rebased on to v3.10.107, the
> latest stable release for 3.10. That's pretty far back in history, so
> there were substantial conflict resolutions and adjustments required.
> :-) Hope tha
On Fri, Jul 28, 2017 at 10:22:52PM -0700, Eric Dumazet wrote:
> On Fri, 2017-07-28 at 12:30 -0700, David Miller wrote:
> > From: Mark Salyzyn
> > Date: Fri, 28 Jul 2017 10:29:57 -0700
> >
> > > Please backport the upstream patch to the stable trees (including
> > > 3.10.y, 3.18.y, 4.4.y and 4.9.y
1 - 100 of 229 matches
Mail list logo
