RE: [PATCH net-next 5/5] net: dsa: split dsa_port's netdev member

From: Vivien Didelot > Sent: 13 October 2017 16:29 > Vivien Didelot writes: > > >>> How about using: > >>> > >>> union { > >>> struct net_device *master; > >>> struct net_device *slave; > >>> } netdev; > >> ... > >> > >> You can remove

RE: Kernel Performance Tuning for High Volume SCTP traffic

From: Traiano Welcome (copied to netdev) > Sent: 13 October 2017 07:16 > To: linux-s...@vger.kernel.org > Subject: Kernel Performance Tuning for High Volume SCTP traffic > > Hi List > > I'm running a linux server processing high volumes of SCTP traffic and > am seeing large numbers of packet

RE: Kernel Performance Tuning for High Volume SCTP traffic

From: Traiano Welcome > Sent: 13 October 2017 17:04 > On Fri, Oct 13, 2017 at 11:56 PM, David Laight <david.lai...@aculab.com> > wrote: > > From: Traiano Welcome > > > > (copied to netdev) > >> Sent: 13 October 2017 07:16 > >> To: linux-s...@vger

RE: [PATCH net-next 5/5] net: dsa: split dsa_port's netdev member

From: Florian Fainelli > Sent: 13 October 2017 00:05 ... > How about using: > > union { > struct net_device *master; > struct net_device *slave; > } netdev; ... You can remove the 'netdev' all the compilers support unnamed unions. David

RE: [PATCH net-next v2 2/4] net: dsa: mv88e6060: setup random mac address

From: Vivien Didelot > Sent: 13 October 2017 02:41 > As for mv88e6xxx, setup the switch from within the mv88e6060 driver with > a random MAC address, and remove the .set_addr implementation. > > Signed-off-by: Vivien Didelot > --- >

RE: [net-next 6/9] e1000e: fix buffer overrun while the I219 is processing DMA transactions

From: Jeff Kirsher > Sent: 10 October 2017 18:22 > Intel 100/200 Series Chipset platforms reduced the round-trip > latency for the LAN Controller DMA accesses, causing in some high > performance cases a buffer overrun while the I219 LAN Connected > Device is processing the DMA transactions. I219LM

RE: [PATCH v2] xdp: Sample xdp program implementing ip forward

From: Jesper Dangaard Brouer > Sent: 10 October 2017 20:06 ... > > + int src_ip = 0, dest_ip = 0; ... > > + key4.b8[4] = dest_ip % 0x100; > > + key4.b8[5] = (dest_ip >> 8) % 0x100; > > + key4.b8[6] = (dest_ip >> 16) % 0x100; > > +

RE: [PATCH 3/4] net: qcom/emac: enforce DMA address restrictions

From: Timur Tabi > Sent: 11 October 2017 20:52 > The EMAC has a restriction that the upper 32 bits of the base addresses > for the RFD and RRD rings must be the same. The ensure that restriction, > we allocate twice the space for the RRD and locate it at an appropriate > address. > > We also

RE: [PATCH net-next v2 02/10] net: dsa: debugfs: add tree

From: Vivien Didelot > Sent: 08 September 2017 15:57 ... > > > Also more important, you will notice what seems to be a bug to me: > > > I can read or write a file even if I didn't mask the corresponding mode > > > hence the double check in dsa_debugfs_show and dsa_debugfs_write. > > > > The mode

RE: [iproute PATCH 1/6] utils: Implement strlcpy() and strlcat()

From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: 04 September 2017 19:25 > On Mon, 4 Sep 2017 17:00:15 +0200 > Phil Sutter <p...@nwl.cc> wrote: > > > On Mon, Sep 04, 2017 at 02:49:20PM +, David Laight wrote: > > > From: Phil Sutter >

RE: [PATCH] tipc: Use bsearch library function

From: David Miller > Sent: 11 September 2017 22:30 > From: Thomas Meyer > Date: Sat, 9 Sep 2017 05:18:19 +0200 > > > @@ -168,6 +169,18 @@ static struct name_seq *tipc_nameseq_create(u32 type, > > struct hlist_head > *seq_hea > > return nseq; > > } > > > > +static int

RE: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN

From: Arnd Bergmann > Sent: 22 September 2017 22:29 ... > It seems that this is triggered in part by using strlcpy(), which the > compiler doesn't recognize as copying at most 'len' bytes, since strlcpy > is not part of the C standard. Neither is strncpy(). It'll almost certainly be a marker in

RE: [PATCH v2 02/16] thunderbolt: Add support for XDomain properties

From: Mika Westerberg > Sent: 27 September 2017 12:33 ... > Just for my education, is there some rule which tells when __packed is > to be used? For example the above structures are all 32-bit aligned but > how about something like: > > struct foo { > u32 value1; > u8 value2; > }; >

RE: [PATCH net v2] net: dsa: mv88e6xxx: lock mutex when freeing IRQs

From: Andrew Lunn > Sent: 27 September 2017 14:07 > To: David Laight > On Wed, Sep 27, 2017 at 09:06:01AM +0000, David Laight wrote: > > From: Vivien Didelot > > > Sent: 26 September 2017 19:57 > > > mv88e6xxx_g2_irq_free locks the registers mutex, but not &

RE: [PATCH] net: stmmac: Meet alignment requirements for DMA

From: Matt Redfearn > Sent: 26 September 2017 14:58 ... > > As long as you use the dma_{map,unamp}_single() and sync to/from > > deivce interfaces properly, the cacheline issues will be handled properly > > and the cpu and the device will see proper uptodate memory contents. > > I interpret the

RE: [PATCH RFC 3/5] Add KSZ8795 switch driver

From: Andrew Lunn > Sent: 28 September 2017 20:34 ... > > There are 34 counters. In normal case using generic bus I/O or PCI to read > > them > > is very quick, but the switch is mostly accessed using SPI, or even I2C. > > As the SPI > > access is very slow. > > How slow is it? The Marvell

RE: [PATCH net-next 03/10] sctp: factor out stream->in allocation

From: Marcelo Ricardo Leitner > Sent: 28 September 2017 21:25 > Same idea as previous patch. That needs a proper description. David

RE: [PATCH 3/7] crypto:gf128mul: The x8_ble multiplication functions

From: Harsh Jain > Sent: 03 October 2017 07:46 > It multiply GF(2^128) elements in the ble format. > It will be used by chelsio driver to fasten gf multiplication. ^ speed up ?? David

RE: [PATCH net] ethernet: xircom: small clean up in setup_xirc2ps_cs()

From: Dan Carpenter > Sent: 21 August 2017 10:48 > The get_options() function takes the whole ARRAY_SIZE(). It doesn't > matter here because we don't use more than 7 elements. > > Signed-off-by: Dan Carpenter > > diff --git a/drivers/net/ethernet/xircom/xirc2ps_cs.c

RE: Something hitting my total number of connections to the server

From: Akshat Kakkar > Sent: 18 August 2017 10:14 > On Thu, Aug 17, 2017 at 5:06 PM, Eric Dumazet wrote: > > On Thu, 2017-08-17 at 14:35 +0530, Akshat Kakkar wrote: > > > >> I upgraded to 4.4 but still experiencing same issue. > >> Please help. > > > > Still too old kernel,

RE: [PATCH net-next 1/3 v6] net: ether: Add support for multiplexing and aggregation type

From: David Miller > Sent: 20 August 2017 23:12 > From: Jamal Hadi Salim > Date: Sun, 20 Aug 2017 14:18:03 -0400 > > > On 17-08-19 01:35 AM, Subash Abhinov Kasiviswanathan wrote: > >> Define the multiplexing and aggregation (MAP) ether type 0xDA1A. This > >> is needed for

RE: [iproute PATCH v3 4/5] tc/tc_filter: Make sure filter name is not empty

From: Phil Sutter > Sent: 21 August 2017 11:03 > To: Stephen Hemminger > Cc: netdev@vger.kernel.org > Subject: [iproute PATCH v3 4/5] tc/tc_filter: Make sure filter name is not > empty > > The later check for 'k[0] != 0' requires a non-empty filter name, > otherwise NULL pointer dereference in

RE: [PATCH net-next v4] openvswitch: enable NSH support

From: Ben Pfaff > Sent: 22 August 2017 18:35 ... > We solved the alignment problem in OVS userspace a different way, by > defining our versions of the network protocol headers so that they only > need 16-bit alignment. In turn, we did that by defining a > ovs_16aligned_be32 type as a pair of

RE: [iproute PATCH v2 1/7] ipntable: Make sure filter.name is NULL-terminated

From: Phil Sutter > Sent: 18 August 2017 11:52 > On Fri, Aug 18, 2017 at 09:19:16AM +, David Laight wrote: > > From: Phil Sutter > > > Sent: 17 August 2017 18:09 > > > To: Stephen Hemminger > > > Cc: netdev@vger.kernel.org > > > Subject: [iprou

RE: [iproute PATCH v2 4/5] tc/tc_filter: Make sure filter name is not empty

From: Phil Sutter > Sent: 18 August 2017 12:16 > On Fri, Aug 18, 2017 at 09:30:35AM +, David Laight wrote: > > From: Phil Sutter > > > Sent: 17 August 2017 18:10 > > > The later check for 'k[0] != 0' requires a non-empty filter name, > > > otherwise NULL

RE: [iproute PATCH 1/6] utils: Implement strlcpy() and strlcat()

From: Phil Sutter > Sent: 01 September 2017 17:53 > By making use of strncpy(), both implementations are really simple so > there is no need to add libbsd as additional dependency. > ... > + > +size_t strlcpy(char *dst, const char *src, size_t size) > +{ > + if (size) { > +

RE: [PATCH v2 0/2] enable hires timer to timeout datagram socket

From: Vallish Vaidyeshwara > Sent: 27 August 2017 21:47 ... > I respect the decision not to upstream this patch series, however I > wanted to provide additional details. Application wanting high > resolution events with real guarantees is not the case, but the case > here is regression in system

RE: [PATCH net-next v2] net: bcmgenet: Use correct I/O accessors

From: Florian Fainelli > Sent: 29 August 2017 20:26 > The GENET driver currently uses __raw_{read,write}l which means > native I/O endian. This works correctly for an ARM LE kernel (default) > but fails miserably on an ARM BE (BE8) kernel where registers are kept > little endian, so replace uses

RE: [RFC PATCH] net: limit maximum number of packets to mark with xmit_more

From: Jakub Kicinski > Sent: 25 August 2017 20:34 > > On Fri, 25 Aug 2017 08:24:49 -0700, Jacob Keller wrote: > > Under some circumstances, such as with many stacked devices, it is > > possible that dev_hard_start_xmit will bundle many packets together, and > > mark them all with xmit_more. > >

RE: [PATCH] rtl8xxxu: mark expected switch fall-throughs

From: Joe Perches > Sent: 11 October 2017 11:21 > On Tue, 2017-10-10 at 14:30 -0500, Gustavo A. R. Silva wrote: > > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > > where we are expecting to fall through. > > perhaps use Arnaldo's idea: > >

RE: [PATCH net-next] liquidio: fix format truncation warning reported by gcc 7.1.1

From: Felix Manlunas > Sent: 26 September 2017 19:48 > gcc 7.1.1 with -Wformat-truncation reports these warnings: > > drivers/net/ethernet/cavium/liquidio/lio_core.c: In function > `octeon_setup_interrupt': > drivers/net/ethernet/cavium/liquidio/lio_core.c:1003:41: warning: `%u' > directive

RE: [PATCH net v2] net: dsa: mv88e6xxx: lock mutex when freeing IRQs

From: Vivien Didelot > Sent: 26 September 2017 19:57 > mv88e6xxx_g2_irq_free locks the registers mutex, but not > mv88e6xxx_g1_irq_free, which results in a stack trace from > assert_reg_lock when unloading the mv88e6xxx module. Fix this. > > Fixes: 3460a5770ce9 ("net: dsa: mv88e6xxx: Mask g1

RE: [net-next 14/15] i40e: ignore skb->xmit_more when deciding to set RS bit

From: Jeff Kirsher > Sent: 06 October 2017 18:57 > From: Jacob Keller > > Since commit 6a7fded776a7 ("i40e: Fix RS bit update in Tx path and > disable force WB workaround") we've tried to "optimize" setting the > RS bit based around skb->xmit_more. This same logic was

RE: [PATCH v2] isdn/gigaset: Convert timers to use timer_setup()

From: Kees Cook > Sent: 06 October 2017 20:40 ... > I'm in no rush for any specific change. There are about 900 call sites > I'm making my way through, about 2/3rd are pretty trivial, and the > less obvious is what I've started sending out now, since I expect some > will need some more careful

RE: [PATCH v1 RFC 1/7] Replace license with GPL

From: tristram...@microchip.com > Sent: 06 October 2017 21:33 > Replace license with GPL. Don't you need permission from all the people who have updated the files in order to make this change? David

RE: [PATCH 3/4] net: qcom/emac: enforce DMA address restrictions

From: Timur Tabi > Sent: 12 October 2017 15:13 > On 10/12/17 4:30 AM, David Laight wrote: > > Isn't the memory allocated by a single kzalloc() call? > > dma_alloc_coherenent, actually. > > > IIRC that guarantees it doesn't cross a power or 2 boundary less than > &g

RE: [PATCH net-next 1/3] ibmvnic: Enable scatter-gather support

From: Thomas Falcon > Sent: 17 October 2017 18:37 > This patch enables scatter gather support. Since there is no > HW/FW scatter-gather support at this time, the driver needs to > loop through each fragment and copy it to a contiguous, pre-mapped > buffer entry. ... > offset = index *

RE: [PATCH] lib/dynamic_queue_limits.c: relax BUG_ON to WARN_ON in dql_complete()

From: Ard Biesheuvel > Sent: 18 October 2017 16:45 > Even though calling dql_completed() with a count that exceeds the > queued count is a serious error, it still does not justify bringing > down the entire kernel with a BUG_ON(). So relax it to a WARN_ON() > instead. > > Signed-off-by: Ard

RE: Get rid of RCU callbacks in TC filters?

From: Cong Wang > Sent: 20 October 2017 21:52 > To: Paul E. McKenney > Cc: Jamal Hadi Salim; Chris Mi; Linux Kernel Network Developers; Daniel > Borkmann; Eric Dumazet; David > Miller; Jiri Pirko > Subject: Re: Get rid of RCU callbacks in TC filters? > > On Fri, Oct 20, 2017 at 1:31 PM, Cong

RE: [PATCH net-next v2 1/3] net: bgmac: Pad packets to a minimum size

From: Florian Fainelli > Sent: 09 November 2017 22:35 > > In preparation for enabling Broadcom tags with b53, pad packets to a > minimum size of 64 bytes (sans FCS) in order for the Broadcom switch to > accept ingressing frames. Without this, we would typically be able to > DHCP, but not resolve

RE: [PATCH V11 4/5] vsprintf: add printk specifier %px

From: Linus Torvalds > Sent: 29 November 2017 02:29 > > On Tue, Nov 28, 2017 at 6:05 PM, Tobin C. Harding wrote: > > > >Let's add specifier %px as a > > clear, opt-in, way to print a pointer and maintain some level of > > isolation from all the other hex integer output within

RE: [PATCH V11 0/5] hash addresses printed with %p

From: Andrew Morton > Sent: 29 November 2017 23:21 > > > > The added advantage of hashing %p is that security is now opt-out, if > > you _really_ want the address you have to work a little harder and use > > %px. You need a system-wide opt-out that prints the actual values. Otherwise developers

RE: [PATCH net 3/5] sctp: only allow the asoc reset when the asoc outq is empty

From: Xin Long > Sent: 25 November 2017 13:06 > > As it says in rfc6525#section5.1.4, before sending the request, > >C2: The sender has either no outstanding TSNs or considers all > outstanding TSNs abandoned. > > Prior to this patch, it tried to consider all outstanding TSNs

RE: [PATCH V11 4/5] vsprintf: add printk specifier %px

From: Kees Cook > Sent: 29 November 2017 22:28 > On Wed, Nov 29, 2017 at 2:07 AM, David Laight <david.lai...@aculab.com> wrote: > > From: Linus Torvalds > >> Sent: 29 November 2017 02:29 > >> > >> On Tue, Nov 28, 2017 at 6:05 PM, Tobin C. Harding <

RE: [PATCH 0/9] use network namespace for iSCSI control interfaces

From: Chris Leech > Sent: 15 November 2017 00:25 > To: David Laight > Cc: netdev@vger.kernel.org; contain...@lists.linux-foundation.org > Subject: Re: [PATCH 0/9] use network namespace for iSCSI control interfaces > > On Wed, Nov 08, 2017 at 10:31:04AM +, David Laight wrot

RE: [PATCH 3/7] net: core: eliminate dev_alloc_name{,_ns} code duplication

From: Rasmus Villemoes > Sent: 12 November 2017 23:15 > dev_alloc_name contained a BUG_ON(), which I moved to dev_alloc_name_ns; > the only other caller of that already has the same BUG_ON. > > Signed-off-by: Rasmus Villemoes > --- > net/core/dev.c | 12 ++-- >

RE: [PATCH net-next] net: thunderbolt: Clear finished Tx frame bus address in tbnet_tx_callback()

From: Mika Westerberg > Sent: 13 November 2017 10:22 > To: David Miller > Cc: michael.ja...@intel.com; yehezkel.ber...@intel.com; netdev@vger.kernel.org > Subject: Re: [PATCH net-next] net: thunderbolt: Clear finished Tx frame bus > address in > tbnet_tx_callback() > > On Sat, Nov 11, 2017 at

RE: [PATCH] net: mvneta: fix handling of the Tx descriptor counter

From: Simon Guinot > Sent: 13 November 2017 15:36 > To: David Miller > Cc: thomas.petazz...@free-electrons.com; netdev@vger.kernel.org; m...@gmx.de; > andreas.tob...@cloudguard.ch; gregory.clem...@free-electrons.com; > antoine.ten...@free-electrons.com; > m...@semihalf.com; sta...@vger.kernel.org

RE: [PATCH] net: bridge: add max_fdb_count

From: Sarah Newman > Sent: 15 November 2017 19:27 > Current memory and CPU usage for managing bridge fdb entries is unbounded. > Add a parameter max_fdb_count, controlled from sysfs, which places an upper > limit on the number of entries. Defaults to 1024. > > When max_fdb_count is met or

RE: [net-next 1/1] tipc: enforce valid ratio between skb truesize and contents

From: Jon Maloy > Sent: 15 November 2017 20:24 > The socket level flow control is based on the assumption that incoming > buffers meet the condition (skb->truesize / roundup(skb->len) <= 4), > where the latter value is rounded off upwards to the nearest 1k number. > This does empirically hold true

RE: [PATCH net-next v2 1/3] enic: reset fetch index

From: Parvi Kaustubhi > Sent: 01 November 2017 15:45 > Since we are allowing rx ring size modification, reset fetch index > everytime. Otherwise it could have a stale value that can lead to a null > pointer dereference. > > Signed-off-by: Govindarajulu Varadarajan >

RE: [PATCH] [net-next,v2] ibmvnic: Feature implementation of Vital Product Data (VPD) for the ibmvnic driver

From: David Miller > Sent: 04 November 2017 13:21 > From: Desnes Augusto Nunes do Rosario > Date: Wed, 1 Nov 2017 19:03:32 -0200 > > > + substr = strnstr(adapter->vpd->buff, "RM", adapter->vpd->len); > > + if (!substr) { > > + dev_info(dev, "No FW level

RE: [PATCH x86 v2] uprobe: emulate push insns for uprobe on x86

From: Yonghong Song > Sent: 09 November 2017 00:55 > > Uprobe is a tracing mechanism for userspace programs. > Typical uprobe will incur overhead of two traps. > First trap is caused by replaced trap insn, and > the second trap is to execute the original displaced > insn in user space. > > To

RE: [PATCH 0/9] use network namespace for iSCSI control interfaces

From: Chris Leech > Sent: 07 November 2017 22:45 > > I've posted these changes to allow iSCSI management within a container > using a network namespace to the SCSI and Open-iSCSI lists, but seeing > as it's not really SCSI/block related I'm casting a wider net looking > for reviews. I didn't

RE: mlx5 broken affinity

From: Sagi Grimberg > Sent: 08 November 2017 07:28 ... > > Why would you give the user a knob to destroy what you carefully optimized? > > Well, looks like someone relies on this knob, the question is if he is > doing something better for his workload. I don't know, its really up to > the user to

RE: [PATCH] net: mvneta: fix handling of the Tx descriptor counter

From: Simon Guinot > Sent: 08 November 2017 16:59 > > The mvneta controller provides a 8-bit register to update the pending > Tx descriptor counter. Then, a maximum of 255 Tx descriptors can be > added at once. In the current code the mvneta_txq_pend_desc_add function > assumes the caller takes

RE: [PATCH v4] scripts: add leaking_addresses.pl

From: Tobin C. Harding > Sent: 07 November 2017 10:32 > > Currently we are leaking addresses from the kernel to user space. This > script is an attempt to find some of those leakages. Script parses > `dmesg` output and /proc and /sys files for hex strings that look like > kernel addresses. ...

RE: [PATCHv2 net-next 04/12] sctp: implement make_datafrag for sctp_stream_interleave

From: Xin Long > Sent: 08 December 2017 13:04 ... > @@ -264,8 +264,8 @@ struct sctp_datamsg *sctp_datamsg_from_user(struct > sctp_association *asoc, > frag |= SCTP_DATA_SACK_IMM; > } > > - chunk = sctp_make_datafrag_empty(asoc, sinfo, len,

RE: [PATCHv2 net-next 04/12] sctp: implement make_datafrag for sctp_stream_interleave

From: 'Marcelo Ricardo Leitner' > Sent: 08 December 2017 15:16 > On Fri, Dec 08, 2017 at 03:01:31PM +, David Laight wrote: > > From: Marcelo Ricardo Leitner > > > Sent: 08 December 2017 14:57 > > > > > > On Fri, Dec 08, 2017 at 02:06:04PM +, Dav

RE: [PATCHv2 net-next 04/12] sctp: implement make_datafrag for sctp_stream_interleave

From: Marcelo Ricardo Leitner > Sent: 08 December 2017 16:00 ... > > Is it worth replacing the si struct with an index/enum value, and indexing > > an > > array of method pointer structs? That would save you at least one > > dereference. > > Hmmm, maybe, yes. It would be like >

RE: [PATCHv2 net-next 04/12] sctp: implement make_datafrag for sctp_stream_interleave

From: Xin Long > Sent: 08 December 2017 16:18 > ... > >> Alternatively you could preform the dereference in two steps (i.e. declare > >> an si > >> pointer on the stack and set it equal to asoc->stream.si, then deref > >> si->make_datafrag at call time. That will at least give the compiler an >

RE: [PATCHv2 net-next 04/12] sctp: implement make_datafrag for sctp_stream_interleave

From: Marcelo Ricardo Leitner > Sent: 08 December 2017 14:57 > > On Fri, Dec 08, 2017 at 02:06:04PM +0000, David Laight wrote: > > From: Xin Long > > > Sent: 08 December 2017 13:04 > > ... > > > @@ -264,8 +264,8 @@ struct sctp_datamsg *sctp_datamsg_from_us

RE: [PATCHv2 net-next 04/12] sctp: implement make_datafrag for sctp_stream_interleave

From: Xin Long ... > Hi, David, Sorry, I'm not sure we're worrying about the cpu cost or > codes style now ? > > For cpu cost, I think 0x848(%r13) operation must be better than the > generated code of if-else. Nope - the call xxx(%ryyy) is likely to be a data cache miss and a complete cpu

RE: [PATCH V11 3/5] printk: hash addresses printed with %p

From: David Miller > Sent: 05 December 2017 20:31 ... > > Would it make sense to keep the 3 lowest bits of the address? > > > > Currently printed pointers no longer have any correlation with the actual > > alignment in memory of the object, which is a typical cause of a class of > > bugs. > >

RE: [PATCH net 4/4] sctp: fix some type cast warnings introduced since very beginning

From: Xin Long > Sent: 28 October 2017 12:44 > These warnings were found by running 'make C=2 M=net/sctp/'. > They are there since very beginning. ... > - param.crr_id = i; > + param.crr_id = htonl(i); ... Isn't this a bug fix, not just removing a warning?? David

RE: [PATCH net-next 1/1] forcedeth: replace pci_alloc_consistent with dma_alloc_coherent

From: Zhu Yanjun > Sent: 28 October 2017 13:26 > The functions pci_alloc_consistent is obsolete. So it is replaced > with dma_alloc_coherent ... > + dma_free_coherent(>pci_dev->dev, > + sizeof(struct ring_desc) * > +

RE: [PATCH v2] net: dsa: drop some VLAs in switch.c

From: Salvatore Mesoraca > Sent: 07 May 2018 20:03 ... > This optimization will save us an allocation when number of ports is > less than 32 or 64 (depending on arch). > IMHO it's useful, if you consider that, right now, DSA works only with > 12-ports switches. Why not just error out if the

RE: [PATCH net-next] sctp: add support for SCTP_REUSE_PORT sockopt

... > > >> the reason this was added is to have a specified way to allow a system to > > >> behave like a client and server making use of the INIT collision. > > >> > > >> For 1-to-many style sockets you can do this by creating a socket, > > >> binding it, > > >> calling listen on it and trying

RE: [PATCH v2 net-next 1/2] net: dsa: lan9303: Add port_fast_age and port_fdb_dump methods

From: Egil Hjelmeland > Sent: 19 October 2017 17:53 ... > >> IMHO it is best to define a struct for the 'ctx and then do: > >> ..., void *v_ctx) > >> { > >> foo_ctx *ctx = v_ctx; > >> int port = ctx->port; > >> > >> That stops anyone having to double-check that the *(int *) > >> is

RE: [PATCH net-next 6/8] tools: bpftool: print all relevant byte opcodes for "load double word"

From: Jakub Kicinski > Sent: 19 October 2017 23:46 > The eBPF instruction permitting to load double words (8 bytes) into a > register need 8-byte long "immediate" field, and thus occupy twice the > space of other instructions. bpftool was aware of this and would > increment the instruction counter

RE: [PATCH v2 net-next 1/2] net: dsa: lan9303: Add port_fast_age and port_fdb_dump methods

From: Andrew Lunn > Sent: 19 October 2017 15:15 > > > +/* Clear learned (non-static) entry on given port */ > > > +static void alr_loop_cb_del_port_learned(struct lan9303 *chip, u32 dat0, > > > + u32 dat1, int portmap, void *ctx) > > > +{ > > > + int *port = ctx; >

RE: [PATCH net-next 1/3] ibmvnic: Enable scatter-gather support

From: Thomas Falcon > Sent: 26 October 2017 18:52 ... > >>memset(dst, 0, adapter->req_mtu); > > Seems unnecessary. > > I removed that bit, and so far you seem to be right :) . I'd check that short frames are padded with zeros. David

RE: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

From: Willem de Bruijn > Sent: 25 October 2017 19:50 ... > From skb->dev and netdev_priv, the tun device has flags 0x1002 == > IFF_TAP | IFF_NO_PI. This kernel precedes the recent support for > IFF_NAPI and IFF_NAPI_FRAGS. The allocation most likely happened > in tun_build_skb from

RE: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

From: Linus Torvalds > Sent: 07 January 2018 19:47 ... > Also, people definitely *are* noticing the performance issues with the > current set of patches, and they are causing real problems. Go search > for reports of Amazon AWS slowdowns. Try over 35% slowdown Given that AWS instance runs

RE: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

From: Alan Cox > Sent: 08 January 2018 12:13 ... > > Try over 35% slowdown > > Given that AWS instance runs known code (user and kernel) why do we > > need to worry about any of these sideband attacks? > > You may not need to. Amazon themselves obviously need to worry that no > other VM

RE: [PATCH 04/36] usercopy: Prepare for usercopy whitelisting

From: Christopher Lameter > Sent: 10 January 2018 18:28 > On Tue, 9 Jan 2018, Kees Cook wrote: > > > +struct kmem_cache *kmem_cache_create_usercopy(const char *name, > > + size_t size, size_t align, slab_flags_t flags, > > + size_t useroffset, size_t usersize,

RE: [PATCH] net: cxgb4: avoid memcpy beyond end of source buffer

From: Arnd Bergmann > Sent: 02 February 2018 15:19 > > Building with link-time-optimizations revealed that the cxgb4 driver does > a fixed-size memcpy() from a variable-length constant string into the > network interface name: ... > I can see two equally workable solutions: either we use a

RE: [PATCH] tcp_lp: use 64-bit arithmetic instead of 32-bit

> > The question you need to ask is 'can it overflow 32bit maths', otherwise > > you are potentially making the system do extra work for no reason. > > > > Yeah, I get your point and it seems that in this particular case there > is no risk of a 32bit overflow, but in general and IMHO as the code

RE: [PATCH net-next 0/7] tcp: implement rb-tree based retransmit queue

From: Eric Dumazet > Sent: 06 February 2018 14:20 ... > Please give exact details. > Sending 64, 128, 256 or 512 bytes at a time on TCP_STREAM makes little sense. > We are not optimizing stack for pathological cases, sorry. There are plenty of workloads which are not bulk data and where multiple

RE: [PATCH v5 07/14] net: pch_gbe: Fix handling of TX padding

From: Paul Burton > Sent: 17 February 2018 20:11 > > The ethernet controller found in the Intel EG20T Platform Controller > Hub requires that we place 2 bytes of padding between the ethernet > header & the packet payload. Our pch_gbe driver handles this by copying > packets to be transmitted to a

RE: [PATCH][V2] net: dsa: mv88e6xxx: avoid unintended sign extension on a 16 bit shift

From: Colin King > Sent: 16 February 2018 16:55 > > From: Colin Ian King > > The shifting of timehi by 16 bits to the left will be promoted to > a 32 bit signed int and then sign-extended to an u64. If the top bit > of timehi is set then all then all the upper bits of

RE: [net-next v2 1/1] tipc: avoid unnecessary copying of bundled messages

From: Jon Maloy Date: Thu, 15 Feb 2018 14:14:37 +0100 > A received sk buffer may contain dozens of smaller 'bundled' messages > which after extraction go each in their own direction. > > Unfortunately, when we extract those messages using skb_clone() each > of the

RE: [PATCH v2 1/2] net/sctp: Make wrappers for accessing in/out streams

From: Konstantin Khorenko > Sent: 03 August 2018 17:21 ... > --- a/net/sctp/stream.c > +++ b/net/sctp/stream.c > @@ -37,6 +37,18 @@ > #include > #include > > +struct sctp_stream_out *sctp_stream_out(const struct sctp_stream *stream, > + __u16 sid) > +{ > +

RE: [PATCH v2 0/2] net/sctp: Avoid allocating high order memory with kmalloc()

From: Konstantin Khorenko > Sent: 03 August 2018 17:21 > > Each SCTP association can have up to 65535 input and output streams. > For each stream type an array of sctp_stream_in or sctp_stream_out > structures is allocated using kmalloc_array() function. This function > allocates physically

RE: [iproute PATCH 4/4] lib: Enable colored output only for TTYs

From: Stephen Hemminger > Sent: 15 August 2018 16:04 ... > > This also disables color sequence when the output is piped to a pager > > such as less which with the -R argument can handle it just fine. > > > > ie., the user needs to remove the color arg when that output is not wanted. > > If you

RE: [PATCH v2 0/2] net/sctp: Avoid allocating high order memory with kmalloc()

From: Michael Tuexen > Sent: 03 August 2018 21:57 ... > >> Given how useless SCTP streams are, does anything actually use > >> more than about 4? > > > > Maybe Michael can help us with that. I'm also curious now. > In the context of SIGTRAN I have seen 17 streams... Ok, I've seen 17 there as

RE: [PATCH 1/2] staging: rtl8192e: Fix compiler warning about strncpy

From: Larry Finger > Sent: 20 August 2018 18:51 > When strncpy() is called with source and destination strings the same > length, gcc 8 warns that there may be an unterminated string. Using > strlcpy() rather than strncpy() forces a null at the end and quiets the > warning. > > Signed-off-by:

RE: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

From: Daniel Micay > Sent: 10 March 2018 23:45 > > > Just wondering. Is this actually a VLA. FFT_NUM_SAMPLES was static const so > > not really going to show a lot of variation. This array will always have the > > same size on the stack. > > The issue is that unlike in C++, a `static const`

RE: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

The amount of replicated defined could also be reduced by passing > or < to a min_max() macro. So you start off with something like: #define min(x, y) __min_max(x, <, y) #define max(x, y) __min_max(x, >, y) then have: #define __min_max(x, cond, y) ((x) cond (y) ? (x) : (y)) in all its associated

RE: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

From: Kees Cook > Sent: 13 March 2018 22:15 ... > I'll send a "const_max()" which will refuse to work on > non-constant-values (so it doesn't get accidentally used on variables > that could be exposed to double-evaluation), and will work for stack > array declarations (to avoid the

RE: [PATCH] net: dsa: drop some VLAs in switch.c

From: Salvatore Mesoraca > Sent: 13 March 2018 22:01 > 2018-03-13 20:58 GMT+01:00 Vivien Didelot > : > > Hi Salvatore, > > Hi Vivien, > > > Salvatore Mesoraca writes: > > > >> dsa_switch's num_ports is currently fixed to

RE: RFC on writel and writel_relaxed

From: Benjamin Herrenschmidt > Sent: 28 March 2018 10:56 ... > For example, let's say I have a device with a reset bit and the spec > says the reset bit needs to be set for at least 10us. > > This is wrong: > > writel(1, RESET_REG); > usleep(10); > writel(0, RESET_REG); > >

RE: [PATCH 000/109] remove in-kernel calls to syscalls

From: Dominik Brodowski > Sent: 29 March 2018 15:42 > On Thu, Mar 29, 2018 at 07:20:27AM -0700, Matthew Wilcox wrote: > > On Thu, Mar 29, 2018 at 01:22:37PM +0200, Dominik Brodowski wrote: > > > At least on 64-bit x86, it will likely be a hard requirement from v4.17 > > > onwards to not call

RE: RFC on writel and writel_relaxed

From: Benjamin Herrenschmidt > Sent: 28 March 2018 16:13 ... > > I've always wondered exactly what the twi;isync were for - always seemed > > very heavy handed for most mmio reads. > > Particularly if you are doing mmio reads from a data fifo. > > If you do that you should use the "s" version of

RE: [PATCH v5 0/2] Remove false-positive VLAs when using max()

From: Linus Torvalds > Sent: 16 March 2018 17:29 > On Fri, Mar 16, 2018 at 4:47 AM, Florian Weimer wrote: > > > > If you want to catch stack frames which have unbounded size, > > -Werror=stack-usage=1000 or -Werror=vla-larger-than=1000 (with the constant > > adjusted as

RE: [PATCH v5 0/2] Remove false-positive VLAs when using max()

From: linus...@gmail.com [mailto:linus...@gmail.com] On Behalf Of Linus Torvalds > Sent: 18 March 2018 23:36 ... > > Yeah, and since we're in the situation that *new* gcc versions work > for us anyway, and we only have issues with older gcc's (that sadly > people still use), even if there was a

RE: [RFC PATCH 0/3] kernel: add support for 256-bit IO access

From: Rahul Lakkireddy > Sent: 19 March 2018 14:21 > > This series of patches add support for 256-bit IO read and write. > The APIs are readqq and writeqq (quad quadword - 4 x 64), that read > and write 256-bits at a time from IO, respectively. Why not use the AVX2 registers to get 512bit

RE: [RFC PATCH 0/3] kernel: add support for 256-bit IO access

From: Thomas Gleixner > Sent: 19 March 2018 15:05 > > On Mon, 19 Mar 2018, David Laight wrote: > > From: Rahul Lakkireddy > > In principle it ought to be possible to get access to one or two > > (eg) AVX registers by saving them to stack and telling the fpu > >

RE: [RFC PATCH 0/3] kernel: add support for 256-bit IO access

From: Thomas Gleixner > Sent: 19 March 2018 15:37 ... > > If system call entry reset the AVX registers then any FP save/restore > > would be faster because the AVX registers wouldn't need to be saved > > (and the cpu won't save them). > > I believe the instruction to reset the AVX registers is

RE: [RFC PATCH 0/3] kernel: add support for 256-bit IO access

From: Ingo Molnar > Sent: 20 March 2018 10:54 ... > Note that a generic version might still be worth trying out, if and only if > it's > safe to access those vector registers directly: modern x86 CPUs will do their > non-constant memcpy()s via the common memcpy_erms() function - which could in >

<    1   2   3   4   5   6   7   >