On 6/20/20 12:36 AM, Andrew Lunn wrote:
>> I've run into the same issue. To resolve it, In my case, in the same file,
>> I've had to send all IGMP control traffic to the CPU:
>> skb->offload_fwd_mark = 1;
>> switch (ih->type) {
>> case IGMP_HOST_MEMBERSHIP_REPORT:
>>
Hi Geert,
Am 19.06.20 um 21:15 schrieb Geert Uytterhoeven:
> Some EtherAVB variants support internal clock delay configuration, which
> can add larger delays than the delays that are typically supported by
> the PHY (using an "rgmii-*id" PHY mode, and/or "[rt]xc-skew-ps"
> properties).
>
> Add pro
Hi Andrew,
Thanks a lot for the quick reply!
On 6/19/20 11:58 PM, Andrew Lunn wrote:
> On Fri, Jun 19, 2020 at 11:31:04PM +0200, Daniel Mack wrote:
>> When an IGMP query enters the switch, it is redirected to the CPU port
>> as all 'external' ports are configured for IGMP/MLP snooping by the
>>
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2
Nothing should be using this macro, and the entire idea of tricking the
compiler into silencing such warnings is a mistake.
Signed-off-by: Kees Cook
---
Documentation/process/deprecated.rst | 18 ++
1 file changed, 18 insertions(+)
diff --git a/Documentation/process/deprecated.r
From: Jason Yan
This is an effort to eliminate the uninitialized_var() macro[1].
The use of this macro is the wrong solution because it forces off ANY
analysis by the compiler for a given variable. It even masks "unused
variable" warnings.
Quoted from Linus[2]:
"It's a horrible thing to use, i
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings
(e.g. "unused variable"). If the compiler thinks it is uninitialized,
either simply initialize the variable or make compiler changes.
In preparation for removing
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings
(e.g. "unused variable"). If the compiler thinks it is uninitialized,
either simply initialize the variable or make compiler changes.
As recommended[2] by[3] Lin
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings
(e.g. "unused variable"). If the compiler thinks it is uninitialized,
either simply initialize the variable or make compiler changes.
I preparation for removing[
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2
On Fri, Jun 19, 2020 at 5:51 PM Zefan Li wrote:
>
> 在 2020/6/20 8:45, Zefan Li 写道:
> > On 2020/6/20 3:51, Cong Wang wrote:
> >> On Thu, Jun 18, 2020 at 11:40 PM Zefan Li wrote:
> >>>
> >>> On 2020/6/19 5:09, Cong Wang wrote:
> On Thu, Jun 18, 2020 at 12:36 PM Roman Gushchin wrote:
> >
>
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2
v2:
- more special-cased fixes
- add reviews
v1: https://lore.kernel.org/lkml/20200603233203.1695403-1-keesc...@chromium.org
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings
(e.g. "unused variable"). If the com
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2
From: Willem de Bruijn
Date: Thu, 18 Jun 2020 12:40:43 -0400
> From: Willem de Bruijn
>
> The ETF qdisc can queue skbs that it could not pace on the errqueue.
>
> Address a few issues in the selftest
>
> - recv buffer size was too small, and incorrectly calculated
> - compared errno to ee_cod
From: Thomas Falcon
Date: Thu, 18 Jun 2020 10:43:46 -0500
> The max MTU limit defined for ibmveth is not accounting for
> virtual ethernet buffer overhead, which is twenty-two additional
> bytes set aside for the ethernet header and eight additional bytes
> of an opaque handle reserved for use by
From: Russell King
Date: Thu, 18 Jun 2020 16:38:51 +0100
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 7653277d03b7..8c8314715efd 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethern
From: "Gustavo A. R. Silva"
Date: Thu, 18 Jun 2020 09:53:42 -0500
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
>
> This code was detected with the help of Coccinelle and, audited and
> fixed manually.
>
> Signed-off-by:
From: "Gustavo A. R. Silva"
Date: Thu, 18 Jun 2020 09:46:48 -0500
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes. Also, remove unnecessary
> variable _size_.
>
> This code was detected with the help of Coccinelle and, audit
From: Russell King - ARM Linux admin
Date: Thu, 18 Jun 2020 14:45:00 +0100
> Last time this series was posted back in May, Florian reviewed the
> patches, which was the only feedback I received. I'm now posting
> them without the RFC tag.
>
> This series aims to improve the probing for Clause 4
From: "Gustavo A. R. Silva"
Date: Thu, 18 Jun 2020 08:35:00 -0500
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
>
> This code was detected with the help of Coccinelle and, audited and
> fixed manually.
>
> Signed-off-by:
From: Zheng Bin
Date: Thu, 18 Jun 2020 21:26:29 +0800
> macvlan_changelink_sources
> if (addr)
> ret = macvlan_hash_add_source(vlan, addr)
> nla_for_each_attr(nla, head, len, rem)
> ret = macvlan_hash_add_source(vlan, addr)
> -->If fail, need to free previous malloc memory
>
> Fi
From: we...@ucloud.cn
Date: Thu, 18 Jun 2020 20:49:07 +0800
> From: wenxu
>
> v2:
> patch2: store the cb_priv of representor to the flow_block_cb->indr.cb_priv
> in the driver. And make the correct check with the statments
> this->indr.cb_priv == cb_priv
>
> patch4: del the driver list only in
From: Sabrina Dubroca
Date: Thu, 18 Jun 2020 12:13:22 +0200
> Currently, trying to change the DF parameter of a geneve device does
> nothing:
>
> # ip -d link show geneve1
> 14: geneve1:
> link/ether
> geneve id 1 remote 10.0.0.1 ttl auto df set dstport 6081
> # ip
From: Claudiu Manoil
Date: Thu, 18 Jun 2020 12:16:52 +0300
> VLAN tag insertion/extraction offload is correctly
> activated at probe time but deactivation of this feature
> (i.e. via ethtool) is broken. Toggling works only for
> Tx/Rx ring 0 of a PF, and is ignored for the other rings,
> includi
On Fri, Jun 19, 2020 at 6:14 PM Roman Gushchin wrote:
>
> On Sat, Jun 20, 2020 at 09:00:40AM +0800, Zefan Li wrote:
> > I think so, though I'm not familiar with the bfp cgroup code.
> >
> > > If so, we might wanna fix it in a different way,
> > > just checking if (!(css->flags & CSS_NO_REF)) in cg
From: Claudiu Beznea
Date: Thu, 18 Jun 2020 11:37:40 +0300
> Undo previously done operation in case macb_phylink_connect()
> fails. Since macb_reset_hw() is the 1st undo operation the
> napi_exit label was renamed to reset_hw.
>
> Fixes: 7897b071ac3b ("net: macb: convert to phylink")
> Signed-of
From: David Howells
Date: Thu, 18 Jun 2020 08:50:15 +0100
>
> Here are three fixes for rxrpc:
>
> (1) Fix a trace symbol mapping. It doesn't seem to let you map to "".
>
> (2) Fix the handling of the remote receive window size when it increases
> beyond the size we can support for our
>>> If so, we might wanna fix it in a different way,
>>> just checking if (!(css->flags & CSS_NO_REF)) in cgroup_bpf_put()
>>> like in cgroup_put(). It feels more reliable to me.
>>>
>>
>> Yeah I also have this idea in my mind.
>
> I wonder if the following patch will fix the issue?
>
I guess so
t4_prep_fw goto bye tag with positive return value when something
bad happened and which can not free resource in adap_init0.
so fix it to return negative value.
Fixes: 16e47624e76b ("cxgb4: Add new scheme to update T4/T5 firmware")
Reported-by: Hulk Robot
Signed-off-by: Li Heng
Signed-off-by: J
From: Кочетков Максим
Date: Sat, 20 Jun 2020 00:31:29 +0300
> It is based on 5.7.0
You need to post your patches against the tree onto which it
will be applied, which in this case is net-next.
On Thu, Jun 18, 2020 at 02:25:33PM +0530, Manivannan Sadhasivam wrote:
> Hi,
>
> On 0611, Marc Kleine-Budde wrote:
> > On 6/10/20 9:44 AM, Manivannan Sadhasivam wrote:
> > > Hello,
> > >
> > > This series adds CAN network driver support for Microchip MCP25XXFD CAN
> > > Controller with MCP2517FD
On 6/19/20 12:13 PM, Davide Caratti wrote:
hello Ariel,
(I'm doing a resend because I suspect that my original reply was dropped
somewhere).
Thanks for your patch! some comments/questions below:
On Fri, 2020-06-19 at 01:15 +0300, Ariel Levkovich wrote:
Allow setting a hash value to a packet f
in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Lorenzo-Bianconi/mt76-mt76x2-fix-pci-suspend/20200618-192056
base:
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git
master
config: x86_64-randconfig-a013-20200619
The user tool modinfo is used to get information on kernel modules, including a
description where it is available.
This patch adds a brief MODULE_DESCRIPTION to the following modules:
9p
drop_monitor
esp4_offload
esp6_offload
fou
fou6
ila
sch_fq
sch_fq_codel
sch_hhf
Signed-off-by: Rob Gill
---
-next.git
0fb9fbab405351aa0c18973881c4103e4da886b6
config: nds32-randconfig-r002-20200619 (attached as .config)
compiler: nds32le-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
2020-06-19 16:17 UTC-0700 ~ Andrii Nakryiko
> Add statements about bpftool being able to discover process info, holding
> reference to BPF map, prog, link, or BTF. Show example output as well.
>
> Signed-off-by: Andrii Nakryiko
Reviewed-by: Quentin Monnet
Thanks!
2020-06-19 16:17 UTC-0700 ~ Andrii Nakryiko
> Add bpf_iter-based way to find all the processes that hold open FDs against
> BPF object (map, prog, link, btf). bpftool always attempts to discover this,
> but will silently give up if kernel doesn't yet support bpf_iter BPF programs.
> Process name a
On Sat, Jun 20, 2020 at 09:00:40AM +0800, Zefan Li wrote:
> On 2020/6/20 8:51, Roman Gushchin wrote:
> > On Fri, Jun 19, 2020 at 02:40:19PM +0800, Zefan Li wrote:
> >> On 2020/6/19 5:09, Cong Wang wrote:
> >>> On Thu, Jun 18, 2020 at 12:36 PM Roman Gushchin wrote:
>
> On Thu, Jun 18, 202
On 2020/6/20 8:51, Roman Gushchin wrote:
> On Fri, Jun 19, 2020 at 02:40:19PM +0800, Zefan Li wrote:
>> On 2020/6/19 5:09, Cong Wang wrote:
>>> On Thu, Jun 18, 2020 at 12:36 PM Roman Gushchin wrote:
On Thu, Jun 18, 2020 at 12:19:13PM -0700, Cong Wang wrote:
> On Wed, Jun 17, 2020 at
在 2020/6/20 8:45, Zefan Li 写道:
> On 2020/6/20 3:51, Cong Wang wrote:
>> On Thu, Jun 18, 2020 at 11:40 PM Zefan Li wrote:
>>>
>>> On 2020/6/19 5:09, Cong Wang wrote:
On Thu, Jun 18, 2020 at 12:36 PM Roman Gushchin wrote:
>
> On Thu, Jun 18, 2020 at 12:19:13PM -0700, Cong Wang wrote:
>
On Fri, Jun 19, 2020 at 02:40:19PM +0800, Zefan Li wrote:
> On 2020/6/19 5:09, Cong Wang wrote:
> > On Thu, Jun 18, 2020 at 12:36 PM Roman Gushchin wrote:
> >>
> >> On Thu, Jun 18, 2020 at 12:19:13PM -0700, Cong Wang wrote:
> >>> On Wed, Jun 17, 2020 at 6:44 PM Zefan Li wrote:
>
> Cc: R
On 2020/6/20 3:51, Cong Wang wrote:
> On Thu, Jun 18, 2020 at 11:40 PM Zefan Li wrote:
>>
>> On 2020/6/19 5:09, Cong Wang wrote:
>>> On Thu, Jun 18, 2020 at 12:36 PM Roman Gushchin wrote:
On Thu, Jun 18, 2020 at 12:19:13PM -0700, Cong Wang wrote:
> On Wed, Jun 17, 2020 at 6:44 PM Ze
-next.git
0fb9fbab405351aa0c18973881c4103e4da886b6
config: riscv-randconfig-r033-20200619 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
487ca07fcc75d52755c9fe2ee05bcb3b6c44)
reproduce (this is a W=1 build):
wget
https
Adding hci_dev_lock since hci_conn_params_(lookup|add) require this
lock.
Suggested-by: Miao-chen Chou
Signed-off-by: Abhishek Pandit-Subedi
---
net/bluetooth/mgmt.c | 8
1 file changed, 8 insertions(+)
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 2a732cab1dc99d..5e
On Wed, Jun 17, 2020 at 10:35:28AM +0200, Roger Pau Monné wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
>
>
>
> On Tue, Jun 16, 2020 at 09:49:25PM +, Ancha
On Fri, Jun 19, 2020 at 3:21 PM Daniel Borkmann wrote:
>
> On 6/19/20 8:41 PM, Andrii Nakryiko wrote:
> > On Fri, Jun 19, 2020 at 6:08 AM Daniel Borkmann
> > wrote:
> >> On 6/19/20 2:39 AM, John Fastabend wrote:
> >>> John Fastabend wrote:
> Andrii Nakryiko wrote:
> > On Thu, Jun 18, 20
bpf_object__find_program_by_title(), used by CO-RE relocation code, doesn't
return .text "BPF program", if it is a function storage for sub-programs.
Because of that, any CO-RE relocation in helper non-inlined functions will
fail. Fix this by searching for .text-corresponding BPF program manually.
Extend xdp_redirect_cpu_{usr,kern}.c adding the possibility to load
a XDP program on cpumap entries. The following options have been added:
- mprog-name: cpumap entry program name
- mprog-filename: cpumap entry program filename
- redirect-device: output interface if the cpumap program performs a
As for DEVMAP, support SEC("xdp_cpumap*") as a short cut for loading
the program with type BPF_PROG_TYPE_XDP and expected attach type
BPF_XDP_CPUMAP.
Signed-off-by: Lorenzo Bianconi
---
tools/lib/bpf/libbpf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/lib/bpf/libbpf.c b/tools/li
Introduce XDP_REDIRECT support for eBPF programs attached to cpumap
entries.
This patch has been tested on Marvell ESPRESSObin using a modified
version of xdp_redirect_cpu sample in order to attach a XDP program
to CPUMAP entries to perform a redirect on the mvneta interface.
In particular the foll
Similar to what have been done for DEVMAP, introduce tests to verify
ability to add a XDP program to an entry in a CPUMAP.
Verify CPUMAP programs can not be attached to devices as a normal
XDP program, and only programs with BPF_XDP_CPUMAP attach type can
be loaded in a CPUMAP.
Signed-off-by: Lore
Add infrastructure to l3mdev (the core code for Layer 3 master devices) in
order to find out the corresponding VRF device for a given table id.
Therefore, the l3mdev implementations:
- can register a callback that returns the device index of the l3mdev
associated with a given table id;
- can o
From: David Ahern
Move the guts of xdp_convert_buff_to_frame to a new helper,
xdp_update_frame_from_buff so it can be reused removing code duplication
Suggested-by: Jesper Dangaard Brouer
Co-developed-by: Lorenzo Bianconi
Signed-off-by: Lorenzo Bianconi
Signed-off-by: David Ahern
---
includ
Add the data structures and the processing logic to keep track of the
associations between VRF devices and routing tables.
When a VRF is instantiated, it needs to refer to a given routing table.
For each table, we explicitly keep track of the existing VRFs that refer to
the table.
Signed-off-by: A
The new strict mode functionality is tested in different configurations and
on different network namespaces.
Signed-off-by: Andrea Mayer
---
.../selftests/net/vrf_strict_mode_test.sh | 390 ++
1 file changed, 390 insertions(+)
create mode 100755 tools/testing/selftests/net/v
During the initialization phase of the VRF module, the callback for table
to VRF device lookup is registered in l3mdev.
Signed-off-by: Andrea Mayer
---
drivers/net/vrf.c | 59 +++
1 file changed, 55 insertions(+), 4 deletions(-)
diff --git a/drivers/n
As it has been already done for devmap, introduce 'struct bpf_cpumap_val'
to formalize the expected values that can be passed in for a CPUMAP.
Update cpumap code to use the struct.
Signed-off-by: Lorenzo Bianconi
---
include/uapi/linux/bpf.h | 9 +
kernel/bpf/cpumap.c|
Introduce the capability to attach an eBPF program to cpumap entries.
The idea behind this feature is to add the possibility to define on
which CPU run the eBPF program if the underlying hw does not support
RSS. Current supported verdicts are XDP_DROP and XDP_PASS.
This patch has been tested on Ma
Similar to what David Ahern proposed in [1] for DEVMAPs, introduce the
capability to attach and run a XDP program to CPUMAP entries.
The idea behind this feature is to add the possibility to define on which CPU
run the eBPF program if the underlying hw does not support RSS.
I respin patch 1/6 from
Do not update xdp_redirect_cpu maps running while option loop but
defer it after all available options have been parsed. This is a
preliminary patch to pass the program name we want to attach to the
map entries as a user option
Signed-off-by: Lorenzo Bianconi
---
samples/bpf/xdp_redirect_cpu_use
Add net.vrf.strict_mode sysctl parameter.
When net.vrf.strict_mode=0 (default) it is possible to associate multiple
VRF devices to the same table. Conversely, when net.vrf.strict_mode=1 a
table can be associated to a single VRF device.
When switching from net.vrf.strict_mode=0 to net.vrf.strict_m
This patch set adds the new "strict mode" functionality to the Virtual
Routing and Forwarding infrastructure (VRF). Hereafter we discuss the
requirements and the main features of the "strict mode" for VRF.
On VRF creation, it is necessary to specify the associated routing table used
during the loo
When preallocated service calls are being discarded, they're passed to
->discard_new_call() to have the caller clean up any attached higher-layer
preallocated pieces before being marked completed. However, the act of
marking them completed now invokes the call's notification function - which
cause
> I've run into the same issue. To resolve it, In my case, in the same file,
> I've had to send all IGMP control traffic to the CPU:
> skb->offload_fwd_mark = 1;
> switch (ih->type) {
> case IGMP_HOST_MEMBERSHIP_REPORT:
> case IGMPV2_HOST_MEMBERSHIP_REPORT:
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Andrew Lunn
> Sent: Friday, June 19, 2020 2:58 PM
> To: Daniel Mack
> Cc: netdev@vger.kernel.org; Ido Schimmel; Jiri Pirko; Ivan Vecera; Florian
> Fainelli
> Subject: Re: Quest
On 6/20/20 12:20 AM, Andrii Nakryiko wrote:
Relicense it to be compatible with the rest of bpftool files.
Cc: Song Liu
Suggested-by: Quentin Monnet
Signed-off-by: Andrii Nakryiko
Applied, thanks!
syzbot wrote:
> This crash does not have a reproducer. I cannot test it.
This should do it:
insmod fs/afs/kafs.ko; rmmod kafs
David
On 6/19/20 8:41 PM, Andrii Nakryiko wrote:
On Fri, Jun 19, 2020 at 6:08 AM Daniel Borkmann wrote:
On 6/19/20 2:39 AM, John Fastabend wrote:
John Fastabend wrote:
Andrii Nakryiko wrote:
On Thu, Jun 18, 2020 at 11:58 AM John Fastabend
wrote:
[...]
That would be great. Self-tests do work,
Relicense it to be compatible with the rest of bpftool files.
Cc: Song Liu
Suggested-by: Quentin Monnet
Signed-off-by: Andrii Nakryiko
---
tools/bpf/bpftool/skeleton/profiler.bpf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/bpf/bpftool/skeleton/profiler.bpf.c
On Fri, Jun 19, 2020 at 2:57 PM Hao Luo wrote:
>
> Only two small places on this version, otherwise it looks good to me.
> I can offer my reviewed-by, if need. :)
>
> Thanks for the patch!
>
> Reviewed-by: Hao Luo
>
> On Fri, Jun 19, 2020 at 1:34 PM Andrii Nakryiko wrote:
> >
> > Switch existing
> #syz test:
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
> 559f5964f95ce6096ae0aa858eaee202500ab9ca
This crash does not have a reproducer. I cannot test it.
>
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
559f5964f95ce6096ae0aa858eaee202500ab9ca
#sys dup: net-next test error: KASAN: use-after-free Write in
afs_wake_up_async_call
#syz dup: net-next test error: KASAN: use-after-free Write in
afs_wake_up_async_call
#syz dup: net-next test error: KASAN: use-after-free Write in
afs_wake_up_async_call
On Fri, Jun 19, 2020 at 11:31:04PM +0200, Daniel Mack wrote:
> Hi,
>
> I'm working on a custom board featuring a Marvell mv88e6085 Ethernet
> switch controlled by the Linux DSA driver, and I'm facing an issue with
> IGMP packet flows.
>
> Consider two Ethernet stations, each connected to the swit
Hi,
I'm working on a custom board featuring a Marvell mv88e6085 Ethernet
switch controlled by the Linux DSA driver, and I'm facing an issue with
IGMP packet flows.
Consider two Ethernet stations, each connected to the switch on a
dedicated port. A Linux bridge combines the two ports. In my setup,
From: Florian Fainelli
Date: Fri, 19 Jun 2020 11:47:45 -0700
> This patch series fixes two problems with the current MDIO bus scanning
> logic which was identified while moving from 4.9 to 5.4 on devices that
> do rely on scanning the MDIO bus at runtime because they use pluggable
> cards.
>
> C
From: "Gustavo A. R. Silva"
Date: Fri, 19 Jun 2020 13:10:07 -0500
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
>
> This code was detected with the help of Coccinelle and, audited and
> fixed manually.
>
> Addresses-KSPP
From: "Gustavo A. R. Silva"
Date: Fri, 19 Jun 2020 13:01:49 -0500
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
>
> This code was detected with the help of Coccinelle and, audited and
> fixed manually.
>
> Addresses-KSPP
From: "Gustavo A. R. Silva"
Date: Fri, 19 Jun 2020 12:41:54 -0500
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
>
> This code was detected with the help of Coccinelle and, audited and
> fixed manually.
>
> Addresses-KSPP
From: "Gustavo A. R. Silva"
Date: Fri, 19 Jun 2020 12:37:15 -0500
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes. Also, remove unnecessary
> variable _size_.
>
> This code was detected with the help of Coccinelle and, audit
From: Eric Dumazet
Date: Fri, 19 Jun 2020 10:27:48 -0700
> If IPv6 is builtin, we do not need an expensive indirect call
> to reach cmp6_send().
^
'icmp6_send', I fixed this up for you.
>
> Signed-off-by: Eric Dumazet
Applied, thanks.
From: Andrew Lunn
Date: Fri, 19 Jun 2020 16:58:02 +0200
> On Fri, Jun 19, 2020 at 11:49:01AM +0300, Maxim Kochetkov wrote:
>> This patch series add new PHY id support.
>> Russell King asked to use single style for referencing functions.
>
> Hi Maxim
>
> In future, please put which tree this pat
From: Vishal Kulkarni
Date: Fri, 19 Jun 2020 19:51:34 +0530
> Patch 1: Adds data structure to maintain list of filters and handles
> init/dinit
>of the same.
>
> Patch 2: Handles addition of filters via ETHTOOL_SRXCLSRLINS.
>
> Patch 3: Handles deletion of filtes via ETHTOOL_SRXCLSRLDE
Hello.
On 19.06.20 21:56, David Miller wrote:
From: Stefan Schmidt
Date: Fri, 19 Jun 2020 09:14:22 +0200
I see you marked both patches here as awaiting upstream in
patchwork. I am not really sure what to do best now. Am I supposed to
pick them up myself and send them in my usual ieee802154 pu
Hello Dave.
An update from ieee802154 for your *net* tree.
Just two small maintenance fixes to update references to the new project
homepage.
regards
Stefan Schmidt
The following changes since commit 0ad6f6e767ec2f613418cbc7ebe5ec4c35af540c:
net: increment xmit_recursion level in dev_direct
You are giving no context on what hardware and with what driver
your changes make a difference for.
This kind of context and information is required in order for
anyone to understand your changes.
We're not accepting these changes until you explain all of this.
Thank you.
From: Flavio Suligoi
Date: Fri, 19 Jun 2020 11:02:04 +0200
> Fix typo: "trigered" --> "triggered"
>
> Signed-off-by: Flavio Suligoi
Applied.
From: Flavio Suligoi
Date: Fri, 19 Jun 2020 11:18:11 +0200
> Fix typo: "Triger" --> "Trigger"
>
> Signed-off-by: Flavio Suligoi
Applied.
From: Steffen Klassert
Date: Fri, 19 Jun 2020 09:43:37 +0200
> 1) Fix double ESP trailer insertion in IPsec crypto offload if
>netif_xmit_frozen_or_stopped is true. From Huy Nguyen.
>
> 2) Merge fixup for "remove output_finish indirection from
>xfrm_state_afinfo". From Stephen Rothwell.
From: Stefan Schmidt
Date: Fri, 19 Jun 2020 09:14:22 +0200
> I see you marked both patches here as awaiting upstream in
> patchwork. I am not really sure what to do best now. Am I supposed to
> pick them up myself and send them in my usual ieee802154 pull request?
>
> Before you had been picking
1 - 100 of 285 matches
Mail list logo
