* Re: [PATCH net] net: genl: fix error path memory leak in policy dumping
From: Jakub Kicinski @ 2022-08-16 1:23 UTC (permalink / raw)
To: davem; +Cc: netdev, edumazet, pabeni, johannes.berg,
syzbot+dc54d9ba8153b216cae0
In-Reply-To: <20220815182021.48925-1-kuba@kernel.org>
On Mon, 15 Aug 2022 11:20:21 -0700 Jakub Kicinski wrote:
> If construction of the array of policies fails when recording
> non-first policy we need to unwind.
>
> Reported-by: syzbot+dc54d9ba8153b216cae0@syzkaller.appspotmail.com
> Fixes: 50a896cf2d6f ("genetlink: properly support per-op policy dumping")
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
syzbot says still pooped, indeed there's more leaks in
netlink_policy_dump_add_policy() itself. v2 coming...
^ permalink raw reply
* Re: [PATCH 1/2] vDPA: allow userspace to query features of a vDPA device
From: Zhu, Lingshan @ 2022-08-16 1:49 UTC (permalink / raw)
To: Si-Wei Liu, jasowang, mst
Cc: virtualization, netdev, kvm, parav, xieyongji, gautam.dawar
In-Reply-To: <15a9ba60-f6f5-f73a-8923-0d0513ea7d62@oracle.com>
On 8/16/2022 2:15 AM, Si-Wei Liu wrote:
>
>
> On 8/15/2022 2:26 AM, Zhu Lingshan wrote:
>> This commit adds a new vDPA netlink attribution
>> VDPA_ATTR_VDPA_DEV_SUPPORTED_FEATURES. Userspace can query
>> features of vDPA devices through this new attr.
>>
>> Signed-off-by: Zhu Lingshan <lingshan.zhu@intel.com>
>> ---
>> drivers/vdpa/vdpa.c | 17 +++++++++++++----
>> include/uapi/linux/vdpa.h | 3 +++
>> 2 files changed, 16 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c
>> index c06c02704461..efb55a06e961 100644
>> --- a/drivers/vdpa/vdpa.c
>> +++ b/drivers/vdpa/vdpa.c
>> @@ -491,6 +491,8 @@ static int vdpa_mgmtdev_fill(const struct
>> vdpa_mgmt_dev *mdev, struct sk_buff *m
>> err = -EMSGSIZE;
>> goto msg_err;
>> }
>> +
>> + /* report features of a vDPA management device through
>> VDPA_ATTR_DEV_SUPPORTED_FEATURES */
>> if (nla_put_u64_64bit(msg, VDPA_ATTR_DEV_SUPPORTED_FEATURES,
>> mdev->supported_features, VDPA_ATTR_PAD)) {
>> err = -EMSGSIZE;
>> @@ -815,7 +817,7 @@ static int vdpa_dev_net_mq_config_fill(struct
>> vdpa_device *vdev,
>> static int vdpa_dev_net_config_fill(struct vdpa_device *vdev,
>> struct sk_buff *msg)
>> {
>> struct virtio_net_config config = {};
>> - u64 features;
>> + u64 features_device, features_driver;
>> u16 val_u16;
>> vdpa_get_config_unlocked(vdev, 0, &config, sizeof(config));
>> @@ -832,12 +834,19 @@ static int vdpa_dev_net_config_fill(struct
>> vdpa_device *vdev, struct sk_buff *ms
>> if (nla_put_u16(msg, VDPA_ATTR_DEV_NET_CFG_MTU, val_u16))
>> return -EMSGSIZE;
>> - features = vdev->config->get_driver_features(vdev);
>> - if (nla_put_u64_64bit(msg, VDPA_ATTR_DEV_NEGOTIATED_FEATURES,
>> features,
>> + features_driver = vdev->config->get_driver_features(vdev);
>> + if (nla_put_u64_64bit(msg, VDPA_ATTR_DEV_NEGOTIATED_FEATURES,
>> features_driver,
>> + VDPA_ATTR_PAD))
>> + return -EMSGSIZE;
>> +
>> + features_device = vdev->config->get_device_features(vdev);
>> +
>> + /* report features of a vDPA device through
>> VDPA_ATTR_VDPA_DEV_SUPPORTED_FEATURES */
>> + if (nla_put_u64_64bit(msg,
>> VDPA_ATTR_VDPA_DEV_SUPPORTED_FEATURES, features_device,
>> VDPA_ATTR_PAD))
>> return -EMSGSIZE;
>> - return vdpa_dev_net_mq_config_fill(vdev, msg, features, &config);
>> + return vdpa_dev_net_mq_config_fill(vdev, msg, features_driver,
>> &config);
>> }
>> static int
>> diff --git a/include/uapi/linux/vdpa.h b/include/uapi/linux/vdpa.h
>> index 25c55cab3d7c..d171b92ef522 100644
>> --- a/include/uapi/linux/vdpa.h
>> +++ b/include/uapi/linux/vdpa.h
>> @@ -46,7 +46,10 @@ enum vdpa_attr {
>> VDPA_ATTR_DEV_NEGOTIATED_FEATURES, /* u64 */
>> VDPA_ATTR_DEV_MGMTDEV_MAX_VQS, /* u32 */
>> + /* features of a vDPA management device */
>> VDPA_ATTR_DEV_SUPPORTED_FEATURES, /* u64 */
>> + /* features of a vDPA device, e.g., /dev/vhost-vdpa0 */
>> + VDPA_ATTR_VDPA_DEV_SUPPORTED_FEATURES, /* u64 */
> Append to the end, please. Otherwise it breaks userspace ABI.
OK, will fix it in V2
>
> -Siwei
>
>> VDPA_ATTR_DEV_QUEUE_INDEX, /* u32 */
>> VDPA_ATTR_DEV_VENDOR_ATTR_NAME, /* string */
>
^ permalink raw reply
* Re: [PATCH net] net: genl: fix error path memory leak in policy dumping
From: Jakub Kicinski @ 2022-08-16 1:51 UTC (permalink / raw)
To: Rafael Soares
Cc: davem, netdev, edumazet, pabeni, johannes.berg,
syzbot+dc54d9ba8153b216cae0
In-Reply-To: <Yvq16sC3Pytaf04k@macondo>
On Mon, 15 Aug 2022 18:08:58 -0300 Rafael Soares wrote:
> On Mon, Aug 15, 2022 at 11:20:21AM -0700, Jakub Kicinski wrote:
> > If construction of the array of policies fails when recording
> > non-first policy we need to unwind.
> >
> > Reported-by: syzbot+dc54d9ba8153b216cae0@syzkaller.appspotmail.com
> > Fixes: 50a896cf2d6f ("genetlink: properly support per-op policy dumping")
> > Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> > ---
> > net/netlink/genetlink.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
> > index 1afca2a6c2ac..57010927e20a 100644
> > --- a/net/netlink/genetlink.c
> > +++ b/net/netlink/genetlink.c
> > @@ -1174,13 +1174,17 @@ static int ctrl_dumppolicy_start(struct netlink_callback *cb)
> > op.policy,
> > op.maxattr);
> > if (err)
> > - return err;
> > + goto err_free_state;
>
> There's another call to netlink_policy_dump_add_policy() right above
> this one. The patch I posted to syzkaller frees the memory inside
> netlink_policy_dump_add_policy() and the result was OK.
Oh, sorry, I didn't see this reply. Every single time after the merge
window is over the stable folks bombard the mailing systems with their
backported patches and bring the mailing lists to their knees :/
Do you see your posting on lore.kernel.org? I presume not. You really
need to use ./scripts/get_maintainer and CC relevant folks directly.
This is v2 of my fix I submitted to syzbot for testing:
https://git.kernel.org/pub/scm/linux/kernel/git/kuba/linux.git/commit/?h=genl-fix&id=66f01a660c4439fc78a6fc68413f895b8fd07474
The earlier call to netlink_policy_dump_add_policy() should not be
a problem if the function unwound its state properly.
^ permalink raw reply
* Re: [PATCH 0/6] virtio/vsock: introduce dgrams, sk_buff, and qdisc
From: Bobby Eshleman @ 2022-08-16 1:55 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Bobby Eshleman, Wei Liu, Cong Wang, Stephen Hemminger,
Bobby Eshleman, Jiang Wang, Dexuan Cui, Haiyang Zhang,
linux-kernel, virtualization, Eric Dumazet, netdev,
Stefan Hajnoczi, kvm, Jakub Kicinski, Paolo Abeni, linux-hyperv,
David S. Miller
In-Reply-To: <20220815162524-mutt-send-email-mst@kernel.org>
On Mon, Aug 15, 2022 at 04:39:08PM -0400, Michael S. Tsirkin wrote:
>
> Given this affects the driver/device interface I'd like to
> ask you to please copy virtio-dev mailing list on these patches.
> Subscriber only I'm afraid you will need to subscribe :(
>
Ah makes sense, will do!
Best,
Bobby
^ permalink raw reply
* Re: [PATCH 2/2] vDPA: conditionally read fields in virtio-net dev
From: Zhu, Lingshan @ 2022-08-16 1:58 UTC (permalink / raw)
To: Si-Wei Liu, jasowang, mst
Cc: virtualization, netdev, kvm, parav, xieyongji, gautam.dawar
In-Reply-To: <c5075d3d-9d2c-2716-1cbf-cede49e2d66f@oracle.com>
On 8/16/2022 7:32 AM, Si-Wei Liu wrote:
>
>
> On 8/15/2022 2:26 AM, Zhu Lingshan wrote:
>> Some fields of virtio-net device config space are
>> conditional on the feature bits, the spec says:
>>
>> "The mac address field always exists
>> (though is only valid if VIRTIO_NET_F_MAC is set)"
>>
>> "max_virtqueue_pairs only exists if VIRTIO_NET_F_MQ
>> or VIRTIO_NET_F_RSS is set"
>>
>> "mtu only exists if VIRTIO_NET_F_MTU is set"
>>
>> so we should read MTU, MAC and MQ in the device config
>> space only when these feature bits are offered.
>>
>> For MQ, if both VIRTIO_NET_F_MQ and VIRTIO_NET_F_RSS are
>> not set, the virtio device should have
>> one queue pair as default value, so when userspace querying queue
>> pair numbers,
>> it should return mq=1 than zero.
>>
>> For MTU, if VIRTIO_NET_F_MTU is not set, we should not read
>> MTU from the device config sapce.
>> RFC894 <A Standard for the Transmission of IP Datagrams over Ethernet
>> Networks>
>> says:"The minimum length of the data field of a packet sent over an
>> Ethernet is 1500 octets, thus the maximum length of an IP datagram
>> sent over an Ethernet is 1500 octets. Implementations are encouraged
>> to support full-length packets"
> Noted there's a typo in the above "The *maximum* length of the data
> field of a packet sent over an Ethernet is 1500 octets ..." and the
> RFC was written 1984.
the spec RFC894 says it is 1500, see
https://www.rfc-editor.org/rfc/rfc894.txt
>
> Apparently that is no longer true with the introduction of Jumbo size
> frame later in the 2000s. I'm not sure what is the point of mention
> this ancient RFC. It doesn't say default MTU of any Ethernet
> NIC/switch should be 1500 in either case.
This could be a larger number for sure, we are trying to find out the
min value for Ethernet here, to support 1500 octets, MTU should be 1500
at least, so I assume 1500 should be the default value for MTU
>
>>
>> virtio spec says:"The virtio network device is a virtual ethernet card",
> Right,
>> so the default MTU value should be 1500 for virtio-net.
> ... but it doesn't say the default is 1500. At least, not in explicit
> way. Why it can't be 1492 or even lower? In practice, if the network
> backend has a MTU higher than 1500, there's nothing wrong for guest to
> configure default MTU more than 1500.
same as above
>
>>
>> For MAC, the spec says:"If the VIRTIO_NET_F_MAC feature bit is set,
>> the configuration space mac entry indicates the “physical” address
>> of the network card, otherwise the driver would typically
>> generate a random local MAC address." So there is no
>> default MAC address if VIRTIO_NET_F_MAC not set.
>>
>> This commits introduces functions vdpa_dev_net_mtu_config_fill()
>> and vdpa_dev_net_mac_config_fill() to fill MTU and MAC.
>> It also fixes vdpa_dev_net_mq_config_fill() to report correct
>> MQ when _F_MQ is not present.
>>
>> These functions should check devices features than driver
>> features, and struct vdpa_device is not needed as a parameter
>>
>> The test & userspace tool output:
>>
>> Feature bit VIRTIO_NET_F_MTU, VIRTIO_NET_F_RSS, VIRTIO_NET_F_MQ
>> and VIRTIO_NET_F_MAC can be mask out by hardcode.
>>
>> However, it is challenging to "disable" the related fields
>> in the HW device config space, so let's just assume the values
>> are meaningless if the feature bits are not set.
>>
>> Before this change, when feature bits for RSS, MQ, MTU and MAC
>> are not set, iproute2 output:
>> $vdpa vdpa0: mac 00:e8:ca:11:be:05 link up link_announce false mtu 1500
>> negotiated_features
>>
>> without this commit, function vdpa_dev_net_config_fill()
>> reads all config space fields unconditionally, so let's
>> assume the MAC and MTU are meaningless, and it checks
>> MQ with driver_features, so we don't see max_vq_pairs.
>>
>> After applying this commit, when feature bits for
>> MQ, RSS, MAC and MTU are not set,iproute2 output:
>> $vdpa dev config show vdpa0
>> vdpa0: link up link_announce false max_vq_pairs 1 mtu 1500
>> negotiated_features
>>
>> As explained above:
>> Here is no MAC, because VIRTIO_NET_F_MAC is not set,
>> and there is no default value for MAC. It shows
>> max_vq_paris = 1 because even without MQ feature,
>> a functional virtio-net must have one queue pair.
>> mtu = 1500 is the default value as ethernet
>> required.
>>
>> This commit also add supplementary comments for
>> __virtio16_to_cpu(true, xxx) operations in
>> vdpa_dev_net_config_fill() and vdpa_fill_stats_rec()
>>
>> Signed-off-by: Zhu Lingshan <lingshan.zhu@intel.com>
>> ---
>> drivers/vdpa/vdpa.c | 60 +++++++++++++++++++++++++++++++++++----------
>> 1 file changed, 47 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c
>> index efb55a06e961..a74660b98979 100644
>> --- a/drivers/vdpa/vdpa.c
>> +++ b/drivers/vdpa/vdpa.c
>> @@ -801,19 +801,44 @@ static int vdpa_nl_cmd_dev_get_dumpit(struct
>> sk_buff *msg, struct netlink_callba
>> return msg->len;
>> }
>> -static int vdpa_dev_net_mq_config_fill(struct vdpa_device *vdev,
>> - struct sk_buff *msg, u64 features,
>> +static int vdpa_dev_net_mq_config_fill(struct sk_buff *msg, u64
>> features,
>> const struct virtio_net_config *config)
>> {
>> u16 val_u16;
>> - if ((features & BIT_ULL(VIRTIO_NET_F_MQ)) == 0)
>> - return 0;
>> + if ((features & BIT_ULL(VIRTIO_NET_F_MQ)) == 0 &&
>> + (features & BIT_ULL(VIRTIO_NET_F_RSS)) == 0)
>> + val_u16 = 1;
>> + else
>> + val_u16 = __virtio16_to_cpu(true, config->max_virtqueue_pairs);
>> - val_u16 = le16_to_cpu(config->max_virtqueue_pairs);
>> return nla_put_u16(msg, VDPA_ATTR_DEV_NET_CFG_MAX_VQP, val_u16);
>> }
>> +static int vdpa_dev_net_mtu_config_fill(struct sk_buff *msg, u64
>> features,
>> + const struct virtio_net_config *config)
>> +{
>> + u16 val_u16;
>> +
>> + if ((features & BIT_ULL(VIRTIO_NET_F_MTU)) == 0)
>> + val_u16 = 1500;
> As said, there's no virtio spec defined value for MTU. Please leave
> this field out if feature VIRTIO_NET_F_MTU is not negotiated.
same as above
>> + else
>> + val_u16 = __virtio16_to_cpu(true, config->mtu);
>> +
>> + return nla_put_u16(msg, VDPA_ATTR_DEV_NET_CFG_MTU, val_u16);
>> +}
>> +
>> +static int vdpa_dev_net_mac_config_fill(struct sk_buff *msg, u64
>> features,
>> + const struct virtio_net_config *config)
>> +{
>> + if ((features & BIT_ULL(VIRTIO_NET_F_MAC)) == 0)
>> + return 0;
>> + else
>> + return nla_put(msg, VDPA_ATTR_DEV_NET_CFG_MACADDR,
>> + sizeof(config->mac), config->mac);
>> +}
>> +
>> +
>> static int vdpa_dev_net_config_fill(struct vdpa_device *vdev,
>> struct sk_buff *msg)
>> {
>> struct virtio_net_config config = {};
>> @@ -822,18 +847,16 @@ static int vdpa_dev_net_config_fill(struct
>> vdpa_device *vdev, struct sk_buff *ms
>> vdpa_get_config_unlocked(vdev, 0, &config, sizeof(config));
>> - if (nla_put(msg, VDPA_ATTR_DEV_NET_CFG_MACADDR,
>> sizeof(config.mac),
>> - config.mac))
>> - return -EMSGSIZE;
>> + /*
>> + * Assume little endian for now, userspace can tweak this for
>> + * legacy guest support.
> You can leave it as a TODO for kernel (vdpa core limitation), but
> AFAIK there's nothing userspace needs to do to infer the endianness.
> IMHO it's the kernel's job to provide an abstraction rather than rely
> on userspace guessing it.
we have discussed it in another thread, and this comment is suggested by
MST.
>
>> + */
>> + val_u16 = __virtio16_to_cpu(true, config.status);
>> val_u16 = __virtio16_to_cpu(true, config.status);
>> if (nla_put_u16(msg, VDPA_ATTR_DEV_NET_STATUS, val_u16))
>> return -EMSGSIZE;
>> - val_u16 = __virtio16_to_cpu(true, config.mtu);
>> - if (nla_put_u16(msg, VDPA_ATTR_DEV_NET_CFG_MTU, val_u16))
>> - return -EMSGSIZE;
>> -
>> features_driver = vdev->config->get_driver_features(vdev);
>> if (nla_put_u64_64bit(msg, VDPA_ATTR_DEV_NEGOTIATED_FEATURES,
>> features_driver,
>> VDPA_ATTR_PAD))
>> @@ -846,7 +869,13 @@ static int vdpa_dev_net_config_fill(struct
>> vdpa_device *vdev, struct sk_buff *ms
>> VDPA_ATTR_PAD))
>> return -EMSGSIZE;
>> - return vdpa_dev_net_mq_config_fill(vdev, msg, features_driver,
>> &config);
>> + if (vdpa_dev_net_mac_config_fill(msg, features_device, &config))
>> + return -EMSGSIZE;
>> +
>> + if (vdpa_dev_net_mtu_config_fill(msg, features_device, &config))
>> + return -EMSGSIZE;
>> +
>> + return vdpa_dev_net_mq_config_fill(msg, features_device, &config);
>> }
>> static int
>> @@ -914,6 +943,11 @@ static int vdpa_fill_stats_rec(struct
>> vdpa_device *vdev, struct sk_buff *msg,
>> }
>> vdpa_get_config_unlocked(vdev, 0, &config, sizeof(config));
>> + /*
>> + * Assume little endian for now, userspace can tweak this for
>> + * legacy guest support.
>> + */
>> +
> Ditto.
same as above
Thanks
>
> Thanks,
> -Siwei
>> max_vqp = __virtio16_to_cpu(true, config.max_virtqueue_pairs);
>> if (nla_put_u16(msg, VDPA_ATTR_DEV_NET_CFG_MAX_VQP, max_vqp))
>> return -EMSGSIZE;
>
^ permalink raw reply
* [PATCH net-next,0/3] cleanup of qdisc offload function
From: Zhengchao Shao @ 2022-08-16 2:04 UTC (permalink / raw)
To: netdev, linux-kernel, jhs, xiyou.wangcong, jiri, davem, edumazet,
kuba, pabeni
Cc: weiyongjun1, yuehaibing, shaozhengchao
Some qdiscs don't care return value of qdisc offload function, so make
function void.
Zhengchao Shao (3):
net: sched: make mq_offload() void
net: sched: make prio_offload() void
net: sched: make red_offload() void
net/sched/sch_mq.c | 6 +++---
net/sched/sch_prio.c | 6 +++---
net/sched/sch_red.c | 6 +++---
3 files changed, 9 insertions(+), 9 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH net-next,1/3] net: sched: make mq_offload() void
From: Zhengchao Shao @ 2022-08-16 2:04 UTC (permalink / raw)
To: netdev, linux-kernel, jhs, xiyou.wangcong, jiri, davem, edumazet,
kuba, pabeni
Cc: weiyongjun1, yuehaibing, shaozhengchao
In-Reply-To: <20220816020423.323820-1-shaozhengchao@huawei.com>
The return value of function mq_offload is unused, make mq_offload() void.
Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
---
net/sched/sch_mq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/sched/sch_mq.c b/net/sched/sch_mq.c
index 83d2e54bf303..9bfa9c8d4872 100644
--- a/net/sched/sch_mq.c
+++ b/net/sched/sch_mq.c
@@ -21,7 +21,7 @@ struct mq_sched {
struct Qdisc **qdiscs;
};
-static int mq_offload(struct Qdisc *sch, enum tc_mq_command cmd)
+static void mq_offload(struct Qdisc *sch, enum tc_mq_command cmd)
{
struct net_device *dev = qdisc_dev(sch);
struct tc_mq_qopt_offload opt = {
@@ -30,9 +30,9 @@ static int mq_offload(struct Qdisc *sch, enum tc_mq_command cmd)
};
if (!tc_can_offload(dev) || !dev->netdev_ops->ndo_setup_tc)
- return -EOPNOTSUPP;
+ return;
- return dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_QDISC_MQ, &opt);
+ dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_QDISC_MQ, &opt);
}
static int mq_offload_stats(struct Qdisc *sch)
--
2.17.1
^ permalink raw reply related
* [PATCH net-next,2/3] net: sched: make prio_offload() void
From: Zhengchao Shao @ 2022-08-16 2:04 UTC (permalink / raw)
To: netdev, linux-kernel, jhs, xiyou.wangcong, jiri, davem, edumazet,
kuba, pabeni
Cc: weiyongjun1, yuehaibing, shaozhengchao
In-Reply-To: <20220816020423.323820-1-shaozhengchao@huawei.com>
The return value of function prio_offload is unused, make prio_offload()
void.
Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
---
net/sched/sch_prio.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/sched/sch_prio.c b/net/sched/sch_prio.c
index 3b8d7197c06b..a7124c63f700 100644
--- a/net/sched/sch_prio.c
+++ b/net/sched/sch_prio.c
@@ -139,7 +139,7 @@ prio_reset(struct Qdisc *sch)
sch->q.qlen = 0;
}
-static int prio_offload(struct Qdisc *sch, struct tc_prio_qopt *qopt)
+static void prio_offload(struct Qdisc *sch, struct tc_prio_qopt *qopt)
{
struct net_device *dev = qdisc_dev(sch);
struct tc_prio_qopt_offload opt = {
@@ -148,7 +148,7 @@ static int prio_offload(struct Qdisc *sch, struct tc_prio_qopt *qopt)
};
if (!tc_can_offload(dev) || !dev->netdev_ops->ndo_setup_tc)
- return -EOPNOTSUPP;
+ return;
if (qopt) {
opt.command = TC_PRIO_REPLACE;
@@ -160,7 +160,7 @@ static int prio_offload(struct Qdisc *sch, struct tc_prio_qopt *qopt)
opt.command = TC_PRIO_DESTROY;
}
- return dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_QDISC_PRIO, &opt);
+ dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_QDISC_PRIO, &opt);
}
static void
--
2.17.1
^ permalink raw reply related
* [PATCH net-next,3/3] net: sched: make red_offload() void
From: Zhengchao Shao @ 2022-08-16 2:04 UTC (permalink / raw)
To: netdev, linux-kernel, jhs, xiyou.wangcong, jiri, davem, edumazet,
kuba, pabeni
Cc: weiyongjun1, yuehaibing, shaozhengchao
In-Reply-To: <20220816020423.323820-1-shaozhengchao@huawei.com>
The return value of function red_offload is unused, make red_offload()
void.
Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
---
net/sched/sch_red.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/sched/sch_red.c b/net/sched/sch_red.c
index 40adf1f07a82..8425f4169eed 100644
--- a/net/sched/sch_red.c
+++ b/net/sched/sch_red.c
@@ -181,7 +181,7 @@ static void red_reset(struct Qdisc *sch)
red_restart(&q->vars);
}
-static int red_offload(struct Qdisc *sch, bool enable)
+static void red_offload(struct Qdisc *sch, bool enable)
{
struct red_sched_data *q = qdisc_priv(sch);
struct net_device *dev = qdisc_dev(sch);
@@ -191,7 +191,7 @@ static int red_offload(struct Qdisc *sch, bool enable)
};
if (!tc_can_offload(dev) || !dev->netdev_ops->ndo_setup_tc)
- return -EOPNOTSUPP;
+ return;
if (enable) {
opt.command = TC_RED_REPLACE;
@@ -207,7 +207,7 @@ static int red_offload(struct Qdisc *sch, bool enable)
opt.command = TC_RED_DESTROY;
}
- return dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_QDISC_RED, &opt);
+ dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_QDISC_RED, &opt);
}
static void red_destroy(struct Qdisc *sch)
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next,0/3] cleanup of qdisc offload function
From: Jakub Kicinski @ 2022-08-16 3:10 UTC (permalink / raw)
To: Zhengchao Shao
Cc: netdev, linux-kernel, jhs, xiyou.wangcong, jiri, davem, edumazet,
pabeni, weiyongjun1, yuehaibing
In-Reply-To: <20220816020423.323820-1-shaozhengchao@huawei.com>
On Tue, 16 Aug 2022 10:04:20 +0800 Zhengchao Shao wrote:
> Some qdiscs don't care return value of qdisc offload function, so make
> function void.
How many of these patches do you have? Is there a goal you're working
towards? I don't think the pure return value removals are worth the
noise. They don't even save LoC:
3 files changed, 9 insertions(+), 9 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next] net: rtnetlink: fix module reference count leak issue in rtnetlink_rcv_msg
From: patchwork-bot+netdevbpf @ 2022-08-16 3:10 UTC (permalink / raw)
To: Zhengchao Shao
Cc: netdev, linux-kernel, davem, edumazet, kuba, pabeni, idosch,
petrm, florent.fourcot, razor, weiyongjun1, yuehaibing
In-Reply-To: <20220815024629.240367-1-shaozhengchao@huawei.com>
Hello:
This patch was applied to netdev/net.git (master)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 15 Aug 2022 10:46:29 +0800 you wrote:
> When bulk delete command is received in the rtnetlink_rcv_msg function,
> if bulk delete is not supported, module_put is not called to release
> the reference counting. As a result, module reference count is leaked.
>
> Fixes: a6cec0bcd342("net: rtnetlink: add bulk delete support flag")
> Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
>
> [...]
Here is the summary with links:
- [net-next] net: rtnetlink: fix module reference count leak issue in rtnetlink_rcv_msg
https://git.kernel.org/netdev/net/c/5b22f62724a0
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 1/2] vDPA: allow userspace to query features of a vDPA device
From: Parav Pandit @ 2022-08-16 2:07 UTC (permalink / raw)
To: Zhu, Lingshan, Si-Wei Liu, jasowang@redhat.com, mst@redhat.com
Cc: virtualization@lists.linux-foundation.org, netdev@vger.kernel.org,
kvm@vger.kernel.org, xieyongji@bytedance.com,
gautam.dawar@amd.com
In-Reply-To: <cea494d0-d446-274f-f913-723822a53e6a@intel.com>
> From: Zhu, Lingshan <lingshan.zhu@intel.com>
> Sent: Monday, August 15, 2022 9:49 PM
>
> On 8/16/2022 2:15 AM, Si-Wei Liu wrote:
> >
> >
> > On 8/15/2022 2:26 AM, Zhu Lingshan wrote:
> >> This commit adds a new vDPA netlink attribution
> >> VDPA_ATTR_VDPA_DEV_SUPPORTED_FEATURES. Userspace can query
> features
> >> of vDPA devices through this new attr.
> >>
> >> Signed-off-by: Zhu Lingshan <lingshan.zhu@intel.com>
> >> ---
> >> drivers/vdpa/vdpa.c | 17 +++++++++++++----
> >> include/uapi/linux/vdpa.h | 3 +++
> >> 2 files changed, 16 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c index
> >> c06c02704461..efb55a06e961 100644
> >> --- a/drivers/vdpa/vdpa.c
> >> +++ b/drivers/vdpa/vdpa.c
> >> @@ -491,6 +491,8 @@ static int vdpa_mgmtdev_fill(const struct
> >> vdpa_mgmt_dev *mdev, struct sk_buff *m
> >> err = -EMSGSIZE;
> >> goto msg_err;
> >> }
> >> +
> >> + /* report features of a vDPA management device through
> >> VDPA_ATTR_DEV_SUPPORTED_FEATURES */
> >> if (nla_put_u64_64bit(msg, VDPA_ATTR_DEV_SUPPORTED_FEATURES,
> >> mdev->supported_features, VDPA_ATTR_PAD)) {
> >> err = -EMSGSIZE;
> >> @@ -815,7 +817,7 @@ static int vdpa_dev_net_mq_config_fill(struct
> >> vdpa_device *vdev,
> >> static int vdpa_dev_net_config_fill(struct vdpa_device *vdev,
> >> struct sk_buff *msg)
> >> {
> >> struct virtio_net_config config = {};
> >> - u64 features;
> >> + u64 features_device, features_driver;
> >> u16 val_u16;
> >> vdpa_get_config_unlocked(vdev, 0, &config, sizeof(config));
> >> @@ -832,12 +834,19 @@ static int vdpa_dev_net_config_fill(struct
> >> vdpa_device *vdev, struct sk_buff *ms
> >> if (nla_put_u16(msg, VDPA_ATTR_DEV_NET_CFG_MTU, val_u16))
> >> return -EMSGSIZE;
> >> - features = vdev->config->get_driver_features(vdev);
> >> - if (nla_put_u64_64bit(msg,
> VDPA_ATTR_DEV_NEGOTIATED_FEATURES,
> >> features,
> >> + features_driver = vdev->config->get_driver_features(vdev);
> >> + if (nla_put_u64_64bit(msg,
> VDPA_ATTR_DEV_NEGOTIATED_FEATURES,
> >> features_driver,
> >> + VDPA_ATTR_PAD))
> >> + return -EMSGSIZE;
> >> +
> >> + features_device = vdev->config->get_device_features(vdev);
> >> +
> >> + /* report features of a vDPA device through
> >> VDPA_ATTR_VDPA_DEV_SUPPORTED_FEATURES */
> >> + if (nla_put_u64_64bit(msg,
> >> VDPA_ATTR_VDPA_DEV_SUPPORTED_FEATURES, features_device,
> >> VDPA_ATTR_PAD))
> >> return -EMSGSIZE;
> >> - return vdpa_dev_net_mq_config_fill(vdev, msg, features,
> >> &config);
> >> + return vdpa_dev_net_mq_config_fill(vdev, msg, features_driver,
> >> &config);
> >> }
> >> static int
> >> diff --git a/include/uapi/linux/vdpa.h b/include/uapi/linux/vdpa.h
> >> index 25c55cab3d7c..d171b92ef522 100644
> >> --- a/include/uapi/linux/vdpa.h
> >> +++ b/include/uapi/linux/vdpa.h
> >> @@ -46,7 +46,10 @@ enum vdpa_attr {
> >> VDPA_ATTR_DEV_NEGOTIATED_FEATURES, /* u64 */
> >> VDPA_ATTR_DEV_MGMTDEV_MAX_VQS, /* u32 */
> >> + /* features of a vDPA management device */
Say comment as.
/* Features of the vDPA management device matching the virtio feature bits 0 to 63 when queried on the mgmt. device.
* When returned on the vdpa device, it indicates virtio feature bits 0 to 63 of the vdpa device
*/
> >> VDPA_ATTR_DEV_SUPPORTED_FEATURES, /* u64 */
> >> + /* features of a vDPA device, e.g., /dev/vhost-vdpa0 */
> >> + VDPA_ATTR_VDPA_DEV_SUPPORTED_FEATURES, /* u64 */
> > Append to the end, please. Otherwise it breaks userspace ABI.
> OK, will fix it in V2
I have read Se-Wei comment in the v4.
However I disagree, we don’t need to continue the past mistake done with the naming.
Please add a comment that VDPA_ATTR_DEV_SUPPORTED_FEATURES like above about the exception.
We established that there is no race condition either.
So no need to add new UAPI for some past history.
^ permalink raw reply
* Re: [PATCH v3 0/5] virtio: drop sizing vqs during init
From: Xuan Zhuo @ 2022-08-16 3:07 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Jason Wang, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, virtualization, netdev, Linus Torvalds, Jens Axboe,
James Bottomley, Martin K. Petersen, Guenter Roeck, Greg KH,
linux-kernel
In-Reply-To: <20220815215938.154999-1-mst@redhat.com>
Series:
Reviewed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
There is also a commit, I just submitted, about the problem you pointed
out about using container_of(). Can we submit together?
On Mon, 15 Aug 2022 18:00:21 -0400, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> Reporting after I botched up v2 posting. Sorry about the noise.
>
> Supplying size during init does not work for all transports.
> In fact for legacy pci doing that causes a memory
> corruption which was reported on Google Cloud.
>
> We might get away with changing size to size_hint so it's
> safe to ignore and then fixing legacy to ignore the hint.
>
> But the benefit is unclear in any case, so let's revert for now.
> Any new version will have to come with
> - documentation of performance gains
> - performance testing showing existing workflows
> are not harmed materially. especially ones with
> bursty traffic
> - report of testing on legacy devices
>
>
> Huge shout out to Andres Freund for the effort spent reproducing and
> debugging! Thanks to Guenter Roeck for help with testing!
>
>
> changes from v2
> drop unrelated patches
> changes from v1
> revert the ring size api, it's unused now
>
> Michael S. Tsirkin (5):
> virtio_net: Revert "virtio_net: set the default max ring size by
> find_vqs()"
> virtio: Revert "virtio: add helper virtio_find_vqs_ctx_size()"
> virtio-mmio: Revert "virtio_mmio: support the arg sizes of find_vqs()"
> virtio_pci: Revert "virtio_pci: support the arg sizes of find_vqs()"
> virtio: Revert "virtio: find_vqs() add arg sizes"
>
> arch/um/drivers/virtio_uml.c | 2 +-
> drivers/net/virtio_net.c | 42 +++---------------------
> drivers/platform/mellanox/mlxbf-tmfifo.c | 1 -
> drivers/remoteproc/remoteproc_virtio.c | 1 -
> drivers/s390/virtio/virtio_ccw.c | 1 -
> drivers/virtio/virtio_mmio.c | 9 ++---
> drivers/virtio/virtio_pci_common.c | 20 +++++------
> drivers/virtio/virtio_pci_common.h | 3 +-
> drivers/virtio/virtio_pci_legacy.c | 6 +---
> drivers/virtio/virtio_pci_modern.c | 17 +++-------
> drivers/virtio/virtio_vdpa.c | 1 -
> include/linux/virtio_config.h | 26 +++------------
> 12 files changed, 28 insertions(+), 101 deletions(-)
>
> --
> MST
>
^ permalink raw reply
* Re: [PATCH 2/6] vsock: return errors other than -ENOMEM to socket
From: kernel test robot @ 2022-08-16 2:16 UTC (permalink / raw)
To: Bobby Eshleman
Cc: kbuild-all, Bobby Eshleman, Cong Wang, Jiang Wang,
Stefan Hajnoczi, Stefano Garzarella, Michael S. Tsirkin,
Jason Wang, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger, Wei Liu,
Dexuan Cui, kvm, virtualization, netdev, linux-kernel,
linux-hyperv
In-Reply-To: <d81818b868216c774613dd03641fcfe63cc55a45.1660362668.git.bobby.eshleman@bytedance.com>
Hi Bobby,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on mst-vhost/linux-next]
[also build test WARNING on linus/master v6.0-rc1 next-20220815]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Bobby-Eshleman/virtio-vsock-introduce-dgrams-sk_buff-and-qdisc/20220816-015812
base: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next
config: i386-randconfig-s001-20220815 (https://download.01.org/0day-ci/archive/20220816/202208161059.GPIlPpvd-lkp@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-5) 11.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.4-39-gce1a6720-dirty
# https://github.com/intel-lab-lkp/linux/commit/68c9c8216a573cdfe2170cad677854e2f4a34634
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Bobby-Eshleman/virtio-vsock-introduce-dgrams-sk_buff-and-qdisc/20220816-015812
git checkout 68c9c8216a573cdfe2170cad677854e2f4a34634
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=i386 SHELL=/bin/bash fs/nilfs2/ net/vmw_vsock/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>
sparse warnings: (new ones prefixed by >>)
>> net/vmw_vsock/virtio_transport.c:173:31: sparse: sparse: restricted __le16 degrades to integer
net/vmw_vsock/virtio_transport.c:174:31: sparse: sparse: restricted __le16 degrades to integer
vim +173 net/vmw_vsock/virtio_transport.c
0ea9e1d3a9e3ef Asias He 2016-07-28 161
93afaf2cdefaa9 Bobby Eshleman 2022-08-15 162 static inline bool
93afaf2cdefaa9 Bobby Eshleman 2022-08-15 163 virtio_transport_skbs_can_merge(struct sk_buff *old, struct sk_buff *new)
93afaf2cdefaa9 Bobby Eshleman 2022-08-15 164 {
93afaf2cdefaa9 Bobby Eshleman 2022-08-15 165 return (new->len < GOOD_COPY_LEN &&
93afaf2cdefaa9 Bobby Eshleman 2022-08-15 166 skb_tailroom(old) >= new->len &&
93afaf2cdefaa9 Bobby Eshleman 2022-08-15 167 vsock_hdr(new)->src_cid == vsock_hdr(old)->src_cid &&
93afaf2cdefaa9 Bobby Eshleman 2022-08-15 168 vsock_hdr(new)->dst_cid == vsock_hdr(old)->dst_cid &&
93afaf2cdefaa9 Bobby Eshleman 2022-08-15 169 vsock_hdr(new)->src_port == vsock_hdr(old)->src_port &&
93afaf2cdefaa9 Bobby Eshleman 2022-08-15 170 vsock_hdr(new)->dst_port == vsock_hdr(old)->dst_port &&
93afaf2cdefaa9 Bobby Eshleman 2022-08-15 171 vsock_hdr(new)->type == vsock_hdr(old)->type &&
93afaf2cdefaa9 Bobby Eshleman 2022-08-15 172 vsock_hdr(new)->flags == vsock_hdr(old)->flags &&
93afaf2cdefaa9 Bobby Eshleman 2022-08-15 @173 vsock_hdr(old)->op == VIRTIO_VSOCK_OP_RW &&
93afaf2cdefaa9 Bobby Eshleman 2022-08-15 174 vsock_hdr(new)->op == VIRTIO_VSOCK_OP_RW);
93afaf2cdefaa9 Bobby Eshleman 2022-08-15 175 }
93afaf2cdefaa9 Bobby Eshleman 2022-08-15 176
--
0-DAY CI Kernel Test Service
https://01.org/lkp
^ permalink raw reply
* Re: [PATCH v2] net: moxa: pass pdev instead of ndev to DMA functions
From: patchwork-bot+netdevbpf @ 2022-08-16 3:00 UTC (permalink / raw)
To: Sergei Antonov
Cc: netdev, andrew, kuba, paskripkin, davem, pabeni, f.fainelli
In-Reply-To: <20220812171339.2271788-1-saproj@gmail.com>
Hello:
This patch was applied to netdev/net.git (master)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 12 Aug 2022 20:13:39 +0300 you wrote:
> dma_map_single() calls fail in moxart_mac_setup_desc_ring() and
> moxart_mac_start_xmit() which leads to an incessant output of this:
>
> [ 16.043925] moxart-ethernet 92000000.mac eth0: DMA mapping error
> [ 16.050957] moxart-ethernet 92000000.mac eth0: DMA mapping error
> [ 16.058229] moxart-ethernet 92000000.mac eth0: DMA mapping error
>
> [...]
Here is the summary with links:
- [v2] net: moxa: pass pdev instead of ndev to DMA functions
https://git.kernel.org/netdev/net/c/3a12df22a8f6
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH 0/2] Namespaceify two sysctls related with route
From: cgel.zte @ 2022-08-16 2:25 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, xu.xin16
From: xu xin <xu.xin16@zte.com.cn>
Different netns has different requirements on the setting of error_cost
and error_burst, which are related with limiting the frequency of sending
ICMP_DEST_UNREACH packets or outputing error message to dmesg.
xu xin (2):
ipv4: Namespaceify route/error_cost knob
ipv4: Namespaceify route/error_burst knob
include/net/netns/ipv4.h | 2 ++
net/ipv4/route.c | 41 ++++++++++++++++++++--------------------
2 files changed, 23 insertions(+), 20 deletions(-)
--
2.25.1
^ permalink raw reply
* Re: [PATCH v2] net: moxa: pass pdev instead of ndev to DMA functions
From: Jakub Kicinski @ 2022-08-16 2:56 UTC (permalink / raw)
To: Sergei Antonov
Cc: netdev, Andrew Lunn, Pavel Skripkin, David S . Miller,
Paolo Abeni, Florian Fainelli, Jonas Jensen
In-Reply-To: <20220812171339.2271788-1-saproj@gmail.com>
On Fri, 12 Aug 2022 20:13:39 +0300 Sergei Antonov wrote:
> dma_map_single() calls fail in moxart_mac_setup_desc_ring() and
> moxart_mac_start_xmit() which leads to an incessant output of this:
>
> [ 16.043925] moxart-ethernet 92000000.mac eth0: DMA mapping error
> [ 16.050957] moxart-ethernet 92000000.mac eth0: DMA mapping error
> [ 16.058229] moxart-ethernet 92000000.mac eth0: DMA mapping error
>
> Passing pdev to DMA is a common approach among net drivers.
Thanks! I slapped
Fixes: 6c821bd9edc9 ("net: Add MOXA ART SoCs ethernet driver")
on it when applying, please make sure to provide Fixes tags in
the future (and CC authors so they can review).
^ permalink raw reply
* [PATCH 1/2] ipv4: Namespaceify route/error_cost knob
From: cgel.zte @ 2022-08-16 2:26 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, xu.xin16
In-Reply-To: <20220816022522.81772-1-xu.xin16@zte.com.cn>
From: xu xin <xu.xin16@zte.com.cn>
Different netns has different requirement on the setting of error_cost
sysctl which is used to limit the max frequency of sending
ICMP_DEST_UNREACH packet together with error_burst.
Enable error_cost to be configured per network namespace.
Signed-off-by: xu xin <xu.xin16@zte.com.cn>
---
include/net/netns/ipv4.h | 1 +
net/ipv4/route.c | 20 ++++++++++----------
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
index c7320ef356d9..319395bbad3c 100644
--- a/include/net/netns/ipv4.h
+++ b/include/net/netns/ipv4.h
@@ -85,6 +85,7 @@ struct netns_ipv4 {
u32 ip_rt_min_pmtu;
int ip_rt_mtu_expires;
int ip_rt_min_advmss;
+ int ip_rt_error_cost;
struct local_ports ip_local_ports;
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 795cbe1de912..0598393e03ac 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -118,7 +118,6 @@ static int ip_rt_max_size;
static int ip_rt_redirect_number __read_mostly = 9;
static int ip_rt_redirect_load __read_mostly = HZ / 50;
static int ip_rt_redirect_silence __read_mostly = ((HZ / 50) << (9 + 1));
-static int ip_rt_error_cost __read_mostly = HZ;
static int ip_rt_error_burst __read_mostly = 5 * HZ;
static int ip_rt_gc_timeout __read_mostly = RT_GC_TIMEOUT;
@@ -1005,8 +1004,8 @@ static int ip_error(struct sk_buff *skb)
if (peer->rate_tokens > ip_rt_error_burst)
peer->rate_tokens = ip_rt_error_burst;
peer->rate_last = now;
- if (peer->rate_tokens >= ip_rt_error_cost)
- peer->rate_tokens -= ip_rt_error_cost;
+ if (peer->rate_tokens >= net->ipv4.ip_rt_error_cost)
+ peer->rate_tokens -= net->ipv4.ip_rt_error_cost;
else
send = false;
inet_putpeer(peer);
@@ -3535,13 +3534,6 @@ static struct ctl_table ipv4_route_table[] = {
.mode = 0644,
.proc_handler = proc_dointvec,
},
- {
- .procname = "error_cost",
- .data = &ip_rt_error_cost,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
{
.procname = "error_burst",
.data = &ip_rt_error_burst,
@@ -3590,6 +3582,13 @@ static struct ctl_table ipv4_route_netns_table[] = {
.mode = 0644,
.proc_handler = proc_dointvec,
},
+ {
+ .procname = "error_cost",
+ .data = &init_net.ipv4.ip_rt_error_cost,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
{ },
};
@@ -3653,6 +3652,7 @@ static __net_init int netns_ip_rt_init(struct net *net)
net->ipv4.ip_rt_min_pmtu = DEFAULT_MIN_PMTU;
net->ipv4.ip_rt_mtu_expires = DEFAULT_MTU_EXPIRES;
net->ipv4.ip_rt_min_advmss = DEFAULT_MIN_ADVMSS;
+ net->ipv4.ip_rt_error_cost = HZ;
return 0;
}
--
2.25.1
^ permalink raw reply related
* [PATCH 2/2] ipv4: Namespaceify route/error_burst knob
From: cgel.zte @ 2022-08-16 2:27 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, xu.xin16
In-Reply-To: <20220816022522.81772-1-xu.xin16@zte.com.cn>
From: xu xin <xu.xin16@zte.com.cn>
Different netns has different requirement on the setting of error_burst
sysctl which is used to limit the frequency of sending ICMP_DEST_UNREACH
packet.
Enable error_burst to be configured per network namespace.
Signed-off-by: xu xin <xu.xin16@zte.com.cn>
---
include/net/netns/ipv4.h | 1 +
net/ipv4/route.c | 21 +++++++++++----------
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
index 319395bbad3c..03d16cf32508 100644
--- a/include/net/netns/ipv4.h
+++ b/include/net/netns/ipv4.h
@@ -86,6 +86,7 @@ struct netns_ipv4 {
int ip_rt_mtu_expires;
int ip_rt_min_advmss;
int ip_rt_error_cost;
+ int ip_rt_error_burst;
struct local_ports ip_local_ports;
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 0598393e03ac..4e40b667e3fc 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -114,11 +114,11 @@
#define DEFAULT_MIN_PMTU (512 + 20 + 20)
#define DEFAULT_MTU_EXPIRES (10 * 60 * HZ)
#define DEFAULT_MIN_ADVMSS 256
+#define DEFAULT_ERROR_BURST (5 * HZ)
static int ip_rt_max_size;
static int ip_rt_redirect_number __read_mostly = 9;
static int ip_rt_redirect_load __read_mostly = HZ / 50;
static int ip_rt_redirect_silence __read_mostly = ((HZ / 50) << (9 + 1));
-static int ip_rt_error_burst __read_mostly = 5 * HZ;
static int ip_rt_gc_timeout __read_mostly = RT_GC_TIMEOUT;
@@ -1001,8 +1001,8 @@ static int ip_error(struct sk_buff *skb)
if (peer) {
now = jiffies;
peer->rate_tokens += now - peer->rate_last;
- if (peer->rate_tokens > ip_rt_error_burst)
- peer->rate_tokens = ip_rt_error_burst;
+ if (peer->rate_tokens > net->ipv4.ip_rt_error_burst)
+ peer->rate_tokens = net->ipv4.ip_rt_error_burst;
peer->rate_last = now;
if (peer->rate_tokens >= net->ipv4.ip_rt_error_cost)
peer->rate_tokens -= net->ipv4.ip_rt_error_cost;
@@ -3534,13 +3534,6 @@ static struct ctl_table ipv4_route_table[] = {
.mode = 0644,
.proc_handler = proc_dointvec,
},
- {
- .procname = "error_burst",
- .data = &ip_rt_error_burst,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
{
.procname = "gc_elasticity",
.data = &ip_rt_gc_elasticity,
@@ -3589,6 +3582,13 @@ static struct ctl_table ipv4_route_netns_table[] = {
.mode = 0644,
.proc_handler = proc_dointvec,
},
+ {
+ .procname = "error_burst",
+ .data = &init_net.ipv4.ip_rt_error_burst,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
{ },
};
@@ -3653,6 +3653,7 @@ static __net_init int netns_ip_rt_init(struct net *net)
net->ipv4.ip_rt_mtu_expires = DEFAULT_MTU_EXPIRES;
net->ipv4.ip_rt_min_advmss = DEFAULT_MIN_ADVMSS;
net->ipv4.ip_rt_error_cost = HZ;
+ net->ipv4.ip_rt_error_burst = DEFAULT_ERROR_BURST;
return 0;
}
--
2.25.1
^ permalink raw reply related
* RE: [PATCH 2/2] vDPA: conditionally read fields in virtio-net dev
From: Parav Pandit @ 2022-08-16 2:32 UTC (permalink / raw)
To: Zhu Lingshan, jasowang@redhat.com, mst@redhat.com
Cc: virtualization@lists.linux-foundation.org, netdev@vger.kernel.org,
kvm@vger.kernel.org, xieyongji@bytedance.com,
gautam.dawar@amd.com
In-Reply-To: <20220815092638.504528-3-lingshan.zhu@intel.com>
> From: Zhu Lingshan <lingshan.zhu@intel.com>
> Sent: Monday, August 15, 2022 5:27 AM
>
> Some fields of virtio-net device config space are conditional on the feature
> bits, the spec says:
>
> "The mac address field always exists
> (though is only valid if VIRTIO_NET_F_MAC is set)"
>
> "max_virtqueue_pairs only exists if VIRTIO_NET_F_MQ or
> VIRTIO_NET_F_RSS is set"
>
> "mtu only exists if VIRTIO_NET_F_MTU is set"
>
> so we should read MTU, MAC and MQ in the device config space only when
> these feature bits are offered.
Yes.
>
> For MQ, if both VIRTIO_NET_F_MQ and VIRTIO_NET_F_RSS are not set, the
> virtio device should have one queue pair as default value, so when userspace
> querying queue pair numbers, it should return mq=1 than zero.
No.
No need to treat mac and max_qps differently.
It is meaningless to differentiate when field exist/not-exists vs value valid/not valid.
>
> For MTU, if VIRTIO_NET_F_MTU is not set, we should not read MTU from
> the device config sapce.
> RFC894 <A Standard for the Transmission of IP Datagrams over Ethernet
> Networks> says:"The minimum length of the data field of a packet sent over
> an Ethernet is 1500 octets, thus the maximum length of an IP datagram sent
> over an Ethernet is 1500 octets. Implementations are encouraged to support
> full-length packets"
This line in the RFC 894 of 1984 is wrong.
Errata already exists for it at [1].
[1] https://www.rfc-editor.org/errata_search.php?rfc=894&rec_status=0
>
> virtio spec says:"The virtio network device is a virtual ethernet card", so the
> default MTU value should be 1500 for virtio-net.
>
Practically I have seen 1500 and highe mtu.
And this derivation is not good of what should be the default mtu as above errata exists.
And I see the code below why you need to work so hard to define a default value so that _MQ and _MTU can report default values.
There is really no need for this complexity and such a long commit message.
Can we please expose feature bits as-is and report config space field which are valid?
User space will be querying both.
> For MAC, the spec says:"If the VIRTIO_NET_F_MAC feature bit is set, the
> configuration space mac entry indicates the “physical” address of the
> network card, otherwise the driver would typically generate a random local
> MAC address." So there is no default MAC address if VIRTIO_NET_F_MAC
> not set.
>
> This commits introduces functions vdpa_dev_net_mtu_config_fill() and
> vdpa_dev_net_mac_config_fill() to fill MTU and MAC.
> It also fixes vdpa_dev_net_mq_config_fill() to report correct MQ when
> _F_MQ is not present.
>
Multiple changes in single patch are not good idea.
Its ok to split to smaller patches.
> + if ((features & BIT_ULL(VIRTIO_NET_F_MTU)) == 0)
> + val_u16 = 1500;
> + else
> + val_u16 = __virtio16_to_cpu(true, config->mtu);
> +
Need to work hard to find default values and that too turned out had errata.
There are more fields that doesn’t have default values.
There is no point in kernel doing this guess work, that user space can figure out of what is valid/invalid.
^ permalink raw reply
* Re: upstream kernel crashes
From: Xuan Zhuo @ 2022-08-16 2:45 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Jason Wang, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, virtualization, netdev, Linus Torvalds, Jens Axboe,
James Bottomley, Martin K. Petersen, Guenter Roeck, linux-kernel,
Greg KH, c, Andres Freund
In-Reply-To: <20220815170444-mutt-send-email-mst@kernel.org>
On Mon, 15 Aug 2022 17:32:06 -0400, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Mon, Aug 15, 2022 at 01:53:30PM -0700, Andres Freund wrote:
> > Hi,
> >
> > On 2022-08-15 16:21:51 -0400, Michael S. Tsirkin wrote:
> > > On Mon, Aug 15, 2022 at 10:46:17AM -0700, Andres Freund wrote:
> > > > Hi,
> > > >
> > > > On 2022-08-15 12:50:52 -0400, Michael S. Tsirkin wrote:
> > > > > On Mon, Aug 15, 2022 at 09:45:03AM -0700, Andres Freund wrote:
> > > > > > Hi,
> > > > > >
> > > > > > On 2022-08-15 11:40:59 -0400, Michael S. Tsirkin wrote:
> > > > > > > OK so this gives us a quick revert as a solution for now.
> > > > > > > Next, I would appreciate it if you just try this simple hack.
> > > > > > > If it crashes we either have a long standing problem in virtio
> > > > > > > code or more likely a gcp bug where it can't handle smaller
> > > > > > > rings than what device requestes.
> > > > > > > Thanks!
> > > > > >
> > > > > > I applied the below and the problem persists.
> > > > > >
> > > > > > [...]
> > > > >
> > > > > Okay!
> > > >
> > > > Just checking - I applied and tested this atop 6.0-rc1, correct? Or did you
> > > > want me to test it with the 762faee5a267 reverted? I guess what you're trying
> > > > to test if a smaller queue than what's requested you'd want to do so without
> > > > the problematic patch applied...
> > > >
> > > >
> > > > Either way, I did this, and there are no issues that I could observe. No
> > > > oopses, no broken networking. But:
> > > >
> > > > To make sure it does something I added a debugging printk - which doesn't show
> > > > up. I assume this is at a point at least earlyprintk should work (which I see
> > > > getting enabled via serial)?
> > > >
> >
> > > Sorry if I was unclear. I wanted to know whether the change somehow
> > > exposes a driver bug or a GCP bug. So what I wanted to do is to test
> > > this patch on top of *5.19*, not on top of the revert.
> >
> > Right, the 5.19 part was clear, just the earlier test:
> >
> > > > > > On 2022-08-15 11:40:59 -0400, Michael S. Tsirkin wrote:
> > > > > > > OK so this gives us a quick revert as a solution for now.
> > > > > > > Next, I would appreciate it if you just try this simple hack.
> > > > > > > If it crashes we either have a long standing problem in virtio
> > > > > > > code or more likely a gcp bug where it can't handle smaller
> > > > > > > Thanks!
> >
> > I wasn't sure about.
> >
> > After I didn't see any effect on 5.19 + your patch, I grew a bit suspicious
> > and added the printks.
> >
> >
> > > Yes I think printk should work here.
> >
> > The reason the debug patch didn't change anything, and that my debug printk
> > didn't show, is that gcp uses the legacy paths...
>
> Wait a second. Eureka I think!
>
> So I think GCP is not broken.
> I think what's broken is this patch:
>
> commit cdb44806fca2d0ad29ca644cbf1505433902ee0c
> Author: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> Date: Mon Aug 1 14:38:54 2022 +0800
>
> virtio_pci: support the arg sizes of find_vqs()
>
>
> Specifically:
>
> diff --git a/drivers/virtio/virtio_pci_legacy.c b/drivers/virtio/virtio_pci_legacy.c
> index 2257f1b3d8ae..d75e5c4e637f 100644
> --- a/drivers/virtio/virtio_pci_legacy.c
> +++ b/drivers/virtio/virtio_pci_legacy.c
> @@ -112,6 +112,7 @@ static struct virtqueue *setup_vq(struct virtio_pci_device *vp_dev,
> unsigned int index,
> void (*callback)(struct virtqueue *vq),
> const char *name,
> + u32 size,
> bool ctx,
> u16 msix_vec)
> {
> @@ -125,10 +126,13 @@ static struct virtqueue *setup_vq(struct virtio_pci_device *vp_dev,
> if (!num || vp_legacy_get_queue_enable(&vp_dev->ldev, index))
> return ERR_PTR(-ENOENT);
>
> + if (!size || size > num)
> + size = num;
> +
> info->msix_vector = msix_vec;
>
> /* create the vring */
> - vq = vring_create_virtqueue(index, num,
> + vq = vring_create_virtqueue(index, size,
> VIRTIO_PCI_VRING_ALIGN, &vp_dev->vdev,
> true, false, ctx,
> vp_notify, callback, name);
>
>
>
> So if you pass the size parameter for a legacy device it will
> try to make the ring smaller and that is not legal with
> legacy at all. But the driver treats legacy and modern
> the same, it allocates a smaller queue anyway.
>
>
> Lo and behold, I pass disable-modern=on to qemu and it happily
> corrupts memory exactly the same as GCP does.
Yes, I think you are right.
Thank you very much.
>
>
> So the new find_vqs API is actually completely broken, it can not work for
> legacy at all and for added fun there's no way to find out
> that it's legacy. Maybe we should interpret the patch
>
> So I think I will also revert
>
> 04ca0b0b16f11faf74fa92468dab51b8372586cd..fe3dc04e31aa51f91dc7f741a5f76cc4817eb5b4
>
>
>
>
>
>
>
> > If there were a bug in the legacy path, it'd explain why the problem only
> > shows on gcp, and not in other situations.
> >
> > I'll queue testing the legacy path with the equivalent change.
> >
> > - Andres
> >
> >
> > Greetings,
> >
> > Andres Freund
>
^ permalink raw reply
* Re: [PATCH net-next,0/3] cleanup of qdisc offload function
From: shaozhengchao @ 2022-08-16 3:32 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, linux-kernel, jhs, xiyou.wangcong, jiri, davem, edumazet,
pabeni, weiyongjun1, yuehaibing
In-Reply-To: <20220815201038.4321b77e@kernel.org>
On 2022/8/16 11:10, Jakub Kicinski wrote:
> On Tue, 16 Aug 2022 10:04:20 +0800 Zhengchao Shao wrote:
>> Some qdiscs don't care return value of qdisc offload function, so make
>> function void.
>
> How many of these patches do you have? Is there a goal you're working
> towards? I don't think the pure return value removals are worth the
> noise. They don't even save LoC:
>
> 3 files changed, 9 insertions(+), 9 deletions(-)
Hi Jakub.
Thank you for your reply. Recently I've been studying the kernel code
related to qdisc, and my goal is to understand how qdisc works. If the
code can be optimized, I do what I can to modify the optimization. Is it
more appropriate to add warning to the offload return value? I look
forward to your reply. Thank you.
Zhengchao Shao
^ permalink raw reply
* Re: [PATCH v3 bpf-next 07/15] bpf: Initialize the bpf_run_ctx in bpf_iter_run_prog()
From: Andrii Nakryiko @ 2022-08-16 3:33 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: bpf, netdev, Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann,
David Miller, Eric Dumazet, Jakub Kicinski, kernel-team,
Paolo Abeni, Stanislav Fomichev
In-Reply-To: <20220810190809.2698442-1-kafai@fb.com>
On Wed, Aug 10, 2022 at 12:11 PM Martin KaFai Lau <kafai@fb.com> wrote:
>
> The bpf-iter-prog for tcp and unix sk can do bpf_setsockopt()
> which needs has_current_bpf_ctx() to decide if it is called by a
> bpf prog. This patch initializes the bpf_run_ctx in
> bpf_iter_run_prog() for the has_current_bpf_ctx() to use.
>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
> ---
> include/linux/bpf.h | 2 +-
> kernel/bpf/bpf_iter.c | 5 +++++
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 0a600b2013cc..15ab980e9525 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -1967,7 +1967,7 @@ static inline bool unprivileged_ebpf_enabled(void)
> }
>
> /* Not all bpf prog type has the bpf_ctx.
> - * Only trampoline and cgroup-bpf have it.
> + * Only trampoline, cgroup-bpf, and iter have it.
Apart from this part which I'd drop, lgtm:
Acked-by: Andrii Nakryiko <andrii@kernel.org>
> * For the bpf prog type that has initialized the bpf_ctx,
> * this function can be used to decide if a kernel function
> * is called by a bpf program.
> diff --git a/kernel/bpf/bpf_iter.c b/kernel/bpf/bpf_iter.c
> index 4b112aa8bba3..6476b2c03527 100644
> --- a/kernel/bpf/bpf_iter.c
> +++ b/kernel/bpf/bpf_iter.c
> @@ -685,19 +685,24 @@ struct bpf_prog *bpf_iter_get_info(struct bpf_iter_meta *meta, bool in_stop)
>
> int bpf_iter_run_prog(struct bpf_prog *prog, void *ctx)
> {
> + struct bpf_run_ctx run_ctx, *old_run_ctx;
> int ret;
>
> if (prog->aux->sleepable) {
> rcu_read_lock_trace();
> migrate_disable();
> might_fault();
> + old_run_ctx = bpf_set_run_ctx(&run_ctx);
> ret = bpf_prog_run(prog, ctx);
> + bpf_reset_run_ctx(old_run_ctx);
> migrate_enable();
> rcu_read_unlock_trace();
> } else {
> rcu_read_lock();
> migrate_disable();
> + old_run_ctx = bpf_set_run_ctx(&run_ctx);
> ret = bpf_prog_run(prog, ctx);
> + bpf_reset_run_ctx(old_run_ctx);
> migrate_enable();
> rcu_read_unlock();
> }
> --
> 2.30.2
>
^ permalink raw reply
* Re: [PATCHv2 bpf-next] libbpf: making bpf_prog_load() ignore name if kernel doesn't support
From: Hangbin Liu @ 2022-08-16 3:29 UTC (permalink / raw)
To: Andrii Nakryiko; +Cc: Quentin Monnet, netdev, bpf
In-Reply-To: <CAEf4BzbXehQtWnocp5KnArd0dq-Wg0ddPOyJZCwGPLO_L7wByg@mail.gmail.com>
On Mon, Aug 15, 2022 at 02:59:50PM -0700, Andrii Nakryiko wrote:
> I did a small adjustment to not fill out entire big bpf_attr union
> completely (and added a bit more meaningful "libbpf_nametest" prog
> name):
>
Thanks for the adjustment.
Hangbin
> $ git diff --staged
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 4a351897bdcc..f05dd61a8a7f 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -4415,6 +4415,7 @@ static int probe_fd(int fd)
>
> static int probe_kern_prog_name(void)
> {
> + const size_t attr_sz = offsetofend(union bpf_attr, prog_name);
> struct bpf_insn insns[] = {
> BPF_MOV64_IMM(BPF_REG_0, 0),
> BPF_EXIT_INSN(),
> @@ -4422,12 +4423,12 @@ static int probe_kern_prog_name(void)
> union bpf_attr attr;
> int ret;
>
> - memset(&attr, 0, sizeof(attr));
> + memset(&attr, 0, attr_sz);
> attr.prog_type = BPF_PROG_TYPE_SOCKET_FILTER;
> attr.license = ptr_to_u64("GPL");
> attr.insns = ptr_to_u64(insns);
> attr.insn_cnt = (__u32)ARRAY_SIZE(insns);
> - libbpf_strlcpy(attr.prog_name, "test", sizeof(attr.prog_name));
> + libbpf_strlcpy(attr.prog_name, "libbpf_nametest",
> sizeof(attr.prog_name));
>
> Pushed to bpf-next, thanks!
^ permalink raw reply
* [mst-vhost:vhost 5/8] drivers/virtio/virtio_vdpa.c:291:61: error: 'sizes' undeclared
From: kernel test robot @ 2022-08-16 3:28 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: kbuild-all, kvm, virtualization, netdev
tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost
head: 43ab8a34f3f0c7301813343b9fed2da33c37754a
commit: 71545b3c933acbf165e6596d5cfa4fd15e1ef543 [5/8] virtio: Revert "virtio: find_vqs() add arg sizes"
config: i386-buildonly-randconfig-r004-20220815 (https://download.01.org/0day-ci/archive/20220816/202208161151.sMYdFPvS-lkp@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-5) 11.3.0
reproduce (this is a W=1 build):
# https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git/commit/?id=71545b3c933acbf165e6596d5cfa4fd15e1ef543
git remote add mst-vhost https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git
git fetch --no-tags mst-vhost vhost
git checkout 71545b3c933acbf165e6596d5cfa4fd15e1ef543
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash drivers/virtio/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
drivers/virtio/virtio_vdpa.c: In function 'virtio_vdpa_find_vqs':
>> drivers/virtio/virtio_vdpa.c:291:61: error: 'sizes' undeclared (first use in this function)
291 | names[i], sizes ? sizes[i] : 0,
| ^~~~~
drivers/virtio/virtio_vdpa.c:291:61: note: each undeclared identifier is reported only once for each function it appears in
vim +/sizes +291 drivers/virtio/virtio_vdpa.c
c043b4a8cf3b16 Jason Wang 2020-03-26 270
3153234097f6a0 Solomon Tan 2022-04-18 271 static int virtio_vdpa_find_vqs(struct virtio_device *vdev, unsigned int nvqs,
c043b4a8cf3b16 Jason Wang 2020-03-26 272 struct virtqueue *vqs[],
c043b4a8cf3b16 Jason Wang 2020-03-26 273 vq_callback_t *callbacks[],
c043b4a8cf3b16 Jason Wang 2020-03-26 274 const char * const names[],
c043b4a8cf3b16 Jason Wang 2020-03-26 275 const bool *ctx,
c043b4a8cf3b16 Jason Wang 2020-03-26 276 struct irq_affinity *desc)
c043b4a8cf3b16 Jason Wang 2020-03-26 277 {
c043b4a8cf3b16 Jason Wang 2020-03-26 278 struct virtio_vdpa_device *vd_dev = to_virtio_vdpa_device(vdev);
c043b4a8cf3b16 Jason Wang 2020-03-26 279 struct vdpa_device *vdpa = vd_get_vdpa(vdev);
c043b4a8cf3b16 Jason Wang 2020-03-26 280 const struct vdpa_config_ops *ops = vdpa->config;
c043b4a8cf3b16 Jason Wang 2020-03-26 281 struct vdpa_callback cb;
c043b4a8cf3b16 Jason Wang 2020-03-26 282 int i, err, queue_idx = 0;
c043b4a8cf3b16 Jason Wang 2020-03-26 283
c043b4a8cf3b16 Jason Wang 2020-03-26 284 for (i = 0; i < nvqs; ++i) {
c043b4a8cf3b16 Jason Wang 2020-03-26 285 if (!names[i]) {
c043b4a8cf3b16 Jason Wang 2020-03-26 286 vqs[i] = NULL;
c043b4a8cf3b16 Jason Wang 2020-03-26 287 continue;
c043b4a8cf3b16 Jason Wang 2020-03-26 288 }
c043b4a8cf3b16 Jason Wang 2020-03-26 289
99e8927d8a4da8 Bo Liu 2022-08-10 290 vqs[i] = virtio_vdpa_setup_vq(vdev, queue_idx++, callbacks[i],
99e8927d8a4da8 Bo Liu 2022-08-10 @291 names[i], sizes ? sizes[i] : 0,
99e8927d8a4da8 Bo Liu 2022-08-10 292 ctx ? ctx[i] : false);
c043b4a8cf3b16 Jason Wang 2020-03-26 293 if (IS_ERR(vqs[i])) {
c043b4a8cf3b16 Jason Wang 2020-03-26 294 err = PTR_ERR(vqs[i]);
c043b4a8cf3b16 Jason Wang 2020-03-26 295 goto err_setup_vq;
c043b4a8cf3b16 Jason Wang 2020-03-26 296 }
c043b4a8cf3b16 Jason Wang 2020-03-26 297 }
c043b4a8cf3b16 Jason Wang 2020-03-26 298
c043b4a8cf3b16 Jason Wang 2020-03-26 299 cb.callback = virtio_vdpa_config_cb;
c043b4a8cf3b16 Jason Wang 2020-03-26 300 cb.private = vd_dev;
c043b4a8cf3b16 Jason Wang 2020-03-26 301 ops->set_config_cb(vdpa, &cb);
c043b4a8cf3b16 Jason Wang 2020-03-26 302
c043b4a8cf3b16 Jason Wang 2020-03-26 303 return 0;
c043b4a8cf3b16 Jason Wang 2020-03-26 304
c043b4a8cf3b16 Jason Wang 2020-03-26 305 err_setup_vq:
c043b4a8cf3b16 Jason Wang 2020-03-26 306 virtio_vdpa_del_vqs(vdev);
c043b4a8cf3b16 Jason Wang 2020-03-26 307 return err;
c043b4a8cf3b16 Jason Wang 2020-03-26 308 }
c043b4a8cf3b16 Jason Wang 2020-03-26 309
:::::: The code at line 291 was first introduced by commit
:::::: 99e8927d8a4da8eb8a8a5904dc13a3156be8e7c0 virtio_vdpa: support the arg sizes of find_vqs()
:::::: TO: Bo Liu <liubo03@inspur.com>
:::::: CC: Michael S. Tsirkin <mst@redhat.com>
--
0-DAY CI Kernel Test Service
https://01.org/lkp
^ 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