The x64 bpf jit expects bpf images converge within the given passes, but
it could fail to do so with some corner cases. For example:
l0: ldh [4]
l1: jeq #0x537d, l2, l40
l2: ld [0]
l3: jeq #0xfa163e0d, l4, l40
l4: ldh [12]
l5: ldx #0xe
Herbert Xu wrote:
> > Here's my first cut at a generic Kerberos crypto library in the kernel so
> > that I can share code between rxrpc and sunrpc (and cifs?).
>
> I can't find the bit where you are actually sharing this code with
> sunrpc, am I missing something?
I haven't done that yet. Sorr
On Wed, Nov 25, 2020 at 3:30 PM Magnus Karlsson
wrote:
>
> On Wed, Nov 18, 2020 at 9:34 AM wrote:
> >
> > From: Mariusz Dudek
> >
> > Add support for separation of eBPF program load and xsk socket
> > creation.
> >
> > This is needed for use-case when you want to privide as little
> > privileges
Hi,
I find your output slightly confusing. Maybe you can change your printk stuff
to something more like:
printk("%s %s:%u max_headroom %u\n", __FILE__, __func__, __LINE__,
max_headroom);
On Thursday, 26 November 2020 00:14:35 CET Annika Wickert wrote:
> This is what I get from the bridge wh
On Wed, Nov 25, 2020 at 3:42 PM Magnus Karlsson
wrote:
>
> On Wed, Nov 18, 2020 at 9:34 AM wrote:
> >
> > From: Mariusz Dudek
> >
> > Introduce a sample program to demonstrate the control and data
> > plane split. For the control plane part a new program called
> > xdpsock_ctrl_proc is introduce
Current sample test xdp_redirect_map only count pkts on ingress. But we
can't know whether the pkts are redirected or dropped. So add a counter
on egress interface so we could know how many pkts are redirect in fact.
sample result:
$ ./xdp_redirect_map -X veth1 veth2
input: 5 output: 6
libbpf: el
Hi,
Hi,
>I find your output slightly confusing. Maybe you can change your printk
stuff
> to something more like:
>printk("%s %s:%u max_headroom %u\n", __FILE__, __func__, __LINE__,
max_headroom);
Will add this thx.
>On Thursday, 26 November 2020 00:14:35 CET Annika Wickert
On 2020-11-26 07:44, Yonghong Song wrote:
[...]
What other configures I am missing?
BTW, I cherry-picked the following pick from bpf tree in this experiment.
commit e7f4a5919bf66e530e08ff352d9b78ed89574e6b (HEAD -> xsk)
Author: Björn Töpel
Date: Mon Nov 23 18:56:00 2020 +0100
On Mon 23 Nov 2020 at 16:38, Ioana Ciornei wrote:
> From: Ioana Ciornei
>
> In preparation of removing the .ack_interrupt() callback, we must replace
> its occurrences (aka phy_clear_interrupt), from the 2 places where it is
> called from (phy_enable_interrupts and phy_disable_interrupts), wit
From: Mariusz Dudek
This patch series adds support for separation of eBPF program
load and xsk socket creation. In for example a Kubernetes
environment you can have an AF_XDP CNI or daemonset that is
responsible for launching pods that execute an application
using AF_XDP sockets. It is desirabl
From: Mariusz Dudek
Introduce a sample program to demonstrate the control and data
plane split. For the control plane part a new program called
xdpsock_ctrl_proc is introduced. For the data plane part, some code
was added to xdpsock_user.c to act as the data plane entity.
Application xdpsock_ctr
From: Mariusz Dudek
Add support for separation of eBPF program load and xsk socket
creation.
This is needed for use-case when you want to privide as little
privileges as possible to the data plane application that will
handle xsk socket creation and incoming traffic.
With this patch the data en
Just one comment:
On Mon, 16 Nov 2020 at 23:46, Hemant Kumar wrote:
>
> This MHI client driver allows userspace clients to transfer
> raw data between MHI device and host using standard file operations.
> Driver instantiates UCI device object which is associated to device
> file node. UCI device
From: Magnus Karlsson
Replace size_t with __u32 in the xsk interfaces that contain
this. There is no reason to have size_t since the internal variable
that is manipulated is a __u32. The following APIs are affected:
__u32 xsk_ring_prod__reserve(struct xsk_ring_prod *prod, __u32 nb,
Roman Gushchin writes:
> On Thu, Nov 26, 2020 at 01:21:41AM +0100, Daniel Borkmann wrote:
>> On 11/25/20 4:00 AM, Roman Gushchin wrote:
>> > In the absolute majority of cases if a process is making a kernel
>> > allocation, it's memory cgroup is getting charged.
>> >
>> > Bpf maps can be updated
Hi Andrew, Florian,
> On Wed, Nov 25, 2020 at 05:30:04PM -0800, Florian Fainelli wrote:
> >
> >
> > On 11/25/2020 4:00 PM, Andrew Lunn wrote:
> > > On Thu, Nov 26, 2020 at 12:24:55AM +0100, Lukasz Majewski wrote:
> > >> This is the first attempt to add support for L2 switch available
> > >>
On Wed, Nov 25, 2020 at 4:33 PM Magnus Karlsson
wrote:
>
> On Wed, Nov 25, 2020 at 1:02 AM Daniel Borkmann wrote:
> >
> > On 11/23/20 4:05 PM, Zhu Yanjun wrote:
> > > From: Zhu Yanjun
> > >
> > > The function xsk_map_inc is a simple wrapper of bpf_map_inc and
> > > always returns zero. As such,
Add support for mcan bit timing and control mode according to bosch mcan IP
version 3.3.0
The mcan version read from the Core Release field of CREL register would be
33. Accordingly the properties are to be set for mcan v3.3.0
Signed-off-by: Pankaj Sharma
---
Depends on:
https://marc.info/?l=linu
On 11/26/20 5:51 AM, Pankaj Sharma wrote:
> Add support for mcan bit timing and control mode according to bosch mcan IP
> version 3.3.0
> The mcan version read from the Core Release field of CREL register would be
> 33. Accordingly the properties are to be set for mcan v3.3.0
BTW: do you have the
On Thu, 26 Nov 2020 16:43:25 +0800
Hangbin Liu wrote:
> Current sample test xdp_redirect_map only count pkts on ingress. But we
> can't know whether the pkts are redirected or dropped. So add a counter
> on egress interface so we could know how many pkts are redirect in fact.
This is not true.
On 11/26/20 5:51 AM, Pankaj Sharma wrote:
> Add support for mcan bit timing and control mode according to bosch mcan IP
> version 3.3.0
> The mcan version read from the Core Release field of CREL register would be
> 33. Accordingly the properties are to be set for mcan v3.3.0
>
> Signed-off-by: Pa
Introduce new options on devlink reload API to enable the user to select
the reload action required and constrains limits on these actions that he
may want to ensure.
Add reload stats to show the history per reload action per limit.
Patch 1 adds the new API reload action and reload limit options
Add reload action and reload limit to devlink reload command to enable
the user to select the reload action required and constrains limits on
these actions that he may want to ensure.
The following reload actions are supported:
driver_reinit: driver entities re-initialization, applying
Add pr_out_dev() helper function and use it both by cmd_dev_show_cb()
and by cmd_mon_show_cb().
Dev stats will be added on the next patch to dev context, so
cmd_mon_show_cb() should print the whole dev context and not just dev
handle.
Signed-off-by: Moshe Shemesh
Reviewed-by: Jiri Pirko
---
de
Show reload statistics through devlink dev show using devlink stats
flag. The reload statistics show the history per reload action type and
limit. Add remote reload statistics to show the history of actions
performed due devlink reload commands initiated by remote host.
Output examples:
$ devlink
On 26.11.20 11:48, Marc Kleine-Budde wrote:
On 11/26/20 5:51 AM, Pankaj Sharma wrote:
Add support for mcan bit timing and control mode according to bosch mcan IP
version 3.3.0
The mcan version read from the Core Release field of CREL register would be
33. Accordingly the properties are to be
On 11/25/2020 11:27 AM, Eric Dumazet wrote:
On Wed, Nov 25, 2020 at 10:06 AM Tariq Toukan wrote:
On 11/25/2020 5:25 AM, Herbert Xu wrote:
On Tue, Nov 24, 2020 at 11:48:35AM +0100, Eric Dumazet wrote:
Well, the 'increment' part was suggesting the function was adding
flags, not removing
Am Montag, den 16.11.2020, 09:23 -0800 schrieb Roland Dreier:
> Hi, I recently got a 2.5G USB adapter, and although it works fine, the
> driver continually spams the kernel log with messages like
>
> [127662.025647] cdc_ncm 4-1:2.0 enx3c8cf8f942e0: network connection: connected
> [127662.057680] c
Following on from my previous RFC[1], this series adds two ioctl calls
to the ppp code to implement "channel bridging".
When two ppp channels are bridged, frames presented to ppp_input() on
one channel are passed to the other channel's ->start_xmit function for
transmission.
The primary use-case
This new ioctl pair allows two ppp channels to be bridged together:
frames arriving in one channel are transmitted in the other channel
and vice versa.
The practical use for this is primarily to support the L2TP Access
Concentrator use-case. The end-user session is presented as a ppp
channel (typ
Add documentation of the newly-added PPPIOCBRIDGECHAN and
PPPIOCUNBRIDGECHAN ioctls.
Signed-off-by: Tom Parkin
---
Documentation/networking/ppp_generic.rst | 9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/networking/ppp_generic.rst
b/Documentation/networking/ppp_generi
Hi Lukasz,
On Thu, Nov 26, 2020 at 12:24:55AM +0100, Lukasz Majewski wrote:
> This is the first attempt to add support for L2 switch available on some NXP
> devices - i.e. iMX287 or VF610. This patch set uses common FEC and DSA code.
>
> This code provides _very_ basic switch functionality (packet
It was observed that sending data via batadv over vxlan (on top of
wireguard) reduced the performance massively compared to raw ethernet or
batadv on raw ethernet. A check of perf data showed that the
vxlan_build_skb was calling all the time pskb_expand_head to allocate
enough headroom for:
min_
While vxlan doesn't need any extra tailroom, the lowerdev might need it. In
that case, copy it over to reduce the chance for additional (re)allocations
in the transmit path.
Signed-off-by: Sven Eckelmann
---
drivers/net/vxlan.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/vx
<20201120120235.1925e...@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
I would indeed like to become the maintainer of this driver,
as I do in fact still have working hardware using this code
(a Realtek 8029AS).
Unfortunately, i am still considering myself too inexperienced in
kernel development
On Wed, Nov 25, 2020 at 08:25:11PM -0600, George McCollister wrote:
> > > + {XRS_RX_UNDERSIZE_L, "rx_undersize"},
> > > + {XRS_RX_FRAGMENTS_L, "rx_fragments"},
> > > + {XRS_RX_OVERSIZE_L, "rx_oversize"},
> > > + {XRS_RX_JABBER_L, "rx_jabber"},
> > > + {XRS_RX_ERR_L, "rx_err"},
>
On 2020-11-26 12:03 a.m., Cong Wang wrote:
On Wed, Nov 25, 2020 at 11:11 AM Jakub Kicinski wrote:
On Wed, 25 Nov 2020 12:01:23 +0800 we...@ucloud.cn wrote:
From: wenxu
Currently kernel tc subsystem can do conntrack in cat_ct. But when several
fragment packets go through the act_ct, function
I got a memleak report when doing fault-inject test:
unreferenced object 0x88810ace9000 (size 1024):
comm "ip", pid 4622, jiffies 4295457037 (age 43.378s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 0
[Sorry, I did not know where and how to import the thread, and only got
the first message from Patchwork.]
Dear Linux folks,
Am 25.06.20 um 18:52 schrieb Wolfram Sang:
Missing this firmware is not fatal, my wifi card still works. Even more,
I couldn't find any documentation what it is or whe
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ath/wil6210/wmi.c:279: warning: Function parameter or
member 'ptr_' not described in 'wmi_buffer_block'
drivers/net/wireless/ath/wil6210/wmi.c:279: warning: Excess function parameter
'ptr' description in 'wmi_buffer_block'
[Last batch!]
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
v2:
- Unify rtw_pci_(probe,remove,shutdown}() prototypses
- Suggested-by: Brian Norris
Lee Jones (17):
wil6210: wmi: Correct m
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ath/ath9k/ar9330_1p1_initvals.h:1013:18: warning:
‘ar9331_common_tx_gain_offset1_1’ defined but not used
[-Wunused-const-variable=]
Cc: QCA ath9k Development
Cc: Kalle Valo
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: li
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ath/ath9k/ar9485_initvals.h:1009:18: warning:
‘ar9485_fast_clock_1_1_baseband_postamble’ defined but not used
[-Wunused-const-variable=]
Cc: QCA ath9k Development
Cc: Kalle Valo
Cc: "David S. Miller"
Cc: Jakub Kicinski
C
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ath/ath9k/ar9340_initvals.h:624:18: warning:
‘ar9340Modes_ub124_tx_gain_table_1p0’ defined but not used
[-Wunused-const-variable=]
Cc: QCA ath9k Development
Cc: Kalle Valo
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: lin
There are only a couple of these and none of them are conformant.
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ath/dfs_pri_detector.c:39: warning: Function parameter or
member 'head' not described in 'pulse_elem'
drivers/net/wireless/ath/dfs_pri_detector.c:46: warning:
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/fw/dbg.c:1932: warning: Function parameter
or member 'reg_data' not described in 'iwl_dump_ini_mem'
drivers/net/wireless/intel/iwlwifi/fw/dbg.c:1932: warning: Excess function
parameter 'reg' description in 'iwl
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/fw/acpi.c:123: warning: Function parameter
or member 'dev' not described in 'iwl_acpi_get_dsm_object'
drivers/net/wireless/intel/iwlwifi/fw/acpi.c:123: warning: Function parameter
or member 'rev' not described
Also strip out other duplicates from driver specific headers.
Ensure 'main.h' is explicitly included in 'pci.h' since the latter
uses some defines from the former. It avoids issues like:
from drivers/net/wireless/realtek/rtw88/rtw8822be.c:5:
drivers/net/wireless/realtek/rtw88/pci.h:209:28: err
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/iwl-eeprom-parse.c:340: warning: cannot
understand function prototype: 'struct iwl_eeprom_enhanced_txpwr '
Cc: Johannes Berg
Cc: Emmanuel Grumbach
Cc: Luca Coelho
Cc: Intel Linux Wireless
Cc: Kalle Valo
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ath/ath9k/dynack.c:52: warning: Function parameter or
member 'old' not described in 'ath_dynack_ewma'
drivers/net/wireless/ath/ath9k/dynack.c:52: warning: Function parameter or
member 'new' not described in 'ath_dynack_ewma'
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/iwl-phy-db.c:97: warning: Function
parameter or member 'trans' not described in 'iwl_phy_db'
Cc: Johannes Berg
Cc: Emmanuel Grumbach
Cc: Luca Coelho
Cc: Intel Linux Wireless
Cc: Kalle Valo
Cc: "David S. Mil
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ath/ath9k/ar5008_phy.c:119: warning: Function parameter
or member 'rfBuf' not described in 'ar5008_hw_phy_modify_rx_buffer'
drivers/net/wireless/ath/ath9k/ar5008_phy.c:119: warning: Function parameter
or member 'reg32' not d
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ath/regd.c:378: warning: Function parameter or member
'reg' not described in 'ath_reg_apply_ir_flags'
Cc: Kalle Valo
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Si
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/iwl-eeprom-read.c:347: warning: Function
parameter or member 'trans' not described in 'iwl_read_eeprom'
drivers/net/wireless/intel/iwlwifi/iwl-eeprom-read.c:347: warning: Function
parameter or member 'eeprom' n
Also add documentation for 'mvm'.
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:400: warning: cannot understand
function prototype: 'const u16 expected_tpt_legacy[IWL_RATE_COUNT] = '
drivers/net/wireless/intel/iwlwifi/mvm/rs.c:684: warning: Functi
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ath/dfs_pattern_detector.c:34: warning: Function
parameter or member 'region' not described in 'radar_types'
drivers/net/wireless/ath/dfs_pattern_detector.c:141: warning: Function
parameter or member 'region' not described i
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ath/ath9k/ar9003_2p2_initvals.h:1734:18: warning:
‘ar9300PciePhy_clkreq_disable_L1_2p2’ defined but not used
[-Wunused-const-variable=]
drivers/net/wireless/ath/ath9k/ar9003_2p2_initvals.h:1727:18: warning:
‘ar9300PciePhy_c
Fixes the following W=1 kernel build warning(s):
drivers/net/ethernet/smsc/smc91x.c:2200: warning: Function parameter or member
'dev' not described in 'try_toggle_control_gpio'
drivers/net/ethernet/smsc/smc91x.c:2200: warning: Function parameter or member
'desc' not described in 'try_toggle_co
Resending the stragglers.
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
Lee Jones (8):
net: ethernet: smsc: smc91x: Demote non-conformant kernel function
header
net: xen-netback: xenbus
Fixes the following W=1 kernel build warning(s):
drivers/net/ethernet/ti/am65-cpts.c:736: warning: Function parameter or member
'en' not described in 'am65_cpts_rx_enable'
drivers/net/ethernet/ti/am65-cpts.c:736: warning: Excess function parameter
'skb' description in 'am65_cpts_rx_enable'
Cc
Fixes the following W=1 kernel build warning(s):
drivers/net/ethernet/ti/am65-cpsw-qos.c:364: warning: Function parameter or
member 'ndev' not described in 'am65_cpsw_timer_set'
drivers/net/ethernet/ti/am65-cpsw-qos.c:364: warning: Function parameter or
member 'est_new' not described in 'am65_
Fixes the following W=1 kernel build warning(s):
drivers/net/ethernet/toshiba/ps3_gelic_net.c:1107: warning: Function parameter
or member 'irq' not described in 'gelic_card_interrupt'
drivers/net/ethernet/toshiba/ps3_gelic_net.c:1107: warning: Function parameter
or member 'ptr' not described i
Fixes the following W=1 kernel build warning(s):
drivers/net/xen-netback/xenbus.c:419: warning: Function parameter or member
'dev' not described in 'frontend_changed'
drivers/net/xen-netback/xenbus.c:419: warning: Function parameter or member
'frontend_state' not described in 'frontend_changed
Fixes the following W=1 kernel build warning(s):
from drivers/net/ethernet/ibm/ibmvnic.c:35:
inlined from ‘handle_vpd_rsp’ at drivers/net/ethernet/ibm/ibmvnic.c:4124:3:
drivers/net/ethernet/ibm/ibmvnic.c:1362: warning: Function parameter or member
'hdr_data' not described in 'build_hdr_data'
Fixes the following W=1 kernel build warning(s):
drivers/net/ethernet/toshiba/spider_net.c:263: warning: Function parameter or
member 'hwdescr' not described in 'spider_net_get_descr_status'
drivers/net/ethernet/toshiba/spider_net.c:263: warning: Excess function
parameter 'descr' description i
Fixes the following W=1 kernel build warning(s):
from drivers/net/ethernet/ibm/ibmvnic.c:35:
inlined from ‘handle_vpd_rsp’ at drivers/net/ethernet/ibm/ibmvnic.c:4124:3:
drivers/net/ethernet/ibm/ibmvnic.c:1362: warning: Function parameter or member
'hdr_field' not described in 'build_hdr_data'
On Wed, Nov 25, 2020 at 09:34:29PM +0100, Andrew Lunn wrote:
> > +static struct sk_buff *xrs700x_rcv(struct sk_buff *skb, struct net_device
> > *dev,
> > + struct packet_type *pt)
> > +{
> > + int source_port;
> > + u8 *trailer;
> > +
> > + if (skb_linearize(skb)
On Thu, Nov 26, 2020 at 03:50:04PM +0200, Vladimir Oltean wrote:
> On Wed, Nov 25, 2020 at 09:34:29PM +0100, Andrew Lunn wrote:
> > > +static struct sk_buff *xrs700x_rcv(struct sk_buff *skb, struct
> > > net_device *dev,
> > > +struct packet_type *pt)
> > > +{
> > > + i
Add health reporters for RVU NPA block.
NPA Health reporters handle following HW event groups
- GENERAL events
- ERROR events
- RAS events
- RVU event
An event counter per event is maintained in SW.
Output:
# devlink health
pci/0002:01:00.0:
reporter hw_npa
state healthy error 0 reco
Add health reporters for RVU NIX block.
NIX Health reporter handle following HW event groups
- GENERAL events
- RAS events
- RVU event
An event counter per event is maintained in SW.
Output:
# devlink health
pci/0002:01:00.0:
reporter hw_npa
state healthy error 0 recover 0
reporter
Add devlink support to AF driver. Basic devlink support is added.
Currently info_get is the only supported devlink ops.
devlink ouptput looks like this
# devlink dev
pci/0002:01:00.0
# devlink dev info
pci/0002:01:00.0:
driver octeontx2-af
versions:
fixed:
mbox version: 9
Si
Add basic devlink and devlink health reporters.
Devlink health reporters are added for NPA and NIX blocks.
These reporters report the error count in respective blocks.
Address Jakub's comment to add devlink support for error reporting.
https://www.spinics.net/lists/netdev/msg670712.html
Change-
When NET_DEVLINK is not selected, we get the following build error:
ld: drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.o: in function
`dpaa2_eth_rx_err':
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c:554: undefined reference to
`devlink_trap_report'
ld: drivers/net/ethernet/freescale/dpaa2/dp
On Tue, Nov 24, 2020 at 7:17 PM Jakub Kicinski wrote:
>
> Applied both, thank you!
Thank you Jakub !
If an msk listener receives an MPJ carrying an invalid token, it
will zero the request socket msk entry. That should later
cause fallback and subflow reset - as per RFC - at
subflow_syn_recv_sock() time due to failing hmac validation.
Since commit 4cf8b7e48a09 ("subflow: introduce and use
mptcp_ca
On Thu, Nov 26, 2020 at 11:51:19AM +0100, Jesper Dangaard Brouer wrote:
> On Thu, 26 Nov 2020 16:43:25 +0800
> Hangbin Liu wrote:
>
> > Current sample test xdp_redirect_map only count pkts on ingress. But we
> > can't know whether the pkts are redirected or dropped. So add a counter
> > on egress
On 11/26/20, Jakub Kicinski wrote:
> On Tue, 24 Nov 2020 15:24:21 +0300 Denis Kirjanov wrote:
>> in the case of the socket which is bound to an adress
>> there is no sense to create a path in the next attempts
>
>> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
>> index 41c3303c3357..fd76a8f
Hi Jakub, Sergej,
On Tue, Nov 3, 2020 at 8:41 PM Jakub Kicinski wrote:
>
> On Mon, 2 Nov 2020 01:35:55 +0300 Sergej Bauer wrote:
> > This is the 3rd revision of the patch fix for potential null pointer
> > dereference
> > with lan743x card.
>
> Applied, thanks!
I noticed that this went into ne
On 11/25/2020 4:18 PM, Andrew Lunn wrote:
External email: Use caution opening links or attachments
OK, we will add API options to select bank and page to read any specific
page the user selects. So advanced user will use it get the optional pages
he needs, but what about non advanced user wh
On Thu, Nov 26, 2020 at 03:01:26PM +0100, Andrew Lunn wrote:
> On Thu, Nov 26, 2020 at 03:50:04PM +0200, Vladimir Oltean wrote:
> > On Wed, Nov 25, 2020 at 09:34:29PM +0100, Andrew Lunn wrote:
> > > > +static struct sk_buff *xrs700x_rcv(struct sk_buff *skb, struct
> > > > net_device *dev,
> > > >
Stephen Rothwell writes:
> Hi all,
>
> Today's linux-next merge of the userns tree got a conflict in:
>
> kernel/bpf/task_iter.c
>
> between commit:
>
> 91b2db27d3ff ("bpf: Simplify task_file_seq_get_next()")
>
> from the bpf-next tree and commit:
>
> edc52f17257a ("bpf/task_iter: In task_f
> > What is not yet clear to me is how you direct frames out specific
> > interfaces. This is where i think we hit problems. I don't see a
> > generic mechanism, which is probably why Lukasz put tagger as None.
>
> I've put the "None" tag just to share the "testable" RFC code.
Tagging is a core
Hi Tom,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Tom-Parkin/add-ppp_generic-ioctl-s-to-bridge-channels/20201126-202933
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net
On Wed, Nov 25, 2020 at 11:44 PM Edward Cree wrote:
>
> To make the intent clear, you have to first be certain that you
> understand the intent; otherwise by adding either a break or a
> fallthrough to suppress the warning you are just destroying the
> information that "the intent of this code
From: Zhu Yanjun
The functions xsk_map_put and xsk_map_inc are simple wrappers.
As such, replacing these functions with the functions bpf_map_inc
and bpf_map_put and removing some test codes.
Fixes: d20a1676df7e ("xsk: Move xskmap.c to net/xdp/")
Signed-off-by: Zhu Yanjun
---
net/xdp/xsk.c
Hi,
I was looking at usbnet_get_link_ksettings() and it seems in hindsight
that the idea it rests upon makes an assumption about the hardware
that was at the time it was introduced was often true, but today
isn't.
struct usbnet contains a member struct mii_if_info. Why? That makes
a pretty strong
From: Zhu Yanjun
The functions xsk_map_put and xsk_map_inc are simple wrappers.
As such, replacing these functions with the functions bpf_map_inc
and bpf_map_put and removing some test codes.
Fixes: d20a1676df7e ("xsk: Move xskmap.c to net/xdp/")
Signed-off-by: Zhu Yanjun
---
net/xdp/xsk.c
From: Willem de Bruijn
When setting sk_err, set it to ee_errno, not ee_origin.
Commit f5f99309fa74 ("sock: do not set sk_err in
sock_dequeue_err_skb") disabled updating sk_err on errq dequeue,
which is correct for most error types (origins):
- sk->sk_err = err;
Commit 38b257938ac6 ("so
> > If i was implementing the ethtool side of it, i would probably do some
> > sort of caching system. We know page 0 should always exist, so
> > pre-load that into the cache. Try the netlink API first. If that
> > fails, use the ioctl interface. If the ioctl is used, put everything
> > returned in
Hi Paolo,
On 26/11/2020 15:17, Paolo Abeni wrote:
If an msk listener receives an MPJ carrying an invalid token, it
will zero the request socket msk entry. That should later
cause fallback and subflow reset - as per RFC - at
subflow_syn_recv_sock() time due to failing hmac validation.
Since comm
Hi Miguel,
On Thu, Nov 26, 2020 at 3:54 PM Miguel Ojeda
wrote:
> On Wed, Nov 25, 2020 at 11:44 PM Edward Cree wrote:
> > To make the intent clear, you have to first be certain that you
> > understand the intent; otherwise by adding either a break or a
> > fallthrough to suppress the warning yo
From: Bongsu Jeon
The delay of 20ms is enough to enable and
wake up the Samsung's nfc chip.
Signed-off-by: Bongsu Jeon
---
drivers/nfc/s3fwrn5/i2c.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/nfc/s3fwrn5/i2c.c b/drivers/nfc/s3fwrn5/i2c.c
index ae26594..9a
From: Bongsu Jeon
Extract the common phy blocks to reuse it.
The UART module will use the common blocks.
Signed-off-by: Bongsu Jeon
---
drivers/nfc/s3fwrn5/i2c.c| 111 ---
drivers/nfc/s3fwrn5/phy_common.h | 86 ++
2 files
From: Krzysztof Kozlowski
GPIOs - as returned by of_get_named_gpio() and used by the gpiolib - are
signed integers, where negative number indicates error. The return
value of of_get_named_gpio() should not be assigned to an unsigned int
because in case of !CONFIG_GPIOLIB such number would be a v
On Thu, Nov 26, 2020 at 05:37:22PM +0200, Baruch Siach wrote:
> Hi netdev list,
>
> I am trying to retrieve all MAC supported link modes
> (ETHTOOL_LINK_MODE_*) for network interfaces with SFP port. The
> 'supported' bit mask that ETHTOOL_GLINKSETTINGS provides in
> link_mode_masks[] changes to ma
Hi netdev list,
I am trying to retrieve all MAC supported link modes
(ETHTOOL_LINK_MODE_*) for network interfaces with SFP port. The
'supported' bit mask that ETHTOOL_GLINKSETTINGS provides in
link_mode_masks[] changes to match the SFP module that happens to be
plugged in. When no SFP module is pl
On Thu, Nov 26, 2020 at 05:37:22PM +0200, Baruch Siach wrote:
> Hi netdev list,
>
> I am trying to retrieve all MAC supported link modes
> (ETHTOOL_LINK_MODE_*) for network interfaces with SFP port. The
> 'supported' bit mask that ETHTOOL_GLINKSETTINGS provides in
> link_mode_masks[] changes to ma
On Thu, Nov 26, 2020 at 02:09:33PM +, Sudeep Holla wrote:
> When NET_DEVLINK is not selected, we get the following build error:
[...]
>
> Commit f6b19b354d50 ("net: devlink: select NET_DEVLINK from drivers")
> selected NET_DEVLINK from several drivers and rely on the functions
> being there.
>
Hi Andrew,
On Thu, Nov 26 2020, Andrew Lunn wrote:
> On Thu, Nov 26, 2020 at 05:37:22PM +0200, Baruch Siach wrote:
>> I am trying to retrieve all MAC supported link modes
>> (ETHTOOL_LINK_MODE_*) for network interfaces with SFP port. The
>> 'supported' bit mask that ETHTOOL_GLINKSETTINGS provides
On Thu, Nov 26, 2020 at 10:56:12AM +0100, Toke Høiland-Jørgensen wrote:
> Roman Gushchin writes:
>
> > On Thu, Nov 26, 2020 at 01:21:41AM +0100, Daniel Borkmann wrote:
> >> On 11/25/20 4:00 AM, Roman Gushchin wrote:
> >> > In the absolute majority of cases if a process is making a kernel
> >> > a
1 - 100 of 189 matches
Mail list logo
