Even if the current mapping is correct for the 1 CPU and 2 CPU cases
(currently enetc is included in SoCs with up to 2 CPUs only), better
use a generic rule for the mapping to cover all possible cases.
The number of CPUs is the same as the number of interrupt vectors:
Per device Tx rings -
device_
Am Freitag, dem 09.04.2021 um 10:11 +0800 schrieb Hangbin Liu:
> On Thu, Apr 08, 2021 at 08:11:34AM -0700, Eric Biggers wrote:
> > On Thu, Apr 08, 2021 at 07:58:08PM +0800, Hangbin Liu wrote:
> > > On Thu, Apr 08, 2021 at 09:06:52AM +0800, Hangbin Liu wrote:
> > > > > Also, couldn't you just consid
On Thu, Apr 08, 2021 at 11:52:01AM -0700, Xie He wrote:
> Hi Mel Gorman,
>
> I may have found a problem in pfmemalloc skb handling in
> net/core/dev.c. I see there are "if" conditions checking for
> "sk_memalloc_socks() && skb_pfmemalloc(skb)", and when the condition
> is true, the skb is handled
Some trivial spelling mistakes which caught my eye during the
review of the code.
Signed-off-by: Salil Mehta
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 2 +-
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
On Fri, Apr 9, 2021 at 1:36 PM Jason Wang wrote:
>
>
> 在 2021/4/8 下午5:36, Yongji Xie 写道:
> > On Thu, Apr 8, 2021 at 2:57 PM Jason Wang wrote:
> >>
> >> 在 2021/3/31 下午4:05, Xie Yongji 写道:
> >>> This VDUSE driver enables implementing vDPA devices in userspace.
> >>> Both control path and data path
Ethtool supports module EEPROM dumps via the `ethtool -m ` command.
But in current state its functionality is limited - offset and length
parameters, which are used to specify a linear desired region of EEPROM
data to dump, is not enough, considering emergence of complex module
EEPROM layouts such
From: Vladyslav Tarasiuk
Define get_module_eeprom_by_page() ethtool callback and implement
netlink infrastructure.
get_module_eeprom_by_page() allows network drivers to dump a part of
module's EEPROM specified by page and bank numbers along with offset and
length. It is effectively a netlink rep
From: Vladyslav Tarasiuk
Prepare for ethtool_ops::get_module_eeprom_data() implementation by
extracting common part of mlx5_query_module_eeprom() into a separate
function.
Signed-off-by: Vladyslav Tarasiuk
---
.../net/ethernet/mellanox/mlx5/core/port.c| 79 +++
include/linu
From: Vladyslav Tarasiuk
Allow the driver to recognise DSFP transceiver module ID and therefore
allow its EEPROM dumps using ethtool.
Signed-off-by: Vladyslav Tarasiuk
---
drivers/net/ethernet/mellanox/mlx5/core/port.c | 2 ++
include/linux/mlx5/port.h | 1 +
2 files chang
From: Vladyslav Tarasiuk
Implement ethtool_ops::get_module_eeprom_by_page() to enable
support of new SFP standards.
Signed-off-by: Vladyslav Tarasiuk
---
.../ethernet/mellanox/mlx5/core/en_ethtool.c | 44 +++
.../net/ethernet/mellanox/mlx5/core/port.c| 41 +
From: Andrew Lunn
There are two ways to retrieve information from SFP EEPROMs. Many
devices make use of the common code, and assign the sfp_bus pointer in
the netdev to point to the bus holding the SFP device. Some MAC
drivers directly implement ops in there ethool structure.
Export within net/
From: Vladyslav Tarasiuk
In case netlink get_module_eeprom_by_page() callback is not implemented
by the driver, try to call old get_module_info() and get_module_eeprom()
pair. Recalculate parameters to get_module_eeprom() offset and len using
page number and their sizes. Return error if this can'
From: Andrew Lunn
The new netlink API for reading SFP data requires a new op to be
implemented. The idea of the new netlink SFP code is that userspace is
responsible to parsing the EEPROM data and requesting pages, rather
than have the kernel decide what pages are interesting and returning
them.
From: Andrew Lunn
If the device has a sfp bus attached, call its
sfp_get_module_eeprom_by_page() function, otherwise use the ethtool op
for the device. This follows how the IOCTL works.
Signed-off-by: Andrew Lunn
---
net/ethtool/eeprom.c | 25 -
1 file changed, 20 inser
On Fri, Apr 09, 2021 at 09:08:20AM +0200, Stephan Mueller wrote:
> > > > > > And how do you handle all the other places in the kernel that use
> > > > > > ChaCha20 and
> > > > > > SipHash? For example, drivers/char/random.c?
> > > > >
> > > > > Good question, I will check it and reply to you late
Hi Andrew,
> -Original Message-
> From: Andrew Lunn
> Sent: 2021年4月7日 20:35
> To: Joakim Zhang
> Cc: peppe.cavall...@st.com; alexandre.tor...@st.com;
> joab...@synopsys.com; da...@davemloft.net; k...@kernel.org;
> f.faine...@gmail.com; netdev@vger.kernel.org; dl-linux-imx
> ; jisheng.zh
On Fri, Apr 9, 2021 at 12:30 AM Mel Gorman wrote:
>
> Under what circumstances do you expect sk_memalloc_socks() to be false
> and skb_pfmemalloc() to be true that would cause a problem?
For example, if at the time the skb is allocated,
"sk_memalloc_socks()" was true, then the skb might be alloca
This patch set adds new properties for of_get_mac_address from nvmem.
Fugang Duan (3):
dt-bindings: net: add new properties for of_get_mac_address from nvmem
net: ethernet: add property "nvmem_macaddr_swap" to swap macaddr bytes
order
of_net: add property "nvmem-mac-address" for of_get_m
From: Fugang Duan
Currently, of_get_mac_address supports NVMEM, some platforms
MAC address that read from NVMEM efuse requires to swap bytes
order, so add new property "nvmem_macaddr_swap" to specify the
behavior. If the MAC address is valid from NVMEM, add new property
"nvmem-mac-address" in eth
From: Fugang Duan
ethernet controller driver call .of_get_mac_address() to get
the mac address from devictree tree, if these properties are
not present, then try to read from nvmem.
For example, read MAC address from nvmem:
of_get_mac_address()
of_get_mac_addr_nvmem()
nvm
From: Fugang Duan
If MAC address read from nvmem cell and it is valid mac address,
.of_get_mac_addr_nvmem() add new property "nvmem-mac-address" in
ethernet node. Once user call .of_get_mac_address() to get MAC
address again, it can read valid MAC address from device tree in
directly.
Signed-off
On Fri, Apr 09, 2021 at 01:33:24AM -0700, Xie He wrote:
> On Fri, Apr 9, 2021 at 12:30 AM Mel Gorman
> wrote:
> >
> > Under what circumstances do you expect sk_memalloc_socks() to be false
> > and skb_pfmemalloc() to be true that would cause a problem?
>
> For example, if at the time the skb is
Greetings;
I sent you an email a couple of days ago and haven't heard from you.
Please confirm if you received my email?
Yours Sincerely,
Mr. Cosme Amossou (Lawyer)
E-mail:co...@cabinetcosme.com
On 29/03/2021 08:13, Ido Schimmel wrote:
> On Sat, Mar 27, 2021 at 10:33:34PM +, Colin King wrote:
>> From: Colin Ian King
>>
>> The variable force is being initialized with a value that is
>> never read and it is being updated later with a new value. The
>> initialization is redundant and can
Hi,
Please ignore this patch set version, I will resend it, sorry.
Best Regards,
Joakim Zhang
> -Original Message-
> From: Joakim Zhang
> Sent: 2021年4月9日 16:38
> To: da...@davemloft.net; k...@kernel.org; robh...@kernel.org;
> and...@lunn.ch; hkallwe...@gmail.com; li...@armlinux.org.uk;
Hi Michael,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Michael-Walle/of-net-support-non-platform-devices-in-of_get_mac_address/20210406-234030
base: https://git.kernel.org/pub/scm/linux/kerne
This patch set adds new properties for of_get_mac_address from nvmem.
Fugang Duan (3):
dt-bindings: net: add new properties for of_get_mac_address from nvmem
net: ethernet: add property "nvmem_macaddr_swap" to swap macaddr bytes
order
of_net: add property "nvmem-mac-address" for of_get_m
From: Fugang Duan
ethernet controller driver call .of_get_mac_address() to get
the mac address from devictree tree, if these properties are
not present, then try to read from nvmem.
For example, read MAC address from nvmem:
of_get_mac_address()
of_get_mac_addr_nvmem()
nvm
From: Fugang Duan
Currently, of_get_mac_address supports NVMEM, some platforms
MAC address that read from NVMEM efuse requires to swap bytes
order, so add new property "nvmem_macaddr_swap" to specify the
behavior. If the MAC address is valid from NVMEM, add new property
"nvmem-mac-address" in eth
From: Fugang Duan
If MAC address read from nvmem cell and it is valid mac address,
.of_get_mac_addr_nvmem() add new property "nvmem-mac-address" in
ethernet node. Once user call .of_get_mac_address() to get MAC
address again, it can read valid MAC address from device tree in
directly.
Signed-off
Update maintainer entry for freescale fec driver.
Suggested-by: Heiner Kallweit
Signed-off-by: Joakim Zhang
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1cc3976040d5..efc76153114c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@
On Fri, Apr 9, 2021 at 1:44 AM Mel Gorman wrote:
>
> That would imply that the tap was communicating with a swap device to
> allocate a pfmemalloc skb which shouldn't happen. Furthermore, it would
> require the swap device to be deactivated while pfmemalloc skbs still
> existed. Have you encounter
On Mon, 2021-03-29 at 09:04 +0300, Dan Carpenter wrote:
> On Sat, Mar 27, 2021 at 10:33:34PM +, Colin King wrote:
> > From: Colin Ian King
> >
> > The variable force is being initialized with a value that is
> > never read and it is being updated later with a new value. The
> > initialization
On 07.04.2021 17:50, Heiner Kallweit wrote:
> Resume callback of the PHY driver is called after the one for the MAC
> driver. The PHY driver resume callback calls phy_init_hw(), and this is
> potentially problematic if the MAC driver calls phy_start() in its resume
> callback. One issue was reporte
On Wed, 2021-04-07 at 11:13 -0700, Jakub Kicinski wrote:
> On Wed, 07 Apr 2021 16:54:29 +0200 Paolo Abeni wrote:
> > > > I think in the above example even the normal processing will be
> > > > fooled?!? e.g. even without the napi_disable(), napi_thread_wait() will
> > > > will miss the event/will
On Fri, Apr 09, 2021 at 02:14:12AM -0700, Xie He wrote:
> On Fri, Apr 9, 2021 at 1:44 AM Mel Gorman wrote:
> >
> > That would imply that the tap was communicating with a swap device to
> > allocate a pfmemalloc skb which shouldn't happen. Furthermore, it would
> > require the swap device to be dea
On 4/9/21 11:14 AM, Xie He wrote:
> On Fri, Apr 9, 2021 at 1:44 AM Mel Gorman wrote:
>>
>> That would imply that the tap was communicating with a swap device to
>> allocate a pfmemalloc skb which shouldn't happen. Furthermore, it would
>> require the swap device to be deactivated while pfmemall
kernel.h is being used as a dump for all kinds of stuff for a long time.
Here is the attempt to start cleaning it up by splitting out panic and
oops helpers.
There are several purposes of doing this:
- dropping dependency in bug.h
- dropping a loop by moving out panic_notifier.h
- unload kernel.h
On 4/9/21 11:24 AM, Paolo Abeni wrote:
> On Wed, 2021-04-07 at 11:13 -0700, Jakub Kicinski wrote:
>> On Wed, 07 Apr 2021 16:54:29 +0200 Paolo Abeni wrote:
> I think in the above example even the normal processing will be
> fooled?!? e.g. even without the napi_disable(), napi_thread_wait(
On Fri, Apr 9, 2021 at 2:58 AM Mel Gorman wrote:
>
> On Fri, Apr 09, 2021 at 02:14:12AM -0700, Xie He wrote:
> >
> > Do you mean that at the time "sk_memalloc_socks()" changes from "true"
> > to "false", there would be no in-flight skbs currently being received,
> > and all network communications
On Fri, Apr 9, 2021 at 3:04 AM Eric Dumazet wrote:
>
> Note that pfmemalloc skbs are normally dropped in sk_filter_trim_cap()
>
> Simply make sure your protocol use it.
It seems "sk_filter_trim_cap" needs an "struct sock" argument. Some of
my protocols act like a middle layer to another protocol
Hi All,
I just updated kernel 4.14 within OpenWRT from 4.14.224 to 4.14.229
Booting it shows the splat below on each run. [1]
It seems there are 2 patches regarding flexcan which were introduced in
4.14.226
--> ce59ffca5c49 ("can: flexcan: enable RX FIFO after FRZ/HALT valid")
--> bb7c9039a3
On Fri, Apr 09, 2021 at 10:16:13AM +0300, Claudiu Manoil wrote:
> Even if the current mapping is correct for the 1 CPU and 2 CPU cases
> (currently enetc is included in SoCs with up to 2 CPUs only), better
> use a generic rule for the mapping to cover all possible cases.
> The number of CPUs is the
On 4/7/21 2:09 AM, Aditya Pakki wrote:
> In case of rs failure in rds_send_remove_from_sock(), the 'rm' resource
> is freed and later under spinlock, causing potential use-after-free.
> Set the free pointer to NULL to avoid undefined behavior.
>
> Signed-off-by: Aditya Pakki
> ---
> net/rds/m
Hi,
Analysis of linux with Coverity has detected an issue with the
assignment of ictx->xstorm_st_context.common.fla in
drivers/net/ethernet/broadcom/cnic.c in function cnic_setup_bnx2x_ctx.
This was introduced a while back with the following commit:
commit 619c5cb6885b936c44ae1422ef805b69c629148
Jamal Hadi Salim writes:
> I am concerned about adding new opcodes which only make sense if you
> offload (or make sense only if you are running in s/w).
>
> Those opcodes are intended to be generic abstractions so the dispatcher
> can decide what to do next. Adding things that are specific onl
This series allows the user-space to enable GRO/NAPI on a veth
device even without attaching an XDP program.
It does not change the default veth behavior (no NAPI, no GRO),
except that the GRO feature bit on top of this series will be
effectively off by default on veth devices. Note that currently
Currently the veth device has the GRO feature bit set, even if
no GRO aggregation is possible with the default configuration,
as the veth device does not hook into the GRO engine.
Flipping the GRO feature bit from user-space is a no-op, unless
XDP is enabled. In such scenario GRO could actually ta
As described by commit 9c4c325252c5 ("skbuff: preserve sock
reference when scrubbing the skb."), orphaning a skb
in the TX path will cause OoO.
Let's use skb_orphan_partial() instead of skb_orphan(), so
that we keep the sk around for queue's selection sake and we
still avoid the problem fixed with
After the previous patch, when enabling GRO, locally generated
TCP traffic experiences some measurable overhead, as it traverses
the GRO engine without any chance of aggregation.
This change refine the NAPI receive path admission test, to avoid
unnecessary GRO overhead in most scenarios, when GRO
Add some basic veth tests, that verify the expected flags and
aggregation with different setups (default, xdp, etc...)
Signed-off-by: Paolo Abeni
---
tools/testing/selftests/net/Makefile | 1 +
tools/testing/selftests/net/veth.sh | 177 +++
2 files changed, 178 inserti
From: Colin Ian King
The shifting of the u8 integers f->fs.nat_lip[] by 24 bits to
the left will be promoted to a 32 bit signed int and then
sign-extended to a u64. In the event that the top bit of the u8
is set then all then all the upper 32 bits of the u64 end up as
also being set because of th
This patch adds missing MODULE_DEVICE_TABLE definition which generates
correct modalias for automatic loading of this driver when it is built
as an external module.
Reported-by: Hulk Robot
Signed-off-by: Qiheng Lin
---
drivers/net/ethernet/ibm/ehea/ehea_main.c | 1 +
1 file changed, 1 insertion
On 2021-04-08 5:25 p.m., Jakub Kicinski wrote:
On Thu, 8 Apr 2021 10:05:07 -0400 Jamal Hadi Salim wrote:
On 2021-04-08 9:38 a.m., Petr Machata wrote:
The TC action "trap" is used to instruct the HW datapath to drop the
matched packet and transfer it for processing in the SW pipeline. If
instead
On 4/9/21 12:18 PM, Koen Vandeputte wrote:
> Hi All,
>
> I just updated kernel 4.14 within OpenWRT from 4.14.224 to 4.14.229
> Booting it shows the splat below on each run. [1]
>
>
> It seems there are 2 patches regarding flexcan which were introduced in
> 4.14.226
>
> --> ce59ffca5c49 ("can:
On 2021-04-09 7:03 a.m., Petr Machata wrote:
Jamal Hadi Salim writes:
I am concerned about adding new opcodes which only make sense if you
offload (or make sense only if you are running in s/w).
Those opcodes are intended to be generic abstractions so the dispatcher
can decide what to do nex
Hi,
On Fri, Apr 09, 2021 at 01:02:50PM +0300, Andy Shevchenko wrote:
> kernel.h is being used as a dump for all kinds of stuff for a long time.
> Here is the attempt to start cleaning it up by splitting out panic and
> oops helpers.
>
> There are several purposes of doing this:
> - dropping depen
On 4/9/21 12:14 PM, Xie He wrote:
> On Fri, Apr 9, 2021 at 3:04 AM Eric Dumazet wrote:
>>
>> Note that pfmemalloc skbs are normally dropped in sk_filter_trim_cap()
>>
>> Simply make sure your protocol use it.
>
> It seems "sk_filter_trim_cap" needs an "struct sock" argument. Some of
> my proto
From: wengjianfeng
In many places,first assign a value to a variable and then return
the variable. which is redundant, we should directly return the value.
in pn533_rf_field funciton,return statement in the if statement is
redundant, we just delete it.
Signed-off-by: wengjianfeng
---
drivers/n
Eliminate the following coccicheck warning:
drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c:529:3-9: WARNING:
NULL check before some freeing functions is not needed.
drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c:533:2-8: WARNING:
NULL check before some freeing functions is not needed.
driv
On Fri, Apr 09, 2021 at 01:21:05PM +0200, Marc Kleine-Budde wrote:
> On 4/9/21 12:18 PM, Koen Vandeputte wrote:
> > Hi All,
> >
> > I just updated kernel 4.14 within OpenWRT from 4.14.224 to 4.14.229
> > Booting it shows the splat below on each run. [1]
> >
> >
> > It seems there are 2 patches r
On 3/29/21 10:52 PM, Ido Schimmel wrote:
ip_route_me_harder() does not set source / destination port in the
flow key, so it explains why fib rules that use them are not hit after
mangling the packet. These keys were added in 4.17, but I
don't think this use case every worked. You have a differen
This loop will try to unmap enetc_unmap_tx_buff[-1] and crash.
Fixes: 9d2b68cc108d ("net: enetc: add support for XDP_REDIRECT")
Signed-off-by: Dan Carpenter
---
drivers/net/ethernet/freescale/enetc/enetc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/f
Quoting Andrew Lunn :
On Thu, Apr 08, 2021 at 11:00:08PM +0800, DENG Qingfang wrote:
Hi René,
On Thu, Apr 8, 2021 at 10:02 PM René van Dorst
wrote:
>
> Tested on Ubiquiti ER-X-SFP (MT7621) with 1 external phy which
uses irq=POLL.
>
I wonder if the external PHY's IRQ can be registered i
> From: Jason Gunthorpe
> Sent: Thursday, April 8, 2021 5:46 PM
> On Wed, Apr 07, 2021 at 03:44:35PM +, Parav Pandit wrote:
>
> > > If it returns EOPNOTUPP then the remove is never called so if it
> > > allocated memory and left it allocated then it is leaking memory.
> > >
> > I probably
On Wed, 7 Apr 2021 13:24:04 -0700
Jakub Kicinski wrote:
> On Wed, 7 Apr 2021 20:03:32 +0200 Andrea Mayer wrote:
> > This patch provides counters for SRv6 Behaviors as defined in [1], section
> > 6. For each SRv6 Behavior instance, the counters defined in [1] are:
> >
> > - the total number of
>-Original Message-
>From: Dan Carpenter
[...]
>Subject: [PATCH net-next] net: enetc: fix array underflow in error handling
>code
>
>This loop will try to unmap enetc_unmap_tx_buff[-1] and crash.
>
>Fixes: 9d2b68cc108d ("net: enetc: add support for XDP_REDIRECT")
>Signed-off-by: Dan Carpen
On Fri, 2021-04-09 at 08:02 +0200, Ard Biesheuvel wrote:
> On Fri, 9 Apr 2021 at 05:03, Jason A. Donenfeld wrote:
> > On Fri, Apr 09, 2021 at 10:49:07AM +0800, Hangbin Liu wrote:
> > > On Thu, Apr 08, 2021 at 08:44:35PM -0600, Jason A. Donenfeld wrote:
> > > > Since it's just a normal module libra
On Fri, Apr 09, 2021 at 03:24:28PM +0300, Dan Carpenter wrote:
> This loop will try to unmap enetc_unmap_tx_buff[-1] and crash.
>
> Fixes: 9d2b68cc108d ("net: enetc: add support for XDP_REDIRECT")
> Signed-off-by: Dan Carpenter
> ---
> drivers/net/ethernet/freescale/enetc/enetc.c | 2 +-
> 1 fil
On 09.04.21 13:21, Marc Kleine-Budde wrote:
On 4/9/21 12:18 PM, Koen Vandeputte wrote:
Hi All,
I just updated kernel 4.14 within OpenWRT from 4.14.224 to 4.14.229
Booting it shows the splat below on each run. [1]
It seems there are 2 patches regarding flexcan which were introduced in
4.14.2
Michal Soltys wrote:
> On 3/29/21 10:52 PM, Ido Schimmel wrote:
> >
> > ip_route_me_harder() does not set source / destination port in the
> > flow key, so it explains why fib rules that use them are not hit after
> > mangling the packet. These keys were added in 4.17, but I
> > don't think this
From: Colin Ian King
The shifting of the u8 integers rq->caching by 26 bits to
the left will be promoted to a 32 bit signed int and then
sign-extended to a u64. In the event that rq->caching is
greater than 0x1f then all then all the upper 32 bits of
the u64 end up as also being set because of th
On 09.04.2021 14:55:59, Koen Vandeputte wrote:
>
> On 09.04.21 13:21, Marc Kleine-Budde wrote:
> > On 4/9/21 12:18 PM, Koen Vandeputte wrote:
> > > Hi All,
> > >
> > > I just updated kernel 4.14 within OpenWRT from 4.14.224 to 4.14.229
> > > Booting it shows the splat below on each run. [1]
> > >
On Fri, Apr 09, 2021 at 08:36:07 +0200, Greg KH
> On Thu, Apr 08, 2021 at 07:11:48PM +, Jianmin Wang wrote:
> > while the new services need to invoke libkcapi in the container environment.
> >
> > We have verified that the problem doesn't exist on newer kernel version.
> > However, due to man
On Fri, Apr 09, 2021 at 03:02:41PM +0200, Florian Westphal wrote:
> Michal Soltys wrote:
> > On 3/29/21 10:52 PM, Ido Schimmel wrote:
> > >
> > > ip_route_me_harder() does not set source / destination port in the
> > > flow key, so it explains why fib rules that use them are not hit after
> > > m
On Fri, Apr 09, 2021 at 03:10:01PM +0200, Marc Kleine-Budde wrote:
> On 09.04.2021 14:55:59, Koen Vandeputte wrote:
> >
> > On 09.04.21 13:21, Marc Kleine-Budde wrote:
> > > On 4/9/21 12:18 PM, Koen Vandeputte wrote:
> > > > Hi All,
> > > >
> > > > I just updated kernel 4.14 within OpenWRT from 4
Hi,
Static analysis with Coverity has found an issue with the sxgbe driver
in drivers/net/ethernet/samsung/sxgbe/sxgbe_mtl.c from the following commit:
commit 1edb9ca69e8a7988900fc0283e10550b5592164d
Author: Siva Reddy
Date: Tue Mar 25 12:10:54 2014 -0700
net: sxgbe: add basic framework f
For the structs containing variables with the same sizes, or already size
aligned
> variables, we knew the __packed has no effect. And for these structs, it
> doesn't
> cause performance impact either, correct?
>
> But in the future, if different sized variables are added, the __packed may
Jamal Hadi Salim writes:
> On 2021-04-09 7:03 a.m., Petr Machata wrote:
>> Jamal Hadi Salim writes:
>>
>>> I am concerned about adding new opcodes which only make sense if you
>>> offload (or make sense only if you are running in s/w).
>>>
>>> Those opcodes are intended to be generic abstract
On Fri, Apr 9, 2021 at 4:07 AM Joakim Zhang wrote:
>
> From: Fugang Duan
>
> Currently, of_get_mac_address supports NVMEM, some platforms
What's of_get_mac_address? This is a binding patch. Don't mix Linux
things in it.
> MAC address that read from NVMEM efuse requires to swap bytes
> order, so
Hi Kai,
> Delete unneeded variable initialization.
>
> Signed-off-by: Kai Ye
> ---
> net/bluetooth/6lowpan.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
On Thu, Apr 8, 2021 at 7:39 PM Sven Van Asbroeck wrote:
>
> From: Sven Van Asbroeck
>
> The ethernet frame length is calculated incorrectly. Depending on
> the value of RX_HEAD_PADDING, this may result in ethernet frames
> that are too short (cut off at the end), or too long (garbage added
> to t
Hi Yu,
> When an MGMT_EV_DEVICE_CONNECTED event is reported back to the user
> space we will set the flags to tell if the established connection is
> outbound or not. This is useful for the user space to log better metrics
> and error messages.
>
> Reviewed-by: Miao-chen Chou
> Reviewed-by: Alai
Hi Hilda,
> RTL8822C devices support BT wakeup Host. Add a quirk for these specific
> devices did not power off during suspend and resume.
> By this change, if the Host support that received BT device signal then
> it can be wakeup.
>
> Signed-off-by: hildawu
> ---
> Changes in v2:
> - Add missi
On 4/6/2021 7:49 AM, Jason Gunthorpe wrote:
On Mon, Apr 05, 2021 at 11:42:31PM +, Chuck Lever III wrote:
We need to get a better idea what correctness testing has been done,
and whether positive correctness testing results can be replicated
on a variety of platforms.
RO has been rolling
Hi George,
On Fri, Apr 9, 2021 at 10:12 AM George McCollister
wrote:
>
> I'm glad everyone was able to work together to get this fixed properly
> without any figure pointing or mud slinging! Kudos everyone.
Same, this is what the kernel community is supposed to be all about.
And thank you for t
> On Apr 9, 2021, at 10:26 AM, Tom Talpey wrote:
>
> On 4/6/2021 7:49 AM, Jason Gunthorpe wrote:
>> On Mon, Apr 05, 2021 at 11:42:31PM +, Chuck Lever III wrote:
>>
>>> We need to get a better idea what correctness testing has been done,
>>> and whether positive correctness testing result
Paolo Abeni writes:
> After the previous patch, when enabling GRO, locally generated
> TCP traffic experiences some measurable overhead, as it traverses
> the GRO engine without any chance of aggregation.
>
> This change refine the NAPI receive path admission test, to avoid
> unnecessary GRO over
Paolo Abeni writes:
> Currently the veth device has the GRO feature bit set, even if
> no GRO aggregation is possible with the default configuration,
> as the veth device does not hook into the GRO engine.
>
> Flipping the GRO feature bit from user-space is a no-op, unless
> XDP is enabled. In su
On 4/8/21 10:41 PM, Aaron Conole wrote:
> Joe Stringer writes:
>
>> Hey Aaron, long time no chat :)
>
> Same :)
>
>> On Fri, Mar 19, 2021 at 1:43 PM Aaron Conole wrote:
>>>
>>> When a user instructs a flow pipeline to perform connection tracking,
>>> there is an implicit L3 operation that occu
hello,
On Fri, 2021-04-09 at 16:57 +0200, Toke Høiland-Jørgensen wrote:
> Paolo Abeni writes:
>
> > After the previous patch, when enabling GRO, locally generated
> > TCP traffic experiences some measurable overhead, as it traverses
> > the GRO engine without any chance of aggregation.
> >
> >
On Fri, 09 Apr 2021 11:24:07 +0200 Paolo Abeni wrote:
> I think it can be simplified as the following - if NAPIF_STATE_DISABLE
> is set, napi_threaded_poll()/__napi_poll() will return clearing the
> SCHEDS bits after trying to poll the device:
Indeed!
> diff --git a/net/core/dev.c b/net/core/dev.
Paolo Abeni writes:
> hello,
>
> On Fri, 2021-04-09 at 16:57 +0200, Toke Høiland-Jørgensen wrote:
>> Paolo Abeni writes:
>>
>> > After the previous patch, when enabling GRO, locally generated
>> > TCP traffic experiences some measurable overhead, as it traverses
>> > the GRO engine without any
On Fri, 2021-04-09 at 16:58 +0200, Toke Høiland-Jørgensen wrote:
> Paolo Abeni writes:
>
> > Currently the veth device has the GRO feature bit set, even if
> > no GRO aggregation is possible with the default configuration,
> > as the veth device does not hook into the GRO engine.
> >
> > Flippin
napi_disable() is subject to an hangup, when the threaded
mode is enabled and the napi is under heavy traffic.
If the relevant napi has been scheduled and the napi_disable()
kicks in before the next napi_threaded_wait() completes - so
that the latter quits due to the napi_disable_pending() conditi
On 4/9/2021 10:45 AM, Chuck Lever III wrote:
On Apr 9, 2021, at 10:26 AM, Tom Talpey wrote:
On 4/6/2021 7:49 AM, Jason Gunthorpe wrote:
On Mon, Apr 05, 2021 at 11:42:31PM +, Chuck Lever III wrote:
We need to get a better idea what correctness testing has been done,
and whether posit
On 09.04.2021 17:24, Paolo Abeni wrote:
> napi_disable() is subject to an hangup, when the threaded
> mode is enabled and the napi is under heavy traffic.
>
> If the relevant napi has been scheduled and the napi_disable()
> kicks in before the next napi_threaded_wait() completes - so
> that the la
The format for erspan/erspan6 output is not valid JSON, as on version 2 a
valueless key was presented. The direction should be value and erspan_dir
should be the key.
Fixes: 289763626721 ("erspan: add erspan version II support")
Cc: u9012...@gmail.com
Cc: Stephen Hemminger
Reported-by: Christian
From: Andrea Parri (Microsoft) Sent: Thursday, April
8, 2021 9:13 AM
>
> Use blk_mq_unique_tag() to generate requestIDs for StorVSC, avoiding
> all issues with allocating enough entries in the VMbus requestor.
This looks good to me! I'm glad to see that the idea worked without
too much complex
Hello,
syzbot found the following issue on:
HEAD commit:9c54130c Add linux-next specific files for 20210406
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=17d8d7aad0
kernel config: https://syzkaller.appspot.com/x/.config?x=d125958c3995ddcd
dashboard
1 - 100 of 249 matches
Mail list logo
