turns the access to struct members like rt_mtu_locked into an OOB read in
> the stack. Fix this changing the temporary variable used for IPv4 packets
> in sch_fragment(), similarly to what is done for IPv6 few lines below.
>
> Fixes: c129412f74e9 ("net/sched: sch_frag: add generic
On Tue, Apr 20, 2021 at 1:59 AM Davide Caratti wrote:
>
> hello Cong, thanks for looking at this!
>
> On Mon, 2021-04-19 at 11:46 -0700, Cong Wang wrote:
> > On Mon, Apr 19, 2021 at 8:24 AM Davide Caratti wrote:
> > > diff --git a/net/sched/sch_frag.c b/net/sched/sch_frag.c
> > > index e1e77d3fb6
hello Cong, thanks for looking at this!
On Mon, 2021-04-19 at 11:46 -0700, Cong Wang wrote:
> On Mon, Apr 19, 2021 at 8:24 AM Davide Caratti wrote:
> > diff --git a/net/sched/sch_frag.c b/net/sched/sch_frag.c
> > index e1e77d3fb6c0..8c06381391d6 100644
> > --- a/net/sched/sch_frag.c
> > +++ b/net
l.com
==
BUG: KASAN: use-after-free in
sctp_do_8_2_transport_strike.constprop.0+0xa27/0xab0
net/sctp/sm_sideeffect.c:531
Read of size 4 at addr 888024d65154 by task swapper/1/0
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.12.0-rc8-syzkaller #0
Hardware name: Google Google Compute E
On Sun, 18 Apr 2021 11:04:16 +0300 Ido Schimmel wrote:
> On Fri, Apr 16, 2021 at 12:27:42PM -0700, Jakub Kicinski wrote:
> > +/**
> > + * struct ethtool_rmon_hist_range - byte range for histogram statistics
> > + * @low: low bound of the bucket (inclusive)
> > + * @high: high bound of the bucket (i
On Mon, Apr 19, 2021 at 8:24 AM Davide Caratti wrote:
> diff --git a/net/sched/sch_frag.c b/net/sched/sch_frag.c
> index e1e77d3fb6c0..8c06381391d6 100644
> --- a/net/sched/sch_frag.c
> +++ b/net/sched/sch_frag.c
> @@ -90,16 +90,16 @@ static int sch_fragment(struct net *net, struct sk_buff
> *skb
On Mon, Apr 19, 2021 at 05:23:44PM +0200, Davide Caratti wrote:
> when 'act_mirred' tries to fragment IPv4 packets that had been previously
> re-assembled using 'act_ct', splats like the following can be observed on
> kernels built with KASAN:
Acked-by: Marcelo Ricardo Leitner
when 'act_mirred' tries to fragment IPv4 packets that had been previously
re-assembled using 'act_ct', splats like the following can be observed on
kernels built with KASAN:
BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60
Read of size 1 at addr 888147009
running openvswitch on kernels built with KASAN, it's possible to see the
following splat while testing fragmentation of IPv4 packets:
BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60
Read of size 1 at addr 888112fc713c by task handler2/1367
CPU: 0 PID: 1367 Comm: han
- patch 1/2 fixes openvswitch IPv4 fragmentation, that does a stack OOB
read after commit d52e5a7e7ca4 ("ipv4: lock mtu in fnhe when received
PMTU < net.ipv4.route.min_pmt")
- patch 2/2 fixes the same issue in TC 'sch_frag' code
Davide Caratti (2):
openvswitch: f
On Fri, 2021-04-16 at 22:29 +0200, Davide Caratti wrote:
[...]
>
> for IPv4 packets, sch_fragment() uses a temporary struct dst_entry. Then,
> in the following call graph:
>
> ip_fragment()
^^ the above line is a typo,
> ip_do_fragment()
> ip_skb_dst_mtu()
> ip_dst_mtu_mayb
On Fri, Apr 16, 2021 at 12:27:42PM -0700, Jakub Kicinski wrote:
> +/**
> + * struct ethtool_rmon_hist_range - byte range for histogram statistics
> + * @low: low bound of the bucket (inclusive)
> + * @high: high bound of the bucket (inclusive)
> + */
> +struct ethtool_rmon_hist_range {
> + u16
when the Linux kernel fragments a packet that was previously re-assembled
by the 'act_ct' action, the following splat can be seen on KASAN kernels:
BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60
Read of size 1 at addr 7f209574 by task ping/5640
CPU: 29 PID:
Most devices maintain RMON (RFC 2819) stats - particularly
the "histogram" of packets received by size. Unlike other
RFCs which duplicate IEEE stats, the short/oversized frame
counters in RMON don't seem to match IEEE stats 1-to-1 either,
so expose those, too. Do not expose basic packet, CRC errors
+533,7 @@ struct ethtool_module_eeprom {
* read.
* @get_eth_phy_stats: Query some of the IEEE 802.3 PHY statistics.
* @get_eth_mac_stats: Query some of the IEEE 802.3 MAC statistics.
+ * @get_eth_ctrl_stats: Query some of the IEEE 802.3 MAC Ctrl statistics.
*
* All operations are optional
rrors;
+};
+
/* Basic IEEE 802.3 PHY statistics (30.3.2.1.*), not otherwise exposed
* via a more targeted API.
*/
@@ -495,6 +523,7 @@ struct ethtool_module_eeprom {
* specified page. Returns a negative error code or the amount of bytes
* read.
* @get_eth_phy_stats: Query some of the
Number of devices maintains the standard-based MAC control
counters for control frames. Add a API for those.
Signed-off-by: Jakub Kicinski
---
include/linux/ethtool.h | 11 ++
include/uapi/linux/ethtool.h | 2 ++
include/uapi/linux/ethtool_netlink.h | 14 +++
TOOL_RMON_HIST_MAX];
+};
+
#define ETH_MODULE_EEPROM_PAGE_LEN 128
#define ETH_MODULE_MAX_I2C_ADDRESS 0x7f
@@ -533,6 +571,8 @@ struct ethtool_module_eeprom {
* read.
* @get_eth_phy_stats: Query some of the IEEE 802.3 PHY statistics.
* @get_eth_mac_stats: Query some of the IEEE 802.3 MAC sta
rrors;
+};
+
/* Basic IEEE 802.3 PHY statistics (30.3.2.1.*), not otherwise exposed
* via a more targeted API.
*/
@@ -495,6 +523,7 @@ struct ethtool_module_eeprom {
* specified page. Returns a negative error code or the amount of bytes
* read.
* @get_eth_phy_stats: Query some of the
On Thu, 2021-04-15 at 16:05 -0700, Jakub Kicinski wrote:
> On Thu, 15 Apr 2021 15:46:52 -0700 Saeed Mahameed wrote:
> > > > best practice here is to centralize all the data structures and
> > > > information definitions in one place, you define the stat id,
> > > > string,
> > > > and value offset,
On Thu, 15 Apr 2021 15:46:52 -0700 Saeed Mahameed wrote:
> > > best practice here is to centralize all the data structures and
> > > information definitions in one place, you define the stat id,
> > > string,
> > > and value offset, then a generic loop can generate the strset and
> > > fill
> > > u
u64 FrameTooLongErrors;
> > > +};
> > > +
> > > /* Basic IEEE 802.3 PHY statistics (30.3.2.1.*), not otherwise
> > > exposed
> > > * via a more targeted API.
> > > */
> > > @@ -495,6 +523,7 @@ struct ethtool_module_eeprom {
> >
On Wed, Apr 14, 2021 at 10:49:37AM -0400, Tianyu Lan wrote:
> From: Tianyu Lan
>
> Hyper-V provides GHCB protocol to write Synthetic Interrupt
> Controller MSR registers and these registers are emulated by
> Hypervisor rather than paravisor.
What is paravisor? Is that the VMPL0 to borrow AMD spe
; + u64 OutOfRangeLengthField;
> > + u64 FrameTooLongErrors;
> > +};
> > +
> > /* Basic IEEE 802.3 PHY statistics (30.3.2.1.*), not otherwise exposed
> > * via a more targeted API.
> > */
> > @@ -495,6 +523,7 @@ struct ethtool_module_eeprom {
On 4/14/2021 11:41 PM, Christoph Hellwig wrote:
+EXPORT_SYMBOL_GPL(hv_ghcb_msr_write);
Just curious, who is going to use all these exports? These seems like
extremely low-level functionality. Isn't there a way to build a more
useful higher level API?
Yes, will remove it.
TooLongErrors;
> +};
> +
> /* Basic IEEE 802.3 PHY statistics (30.3.2.1.*), not otherwise exposed
> * via a more targeted API.
> */
> @@ -495,6 +523,7 @@ struct ethtool_module_eeprom {
> * specified page. Returns a negative error code or the amount of
> bytes
> *
rrors;
+};
+
/* Basic IEEE 802.3 PHY statistics (30.3.2.1.*), not otherwise exposed
* via a more targeted API.
*/
@@ -495,6 +523,7 @@ struct ethtool_module_eeprom {
* specified page. Returns a negative error code or the amount of bytes
* read.
* @get_eth_phy_stats: Query some of the
ol_ops - optional netdev operations
* @cap_link_lanes_supported: indicates if the driver supports lanes
@@ -533,6 +571,8 @@ struct ethtool_module_eeprom {
* read.
* @get_eth_phy_stats: Query some of the IEEE 802.3 PHY statistics.
* @get_eth_mac_stats: Query some of the IEEE 802.3 MAC statisti
Number of devices maintains the standard-based MAC control
counters for control frames. Add a API for those.
Signed-off-by: Jakub Kicinski
---
include/linux/ethtool.h | 11 ++
include/uapi/linux/ethtool.h | 2 ++
include/uapi/linux/ethtool_netlink.h | 14 +++
> +EXPORT_SYMBOL_GPL(hv_ghcb_msr_write);
Just curious, who is going to use all these exports? These seems like
extremely low-level functionality. Isn't there a way to build a more
useful higher level API?
From: Tianyu Lan
Hyper-V provides GHCB protocol to write Synthetic Interrupt
Controller MSR registers and these registers are emulated by
Hypervisor rather than paravisor.
Hyper-V requests to write SINTx MSR registers twice(once via
GHCB and once via wrmsr instruction including the proxy bit 21)
8a7b845c0083047...@syzkaller.appspotmail.com
==
BUG: KASAN: slab-out-of-bounds in decode_session6 net/xfrm/xfrm_policy.c:3403
[inline]
BUG: KASAN: slab-out-of-bounds in __xfrm_decode_session+0x1ba4/0x2720
net/xfrm/xfrm_policy.c:3495
Now that we have a chip structure, we can store the temperature reading
method in this structure (OOP style).
Signed-off-by: Marek Behún
Reviewed-by: Andrew Lunn
---
drivers/net/phy/marvell10g.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers
On Wed, Apr 07, 2021 at 12:11:00AM +0200, Marek Behún wrote:
> Now that we have a chip structure, we can store the temperature reading
> method in this structure (OOP style).
>
> Signed-off-by: Marek Behún
Reviewed-by: Andrew Lunn
Andrew
Now that we have a chip structure, we can store the temperature reading
method in this structure (OOP style).
Signed-off-by: Marek Behún
---
drivers/net/phy/marvell10g.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/net/phy/marvell10g.c b/dr
syzbot suspects this issue was fixed by commit:
commit befe6d946551d65cddbd32b9cb0170b0249fd5ed
Author: Steven Rostedt (VMware)
Date: Wed Nov 18 14:34:05 2020 +
tracepoint: Do not fail unregistering a probe due to memory failure
bisection log: https://syzkaller.appspot.com/x/bisect.t
rride BLKFLSBUF")
==
BUG: KASAN: use-after-free in kobject_put+0x493/0x540 lib/kobject.c:749
Read of size 1 at addr 8880135d453c by task syz-executor372/8533
CPU: 0 PID: 8533 Comm: syz-executor372 Not tainted
5.12.0-rc4-next-20210326-syzkaller #0
Hardware name: Google Google Compute Engine/G
On Friday 26 March 2021 11:43:10 Don Bollinger wrote:
> > Hello Don!
> >
> > I have read whole discussion and your EEPROM patch proposal. But for me it
> > looks like some kernel glue code for some old legacy / proprietary access
> > method which does not have any
irq restoration")
==
BUG: KASAN: use-after-free in __lock_acquire+0x3e6f/0x54c0
kernel/locking/lockdep.c:4770
Read of size 8 at addr 888144614468 by task syz-executor242/8422
CPU: 0 PID: 8422 Comm: syz-executor242 Not tainted 5.12.0-rc4-syzkaller #0
Hardware name: Google Google Compute E
otmail.com
==
BUG: KASAN: slab-out-of-bounds in fib6_nh_get_excptn_bucket+0x18b/0x1a0
net/ipv6/route.c:1622
Read of size 8 at addr 88801f5f22f8 by task syz-executor.1/20604
CPU: 0 PID: 20604 Comm: syz-executor.1 Not tainted 5.12.0-rc4-syzkaller #
> > What I have works. Your consumers get quirk handling, mine don't need
it.
> > No compromise.
>
> Hi Don
>
> All this discussion is now a mute point. GregKH has spoken.
Ack. I actually checked in with Greg a couple of days ago and got that
answer. I just thought the discussion was going in
> What I have works. Your consumers get quirk handling, mine don't need it.
> No compromise.
Hi Don
All this discussion is now a mute point. GregKH has spoken.
But i'm sure there are some on the side lines, eating popcorn, maybe
learning from the discussion.
Would you think it is O.K. to add a
On Fri, Mar 26, 2021 at 02:09:36PM -0700, Don Bollinger wrote:
> > You keep missing the point. I always refer to the KAPI. The driver we can
> > rework and rework, throw away and reimplement, as much as we want.
> > The KAPI cannot be changed, it is ABI. It is pretty much frozen the day
> the
> > c
core.com; wally_w...@accton.com;
> aken_...@edge-core.com; g...@microsoft.com; jolev...@microsoft.com;
> xinx...@microsoft.com; 'netdev' ; 'Moshe
> Shemesh'
> Subject: Re: [PATCH v2] eeprom/optoe: driver to read/write SFP/QSFP/CMIS
> EEPROMS
>
> > The onl
determine what quirks to apply for all future reads until the module
is unplugged.
Your KAPI is missing how optoe gets access to the GPIOs. Without
knowing if the module has been hotplugged, in a robust manor, you have
problems with quirks. For every userspace read, you need to assume the
module has b
t, it already exists.
Second, it specifies how the data in the EEPROM is accessed. It says that
low memory is in offset 0-127, and paged memory starts at offset (128 +
(page * 128)). For SFP devices, memory at i2c address 0x50 is the first 256
bytes, and everything at 0x51 is pushed up 256 b
On Fri, Mar 26, 2021 at 01:16:14PM -0700, Don Bollinger wrote:
> > > In my community, the SFP/QSFP/CMIS devices (32 to 128 of them per
> > > switch) often cost more than the switch itself. Consumers (both
> > > vendors and
> > > customers) extensively test these devices to ensure correct and
> > >
> > In my community, the SFP/QSFP/CMIS devices (32 to 128 of them per
> > switch) often cost more than the switch itself. Consumers (both
> > vendors and
> > customers) extensively test these devices to ensure correct and
> > reliable operation. Then they buy them literally by the millions.
> > Q
> In my community, the SFP/QSFP/CMIS devices (32 to 128 of them per switch)
> often cost more than the switch itself. Consumers (both vendors and
> customers) extensively test these devices to ensure correct and reliable
> operation. Then they buy them literally by the millions. Quirks lead to
>
> Hello Don!
>
> I have read whole discussion and your EEPROM patch proposal. But for me it
> looks like some kernel glue code for some old legacy / proprietary access
> method which does not have any usage outside of that old code.
I don't know if 'kernel glue code&
> > > Our experience is that a number of SFPs are broken, they don't
> > > follow the standard. Some you cannot perform more than 16 bytes
> > > reads without them locking up. Others will perform a 16 byte read,
> > > but only give you one
> > useful
> > Our experience is that a number of SFPs are broken, they don't follow the
> > standard. Some you cannot perform more than 16 bytes reads without them
> > locking up. Others will perform a 16 byte read, but only give you one
> useful
> > byte of data. So you hav
ome you cannot perform more than 16 bytes reads without them
> locking up. Others will perform a 16 byte read, but only give you one
useful
> byte of data. So you have to read enough of the EEPROM a byte at a time to
> get the vendor and product strings in order to determine what quirks need
&g
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Mon, 22 Mar 2021 16:43:29 +0100 you wrote:
> xps_queue_show is mostly made of an RCU read-side critical section and
> calls bitmap_zalloc with GFP_KERNEL in the middle of it. That is not
> allowed as this call
; > + dev_maps = READ_ONCE(dev->xps_maps[type]);
> >
> > Couldn't dev_maps be freed between here and the read of dev_maps->nr_ids
> > as we're not in an RCU read-side critical section?
>
> Oh, good point. Never mind, then.
>
> > My feeling is
Quoting Antoine Tenart (2021-03-22 18:41:30)
> Quoting Matthew Wilcox (2021-03-22 17:54:39)
> > On Mon, Mar 22, 2021 at 04:43:29PM +0100, Antoine Tenart wrote:
> > > xps_queue_show is mostly made of an RCU read-side critical section and
> > > calls bitmap_zalloc with GFP
ouldn't dev_maps be freed between here and the read of dev_maps->nr_ids
> as we're not in an RCU read-side critical section?
Oh, good point. Never mind, then.
> My feeling is there is not much value in having a tricky allocation
> logic for reads from xps_cpus and xps_rxqs. Whi
Quoting Matthew Wilcox (2021-03-22 17:54:39)
> On Mon, Mar 22, 2021 at 04:43:29PM +0100, Antoine Tenart wrote:
> > xps_queue_show is mostly made of an RCU read-side critical section and
> > calls bitmap_zalloc with GFP_KERNEL in the middle of it. That is not
> > allowed as th
On Mon, Mar 22, 2021 at 04:43:29PM +0100, Antoine Tenart wrote:
> xps_queue_show is mostly made of an RCU read-side critical section and
> calls bitmap_zalloc with GFP_KERNEL in the middle of it. That is not
> allowed as this call may sleep and such behaviours aren't allowed in R
xps_queue_show is mostly made of an RCU read-side critical section and
calls bitmap_zalloc with GFP_KERNEL in the middle of it. That is not
allowed as this call may sleep and such behaviours aren't allowed in RCU
read-side critical sections. Fix this by using GFP_NOWAIT instead.
From: Vasundhara Volam
Once the chip goes through reset, the register mapping may be lost
and any read of the mapped health registers may return garbage value
until the registers are mapped again in the init path.
Reading BNXT_FW_RESET_INPROG_REG after firmware reset will likely
return garbage
Hi Emil,
On Sun, Mar 21, 2021 at 4:23 PM Emil Lenngren wrote:
>
> Hi,
>
> Den mån 22 mars 2021 kl 00:01 skrev Luiz Augusto von Dentz
> :
> > Or we do something like
> > https://lore.kernel.org/linux-bluetooth/20201024002251.1389267-1-luiz.de...@gmail.com/,
> > that said the reason we didn't appli
Hi,
Den mån 22 mars 2021 kl 00:01 skrev Luiz Augusto von Dentz
:
> Or we do something like
> https://lore.kernel.org/linux-bluetooth/20201024002251.1389267-1-luiz.de...@gmail.com/,
> that said the reason we didn't applied my patches was that the
> controller would be the one generating invalid dat
028cc3b5dd88bf0 (tag: v5.12-rc3, master)
> Kernel config: refer to attached file (config)
> C POC code: refer to attached file (poc.c)
>
> KASAN Output =
>
> [ 20.294394] BUG: KASAN: slab-out-of-bounds in hci_le_meta_evt+0x310b/0x3850
> [ 20.30
.c:23
Read of size 8 at addr 888034b802c8 by task syz-executor067/9770
CPU: 0 PID: 9770 Comm: syz-executor067 Not tainted 5.12.0-rc2-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:79 [i
Hello Don!
I have read whole discussion and your EEPROM patch proposal. But for me
it looks like some kernel glue code for some old legacy / proprietary
access method which does not have any usage outside of that old code.
Your code does not contain any quirks which are needed to read different
syzbot suspects this issue was fixed by commit:
commit b4a221ea8a1f890b50838ef389d016c7ff280abc
Author: Archie Pusaka
Date: Fri Jan 22 08:36:11 2021 +
Bluetooth: advmon offload MSFT add rssi support
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14ef5ad6d0
start comm
locking up. Others will perform a 16 byte read, but only give you
one useful byte of data. So you have to read enough of the EEPROM a
byte at a time to get the vendor and product strings in order to
determine what quirks need to be applied. optoe has nothing like
this. Either you don't care and only
On Mon, 15 Mar 2021 10:40 -0800 Jakub Kicinski wrote:
> On Sat, 13 Mar 2021 13:35:56 -0800 Don Bollinger wrote:
> > > away parts of the bottom end and replace it with a different KAPI,
> > > and nobody will notice? In fact, this is probably how it was
> > > designed. Anybody
> >
> > Actually everyo
On Sat, 13 Mar 2021 13:35:56 -0800 Don Bollinger wrote:
> > away parts of the bottom end and replace it with a different KAPI, and
> > nobody will notice? In fact, this is probably how it was designed. Anybody
>
> Actually everyone who touches this code would notice, each implementation
> would
From: Ido Schimmel
Since commit 7d8e8f3433dc ("mlxsw: core: Increase scope of RCU read-side
critical section"), all Rx handlers are called from an RCU read-side
critical section.
Remove the unnecessary rcu_read_lock() / rcu_read_unlock().
Signed-off-by: Ido Schimmel
Reviewed-by:
ess goes through
> > open/seek/read/close access to the optoe managed file in
> > /sys/bus/i2c/devices/{num}-0050/eeprom.
>
> And this python stack is all open source? So you should be able to throw
It is open in the sense that it is accessible to the world on github and the
main
From: Mark Zhang
Read congestion counters from all ports in any lag mode rather than
only in RoCE lag mode (e.g., VF lag).
Signed-off-by: Mark Zhang
Reviewed-by: Saeed Mahameed
Reviewed-by: Maor Gottlieb
Signed-off-by: Saeed Mahameed
---
drivers/net/ethernet/mellanox/mlx5/core/lag.c | 2
> This interface is implemented in python scripts provided by the switch
> platform
> vendor. Those scripts encode the mapping of CPLD i2c muxes to i2c buses to
> port numbers, specific to each switch.
>
> At the bottom of that python stack, all EEPROM access goes through
>
PLD i2c muxes to i2c buses to
port numbers, specific to each switch.
At the bottom of that python stack, all EEPROM access goes through
open/seek/read/close access to the optoe managed file in
/sys/bus/i2c/devices/{num}-0050/eeprom.
You're not going to like this, but ethtool -e and e
lib/list_debug.c:23
Read of size 8 at addr 888028830ac8 by task syz-executor.4/9852
CPU: 0 PID: 9852 Comm: syz-executor.4 Not tainted 5.12.0-rc2-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:79 [inl
d-off-by: Rafał Miłecki
>
> [...]
Here is the summary with links:
- [net-next] net: broadcom: bcm4908_enet: read MAC from OF
https://git.kernel.org/netdev/net-next/c/3559c1ea4336
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
From: Rafał Miłecki
BCM4908 devices have MAC address accessible using NVMEM so it's needed
to use OF helper for reading it.
Signed-off-by: Rafał Miłecki
---
drivers/net/ethernet/broadcom/bcm4908_enet.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ether
> I am proposing acceptance of a commonly used implementation for accessing
> SFPs because the one used by the netdev/netlink community does not fit the
> architecture of the white box NOS/switch community.
Please could you expand on this. I've given suggests as to how the new
netlink KAPI could b
On Fri, 5 Mar 2021 2:55 PM -0800 Jakub Kicinski wrote:
> On Fri, 5 Mar 2021 11:07:08 -0800 Don Bollinger wrote:
> > Acknowledging your objections, I nonetheless request that optoe be
> > accepted into upstream as an eeprom driver in drivers/misc/eeprom. It
> > is a legitimate driver, with a legiti
On Fri, 5 Mar 2021 11:07:08 -0800 Don Bollinger wrote:
> Acknowledging your objections, I nonetheless request that optoe be accepted
> into upstream as an eeprom driver in drivers/misc/eeprom. It is a
> legitimate driver, with a legitimate user community, which deserves the
> benefits of being man
On Mon, Mar 1, 2021 at 12:46 PM-0800, Andrew Lunn wrote:
> > To be more specific, optoe is only replacing the functionality of
> > drivers/net/phy/sfp.c, the functions of sfp_i2c_read() and
sfp_i2c_write().
> > These are the routines at the very bottom of the ethtool stack that
> > actually execute
Hi,
Static analysis with Coverity had detected an uninitialized pointer read
in function ocelot_flower_parse_key in
drivers/net/ethernet/mscc/ocelot_flower.c introduced by commit:
commit 75944fda1dfe836fdd406bef6cb3cc8a80f7af83
Author: Xiaoliang Yang
Date: Fri Oct 2 15:02:23 2020 +0300
patchwork-bot+netdev...@kernel.org wrote on Thu, Mar 04, 2021 at 01:10:07AM
+:
> This patch was applied to netdev/net.git
thanks for taking the patch, I didn't take the time to reply yesterday
after my bisect finally finished.
I've got the culprit now, could you add the following?
Signed-
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Tue, 2 Mar 2021 17:19:32 +0800 you wrote:
> I met below warning when cating a small size(about 80bytes) txt file
> on 9pfs(msize=2097152 is passed to 9p mount option), the reason is we
> miss iov_iter_advance() if
ove from the list if reference is not
> 0, right? So what if I send 1000 of netlink remove messages? Will it
> drain refcount to 0?
> I did not read all involved code, but the typical pattern is to drop
> refcount and always remove from the list. Then the last use will
> delete the
NT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+9ec037722d2603a9f...@syzkaller.appspotmail.com
==
BUG: KASAN: use-after-free in cipso_v4_genopt+0x1078/0x1700
net/ipv4/cipso_ipv4.c:1784
Read of
On Tue, Mar 2, 2021 at 6:03 AM Dmitry Vyukov wrote:
>
...
> Besides these 2 crashes, we've also seen one on a 4.19 based kernel, see
> below.
> Based on the reports with mismatching stacks, it looks like
> cipso_v4_genopt is doing some kind of wild pointer access (uninit
> pointer?).
Hmm, inte
c037722d2603a9f...@syzkaller.appspotmail.com
==
BUG: KASAN: use-after-free in cipso_v4_genopt+0x1078/0x1700
net/ipv4/cipso_ipv4.c:1784
Read of size 1 at addr 888017bba510 by task kworker/1:3/4821
CPU: 1 PID: 4821 Comm: kworker/
On Tue, 2 Mar 2021 17:08:13 +0900 Dominique Martinet wrote:
>
>
> Jisheng Zhang wrote on Tue, Mar 02, 2021 at 03:39:40PM +0800:
> > > Rather than make an exception for 0, how about just removing the if as
> > > follow ?
> >
> > IMHO, we may need to keep the "if" in current logic. When count
>
I met below warning when cating a small size(about 80bytes) txt file
on 9pfs(msize=2097152 is passed to 9p mount option), the reason is we
miss iov_iter_advance() if the read count is 0 for zerocopy case, so
we didn't truncate the pipe, then iov_iter_pipe() thinks the pipe is
full. Fix
Jisheng Zhang wrote on Tue, Mar 02, 2021 at 03:39:40PM +0800:
> > Rather than make an exception for 0, how about just removing the if as
> > follow ?
>
> IMHO, we may need to keep the "if" in current logic. When count
> reaches zero, we need to break the "while(iov_iter_count(to))" loop, so
> rem
On Tue, 2 Mar 2021 13:38:08 +0900 Dominique Martinet wrote:
>
>
> Jisheng Zhang wrote on Mon, Mar 01, 2021 at 11:01:57AM +0800:
> > Per my understanding of iov_iter, we need to call iov_iter_advance()
> > even when the read out count is 0. I believe we can see this common
Jisheng Zhang wrote on Mon, Mar 01, 2021 at 11:01:57AM +0800:
> Per my understanding of iov_iter, we need to call iov_iter_advance()
> even when the read out count is 0. I believe we can see this common style
> in other fs.
I'm not sure where you see this style, but I don't s
On 2/11/21 11:50 AM, AngeloGioacchino Del Regno wrote:
> On IPAv3.1 there is no such FLAVOR_0 register so it is impossible
> to read tx/rx channel masks and we have to rely on the correctness
> on the provided configuration.
This works, and is simple.
I think I would rather pop
> To be more specific, optoe is only replacing the functionality of
> drivers/net/phy/sfp.c, the functions of sfp_i2c_read() and sfp_i2c_write().
> These are the routines at the very bottom of the ethtool stack that actually
> execute the i2c calls to get the data. The existing routines are very
>
On Fri, Feb 26, 2021 at 6:46 PM -0800, Don Bollinger wrote:
> On Fri, Feb 26, 2021 at 2:35 PM -0800, Andrew Lunn wrote:
> > On Mon, Feb 15, 2021 at 11:38:21AM -0800, Don Bollinger wrote:
> > > optoe is an i2c based driver that supports read/write access to all
> > >
reason is we
> > miss iov_iter_advance() if the read count is 0, so we didn't truncate
> > the pipe, then iov_iter_pipe() thinks the pipe is full. Fix it by
> > calling iov_iter_advance() on the iov_iter "to" even if read count is 0
>
> Hm, there are plenty of other er
Jisheng Zhang wrote on Mon, Mar 01, 2021 at 10:33:36AM +0800:
> I met below warning when cating a small size(about 80bytes) txt file
> on 9pfs(msize=2097152 is passed to 9p mount option), the reason is we
> miss iov_iter_advance() if the read count is 0, so we didn't truncate
&g
I met below warning when cating a small size(about 80bytes) txt file
on 9pfs(msize=2097152 is passed to 9p mount option), the reason is we
miss iov_iter_advance() if the read count is 0, so we didn't truncate
the pipe, then iov_iter_pipe() thinks the pipe is full. Fix it by
ca
1 - 100 of 2400 matches
Mail list logo
