* [PATCH] configure: Define _GNU_SOURCE when checking for setns
From: Khem Raj @ 2022-08-11 5:34 UTC (permalink / raw)
To: netdev; +Cc: Khem Raj
glibc defines this function only as gnu extention
Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index 440facb..c02753b 100755
--- a/configure
+++ b/configure
@@ -191,6 +191,7 @@ check_ipt_lib_dir()
check_setns()
{
cat >$TMPDIR/setnstest.c <<EOF
+#define _GNU_SOURCE
#include <sched.h>
int main(int argc, char **argv)
{
--
2.37.1
^ permalink raw reply related
* Re: [PATCH net-next] net: lan743x: Fix the multi queue overflow issue
From: Jakub Kicinski @ 2022-08-11 5:35 UTC (permalink / raw)
To: Raju Lakkaraju
Cc: netdev, davem, linux-kernel, bryan.whitehead, richardcochran,
UNGLinuxDriver, Ian.Saturley
In-Reply-To: <20220809083628.650493-1-Raju.Lakkaraju@microchip.com>
On Tue, 9 Aug 2022 14:06:28 +0530 Raju Lakkaraju wrote:
> Fix the Tx multi-queue overflow issue
>
> Tx ring size of 128 (for TCP) provides ability to handle way more data than
> what Rx can (Rx buffers are constrained to one frame or even less during a
> dynamic mtu size change)
>
> TX napi weight dependent of the ring size like it is now (ring size -1)
> because there is an express warning in the kernel about not registering weight
> values > NAPI_POLL_WEIGHT (currently 64)
I've read this message 3 times, I don't understand what you're saying.
Could you please rewrite it and add necessary details?
> diff --git a/drivers/net/ethernet/microchip/lan743x_main.c b/drivers/net/ethernet/microchip/lan743x_main.c
> index a9a1dea6d731..d7c14ee7e413 100644
> --- a/drivers/net/ethernet/microchip/lan743x_main.c
> +++ b/drivers/net/ethernet/microchip/lan743x_main.c
> @@ -2064,8 +2064,10 @@ static void lan743x_tx_frame_end(struct lan743x_tx *tx,
> static netdev_tx_t lan743x_tx_xmit_frame(struct lan743x_tx *tx,
> struct sk_buff *skb)
> {
> + struct lan743x_adapter *adapter = tx->adapter;
> int required_number_of_descriptors = 0;
> unsigned int start_frame_length = 0;
> + netdev_tx_t retval = NETDEV_TX_OK;
> unsigned int frame_length = 0;
> unsigned int head_length = 0;
> unsigned long irq_flags = 0;
> @@ -2083,9 +2085,13 @@ static netdev_tx_t lan743x_tx_xmit_frame(struct lan743x_tx *tx,
> if (required_number_of_descriptors > (tx->ring_size - 1)) {
> dev_kfree_skb_irq(skb);
> } else {
> - /* save to overflow buffer */
> - tx->overflow_skb = skb;
> - netif_stop_queue(tx->adapter->netdev);
> + /* save how many descriptors we needed to restart the queue */
> + tx->rqd_descriptors = required_number_of_descriptors;
> + retval = NETDEV_TX_BUSY;
> + if (is_pci11x1x_chip(adapter))
> + netif_stop_subqueue(adapter->netdev, tx->channel_number);
Is tx->channel_number not 0 for devices other than pci11x1x ?
netif_stop_queue() is just an alias for queue 0 IIRC so
you can save all the ifs, most likely?
> + else
> + netif_stop_queue(adapter->netdev);
> }
> goto unlock;
> }
> @@ -2093,7 +2099,7 @@ static netdev_tx_t lan743x_tx_xmit_frame(struct lan743x_tx *tx,
> /* space available, transmit skb */
> if ((skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) &&
> (tx->ts_flags & TX_TS_FLAG_TIMESTAMPING_ENABLED) &&
> - (lan743x_ptp_request_tx_timestamp(tx->adapter))) {
> + (lan743x_ptp_request_tx_timestamp(adapter))) {
If this is a fix you should hold off on refactoring like adding the
local variable for adapter to make backports easier.
> skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
> do_timestamp = true;
> if (tx->ts_flags & TX_TS_FLAG_ONE_STEP_SYNC)
> @@ -1110,7 +1109,7 @@ struct lan743x_tx_buffer_info {
> unsigned int buffer_length;
> };
>
> -#define LAN743X_TX_RING_SIZE (50)
> +#define LAN743X_TX_RING_SIZE (128)
So the ring size is getting increased? I did not get that from the
commit message at all :S
^ permalink raw reply
* Re: [PATCH v7 0/4] Implement vdpasim suspend operation
From: Eugenio Perez Martin @ 2022-08-11 5:35 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: kvm list, linux-kernel, Jason Wang, virtualization, netdev,
Dinan Gunawardena, Martin Porter, Wu Zongyong, Uminski, Piotr,
Dawar, Gautam, ecree.xilinx, Martin Petrus Hubertus Habets,
Stefano Garzarella, Pablo Cascon Katchadourian, habetsm.xilinx,
Laurent Vivier, Zhu Lingshan, Kamde, Tanuj, Longpeng, Cindy Lu,
Harpreet Singh Anand, Parav Pandit, Si-Wei Liu, Eli Cohen,
Xie Yongji, Zhang Min, Dan Carpenter, Christophe JAILLET
In-Reply-To: <20220810151907-mutt-send-email-mst@kernel.org>
On Wed, Aug 10, 2022 at 9:20 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Wed, Aug 10, 2022 at 07:15:08PM +0200, Eugenio Pérez wrote:
> > Implement suspend operation for vdpa_sim devices, so vhost-vdpa will offer
> > that backend feature and userspace can effectively suspend the device.
> >
> > This is a must before getting virtqueue indexes (base) for live migration,
> > since the device could modify them after userland gets them. There are
> > individual ways to perform that action for some devices
> > (VHOST_NET_SET_BACKEND, VHOST_VSOCK_SET_RUNNING, ...) but there was no
> > way to perform it for any vhost device (and, in particular, vhost-vdpa).
> >
> > After a successful return of ioctl the device must not process more virtqueue
> > descriptors. The device can answer to read or writes of config fields as if it
> > were not suspended. In particular, writing to "queue_enable" with a value of 1
> > will not make the device start processing virtqueue buffers.
> >
> > In the future, we will provide features similar to
> > VHOST_USER_GET_INFLIGHT_FD so the device can save pending operations.
> >
> > Applied on top of [1] branch after removing the old commits.
>
> Except, I can't really do this without invaliding all testing.
> Can't you post an incremental patch?
>
Oops, sorry.
I can send it for doc and internal code. But is it ok to remove an
ioctl arg with incremental patches?
Thanks!
> > Comments are welcome.
> >
> > v7:
> > * Remove ioctl leftover argument and update doc accordingly.
>
> > v6:
> > * Remove the resume operation, making the ioctl simpler. We can always add
> > another ioctl for VM_STOP/VM_RESUME operation later.
> > * s/stop/suspend/ to differentiate more from reset.
> > * Clarify scope of the suspend operation.
> >
> > v5:
> > * s/not stop/resume/ in doc.
> >
> > v4:
> > * Replace VHOST_STOP to VHOST_VDPA_STOP in vhost ioctl switch case too.
> >
> > v3:
> > * s/VHOST_STOP/VHOST_VDPA_STOP/
> > * Add documentation and requirements of the ioctl above its definition.
> >
> > v2:
> > * Replace raw _F_STOP with BIT_ULL(_F_STOP).
> > * Fix obtaining of stop ioctl arg (it was not obtained but written).
> > * Add stop to vdpa_sim_blk.
> >
> > [1] git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git
> >
> > Eugenio Pérez (4):
> > vdpa: Add suspend operation
> > vhost-vdpa: introduce SUSPEND backend feature bit
> > vhost-vdpa: uAPI to suspend the device
> > vdpa_sim: Implement suspend vdpa op
> >
> > drivers/vdpa/vdpa_sim/vdpa_sim.c | 14 +++++++++++
> > drivers/vdpa/vdpa_sim/vdpa_sim.h | 1 +
> > drivers/vdpa/vdpa_sim/vdpa_sim_blk.c | 3 +++
> > drivers/vdpa/vdpa_sim/vdpa_sim_net.c | 3 +++
> > drivers/vhost/vdpa.c | 35 +++++++++++++++++++++++++++-
> > include/linux/vdpa.h | 4 ++++
> > include/uapi/linux/vhost.h | 9 +++++++
> > include/uapi/linux/vhost_types.h | 2 ++
> > 8 files changed, 70 insertions(+), 1 deletion(-)
> >
> > --
> > 2.31.1
> >
>
^ permalink raw reply
* Re: [PATCH net] selftests: forwarding: Fix failing tests with old libnet
From: patchwork-bot+netdevbpf @ 2022-08-11 5:40 UTC (permalink / raw)
To: Ido Schimmel
Cc: netdev, davem, kuba, pabeni, edumazet, amcohen, dsahern, ivecera,
mlxsw
In-Reply-To: <20220809113320.751413-1-idosch@nvidia.com>
Hello:
This patch was applied to netdev/net.git (master)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 9 Aug 2022 14:33:20 +0300 you wrote:
> The custom multipath hash tests use mausezahn in order to test how
> changes in various packet fields affect the packet distribution across
> the available nexthops.
>
> The tool uses the libnet library for various low-level packet
> construction and injection. The library started using the
> "SO_BINDTODEVICE" socket option for IPv6 sockets in version 1.1.6 and
> for IPv4 sockets in version 1.2.
>
> [...]
Here is the summary with links:
- [net] selftests: forwarding: Fix failing tests with old libnet
https://git.kernel.org/netdev/net/c/8bcfb4ae4d97
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [RFC net-next 3/4] ynl: add a sample python library
From: Benjamin Poirier @ 2022-08-11 5:48 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, davem, edumazet, pabeni, sdf, jacob.e.keller, vadfed,
johannes, jiri, dsahern, stephen, fw, linux-doc
In-Reply-To: <20220811022304.583300-4-kuba@kernel.org>
On 2022-08-10 19:23 -0700, Jakub Kicinski wrote:
> A very short and very incomplete generic python library.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
> tools/net/ynl/samples/ynl.py | 342 +++++++++++++++++++++++++++++++++++
> 1 file changed, 342 insertions(+)
> create mode 100644 tools/net/ynl/samples/ynl.py
>
> diff --git a/tools/net/ynl/samples/ynl.py b/tools/net/ynl/samples/ynl.py
> new file mode 100644
> index 000000000000..59c178e063f1
> --- /dev/null
> +++ b/tools/net/ynl/samples/ynl.py
> @@ -0,0 +1,342 @@
[...]
> +class YnlFamily:
> + def __init__(self, def_path, schema=None):
> + with open(def_path, "r") as stream:
> + self.yaml = yaml.safe_load(stream)
> +
> + if schema:
> + with open(os.path.dirname(os.path.dirname(file_name)) + '/schema.yaml', "r") as stream:
> + schema = yaml.safe_load(stream)
> +
> + jsonschema.validate(self.yaml, schema)
> +
The schema validation part was not working. I got it going with the
following changes. It then flags some problems in ethtool.yaml.
diff --git a/tools/net/ynl/samples/ethtool.py b/tools/net/ynl/samples/ethtool.py
index 63c8e29f8e5d..4c5a4629748d 100755
--- a/tools/net/ynl/samples/ethtool.py
+++ b/tools/net/ynl/samples/ethtool.py
@@ -14,7 +14,7 @@ def main():
parser.add_argument('--ifindex', dest='ifindex', type=str)
args = parser.parse_args()
- ynl = YnlFamily(args.spec)
+ ynl = YnlFamily(args.spec, args.schema)
if args.dev_name:
channels = ynl.channels_get({'header': {'dev_name': args.dev_name}})
diff --git a/tools/net/ynl/samples/ynl.py b/tools/net/ynl/samples/ynl.py
index 59c178e063f1..35c894b0ec19 100644
--- a/tools/net/ynl/samples/ynl.py
+++ b/tools/net/ynl/samples/ynl.py
@@ -247,7 +247,7 @@ class YnlFamily:
self.yaml = yaml.safe_load(stream)
if schema:
- with open(os.path.dirname(os.path.dirname(file_name)) + '/schema.yaml', "r") as stream:
+ with open(schema, "r") as stream:
schema = yaml.safe_load(stream)
jsonschema.validate(self.yaml, schema)
^ permalink raw reply related
* Re: [PATCH] net_sched: cls_route: remove from list when handle is 0
From: patchwork-bot+netdevbpf @ 2022-08-11 6:10 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo
Cc: netdev, jhs, xiyou.wangcong, jiri, zplin, kamal, stable
In-Reply-To: <20220809170518.164662-1-cascardo@canonical.com>
Hello:
This patch was applied to netdev/net.git (master)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 9 Aug 2022 14:05:18 -0300 you wrote:
> When a route filter is replaced and the old filter has a 0 handle, the old
> one won't be removed from the hashtable, while it will still be freed.
>
> The test was there since before commit 1109c00547fc ("net: sched: RCU
> cls_route"), when a new filter was not allocated when there was an old one.
> The old filter was reused and the reinserting would only be necessary if an
> old filter was replaced. That was still wrong for the same case where the
> old handle was 0.
>
> [...]
Here is the summary with links:
- net_sched: cls_route: remove from list when handle is 0
https://git.kernel.org/netdev/net/c/9ad36309e271
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net 1/2] tls: rx: device: bound the frag walk
From: patchwork-bot+netdevbpf @ 2022-08-11 6:10 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, tariqt, maximmi, borisp,
john.fastabend, ranro
In-Reply-To: <20220809175544.354343-1-kuba@kernel.org>
Hello:
This series was applied to netdev/net.git (master)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 9 Aug 2022 10:55:43 -0700 you wrote:
> We can't do skb_walk_frags() on the input skbs, because
> the input skbs is really just a pointer to the tcp read
> queue. We need to bound the "is decrypted" check by the
> amount of data in the message.
>
> Note that the walk in tls_device_reencrypt() is after a
> CoW so the skb there is safe to walk. Actually in the
> current implementation it can't have frags at all, but
> whatever, maybe one day it will.
>
> [...]
Here is the summary with links:
- [net,1/2] tls: rx: device: bound the frag walk
https://git.kernel.org/netdev/net/c/86b259f6f888
- [net,2/2] tls: rx: device: don't try to copy too much on detach
https://git.kernel.org/netdev/net/c/d800a7b3577b
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net v2] net/tls: Use RCU API to access tls_ctx->netdev
From: patchwork-bot+netdevbpf @ 2022-08-11 6:10 UTC (permalink / raw)
To: Maxim Mikityanskiy
Cc: davem, edumazet, kuba, pabeni, borisp, saeedm, tariqt,
john.fastabend, gal, netdev, j.vosburgh, vfalico, andy,
ayush.sawal, vinay.yadav, rohitm, kuniyu, dsahern
In-Reply-To: <20220810081602.1435800-1-maximmi@nvidia.com>
Hello:
This patch was applied to netdev/net.git (master)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 10 Aug 2022 11:16:02 +0300 you wrote:
> Currently, tls_device_down synchronizes with tls_device_resync_rx using
> RCU, however, the pointer to netdev is stored using WRITE_ONCE and
> loaded using READ_ONCE.
>
> Although such approach is technically correct (rcu_dereference is
> essentially a READ_ONCE, and rcu_assign_pointer uses WRITE_ONCE to store
> NULL), using special RCU helpers for pointers is more valid, as it
> includes additional checks and might change the implementation
> transparently to the callers.
>
> [...]
Here is the summary with links:
- [net,v2] net/tls: Use RCU API to access tls_ctx->netdev
https://git.kernel.org/netdev/net/c/94ce3b64c62d
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [syzbot] WARNING in ieee80211_ibss_csa_beacon
From: Siddh Raman Pant @ 2022-08-11 6:41 UTC (permalink / raw)
To: syzbot
Cc: davem, johannes, kuba, linux-kernel, linux-wireless, netdev,
syzkaller-bugs
In-Reply-To: <000000000000f5acfd05e5e5ccdc@google.com>
On Wed, 10 Aug 2022 22:17:12 +0530 syzbot wrote:
> Hello,
>
> syzbot tried to test the proposed patch but the build/boot failed:
Trying again.
#syz test https://github.com/siddhpant/linux.git warning_ibss_csa_beacon
^ permalink raw reply
* Re: [PATCH v2 net-next] net: ethernet: ti: davinci_mdio: Add workaround for errata i2329
From: Ravi Gunasekaran @ 2022-08-11 7:00 UTC (permalink / raw)
To: Andrew Lunn
Cc: davem, edumazet, kuba, pabeni, linux-omap, netdev, linux-kernel,
linux-arm-kernel, kishon, vigneshr
In-Reply-To: <YvRNpAdG7/edUEc+@lunn.ch>
On 11/08/22 6:00 am, Andrew Lunn wrote:
>> +static int davinci_mdiobb_read(struct mii_bus *bus, int phy, int reg)
>> +{
>> + int ret;
>> + struct mdiobb_ctrl *ctrl = bus->priv;
>> + struct davinci_mdio_data *data;
>> +
>> + data = container_of(ctrl, struct davinci_mdio_data, bb_ctrl);
>> +
>> + if (phy & ~PHY_REG_MASK || reg & ~PHY_ID_MASK)
>> + return -EINVAL;
>
> You don't need this. Leave it up to the bit banging code to do the
> validation. This also breaks C45, which the bit banging code can do,
> and it looks like the hardware cannot.
I will remove these validation.
>> +
>> + ret = pm_runtime_resume_and_get(data->dev);
>> + if (ret < 0)
>> + return ret;
>> +
>> + ret = mdiobb_read(bus, phy, reg);
>> +
>> + pm_runtime_mark_last_busy(data->dev);
>> + pm_runtime_put_autosuspend(data->dev);
>
> Once you take the validation out, this function then all becomes about
> runtime power management. Should the bit banging core actually be
> doing this? It seems like it is something which could be useful for
> other devices.
>
> struct mii_bus has a parent member. If set, you could apply these run
> time PM functions to that. Please add a patch to modify the core bit
> banging code, and then you should be able to remove these helpers.
Devices may or may not be configured for runtime autosuspend, and
perhaps may not even use runtime PM. pm_runtime_enabled() and the
autosuspend configuration could be addressed by checking against
dev->power.use_autosuspend flag. But if the runtime PM functions are
added to the bit banging core, would it not restrict the usage of
pm_runtime_put_*() variants for others?
There is atleast one device sh_eth, which is not configured for
autosuspend but uses the bit bang core in sh_mdiobb_read() and invokes
regular runtime PM functions.
>> static int davinci_mdio_probe(struct platform_device *pdev)
>> {
>> struct mdio_platform_data *pdata = dev_get_platdata(&pdev->dev);
>> @@ -340,12 +535,30 @@ static int davinci_mdio_probe(struct platform_device *pdev)
>> struct phy_device *phy;
>> int ret, addr;
>> int autosuspend_delay_ms = -1;
>> + const struct soc_device_attribute *soc_match_data;
>
> netdev uses reverse christmas tree. Variables should be sorted longest
> first, shortest last.
Noted. I will fix this as well.
--
Regards,
Ravi
^ permalink raw reply
* Re: [PATCH] Bluetooth: Honor name resolve evt regardless of discov state
From: Archie Pusaka @ 2022-08-11 7:00 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: linux-bluetooth, Marcel Holtmann, CrosBT Upstreaming,
Archie Pusaka, Ying Hsu, David S. Miller, Eric Dumazet,
Jakub Kicinski, Johan Hedberg, Paolo Abeni,
Linux Kernel Mailing List, open list:NETWORKING [GENERAL]
In-Reply-To: <CABBYNZLhhdKLqYu-5OWQcHs22aeEJw0tSjVNhgpMCj_ctH+Ldg@mail.gmail.com>
Hi Luiz,
On Thu, 11 Aug 2022 at 03:58, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> Hi Archie,
>
> On Wed, Aug 10, 2022 at 1:47 AM Archie Pusaka <apusaka@google.com> wrote:
> >
> > From: Archie Pusaka <apusaka@chromium.org>
> >
> > Currently, we don't update the name resolving cache when receiving
> > a name resolve event if the discovery phase is not in the resolving
> > stage.
> >
> > However, if the user connect to a device while we are still resolving
> > remote name for another device, discovery will be stopped, and because
> > we are no longer in the discovery resolving phase, the corresponding
> > remote name event will be ignored, and thus the device being resolved
> > will stuck in NAME_PENDING state.
> >
> > If discovery is then restarted and then stopped, this will cause us to
> > try cancelling the name resolve of the same device again, which is
> > incorrect and might upset the controller.
>
> Please add the Fixes tag.
Unfortunately I don't know when was the issue introduced, I don't even
know whether this is a recent issue or an old one.
Looking back, this part of the code has stayed this way since 2012.
Do I still need to add the fixes tag? If so, does it have to be accurate?
>
> > Signed-off-by: Archie Pusaka <apusaka@chromium.org>
> > Reviewed-by: Ying Hsu <yinghsu@chromium.org>
> >
> > ---
> > The following steps are performed:
> > (1) Prepare 2 classic peer devices that needs RNR. Put device A
> > closer to DUT and device B (much) farther from DUT.
> > (2) Remove all cache and previous connection from DUT
> > (3) Put both peers into pairing mode, then start scanning on DUT
> > (4) After ~8 sec, turn off peer B.
> > *This is done so DUT can discover peer B (discovery time is 10s),
> > but it hasn't started RNR. Peer is turned off to buy us the max
> > time in the RNR phase (5s).
> > (5) Immediately as device A is shown on UI, click to connect.
> > *We thus know that the DUT is in the RNR phase and trying to
> > resolve the name of peer B when we initiate connection to peer A.
> > (6) Forget peer A.
> > (7) Restart scan and stop scan.
> > *Before the CL, stop scan is broken because we will try to cancel
> > a nonexistent RNR
> > (8) Restart scan again. Observe DUT can scan normally.
> >
> >
> > net/bluetooth/hci_event.c | 17 ++++++++++-------
> > 1 file changed, 10 insertions(+), 7 deletions(-)
> >
> > diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> > index 395c6479456f..95e145e278c9 100644
> > --- a/net/bluetooth/hci_event.c
> > +++ b/net/bluetooth/hci_event.c
> > @@ -2453,6 +2453,16 @@ static void hci_check_pending_name(struct hci_dev *hdev, struct hci_conn *conn,
> > !test_and_set_bit(HCI_CONN_MGMT_CONNECTED, &conn->flags))
> > mgmt_device_connected(hdev, conn, name, name_len);
> >
> > + e = hci_inquiry_cache_lookup_resolve(hdev, bdaddr, NAME_PENDING);
> > +
> > + if (e) {
> > + list_del(&e->list);
> > +
> > + e->name_state = name ? NAME_KNOWN : NAME_NOT_KNOWN;
> > + mgmt_remote_name(hdev, bdaddr, ACL_LINK, 0x00, e->data.rssi,
> > + name, name_len);
> > + }
> > +
> > if (discov->state == DISCOVERY_STOPPED)
> > return;
> >
> > @@ -2462,7 +2472,6 @@ static void hci_check_pending_name(struct hci_dev *hdev, struct hci_conn *conn,
> > if (discov->state != DISCOVERY_RESOLVING)
> > return;
> >
> > - e = hci_inquiry_cache_lookup_resolve(hdev, bdaddr, NAME_PENDING);
> > /* If the device was not found in a list of found devices names of which
> > * are pending. there is no need to continue resolving a next name as it
> > * will be done upon receiving another Remote Name Request Complete
> > @@ -2470,12 +2479,6 @@ static void hci_check_pending_name(struct hci_dev *hdev, struct hci_conn *conn,
> > if (!e)
> > return;
> >
> > - list_del(&e->list);
> > -
> > - e->name_state = name ? NAME_KNOWN : NAME_NOT_KNOWN;
> > - mgmt_remote_name(hdev, bdaddr, ACL_LINK, 0x00, e->data.rssi,
> > - name, name_len);
> > -
> > if (hci_resolve_next_name(hdev))
> > return;
> >
> > --
> > 2.37.1.595.g718a3a8f04-goog
> >
>
>
> --
> Luiz Augusto von Dentz
Thanks,
Archie
^ permalink raw reply
* Re: pull-request: bpf 2022-08-10
From: Alexei Starovoitov @ 2022-08-11 7:06 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Daniel Borkmann, David S. Miller, Paolo Abeni, Eric Dumazet,
Alexei Starovoitov, Andrii Nakryiko, Network Development, bpf
In-Reply-To: <20220810211857.51884269@kernel.org>
On Wed, Aug 10, 2022 at 9:18 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Wed, 10 Aug 2022 20:53:57 -0700 Jakub Kicinski wrote:
> > On Wed, 10 Aug 2022 21:06:24 +0200 Daniel Borkmann wrote:
> > > The following pull-request contains BPF updates for your *net* tree.
> >
> > Could you follow up before we send the PR to Linus if this is legit?
> >
> > kernel/bpf/syscall.c:5089:5: warning: no previous prototype for function 'kern_sys_bpf' [-Wmissing-prototypes]
> > int kern_sys_bpf(int cmd, union bpf_attr *attr, unsigned int size)
> > ^
> > kernel/bpf/syscall.c:5089:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
> > int kern_sys_bpf(int cmd, union bpf_attr *attr, unsigned int size)
>
> Looking at the code it seems intentional, even if questionable.
> I wish BPF didn't have all these W=1 warnings, I always worry
> we'll end up letting an real one in since the CI only compares
> counts and the counts seem to fluctuate.
Yeah. It is intentional.
We used all sorts of hacks to shut up this pointless warning.
Just grep for __diag_ignore_all("-Wmissing-prototypes
in two files already.
Here I've opted for the explicit hack and the comment.
Pushed this fix to bpf tree:
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=4e4588f1c4d2e67c993208f0550ef3fae33abce4
Please consider pulling these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
^ permalink raw reply
* [PATCH] net: dsa: mv88e6060: prevent crash on an unused port
From: Sergei Antonov @ 2022-08-11 7:09 UTC (permalink / raw)
To: netdev
Cc: Sergei Antonov, Vivien Didelot, Florian Fainelli,
David S . Miller, Vladimir Oltean
If the port isn't a CPU port nor a user port, 'cpu_dp'
is a null pointer and a crash happened on dereferencing
it in mv88e6060_setup_port():
[ 9.575872] Unable to handle kernel NULL pointer dereference at virtual address 00000014
...
[ 9.942216] mv88e6060_setup from dsa_register_switch+0x814/0xe84
[ 9.948616] dsa_register_switch from mdio_probe+0x2c/0x54
[ 9.954433] mdio_probe from really_probe.part.0+0x98/0x2a0
[ 9.960375] really_probe.part.0 from driver_probe_device+0x30/0x10c
[ 9.967029] driver_probe_device from __device_attach_driver+0xb8/0x13c
[ 9.973946] __device_attach_driver from bus_for_each_drv+0x90/0xe0
[ 9.980509] bus_for_each_drv from __device_attach+0x110/0x184
[ 9.986632] __device_attach from bus_probe_device+0x8c/0x94
[ 9.992577] bus_probe_device from deferred_probe_work_func+0x78/0xa8
[ 9.999311] deferred_probe_work_func from process_one_work+0x290/0x73c
[ 10.006292] process_one_work from worker_thread+0x30/0x4b8
[ 10.012155] worker_thread from kthread+0xd4/0x10c
[ 10.017238] kthread from ret_from_fork+0x14/0x3c
Fixes: 0abfd494deef ("net: dsa: use dedicated CPU port")
CC: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
CC: Florian Fainelli <f.fainelli@gmail.com>
CC: David S. Miller <davem@davemloft.net>
Signed-off-by: Sergei Antonov <saproj@gmail.com>
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
---
drivers/net/dsa/mv88e6060.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/dsa/mv88e6060.c b/drivers/net/dsa/mv88e6060.c
index a4c6eb9a52d0..83dca9179aa0 100644
--- a/drivers/net/dsa/mv88e6060.c
+++ b/drivers/net/dsa/mv88e6060.c
@@ -118,6 +118,9 @@ static int mv88e6060_setup_port(struct mv88e6060_priv *priv, int p)
int addr = REG_PORT(p);
int ret;
+ if (dsa_is_unused_port(priv->ds, p))
+ return 0;
+
/* Do not force flow control, disable Ingress and Egress
* Header tagging, disable VLAN tunneling, and set the port
* state to Forwarding. Additionally, if this is the CPU
--
2.32.0
^ permalink raw reply related
* [syzbot] linux-next boot error: general protection fault in netdev_queue_update_kobjects
From: syzbot @ 2022-08-11 7:29 UTC (permalink / raw)
To: atenart, davem, edumazet, kuba, linux-kernel, linux-next, netdev,
pabeni, sfr, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: bc6c6584ffb2 Add linux-next specific files for 20220810
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1518dbbb080000
kernel config: https://syzkaller.appspot.com/x/.config?x=5784be4315a4403b
dashboard link: https://syzkaller.appspot.com/bug?extid=cf0ad9bc61d1fa5ef614
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+cf0ad9bc61d1fa5ef614@syzkaller.appspotmail.com
input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1
ACPI: button: Sleep Button [SLPF]
ACPI: \_SB_.LNKC: Enabled at IRQ 11
virtio-pci 0000:00:03.0: virtio_pci: leaving for legacy driver
ACPI: \_SB_.LNKD: Enabled at IRQ 10
virtio-pci 0000:00:04.0: virtio_pci: leaving for legacy driver
ACPI: \_SB_.LNKB: Enabled at IRQ 10
virtio-pci 0000:00:06.0: virtio_pci: leaving for legacy driver
virtio-pci 0000:00:07.0: virtio_pci: leaving for legacy driver
N_HDLC line discipline registered with maxframe=4096
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
00:04: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
00:05: ttyS2 at I/O 0x3e8 (irq = 6, base_baud = 115200) is a 16550A
00:06: ttyS3 at I/O 0x2e8 (irq = 7, base_baud = 115200) is a 16550A
Non-volatile memory driver v1.3
Linux agpgart interface v0.103
ACPI: bus type drm_connector registered
[drm] Initialized vgem 1.0.0 20120112 for vgem on minor 0
[drm] Initialized vkms 1.0.0 20180514 for vkms on minor 1
Console: switching to colour frame buffer device 128x48
platform vkms: [drm] fb0: vkmsdrmfb frame buffer device
usbcore: registered new interface driver udl
brd: module loaded
loop: module loaded
zram: Added device: zram0
null_blk: disk nullb0 created
null_blk: module loaded
Guest personality initialized and is inactive
VMCI host device registered (name=vmci, major=10, minor=120)
Initialized host personality
usbcore: registered new interface driver rtsx_usb
usbcore: registered new interface driver viperboard
usbcore: registered new interface driver dln2
usbcore: registered new interface driver pn533_usb
nfcsim 0.2 initialized
usbcore: registered new interface driver port100
usbcore: registered new interface driver nfcmrvl
Loading iSCSI transport class v2.0-870.
scsi host0: Virtio SCSI HBA
st: Version 20160209, fixed bufsize 32768, s/g segs 256
Rounding down aligned max_sectors from 4294967295 to 4294967288
db_root: cannot open: /etc/target
slram: not enough parameters.
ftl_cs: FTL header not found.
wireguard: WireGuard 1.0.0 loaded. See www.wireguard.com for information.
wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
eql: Equalizer2002: Simon Janes (simon@ncm.com) and David S. Miller (davem@redhat.com)
MACsec IEEE 802.1AE
tun: Universal TUN/TAP device driver, 1.6
general protection fault, probably for non-canonical address 0xffff000000000800: 0000 [#1] PREEMPT SMP KASAN
KASAN: maybe wild-memory-access in range [0xfff8200000004000-0xfff8200000004007]
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-next-20220810-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022
RIP: 0010:freelist_dereference mm/slub.c:347 [inline]
RIP: 0010:get_freepointer mm/slub.c:354 [inline]
RIP: 0010:get_freepointer_safe mm/slub.c:368 [inline]
RIP: 0010:slab_alloc_node mm/slub.c:3211 [inline]
RIP: 0010:slab_alloc mm/slub.c:3251 [inline]
RIP: 0010:kmem_cache_alloc_trace+0x164/0x3e0 mm/slub.c:3282
Code: 8b 51 08 48 8b 01 48 83 79 10 00 48 89 44 24 08 0f 84 bf 01 00 00 48 85 c0 0f 84 b6 01 00 00 48 8b 7d 00 8b 4d 28 40 f6 c7 0f <48> 8b 1c 08 0f 85 c2 01 00 00 48 8d 4a 08 65 48 0f c7 0f 0f 94 c0
RSP: 0000:ffffc90000067810 EFLAGS: 00010246
RAX: ffff000000000000 RBX: 0000000000000000 RCX: 0000000000000800
RDX: 0000000000002d18 RSI: 0000000000000dc0 RDI: 000000000003dce0
RBP: ffff888011842140 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000dc0 R14: 0000000000000a20 R15: 0000000000000dc0
FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff88823ffff000 CR3: 000000000bc8e000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
kmalloc include/linux/slab.h:600 [inline]
kzalloc include/linux/slab.h:733 [inline]
kobject_uevent_env+0x230/0x1640 lib/kobject_uevent.c:524
netdev_queue_add_kobject net/core/net-sysfs.c:1677 [inline]
netdev_queue_update_kobjects+0x3d1/0x4e0 net/core/net-sysfs.c:1718
register_queue_kobjects net/core/net-sysfs.c:1779 [inline]
netdev_register_kobject+0x330/0x400 net/core/net-sysfs.c:2019
register_netdevice+0xe01/0x1680 net/core/dev.c:10070
virtnet_probe+0x1378/0x2f30 drivers/net/virtio_net.c:3923
virtio_dev_probe+0x577/0x870 drivers/virtio/virtio.c:305
call_driver_probe drivers/base/dd.c:530 [inline]
really_probe+0x249/0xb90 drivers/base/dd.c:609
__driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:748
driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:778
__driver_attach+0x223/0x550 drivers/base/dd.c:1150
bus_for_each_dev+0x147/0x1d0 drivers/base/bus.c:301
bus_add_driver+0x4c9/0x640 drivers/base/bus.c:618
driver_register+0x220/0x3a0 drivers/base/driver.c:240
virtio_net_driver_init+0x93/0xd2 drivers/net/virtio_net.c:4102
do_one_initcall+0xfe/0x650 init/main.c:1299
do_initcall_level init/main.c:1374 [inline]
do_initcalls init/main.c:1390 [inline]
do_basic_setup init/main.c:1409 [inline]
kernel_init_freeable+0x6b1/0x73a init/main.c:1616
kernel_init+0x1a/0x1d0 init/main.c:1505
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
</TASK>
Modules linked in:
----------------
Code disassembly (best guess):
0: 8b 51 08 mov 0x8(%rcx),%edx
3: 48 8b 01 mov (%rcx),%rax
6: 48 83 79 10 00 cmpq $0x0,0x10(%rcx)
b: 48 89 44 24 08 mov %rax,0x8(%rsp)
10: 0f 84 bf 01 00 00 je 0x1d5
16: 48 85 c0 test %rax,%rax
19: 0f 84 b6 01 00 00 je 0x1d5
1f: 48 8b 7d 00 mov 0x0(%rbp),%rdi
23: 8b 4d 28 mov 0x28(%rbp),%ecx
26: 40 f6 c7 0f test $0xf,%dil
* 2a: 48 8b 1c 08 mov (%rax,%rcx,1),%rbx <-- trapping instruction
2e: 0f 85 c2 01 00 00 jne 0x1f6
34: 48 8d 4a 08 lea 0x8(%rdx),%rcx
38: 65 48 0f c7 0f cmpxchg16b %gs:(%rdi)
3d: 0f 94 c0 sete %al
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* [PATCH 1/2] virtio_net: fix for stuck when change rx ring size with dev down
From: Xuan Zhuo @ 2022-08-11 8:02 UTC (permalink / raw)
To: virtualization
Cc: Michael S. Tsirkin, Jason Wang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, Kangjie Xu
In-Reply-To: <20220811080258.79398-1-xuanzhuo@linux.alibaba.com>
When dev is set to DOWN state, napi has been disabled, if we modify the
ring size at this time, we should not call napi_disable() again, which
will cause stuck.
And all operations are under the protection of rtnl_lock, so there is no
need to consider concurrency issues.
Reported-by: Kangjie Xu <kangjie.xu@linux.alibaba.com>
Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
---
drivers/net/virtio_net.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 816c613c22f7..17687eb3f0bd 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1892,11 +1892,13 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
static int virtnet_rx_resize(struct virtnet_info *vi,
struct receive_queue *rq, u32 ring_num)
{
+ bool running = netif_running(vi->dev);
int err, qindex;
qindex = rq - vi->rq;
- napi_disable(&rq->napi);
+ if (running)
+ napi_disable(&rq->napi);
err = virtqueue_resize(rq->vq, ring_num, virtnet_rq_free_unused_buf);
if (err)
@@ -1905,7 +1907,8 @@ static int virtnet_rx_resize(struct virtnet_info *vi,
if (!try_fill_recv(vi, rq, GFP_KERNEL))
schedule_delayed_work(&vi->refill, 0);
- virtnet_napi_enable(rq->vq, &rq->napi);
+ if (running)
+ virtnet_napi_enable(rq->vq, &rq->napi);
return err;
}
--
2.31.0
^ permalink raw reply related
* [PATCH vhost 0/2] virtio_net: fix for stuck when change ring size with dev down
From: Xuan Zhuo @ 2022-08-11 8:02 UTC (permalink / raw)
To: virtualization
Cc: Michael S. Tsirkin, Jason Wang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev
When dev is set to DOWN state, napi has been disabled, if we modify the
ring size at this time, we should not call napi_disable() again, which
will cause stuck.
And all operations are under the protection of rtnl_lock, so there is no
need to consider concurrency issues.
PS.
Hi Michael, I don't know which way is more convenient for you, so I split the
commit into two commits, so you can fixup to my previous commit:
virtio_net: support tx queue resize
virtio_net: support rx queue resize
Xuan Zhuo (2):
virtio_net: fix for stuck when change rx ring size with dev down
virtio_net: fix for stuck when change tx ring size with dev down
drivers/net/virtio_net.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
--
2.31.0
^ permalink raw reply
* [PATCH 2/2] virtio_net: fix for stuck when change tx ring size with dev down
From: Xuan Zhuo @ 2022-08-11 8:02 UTC (permalink / raw)
To: virtualization
Cc: Michael S. Tsirkin, Jason Wang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, Kangjie Xu
In-Reply-To: <20220811080258.79398-1-xuanzhuo@linux.alibaba.com>
When dev is set to DOWN state, napi has been disabled, if we modify the
ring size at this time, we should not call napi_disable() again, which
will cause stuck.
And all operations are under the protection of rtnl_lock, so there is no
need to consider concurrency issues.
Reported-by: Kangjie Xu <kangjie.xu@linux.alibaba.com>
Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
---
drivers/net/virtio_net.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 17687eb3f0bd..d9c434b00e9b 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1915,12 +1915,14 @@ static int virtnet_rx_resize(struct virtnet_info *vi,
static int virtnet_tx_resize(struct virtnet_info *vi,
struct send_queue *sq, u32 ring_num)
{
+ bool running = netif_running(vi->dev);
struct netdev_queue *txq;
int err, qindex;
qindex = sq - vi->sq;
- virtnet_napi_tx_disable(&sq->napi);
+ if (running)
+ virtnet_napi_tx_disable(&sq->napi);
txq = netdev_get_tx_queue(vi->dev, qindex);
@@ -1946,7 +1948,8 @@ static int virtnet_tx_resize(struct virtnet_info *vi,
netif_tx_wake_queue(txq);
__netif_tx_unlock_bh(txq);
- virtnet_napi_tx_enable(vi, sq->vq, &sq->napi);
+ if (running)
+ virtnet_napi_tx_enable(vi, sq->vq, &sq->napi);
return err;
}
--
2.31.0
^ permalink raw reply related
* Re: [PATCH net] bonding: fix reference count leak in balance-alb mode
From: Nikolay Aleksandrov @ 2022-08-11 8:03 UTC (permalink / raw)
To: Jay Vosburgh, netdev, sunshouxin
Cc: vfalico, andy, davem, edumazet, kuba, pabeni, linux-kernel,
huyd12
In-Reply-To: <26758.1660194413@famine>
On 11/08/2022 08:06, Jay Vosburgh wrote:
> Commit d5410ac7b0ba ("net:bonding:support balance-alb interface
> with vlan to bridge") introduced a reference count leak by not releasing
> the reference acquired by ip_dev_find(). Remedy this by insuring the
> reference is released.
>
> Fixes: d5410ac7b0ba ("net:bonding:support balance-alb interface with vlan to bridge")
> Signed-off-by: Jay Vosburgh <jay.vosburgh@canonical.com>
>
> ---
> drivers/net/bonding/bond_alb.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
> index 60cb9a0225aa..b9dbad3a8af8 100644
> --- a/drivers/net/bonding/bond_alb.c
> +++ b/drivers/net/bonding/bond_alb.c
> @@ -668,8 +668,11 @@ static struct slave *rlb_arp_xmit(struct sk_buff *skb, struct bonding *bond)
>
> dev = ip_dev_find(dev_net(bond->dev), arp->ip_src);
> if (dev) {
> - if (netif_is_bridge_master(dev))
> + if (netif_is_bridge_master(dev)) {
> + dev_put(dev);
> return NULL;
> + }
> + dev_put(dev);
> }
>
> if (arp->op_code == htons(ARPOP_REPLY)) {
Nice catch,
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
^ permalink raw reply
* Re: [PATCH] fec: Restart PPS after link state change
From: Csókás Bence @ 2022-08-11 8:07 UTC (permalink / raw)
To: Andrew Lunn, Richard Cochran; +Cc: netdev, Fugang Duan
In-Reply-To: <YvRjzwMsMWv3AG1H@lunn.ch>
On 2022. 08. 11. 4:05, Andrew Lunn wrote:
> On Wed, Aug 10, 2022 at 06:37:19PM -0700, Richard Cochran wrote:
>> On Thu, Aug 11, 2022 at 02:05:39AM +0200, Andrew Lunn wrote:
>>>> Yes. We use PPS to synchronize devices on a common backplane. We use PTP to
>>>> sync this PPS to a master clock. But if PTP sync drops out, we wouldn't want
>>>> the backplane-level synchronization to fail. The PPS needs to stay on as
>>>> long as userspace *explicitly* disables it, regardless of what happens to
>>>> the link.
>>>
>>> We need the PTP Maintainers view on that. I don't know if that is
>>> normal or not.
>>
>> IMO the least surprising behavior is that once enabled, a feature
>> stays on until explicitly disabled.
>
> O.K, thanks for the response.
>
> Your answer is a bit surprising to me. To me, an interface which is
> administratively down is completely inactive. The action to down it
> should disable everything.
I think you are confusing two states here. This patch addresses the bug
thatcauses the PPS to drop when the Ethernet link goes away. The
interface remainsUP the whole time.
>
> So your answer also implies PPS can be used before the interface is
> set administratively up?
The PPS can already be used before the first link-up, but once it has
acquired a link once, PPS no longer works without a link.
>
> Andrew
^ permalink raw reply
* Re: Question: Ethernet Phy issues on Colibri IMX8X (imx8qxp) - kernel 5.19
From: Philippe Schenker @ 2022-08-11 8:07 UTC (permalink / raw)
To: linux-arm-kernel@lists.infradead.org, Marcel Ziswiler,
netdev@vger.kernel.org, embed3d@gmail.com,
qiangqing.zhang@nxp.com
Cc: philipp.rossak@formulastudent.de, guoniu.zhou@nxp.com,
aisheng.dong@nxp.com, abel.vesa@nxp.com, andrew@lunn.ch
In-Reply-To: <47c884e9-e5ea-16a2-38e5-7b7f61e77e80@gmail.com>
On Wed, 2022-08-10 at 20:40 +0200, Philipp Rossak wrote:
> > Hi Marcel,
> >
> > thanks!
> >
> > With the removed line it is working now!
> >
> > I hope there will be a mainlined solution soon.
This is an interesting question. Since it's a SCFW issue and a general
question about these SoCs, I'll take the liberty of hijacking this
thread for some questions (since NXP is also in the loop now).
@NXP people: which SCFW version should be used in general with mainline
linux-kernel ?
And how is it planned to proceed with SC-firmware enabled SoCs on
mainline linux?
Is the SCFW API backward compatible?
If so, from which version on?
Thanks in advance for enlightening us all on this SCFW issue.
Philippe
> > Cheers
> > Philipp
> >
> > On 10.08.22 10:05, Marcel Ziswiler wrote:
> > > > Sali Philipp
> > > >
> > > > On Wed, 2022-08-10 at 00:55 +0200, Philipp Rossak wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I currently have a project with a Toradex Colibri IMX8X SOM
> > > > > > board> >> whith
> > > > > > an onboard Micrel KSZ8041NL Ethernet PHY.
> > > > > >
> > > > > > The hardware is described in the devictree properly so I
> > > > > > expected> >> that
> > > > > > the onboard Ethernet with the phy is working.
> > > > > >
> > > > > > Currently I'm not able to get the link up.
> > > > > >
> > > > > > I already compared it to the BSP kernel, but I didn't found>
> > > > > > >> anything
> > > > > > helpful. The BSP kernel is working.
> > > > > >
> > > > > > Do you know if there is something in the kernel missing and
> > > > > > got it> >> running?
> > > >
> > > > Yes, you may just revert the following commit babfaa9556d7
> > > > ("clk:> >imx: scu: add more scu clocks")
> > > >
> > > > Alternatively, just commenting out the following single line
> > > > also> >helps:
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/imx/clk-imx8qxp.c?h=v5.19#n172
> > > >
> > > > I just found this out about two weeks ago before I went to
> > > > vacation> >and since have to find out with NXP what
> > > > exactly the idea of this clocking/SCFW stuff is related to our>
> > > > >hardware.
> > > >
> > > > @NXP: If any of you guys could shed some light that would be
> > > > much> >appreciated. Thanks!
> > > >
> > > > > > Thanks,
> > > > > > Philipp
> > > >
> > > > Cheers
> > > >
> > > > Marcel
> >
^ permalink raw reply
* Re:Re: [PATCH] net: usb: qmi_wwan: Add support for Cinterion MV32
From: Slark Xiao @ 2022-08-11 8:07 UTC (permalink / raw)
To: Bjørn Mork
Cc: davem, edumazet, kuba, pabeni, netdev, linux-usb, linux-kernel
In-Reply-To: <87mtccl1ir.fsf@miraculix.mork.no>
At 2022-08-10 20:35:24, "Bjørn Mork" <bjorn@mork.no> wrote:
>"Slark Xiao" <slark_xiao@163.com> writes:
>> At 2022-08-10 17:28:51, "Slark Xiao" <slark_xiao@163.com> wrote:
>>
>>>I have a concern, if Cinterion or other Vendors, like Quectel, use other
>>>chip (such as intel, mediateck and so on), this methods may won't work,
>>
>> My bad. QMI_WWAN driver is designed for Qualcomm based chips only,
>> right?
>
>Yes, but your concern is still valid if any of them re-use ff/ff/50 for
>something which is not RMNET/QMI. We do not want this driver to start
>matching a non-Qualcomm based device.
>
>>>because they share a same VID. Also this may be changed once Qualcomm
>>>update the protocol patterns for future chip.
>
>Yes, that' a risk since we have no knowledge of Qualcomm's plans or
>thoughts around this. It's all pure guesswork from my side. But as
>such, it doesn't differ from the rest of this driver :-) Qualcomm can
>change whatever they want and we'll just have to follow up with whatever
>is required. Like what happened when raw-ip became mandatory.
>
>I do find it unlikely that Qualcomm will ever change the meaning of this
>pattern now that they've started using it. That would not make any
>sense. If they need to create a new vendor specific function type, then
>they can just use one of the "free" protocol numbers (and also subclass
>if they run out of protocol numbers).
>
>But it's your call. If you want to play it safe and keep the VID+PID
>matching, then I'm fine with that too.
>
>
>Bjørn
Then please help me apply it directly. There is no more commit
request for MV32 serials if they don't update base line.
Thanks.
^ permalink raw reply
* Re: [PATCH vhost 0/2] virtio_net: fix for stuck when change ring size with dev down
From: Michael S. Tsirkin @ 2022-08-11 8:11 UTC (permalink / raw)
To: Xuan Zhuo
Cc: virtualization, Jason Wang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev
In-Reply-To: <20220811080258.79398-1-xuanzhuo@linux.alibaba.com>
On Thu, Aug 11, 2022 at 04:02:56PM +0800, Xuan Zhuo wrote:
> When dev is set to DOWN state, napi has been disabled, if we modify the
> ring size at this time, we should not call napi_disable() again, which
> will cause stuck.
>
> And all operations are under the protection of rtnl_lock, so there is no
> need to consider concurrency issues.
>
> PS.
> Hi Michael, I don't know which way is more convenient for you, so I split the
> commit into two commits, so you can fixup to my previous commit:
>
> virtio_net: support tx queue resize
> virtio_net: support rx queue resize
>
> Xuan Zhuo (2):
> virtio_net: fix for stuck when change rx ring size with dev down
> virtio_net: fix for stuck when change tx ring size with dev down
>
> drivers/net/virtio_net.c | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
Which patches does this fix?
Maybe I should squash.
> --
> 2.31.0
^ permalink raw reply
* Re: [PATCH vhost 0/2] virtio_net: fix for stuck when change ring size with dev down
From: Xuan Zhuo @ 2022-08-11 8:12 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: virtualization, Jason Wang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev
In-Reply-To: <20220811041041-mutt-send-email-mst@kernel.org>
On Thu, 11 Aug 2022 04:11:22 -0400, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Thu, Aug 11, 2022 at 04:02:56PM +0800, Xuan Zhuo wrote:
> > When dev is set to DOWN state, napi has been disabled, if we modify the
> > ring size at this time, we should not call napi_disable() again, which
> > will cause stuck.
> >
> > And all operations are under the protection of rtnl_lock, so there is no
> > need to consider concurrency issues.
> >
> > PS.
> > Hi Michael, I don't know which way is more convenient for you, so I split the
> > commit into two commits, so you can fixup to my previous commit:
> >
> > virtio_net: support tx queue resize
> > virtio_net: support rx queue resize
> >
> > Xuan Zhuo (2):
> > virtio_net: fix for stuck when change rx ring size with dev down
> > virtio_net: fix for stuck when change tx ring size with dev down
> >
> > drivers/net/virtio_net.c | 14 ++++++++++----
> > 1 file changed, 10 insertions(+), 4 deletions(-)
>
>
> Which patches does this fix?
> Maybe I should squash.
These two:
virtio_net: support tx queue resize
virtio_net: support rx queue resize
Thanks.
>
> > --
> > 2.31.0
>
^ permalink raw reply
* Re: [PATCH v2] tcp: adjust rcvbuff according copied rate of user space
From: Yonglong Li @ 2022-08-11 8:14 UTC (permalink / raw)
To: Neal Cardwell; +Cc: netdev, davem, edumazet, ycheng, dsahern, kuba, pabeni
In-Reply-To: <CADVnQym47_uqqKWkGnu7hA+vhHjvURMmTdd0Xx6z8m_mspwFJw@mail.gmail.com>
On 8/10/2022 8:43 PM, Neal Cardwell wrote:
> On Wed, Aug 10, 2022 at 3:49 AM Yonglong Li <liyonglong@chinatelecom.cn> wrote:
>>
>> every time data is copied to user space tcp_rcv_space_adjust is called.
>> current It adjust rcvbuff by the length of data copied to user space.
>> If the interval of user space copy data from socket is not stable, the
>> length of data copied to user space will not exactly show the speed of
>> copying data from rcvbuff.
>> so in tcp_rcv_space_adjust it is more reasonable to adjust rcvbuff by
>> copied rate (length of copied data/interval)instead of copied data len
>>
>> I tested this patch in simulation environment by Mininet:
>> with 80~120ms RTT / 1% loss link, 100 runs
>> of (netperf -t TCP_STREAM -l 5), and got an average throughput
>> of 17715 Kbit instead of 17703 Kbit.
>> with 80~120ms RTT without loss link, 100 runs of (netperf -t
>> TCP_STREAM -l 5), and got an average throughput of 18272 Kbit
>> instead of 18248 Kbit.
>
> So with 1% emulated loss that's a 0.06% throughput improvement and
> without emulated loss that's a 0.13% improvement. That sounds like it
> may well be statistical noise, particularly given that we would expect
> the steady-state impact of this change to be negligible.
>
Hi neal,
Thank you for your feedback.
I don't think the improvement is statistical noise. Because I can get small
improvement after patch every time I test.
--
Li YongLong
^ permalink raw reply
* Re: [PATCH] net: dsa: mv88e6060: report max mtu 1536
From: Sergei Antonov @ 2022-08-11 8:23 UTC (permalink / raw)
To: Vladimir Oltean; +Cc: netdev, Florian Fainelli
In-Reply-To: <20220810193825.vq7rdgwx7xua5amj@skbuf>
On Wed, 10 Aug 2022 at 22:38, Vladimir Oltean <olteanv@gmail.com> wrote:
> > > The bug seems to have been introduced by commit 0abfd494deef ("net: dsa:
> > > use dedicated CPU port"), because, although before we'd be uselessly
> > > programming the port VLAN for a disabled port, now in doing so, we
> > > dereference a NULL pointer.
> >
> > The suggested fix with dsa_is_unused_port() works. I tested it on the
> > 'netdev/net.git' repo, see below. Should I submit it as a patch
> > (Fixes: 0abfd494deef)?
>
> Yes. See the section that talks about "git log -1 --pretty=fixes" in
> process/submitting-patches.rst for how the Fixes tag should actually
> look like.
>
> I thought about whether dsa_is_unused_port() is sufficient, since
> theoretically dsa_is_dsa_port() is also a possibility which isn't
> covered by the check. But I rechecked and it appears that the Marvell
> 6060 doesn't support cascade ports, so we should be fine with just that.
Great. I submitted a patch.
> > So I tested "dsa_is_unused_port()" and "switch@10" fixes with
> > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
> > What I did after system boot-up:
> >
> > ~ # dmesg | grep mv88
> > [ 7.187296] mv88e6060 92000090.mdio--1-mii:10: switch Marvell 88E6060 (B0) detected
> > [ 8.325712] mv88e6060 92000090.mdio--1-mii:10: switch Marvell 88E6060 (B0) detected
> > [ 9.190299] mv88e6060 92000090.mdio--1-mii:10 lan2 (uninitialized): PHY [dsa-0.0:02] driver [Generic PHY] (irq=POLL)
> >
> > ~ # ip a
> > 1: lo: <LOOPBACK> mtu 65536 qdisc noop qlen 1000
> > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> > 2: eth0: <BROADCAST,MULTICAST> mtu 1504 qdisc noop qlen 1000
> > link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
>
> The DSA master is super odd for starting with an all-zero MAC address.
> What driver handles this part? Normally, drivers are expected to work
> with a MAC address provided by the firmware (of_get_mac_address or
> other, perhaps proprietary, means) and fall back to eth_random_addr()
> if that is missing.
eth0 is handled by the CONFIG_ARM_MOXART_ETHER driver. By the way, I
had to change some code in it to make it work, and I am going to
submit a patch or two later.
The driver does not know its MAC address initially. On my hardware it
is stored in a flash memory chip, so I assign it using "ip link set
..." either manually or from an /etc/init.d script. A solution with
early MAC assignment in the moxart_mac_probe() function is doable. Do
you think I should implement it?
> > 3: lan2@eth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop qlen 1000
> > link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
>
> Here DSA inherits the MAC address of the master. It does this by default
> in dsa_slave_create() -> eth_hw_addr_inherit(). If the OF node for the
> DSA port has its own MAC address, that will have priority over the MAC
> address of the master.
I quickly tried setting a MAC address in the moxart_mac_probe()
function and DSA did inherit it. Looks like the way to go.
> > ~ # ip link set dev eth0 address 00:90:e8:00:10:03 up
>
> This shouldn't be necessary, neither assigning a MAC address nor putting
> the master up, see Documentation/networking/dsa/configuration.rst, the
> master comes up automatically.
Yes, it indeed does. Thanks.
> > ~ # ip a add 192.168.127.254/24 dev lan2
> >
> > ~ # ip link set dev lan2 address 00:90:e8:00:10:03 up
> > [ 56.383801] DSA: failed to set STP state 3 (-95)
>
> errno 95 is EOPNOTSUPP, we shouldn't warn here, I'll submit a patch for
> that.
Great, I'll review it.
> > Is it correct for eth0 and lan2@eth0 to have the same MAC?
>
> It is not wrong, it's a configuration that many deployed DSA systems use.
Is it also not wrong with several lanN@eth0 interfaces? I'm asking it
because I will probably need to support hardware with more than one
port on the 6060.
> > I could not make it work with different MACs.
>
> That is a problem, and I believe it's a problem with the DSA master driver.
> See, the reason it should work is this. Switch ports don't really have a
> MAC address, since they forward everything and not really terminate anything.
> The MAC address of a switch port is a software construct which means
> that software L3 termination interfaces (of which we have one per port)
> should accept packets with some known MAC DA, and drop the rest, and
> everything should be fine.
>
> There are multiple kinds of DSA tags, but 6060 uses a trailer, and this
> will not shift the 'real' MAC DA of packets compared to where the DSA
> master expects to see them. So if the MAC address of the DSA master is A,
> the MAC address of lan2 is B, and you ping lan2 from the outside world,
> the DSA master will see packets with a MAC DA of B.
>
> So the DSA master sees packets with a MAC DA different from its own
> dev->dev_addr (A) and thinks it's within its right to drop them. Except
> that it isn't, because we do the following to prevent it:
>
> (1) in case the DSA master supports IFF_UNICAST_FLT, we call dev_uc_add()
> from dsa_slave_set_mac_address() and from dsa_slave_open(), and this
> informs it of our address B.
> (2) in case it doesn't support IFF_UNICAST_FLT, we just call
> dsa_master_set_promiscuity() and that should keep it promiscuous and
> it should accept packets regardless of MAC DA (that's the definition).
>
> So you should run some tcpdump and ethtool -S on the DSA master and see
> whether it receives any packets or it drops them. It's possible that
> tcpdump makes packets be accepted, since it puts the interface in
> promiscuous mode.
When I tried to make it work with different MAC addresses, I used
Wireshark and saw that ARP packets did not reach the interface unless
they were broadcast. I might have been a configuration issue rather
than driver issue. Thanks for the explanation! But I will happily
stick to the common MAC address solution if it is not wrong.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox