On 07-01-21, 17:40, Thomas Bogendoerfer wrote:
> On Wed, Jan 06, 2021 at 11:10:38AM -0800, Joe Perches wrote:
> > On Tue, 2021-01-05 at 15:02 +0100, Thomas Bogendoerfer wrote:
> > > Signed-off-by: Thomas Bogendoerfer
> > []
> > > diff --git a/drivers/dma/txx9dmac.h b/drivers/dma/txx9dmac.h
> > []
On 2021/1/7 下午3:18, Eli Cohen wrote:
map_direct_mr() assumed that the number of scatter/gather entries
returned by dma_map_sg_attrs() was equal to the number of segments in
the sgl list. This led to wrong population of the mkey object. Fix this
by properly referring to the returned value.
The
> I thought as much, but maybe there is some driver which can offload
> whole i2c_transfer to HW, and has to pass the addresses of the buffers
> to the HW, and the HW can have problems if the buffers overlap
> somewhere...
Well, sure, you can never know what crazy HW is out there :) But that
shou
On Thu, Jan 07, 2021 at 07:59:37PM -0800, Saeed Mahameed wrote:
> On Thu, 2021-01-07 at 13:58 +0100, Eric Dumazet wrote:
> > On Thu, Jan 7, 2021 at 12:33 PM Vladimir Oltean
> > wrote:
> > > On Thu, Jan 07, 2021 at 12:18:28PM +0100, Eric Dumazet wrote:
> > > > What a mess really.
> > >
> > > Thanks
The first two patches of this series extends the MAC statistics support
to also work for network interfaces which have their link status handled
by firmware (TYPE_FIXED).
The next two patches are fixing a sporadic problem which happens when
the connected DPMAC object is not yet discovered by the f
From: Ioana Ciornei
Split up the initialization phase of the dpmac object from actually
configuring the phylink instance, connecting to it and configuring the
MAC. This is done so that even though the dpni object is connected to a
dpmac which has link management handled by the firmware we are sti
From: Ioana Ciornei
If the network interface object is connected to a MAC of TYPE_FIXED, the
link status management is handled exclusively by the firmware. This does
not mean that the driver cannot access the MAC counters and export them
in ethtool.
For this to happen, we open the attached dpmac
From: Ioana Ciornei
The fsl_mc_get_endpoint() function now returns -EPROBE_DEFER when the
dpmac device was not yet discovered by the fsl-mc bus. When this
happens, pass the error code up so that we can retry the probe at a
later time.
Signed-off-by: Ioana Ciornei
---
Changes in v2:
- replaced
From: Ioana Ciornei
The dpaa2-eth driver has phylink integration only if the connected dpmac
object is in TYPE_PHY (aka the PCS/PHY etc link status is managed by
Linux instead of the firmware). The check is thus unnecessary because
the code path that reaches the .mac_link_up() callback is only wi
Quoting Alexander Duyck (2021-01-07 17:38:35)
> On Thu, Jan 7, 2021 at 12:54 AM Antoine Tenart wrote:
> >
> > Quoting Alexander Duyck (2021-01-06 20:54:11)
> > > On Wed, Jan 6, 2021 at 10:04 AM Antoine Tenart wrote:
> >
> > That would require to hold rcu_read_lock in the caller and I'd like to
>
From: Ioana Ciornei
The fsl_mc_get_endpoint() should return a pointer to the connected
fsl_mc device, if there is one. By interrogating the MC firmware, we
know if there is an endpoint or not so when the endpoint device is
actually searched on the fsl-mc bus and not found we are hitting the
case
From: Ioana Ciornei
The MC firmware takes these PAUSE/ASYM_PAUSE flags provided by the
driver, transforms them back into rx/tx pause enablement status and
applies them to hardware. We are not losing information by this
transformation, thus remove the comment.
Signed-off-by: Ioana Ciornei
---
Ch
On Fri, Jan 08, 2021 at 10:14:01AM +0100, Eric Dumazet wrote:
> If you disagree, repost a rebased patch series so that we can
> test/compare and choose the best solution.
I would rather use Saeed's time as a reviewer to my existing and current
patch set.
Updated patchset with fixes for enbling IRQ for 5GBASER and 10BASER.
Pavana Sharma (4):
dt-bindings: net: Add 5GBASER phy interface
net: phy: Add 5GBASER interface mode
net: dsa: mv88e6xxx: Change serdes lane parameter type from u8 type to
int
net: dsa: mv88e6xxx: Add support for mv88e
Add 5gbase-r PHY interface mode.
Signed-off-by: Pavana Sharma
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/net/ethernet-controller.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml
b/Documentation/devicetree/b
Add 5GBASE-R phy interface mode
Signed-off-by: Pavana Sharma
---
include/linux/phy.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 9effb511acde..548372eb253a 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -106,6 +106,7 @@ e
Returning 0 is no more an error case with MV88E6393 family
which has serdes lane numbers 0, 9 or 10.
So with this change .serdes_get_lane will return lane number
or -errno (-ENODEV or -EOPNOTSUPP).
Signed-off-by: Pavana Sharma
Reviewed-by: Andrew Lunn
---
drivers/net/dsa/mv88e6xxx/chip.c | 28
On 08/01/2021 02:20, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> There is an effort to convert .ndo_get_stats64 to sleepable context, and
> for that to work, we need to prevent callers of dev_get_stats from using
> atomic locking.
>
> The bonding driver retrieves its statistics recursivel
MSFT ActiveSync implementation requires that the size of the response for
incoming query is to be provided in the request input length. Failure to
set the input size proper results in failed request transfer, where the
ActiveSync counterpart reports the NDIS_STATUS_INVALID_LENGTH (0xC0010014L)
erro
On 07.01.21 23:38, Jakub Kicinski wrote:
> On Thu, 7 Jan 2021 22:17:15 +0100 Marc Kleine-Budde wrote:
>>> +struct __packed tcan4x5x_buf_cmd {
>>> + u8 cmd;
>>> + __be16 addr;
>>> + u8 len;
>>> +};
>>
>> This has to be packed, as I assume the compiler would add some space after
>> the
On 1/8/21 3:28 AM, Dongseok Yi wrote:
skbs in fraglist could be shared by a BPF filter loaded at TC. If TC
writes, it will call skb_ensure_writable -> pskb_expand_head to create
a private linear section for the head_skb. And then call
skb_clone_fraglist -> skb_get on each skb in the fraglist.
sk
On Sun, Jan 03, 2021 at 10:57:50PM +0300, Arseny Krasnov wrote:
This extends rx loop for SOCK_SEQPACKET packets and implements
callback which user calls to copy data to its buffer.
Please write a better commit message explaining the changes, e.g. that
you are using 'flags' to transport
On Fri, Jan 08, 2021 at 11:14:50AM +0100, Eric Dumazet wrote:
> On Fri, Jan 8, 2021 at 1:20 AM Vladimir Oltean wrote:
> >
> > From: Vladimir Oltean
> >
> > After commit 28172739f0a2 ("net: fix 64 bit counters on 32 bit arches"),
> > dev_get_stats got an additional argument for storage of statisti
On 1/7/21 3:44 PM, Willem de Bruijn wrote:
On Thu, Jan 7, 2021 at 8:33 AM Daniel Borkmann wrote:
On 1/7/21 2:05 PM, Willem de Bruijn wrote:
On Thu, Jan 7, 2021 at 7:52 AM Daniel Borkmann wrote:
On 1/7/21 12:40 PM, Dongseok Yi wrote:
On 2021-01-07 20:05, Daniel Borkmann wrote:
On 1/7/21 1:3
Hi Arseny,
On Sun, Jan 03, 2021 at 10:54:52PM +0300, Arseny Krasnov wrote:
As SOCK_SEQPACKET guarantees to save record boundaries, so to
do it, new packet operation was added: it marks start of record (with
record length in header). To send record, packet with start marker is
sent first,
From: Christoph Hellwig
> Sent: 21 September 2020 15:22
>
> So looking at the various callers I'm not sure this API is the
> best. If we want to do something fancy I'd hide the struct iovec
> instances entirely with something like:
>
> struct iov_storage {
> struct iovec stack[UIO_FASTIOV]
From: Eric Dumazet
GRO_DROP can only be returned from napi_gro_frags()
if the skb has not been allocated by a prior napi_get_frags()
Since drivers must use napi_get_frags() and test its result
before populating the skb with metadata, we can safely remove
GRO_DROP since it offers no practical use
From: Eric Dumazet
GRO_DROP has no practical use and can be removed,
once ice driver is cleaned up.
This removes one useless conditionel test in napi_gro_frags()
Eric Dumazet (2):
ice: drop dead code in ice_receive_skb()
net-gro: remove GRO_DROP
drivers/net/ethernet/intel/ice/ice_txrx_lib
From: Eric Dumazet
napi_gro_receive() can never return GRO_DROP
GRO_DROP can only be returned from napi_gro_frags()
which is the other NAPI GRO entry point.
Followup patch will remove GRO_DROP, because drivers
are not supposed to call napi_gro_frags() if prior
napi_get_frags() has failed.
Note
The old way of changing the conntrack hashsize runtime was through changing
the module param via file /sys/module/nf_conntrack/parameters/hashsize. This
was extended to sysctl change in commit 3183ab8997a4 ("netfilter: conntrack:
allow increasing bucket size via sysctl too").
The commit introduced
From: Christoph Hellwig
> Sent: 21 September 2020 15:34
>
> Stop duplicating the iovec verify code, and instead add add a
> __import_iovec helper that does the whole verify and import, but takes
> a bool compat to decided on the native or compat layout. This also
> ends up massively simplifying
Jesper Dangaard Brouer wrote:
> The old way of changing the conntrack hashsize runtime was through changing
> the module param via file /sys/module/nf_conntrack/parameters/hashsize. This
> was extended to sysctl change in commit 3183ab8997a4 ("netfilter: conntrack:
> allow increasing bucket size v
This series includes a number of smaller improvements.
v2:
- return on WARN in patch 1
Heiner Kallweit (3):
r8169: replace BUG_ON with WARN in _rtl_eri_write
r8169: improve rtl_ocp_reg_failure
r8169: don't wakeup-enable device on shutdown if WOL is disabled
drivers/net/ethernet/realtek/r8
Use WARN here to avoid stopping the system. In addition print the addr
and mask values that triggered the warning.
v2:
- return on WARN to avoid an invalid register write
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 4 +++-
1 file changed, 3 insertions(+), 1 de
If WOL isn't enabled, then there's no need to enable wakeup from D3
on system shutdown.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethern
Use WARN_ONCE here to get a call trace in case of a problem.
This facilitates finding the offending code part.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/
RTL8168dp is ancient anyway, and I haven't seen any trace of its early
version 27 yet. This chip versions needs quite some special handling,
therefore it would facilitate driver maintenance if support for it
could be dropped. For now just disable detection of this chip version.
If nobody complains
On 08/01/2021 11:39, Eric Dumazet wrote:
> From: Eric Dumazet
>
> GRO_DROP can only be returned from napi_gro_frags()
> if the skb has not been allocated by a prior napi_get_frags()
>
> Since drivers must use napi_get_frags() and test its result
> before populating the skb with metadata, we can
Приветствую тебя, мой друг, надеюсь, ты в порядке, пожалуйста, ответь мне
благодаря,
It is a workaround patch.
UDP/IP header of UDP GROed frag_skbs are not updated even after NAT
forwarding. Only the header of head_skb from ip_finish_output_gso ->
skb_gso_segment is updated but following frag_skbs are not updated.
A call path skb_mac_gso_segment -> inet_gso_segment ->
udp4_ufo_fr
On 1/7/21 10:16 PM, Florian Westphal wrote:
Ben Greear wrote:
I noticed my system has a hung process trying to 'rmmod nf_conntrack'.
I've generally been doing the script that calls rmmod forever,
but only extensively tested on 5.4 kernel and earlier.
If anyone has any ideas, please let me kno
On Wed, Aug 12, 2020 at 6:25 PM Eric Dumazet wrote:
> > Also, I tried the diff for tcp_conn_request...
> > With removing the call to prandom_u32() not useful for
> > prandom_u32/tracing via perf.
>
> I am planning to send the TCP patch once net-next is open. (probably next
> week)
Ping.
What i
Stephen Hemminger writes:
> On Thu, 7 Jan 2021 09:13:34 +0200
> Roi Dayan wrote:
>
>> +#define _IS_JSON_CONTEXT(type) ((type & PRINT_JSON || type & PRINT_ANY) &&
>> is_json_context())
>> +#define _IS_FP_CONTEXT(type) (!is_json_context() && (type & PRINT_FP ||
>> type & PRINT_ANY))
>
> You c
Fri, Jan 08, 2021 at 12:58:13AM CET, ja...@redhat.com wrote:
>On Mon, Dec 28, 2020 at 11:11:45AM +0100, Jiri Pirko wrote:
>> Fri, Dec 18, 2020 at 08:30:33PM CET, ja...@redhat.com wrote:
>> >This comes from an end-user request, where they're running multiple VMs on
>> >hosts with bonded interfaces c
From: Yunjian Wang
There is a potential execution path in which variable err is
returned without being properly initialized previously. Fix
this by initializing variable err to 0.
Addresses-Coverity: ("Uninitialized scalar variable")
Fixes: 1db64e8733f6 ("devlink: Add devlink formatted message (
On 12/22/20 10:52 PM, Xie Yongji wrote:
> This VDUSE driver enables implementing vDPA devices in userspace.
> Both control path and data path of vDPA devices will be able to
> be handled in userspace.
>
> In the control path, the VDUSE driver will make use of message
> mechnism to forward the conf
On Fri, Jan 08, 2021 at 09:52:28PM +0900, Dongseok Yi wrote:
> It is a workaround patch.
>
> UDP/IP header of UDP GROed frag_skbs are not updated even after NAT
> forwarding. Only the header of head_skb from ip_finish_output_gso ->
> skb_gso_segment is updated but following frag_skbs are not updat
On Thu, Jan 07, 2021 at 07:05:21PM -0800, Florian Fainelli wrote:
>
>
> On 1/7/2021 6:22 PM, Brian Silverman wrote:
> > I've written a very small generic MDIO driver that uses the existing
> > mdio-i2c.c library in drivers/net/phy. The driver allows
> > communication to the PHY's MDIO interface
On Wed, Jan 06, 2021 at 02:43:43PM +0100, Loic Poulain wrote:
> Currently, the MHI controller driver defines which channels should
> have their inbound buffers allocated and queued. But ideally, this is
> something that should be decided by the MHI device driver instead,
We call them, "MHI client
On Fri, Jan 08, 2021 at 07:49:28PM +1000, Pavana Sharma wrote:
> Add 5GBASE-R phy interface mode
>
> Signed-off-by: Pavana Sharma
Reviewed-by: Andrew Lunn
Andrew
Pavana, some last nitpicks, sorry I didn't check this before.
I will send another patch to you which shall fix all this things.
On Fri, 8 Jan 2021 19:50:56 +1000
Pavana Sharma wrote:
> +/* Support 10, 100, 200, 1000, 2500, 5000, 1 Mbps (e.g. 88E6393X)
> + * This function adds new speed 500
On Fri, Jan 08, 2021 at 07:48:59PM +1000, Pavana Sharma wrote:
> Add 5gbase-r PHY interface mode.
>
> Signed-off-by: Pavana Sharma
> Acked-by: Rob Herring
Reviewed-by: Andrew Lunn
Andrew
The Marvell 88E6393X device is a single-chip integration of a 11-port
Ethernet switch with eight integrated Gigabit Ethernet (GbE) transceivers
and three 10-Gigabit interfaces.
This patch adds functionalities specific to mv88e6393x family (88E6393X,
88E6193X and 88E6191X)
Co-developed-by: Marek B
On Fri, Jan 8, 2021 at 2:08 PM Sedat Dilek wrote:
>
> On Wed, Aug 12, 2020 at 6:25 PM Eric Dumazet wrote:
>
> > > Also, I tried the diff for tcp_conn_request...
> > > With removing the call to prandom_u32() not useful for
> > > prandom_u32/tracing via perf.
> >
> > I am planning to send the TCP p
On Fri, 8 Jan 2021 19:50:56 +1000
Pavana Sharma wrote:
> +int mv88e6393x_serdes_power(struct mv88e6xxx_chip *chip, int port, int lane,
> + bool on)
> +{
> + u8 cmode;
> +
> + if (port != 0 && port != 9 && port != 10)
> + return -EOPNOTSUPP;
> +
> + cmode =
On Mon, Dec 28, 2020 at 10:32 PM Adam Ford wrote:
> The AVB driver assumes there is an external clock, but it could
> be driven by an external clock. In order to enable a programmable
> clock, it needs to be added to the clocks list and enabled in the
> driver. Since there currently only one clo
On Mon, Dec 28, 2020 at 10:32 PM Adam Ford wrote:
> The bindings have been updated to support two clocks, but the
> original clock now requires the name fck. Add a clock-names
> list in the device tree with fck in it.
>
> Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
i.e. will queue
Hi Adam,
On Tue, Jan 5, 2021 at 1:53 PM Adam Ford wrote:
> On Mon, Jan 4, 2021 at 4:41 AM Geert Uytterhoeven
> wrote:
> > On Mon, Dec 28, 2020 at 10:32 PM Adam Ford wrote:
> > > The bindings have been updated to support two clocks, but the
> > > original clock now requires the name fck to dist
Hi Adam,
On Fri, Jan 8, 2021 at 3:11 PM Geert Uytterhoeven wrote:
> On Mon, Dec 28, 2020 at 10:32 PM Adam Ford wrote:
> > The AVB driver assumes there is an external clock, but it could
> > be driven by an external clock. In order to enable a programmable
> > clock, it needs to be added to the
On Mon, Dec 28, 2020 at 10:32 PM Adam Ford wrote:
> The bindings have been updated to support two clocks, but the
> original clock now requires the name fck. Add a clock-names
> list in the device tree with fck in it.
>
> Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
i.e. will queue
- some nitpicks are fixed here, mostly alignemnts
- also mv88e6393x_serdes_power() now enables 10g PHY not only for
10gbase-r, but also for 5gbase-r mode
Pavana, you can apply this patch as previously:
cd linux
patch -p1
---
drivers/net/dsa/mv88e6xxx/port.c | 24 +++-
drivers
From: Ido Schimmel
This series includes two fixes for thermal control in mlxsw.
Patch #1 validates that the alarm temperature threshold read from a
transceiver is above the warning temperature threshold. If not, the
current thresholds are maintained. It was observed that some transceiver
might b
From: Vadim Pasternak
Increase critical threshold for ASIC thermal zone from 110C to 140C
according to the system hardware requirements. All the supported ASICs
(Spectrum-1, Spectrum-2, Spectrum-3) could be still operational with ASIC
temperature below 140C. With the old critical threshold value
From: Vadim Pasternak
Validate thresholds to avoid a single failure due to some transceiver
unreliability. Ignore the last readouts in case warning temperature is
above alarm temperature, since it can cause unexpected thermal
shutdown. Stay with the previous values and refresh threshold within
th
On Fri, Jan 08, 2021 at 02:12:56PM +0100, Jiri Pirko wrote:
> Fri, Jan 08, 2021 at 12:58:13AM CET, ja...@redhat.com wrote:
> >On Mon, Dec 28, 2020 at 11:11:45AM +0100, Jiri Pirko wrote:
> >> Fri, Dec 18, 2020 at 08:30:33PM CET, ja...@redhat.com wrote:
> >> >This comes from an end-user request, wher
On Fri, Jan 08, 2021 at 03:01:59PM +0100, Loic Poulain wrote:
> Hi Mani,
>
> On Fri, 8 Jan 2021 at 14:44, Manivannan Sadhasivam <
> manivannan.sadhasi...@linaro.org> wrote:
>
> > On Wed, Jan 06, 2021 at 02:43:43PM +0100, Loic Poulain wrote:
> > > Currently, the MHI controller driver defines which
The changes made are compile tested
- Applies perfecly on next-20210108
drivers/net/wireless/realtek/rtlwifi/ps.c | 4 ++--
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/dm.c | 8
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c | 4 ++--
drivers/net/wire
This looks like a case where some conformance test is testing a corner case in
the standard where the Linux TCP stack is not following the standard for valid
reasons.
Linux behavior of silently dropping the packet would reduce DoS changes and
information
leakage for MiTM attacks.
Begin forwarded
On Fri, Jan 08, 2021 at 05:45:54PM +0200, Claudiu Beznea wrote:
> KSZ9131 is used in setups with SAMA7G5. SAMA7G5 supports a special
> power saving mode (backup mode) that cuts the power for almost all
> parts of the SoC. The rail powering the ethernet PHY is also cut off.
> When resuming, in case
On Fri, 8 Jan 2021 14:08:57 +0100
Petr Machata wrote:
> Stephen Hemminger writes:
>
> > On Thu, 7 Jan 2021 09:13:34 +0200
> > Roi Dayan wrote:
> >
> >> +#define _IS_JSON_CONTEXT(type) ((type & PRINT_JSON || type & PRINT_ANY)
> >> && is_json_context())
> >> +#define _IS_FP_CONTEXT(type) (!i
On Fri, 8 Jan 2021 09:25:25 +0200
Leon Romanovsky wrote:
> On Thu, Jan 07, 2021 at 10:54:38PM -0500, Don Dutile wrote:
> > On 1/7/21 7:57 PM, Bjorn Helgaas wrote:
> > > [+cc Alex, Don]
>
> <...>
>
> > > Help me connect the dots here. Is this required because of something
> > > peculiar to
On 08.01.2021 16:45, Claudiu Beznea wrote:
> KSZ9131 is used in setups with SAMA7G5. SAMA7G5 supports a special
> power saving mode (backup mode) that cuts the power for almost all
> parts of the SoC. The rail powering the ethernet PHY is also cut off.
> When resuming, in case the PHY has been conf
From: Vladimir Oltean
There is a desire to standardize the counters that have previously been
reported through ethtool statistics into something that can be more
uniformly queried from user space. The ndo_get_stats64 are a good
candidate to keep standardized counters, as well as add new ones (lik
From: Vladimir Oltean
After commit 28172739f0a2 ("net: fix 64 bit counters on 32 bit arches"),
dev_get_stats got an additional argument for storage of statistics. At
this point, dev_get_stats could return either the passed "storage"
argument, or the output of .ndo_get_stats64.
Then commit caf586
From: Vladimir Oltean
In the effort of making .ndo_get_stats64 be able to sleep, we need to
ensure the callers of dev_get_stats do not use atomic context.
The LED driver for HP-PARISC workstations uses a workqueue to
periodically check for updates in network interface statistics, and
flicker whe
On Fri, 8 Jan 2021 11:07:26 +0100 Ahmad Fatoum wrote:
> >>> +struct __packed tcan4x5x_map_buf {
> >>> + struct tcan4x5x_buf_cmd cmd;
> >>> + u8 data[256 * sizeof(u32)];
> >>> +} cacheline_aligned;
> >>
> >> Due to the packing of the struct tcan4x5x_buf_cmd it should have a length
> >>
From: Vladimir Oltean
dev_get_stats can now return error codes. Take the remaining call sites
where those errors can be propagated, which are all trivial, and convert
them to look at that error code and stop processing.
The effects of simulating a kernel error (returning -ENOMEM) upon
existing p
From: Vladimir Oltean
The dev_get_stats function can now return an error code, so the code
that retrieves vport statistics and sends them through netlink needs to
propagate that error code.
Modify the drastic BUG_ON checks to operate only on the -EMSGSIZE error
code (the only error code previous
From: Vladimir Oltean
dev_get_stats can now return errors. Some call sites are coming from a
context that returns void (ethtool stats, workqueue context). So since
we can't report to the upper layer, do the next best thing: shout.
This patch wraps up the conversion of existing dev_get_stats call
On Fri, Jan 8, 2021 at 1:07 AM Antoine Tenart wrote:
>
> Quoting Alexander Duyck (2021-01-07 17:38:35)
> > On Thu, Jan 7, 2021 at 12:54 AM Antoine Tenart wrote:
> > >
> > > Quoting Alexander Duyck (2021-01-06 20:54:11)
> > > > On Wed, Jan 6, 2021 at 10:04 AM Antoine Tenart
> > > > wrote:
> > >
From: Vladimir Oltean
Now that all callers have been converted to not use atomic context when
calling dev_get_stats, it is time to update the documentation and put a
notice in the function that it expects process context.
Signed-off-by: Vladimir Oltean
---
Changes in v5:
None.
Changes in v4:
N
From: Vladimir Oltean
There is an effort to convert .ndo_get_stats64 to sleepable context, and
for that to work, we need to prevent callers of dev_get_stats from using
atomic locking.
The bonding driver retrieves its statistics recursively from its lower
interfaces, with additional care to only
From: Vladimir Oltean
There is an effort to convert .ndo_get_stats64 to sleepable context, and
for that to work, we need to prevent callers of dev_get_stats from using
atomic locking.
The OVS vport driver calls ovs_vport_get_stats from
ovs_vport_cmd_fill_info, a function with 7 callers: 5 under
From: Vladimir Oltean
The FCoE callback for the Link Error Status Block retrieves the FCS
error count using dev_get_stats. This function can now return errors.
Propagate these all the way to the sysfs device attributes.
Signed-off-by: Vladimir Oltean
---
Changes in v5:
None.
Changes in v4:
Pat
From: Vladimir Oltean
Some drivers need to do special tricks to comply with the new policy of
ndo_get_stats64 being sleepable. For example, the bonding driver, which
derives its stats from its lower interfaces, must recurse with
dev_get_stats into its lowers with no locks held. But for that to wo
From: Vladimir Oltean
The failover framework sets up a virtio_net interface [ when it has the
VIRTIO_NET_F_STANDBY feature ] and a VF interface, having the same MAC
address, in a standby/active relationship. When the active VF is
unplugged, the standby virtio_net temporarily kicks in.
The failov
From: Vladimir Oltean
Currently, any writer that wants to alter the lists of network
interfaces (either the plain list net->dev_base_head, or the hash tables
net->dev_index_head and net->dev_name_head) can keep other writers at
bay using the RTNL mutex.
However, the RTNL mutex has become a very
From: Vladimir Oltean
In the effort of making .ndo_get_stats64 be able to sleep, we need to
ensure the callers of dev_get_stats do not use atomic context.
In the case of the appldata driver, an RCU read-side critical section is
used to ensure the integrity of the list of network interfaces, beca
From: Vladimir Oltean
In the effort of making .ndo_get_stats64 be able to sleep, we need to
ensure the callers of dev_get_stats do not use atomic context.
I need to preface this by saying that I have no idea why netstat_show
takes the dev_base_lock rwlock. Two things can be observed:
(a) it does
From: Vladimir Oltean
In the effort of making .ndo_get_stats64 be able to sleep, we need to
ensure the callers of dev_get_stats do not use atomic context.
The /proc/net/dev file uses an RCU read-side critical section to ensure
the integrity of the list of network interfaces, because it iterates
From: Vladimir Oltean
There is a movement to eliminate the usage of dev_base_lock, which
exists since as far as I could track the kernel history down (the
"7a2deb329241 Import changeset" commit from the bitkeeper branch).
The dev_base_lock approach has multiple issues:
- It is global and not per
From: Willem de Bruijn
skb frags may be backed by highmem and/or compound pages. Various
code calls kmap_atomic to safely access highmem pages. But this
needs additional care for compound pages. Fix a few issues:
patch 1 expect kmap mappings with CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP
patch 2 fixes k
From: Willem de Bruijn
Skb frags may be backed by highmem and/or compound pages. Highmem
pages need kmap_atomic mappings to access. But kmap_atomic maps a
single page, not the entire compound page.
skb_foreach_page iterates over an skb frag, in one step in the common
case, page by page only if k
From: Willem de Bruijn
skb_seq_read iterates over an skb, returning pointer and length of
the next data range with each call.
It relies on kmap_atomic to access highmem pages when needed.
An skb frag may be backed by a compound page, but kmap_atomic maps
only a single page. There are not enough
From: Willem de Bruijn
esp(6)_output_head uses skb_page_frag_refill to allocate a buffer for
the esp trailer.
It accesses the page with kmap_atomic to handle highmem. But
skb_page_frag_refill can return compound pages, of which
kmap_atomic only maps the first underlying page.
skb_page_frag_refi
On Fri, Jan 08, 2021 at 04:46:49PM +0100, Loic Poulain wrote:
> Hi Mani,
>
> On Fri, 8 Jan 2021 at 16:30, Manivannan Sadhasivam <
> manivannan.sadhasi...@linaro.org> wrote:
>
> > > > > /* start channels */
> > > > > - rc = mhi_prepare_for_transfer(mhi_dev);
> > > > > + rc = mhi_prep
On Fri, Jan 08, 2021 at 06:31:54PM +0200, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> dev_get_stats can now return error codes. Take the remaining call sites
> where those errors can be propagated, which are all trivial, and convert
> them to look at that error code and stop processing.
>
On Fri, Jan 08, 2021 at 12:35:23AM +0100, Andrew Lunn wrote:
> > +static struct dsa_port *devlink_to_dsa_port(struct devlink_port *dlp)
> > +{
> > + return container_of(dlp, struct dsa_port, devlink_port);
> > +}
>
> I wonder if this should be moved to include/net/dsa.h next to the
> other littl
TID stuck is seen when there is a race in
CPL_PASS_ACCEPT_RPL/CPL_ABORT_REQ and abort is arriving
before the accept reply, which sets the queue number.
In this case HW ends up sending CPL_ABORT_RPL_RSS to an
incorrect ingress queue.
Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition")
S
From: Vladimir Oltean
Instead of reading these values from the reference manual and writing
them down into the driver, it appears that the hardware gives us the
option of detecting them dynamically.
The number of frame references corresponds to what the reference manual
notes, however it seems t
1 - 100 of 224 matches
Mail list logo
