* Re: [PATCH v2] kcm: remove any offset before parsing messages
From: David Miller @ 2018-09-18 1:45 UTC (permalink / raw)
To: asmadeus; +Cc: doronrk, tom, davejwatson, netdev, linux-kernel
In-Reply-To: <20180912053642.GA2912@nautica>
From: Dominique Martinet <asmadeus@codewreck.org>
Date: Wed, 12 Sep 2018 07:36:42 +0200
> Dominique Martinet wrote on Tue, Sep 11, 2018:
>> Hmm, while trying to benchmark this, I sometimes got hangs in
>> kcm_wait_data() for the last packet somehow?
>> The sender program was done (exited (zombie) so I assumed the sender
>> socket flushed), but the receiver was in kcm_wait_data in kcm_recvmsg
>> indicating it parsed a header but there was no skb to peek at?
>> But the sock is locked so this shouldn't be racy...
>>
>> I can get it fairly often with this patch and small messages with an
>> offset, but I think it's just because the pull changes some timing - I
>> can't hit it with just the clone, and I can hit it with a pull without
>> clone as well.... And I don't see how pulling a cloned skb can impact
>> the original socket, but I'm a bit fuzzy on this.
>
> This is weird, I cannot reproduce at all without that pull, even if I
> add another delay there instead of the pull, so it's not just timing...
I really can't apply this patch until you resolve this.
It is weird, given your description, though...
^ permalink raw reply
* [PATCH bpf-next] samples/bpf: remove duplicated includes
From: YueHaibing @ 2018-09-18 1:45 UTC (permalink / raw)
To: ast, daniel; +Cc: linux-kernel, netdev, YueHaibing
Remove duplicated includes.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
samples/bpf/bpf_load.c | 1 -
samples/bpf/sampleip_user.c | 1 -
samples/bpf/test_current_task_under_cgroup_user.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/samples/bpf/bpf_load.c b/samples/bpf/bpf_load.c
index 904e775..e6d7e0f 100644
--- a/samples/bpf/bpf_load.c
+++ b/samples/bpf/bpf_load.c
@@ -16,7 +16,6 @@
#include <linux/netlink.h>
#include <linux/rtnetlink.h>
#include <linux/types.h>
-#include <sys/types.h>
#include <sys/socket.h>
#include <sys/syscall.h>
#include <sys/ioctl.h>
diff --git a/samples/bpf/sampleip_user.c b/samples/bpf/sampleip_user.c
index 60c2b73..216c7ec 100644
--- a/samples/bpf/sampleip_user.c
+++ b/samples/bpf/sampleip_user.c
@@ -9,7 +9,6 @@
*/
#include <stdio.h>
#include <stdlib.h>
-#include <stdio.h>
#include <unistd.h>
#include <errno.h>
#include <signal.h>
diff --git a/samples/bpf/test_current_task_under_cgroup_user.c b/samples/bpf/test_current_task_under_cgroup_user.c
index 4be4874..2259f99 100644
--- a/samples/bpf/test_current_task_under_cgroup_user.c
+++ b/samples/bpf/test_current_task_under_cgroup_user.c
@@ -11,7 +11,6 @@
#include <unistd.h>
#include <bpf/bpf.h>
#include "bpf_load.h"
-#include <linux/bpf.h>
#include "cgroup_helpers.h"
#define CGROUP_PATH "/my-cgroup"
--
2.7.0
^ permalink raw reply related
* Re: [PATCH 1/2] r8169: Align ASPM/CLKREQ setting function with vendor driver
From: David Miller @ 2018-09-18 1:46 UTC (permalink / raw)
To: kai.heng.feng; +Cc: nic_swsd, hkallweit1, netdev, linux-kernel
In-Reply-To: <20180912065821.7198-1-kai.heng.feng@canonical.com>
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date: Wed, 12 Sep 2018 14:58:20 +0800
> There's a small delay after setting ASPM in vendor drivers, r8101 and
> r8168.
> In addition, those drivers enable ASPM before ClkReq, also change that
> to align with vendor driver.
>
> I haven't seen anything bad becasue of this, but I think it's better to
> keep in sync with vendor driver.
>
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] r8169: enable ASPM on RTL8106E
From: David Miller @ 2018-09-18 1:46 UTC (permalink / raw)
To: kai.heng.feng; +Cc: nic_swsd, hkallweit1, netdev, linux-kernel
In-Reply-To: <20180912065821.7198-2-kai.heng.feng@canonical.com>
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date: Wed, 12 Sep 2018 14:58:21 +0800
> The Intel SoC was prevented from entering lower idle state because
> of RTL8106E's ASPM was not enabled.
>
> So enable ASPM on RTL8106E (chip version 39).
> Now the Intel SoC can enter lower idle state, power consumption and
> temperature are much lower.
>
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] netlink: add NLA_REJECT policy type
From: Marcelo Ricardo Leitner @ 2018-09-17 20:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: Michal Kubecek, linux-wireless, netdev, jbenc
In-Reply-To: <1537177132.2957.6.camel@sipsolutions.net>
On Mon, Sep 17, 2018 at 11:38:52AM +0200, Johannes Berg wrote:
> On Thu, 2018-09-13 at 18:58 -0300, Marcelo Ricardo Leitner wrote:
>
> > Then I ask my first question again: why reject these? They are not
> > hurting anything, are they? It's different from your example I think.
> > In there, the extra information which was ignored leads to a
> > different behavior.
>
> So in one case I was thinking of, there are some fields that simply
> cannot be used for input, they're only used for output. But it may not
> always be obvious to somebody using the API. Thus, I think it makes
> sense to instruct the kernel to reject that, so that whoever gets
> confused has immediate feedback that their usage is wrong. If we ignore
> that, they may not realize their error immediately.
>
> I think the ethtool case is similar: you can read and write some fields,
> and only read others - but if you try to write the read-only fields
> would you prefer to be told "sorry, this is not possible" vs. it being
> silently ignored? I'd definitely prefer the former.
See below.
>
> > Maybe it would be better to have NLA_IGNORE instead? </idea>
>
> I don't think so, it doesn't give any feedback to the application author
> that they're doing something wrong.
Yes, it would have to have some other ways to signal return values.
In some cases there may be other ways to tell the application that it
couldn't be handled at the time. For example, when changing several
ethtool offloadings at once, we could have a feedback for each of the
offloading that was request and it could include "ack, nack and
ignored" and let the application decide if that "ignored" should be an
error or not. It all boils down to what one is trying to do.
That said, I'm now liking this patch. Just too bad we cannot flag
current output-only fields as so, but in the long term I think this
patch will help us.
Thanks,
Marcelo
^ permalink raw reply
* Re: [PATCH rdma-next 00/24] Extend DEVX functionality
From: Leon Romanovsky @ 2018-09-17 20:20 UTC (permalink / raw)
To: Or Gerlitz
Cc: Doug Ledford, Jason Gunthorpe, RDMA mailing list, Yishai Hadas,
Saeed Mahameed, linux-netdev
In-Reply-To: <CAJ3xEMiXhawjV2_MH9CpbONP=HeT6sZZ+pCB2N_Pjd5nq9huEw@mail.gmail.com>
On Mon, Sep 17, 2018 at 11:13:55PM +0300, Or Gerlitz wrote:
> On Mon, Sep 17, 2018 at 11:07 PM, Leon Romanovsky <leonro@mellanox.com> wrote:
> > On Mon, Sep 17, 2018 at 10:51:29PM +0300, Or Gerlitz wrote:
> >> On Mon, Sep 17, 2018 at 10:34 PM, Leon Romanovsky <leonro@mellanox.com> wrote:
> >> > On Mon, Sep 17, 2018 at 02:03:53PM +0300, Leon Romanovsky wrote:
> >> >> From: Leon Romanovsky <leonro@mellanox.com>
> >> >>
> >> >> From Yishai,
> >> >>
> >> >> This series comes to enable the DEVX functionality in some wider scope,
> >> >> specifically,
> >> >> - It enables using kernel objects that were created by the verbs
> >> >> API in the DEVX flow.
> >> >> - It enables white list commands without DEVX user context.
> >> >> - It enables the IB link layer under CAP_NET_RAW capabilities.
> >> >> - It exposes the PRM handles for RAW QP (i.e. TIRN, TISN, RQN, SQN)
> >> >> to be used later on directly by the DEVX interface.
> >> >>
> >> >> In General,
> >> >> Each object that is created/destroyed/modified via verbs will be stamped
> >> >> with a UID based on its user context. This is already done for DEVX objects
> >> >> commands.
> >> >>
> >> >> This will enable the firmware to enforce the usage of kernel objects
> >> >> from the DEVX flow by validating that the same UID is used and the resources are
> >> >> really related to the same user.
> >> >>
> >> >> For example in case a CQ was created with verbs it will be stamped with
> >> >> UID and once will be pointed by a DEVX create QP command the firmware will
> >> >> validate that the input CQN really belongs to the UID which issues the create QP
> >> >> command.
> >> >>
> >> >> As of the above, all the PRM objects (except of the public ones which
> >> >> are managed by the kernel e.g. FLOW, etc.) will have a UID upon their
> >> >> create/modify/destroy commands. The detection of UMEM / physical
> >> >> addressed in the relevant commands will be done by firmware according to a 'umem
> >> >> valid bit' as the UID may be used in both cases.
> >> >>
> >> >> The series also enables white list commands which don't require a
> >> >> specific DEVX context, instead of this a device UID is used so that
> >> >> the firmware will mask un-privileged functionality. The IB link layer
> >> >> is also enabled once CAP_NET_RAW permission exists.
> >> >>
> >> >> To enable using the RAW QP underlay objects (e.g. TIRN, RQN, etc.) later
> >> >> on by DEVX commands the UHW output for this case was extended to return this
> >> >> data when a DEVX context is used.
> >> >>
> >> >> Thanks
> >> >>
> >> >> Leon Romanovsky (1):
> >> >> net/mlx5: Update mlx5_ifc with DEVX UID bits
> >> >>
> >> >> Yishai Hadas (24):
> >> >> net/mlx5: Set uid as part of CQ commands
> >> >> net/mlx5: Set uid as part of QP commands
> >> >> net/mlx5: Set uid as part of RQ commands
> >> >> net/mlx5: Set uid as part of SQ commands
> >> >> net/mlx5: Set uid as part of SRQ commands
> >> >> net/mlx5: Set uid as part of DCT commands
> >> >
> >> > Hi Doug and Jason,
> >> >
> >> > Do you want me to resend 7 patches above in one series and other patches
> >> > in another series just to be below 15 patches limit? Please be aware
> >> > that those patches above are going to mlx5-next and not to
> >> > net-next/rdma-next.
> >> >
> >> > No rebase, no code change, no much meaning too, but it is your call.
> >>
> >> how about yes! for stop shitting on Dave Miller?
> >
> > Or, are you ok?
> >
> > This series is not relevant to Dave Miller and he didn't even listed in CC or TO.
>
> correct, but Dave asked MLNX/Saeed to do X, you should respect X when you post
> to the community Dave is maintaining, even if he didn't ask you, not
> doing so hurts
> our positioning with Dave.
Saeed is going to see/apply/review first 7 patches, which is less than 15,
so we are ok here.
>
>
> >
> > I still prefer to hear answer from respective maintainer to whom this
> > series was sent.
>
> Your maintainer asked you to do X, just do it, once and for all
Both Doug and Jason known how to write emails, they will request "X"
if THEY decide that it is needed/better, there is no need to be their
voice.
Thanks
^ permalink raw reply
* RE: [PATCH net,stable] qmi_wwan: set DTR for modems in forced USB2 mode
From: Deshu Wen @ 2018-09-17 20:21 UTC (permalink / raw)
To: Bjørn Mork, netdev@vger.kernel.org
Cc: linux-usb@vger.kernel.org, Fred Veldini
In-Reply-To: <20180917200024.13571-1-bjorn@mork.no>
Many thanks Bjørn!
-----Original Message-----
From: Bjørn Mork <bjorn@mork.no>
Sent: Monday, September 17, 2018 13:00
To: netdev@vger.kernel.org
Cc: linux-usb@vger.kernel.org; Fred Veldini <fred.veldini@gmail.com>; Deshu Wen <dwen@sierrawireless.com>; Bjørn Mork <bjorn@mork.no>
Subject: [PATCH net,stable] qmi_wwan: set DTR for modems in forced USB2 mode
Recent firmware revisions have added the ability to force these modems to USB2 mode, hiding their SuperSpeed capabilities from the host. The driver has been using the SuperSpeed capability, as shown by the bcdUSB field of the device descriptor, to detect the need to enable the DTR quirk. This method fails when the modems are forced to
USB2 mode by the modem firmware.
Fix by unconditionally enabling the DTR quirk for the affected device IDs.
Reported-by: Fred Veldini <fred.veldini@gmail.com>
Reported-by: Deshu Wen <dwen@sierrawireless.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
drivers/net/usb/qmi_wwan.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c index e3270deecec2..533b6fb8d923 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1213,13 +1213,13 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1199, 0x9061, 8)}, /* Sierra Wireless Modem */
{QMI_FIXED_INTF(0x1199, 0x9063, 8)}, /* Sierra Wireless EM7305 */
{QMI_FIXED_INTF(0x1199, 0x9063, 10)}, /* Sierra Wireless EM7305 */
- {QMI_FIXED_INTF(0x1199, 0x9071, 8)}, /* Sierra Wireless MC74xx */
- {QMI_FIXED_INTF(0x1199, 0x9071, 10)}, /* Sierra Wireless MC74xx */
- {QMI_FIXED_INTF(0x1199, 0x9079, 8)}, /* Sierra Wireless EM74xx */
- {QMI_FIXED_INTF(0x1199, 0x9079, 10)}, /* Sierra Wireless EM74xx */
- {QMI_FIXED_INTF(0x1199, 0x907b, 8)}, /* Sierra Wireless EM74xx */
- {QMI_FIXED_INTF(0x1199, 0x907b, 10)}, /* Sierra Wireless EM74xx */
- {QMI_FIXED_INTF(0x1199, 0x9091, 8)}, /* Sierra Wireless EM7565 */
+ {QMI_QUIRK_SET_DTR(0x1199, 0x9071, 8)}, /* Sierra Wireless MC74xx */
+ {QMI_QUIRK_SET_DTR(0x1199, 0x9071, 10)},/* Sierra Wireless MC74xx */
+ {QMI_QUIRK_SET_DTR(0x1199, 0x9079, 8)}, /* Sierra Wireless EM74xx */
+ {QMI_QUIRK_SET_DTR(0x1199, 0x9079, 10)},/* Sierra Wireless EM74xx */
+ {QMI_QUIRK_SET_DTR(0x1199, 0x907b, 8)}, /* Sierra Wireless EM74xx */
+ {QMI_QUIRK_SET_DTR(0x1199, 0x907b, 10)},/* Sierra Wireless EM74xx */
+ {QMI_QUIRK_SET_DTR(0x1199, 0x9091, 8)}, /* Sierra Wireless EM7565 */
{QMI_FIXED_INTF(0x1bbb, 0x011e, 4)}, /* Telekom Speedstick LTE II (Alcatel One Touch L100V LTE) */
{QMI_FIXED_INTF(0x1bbb, 0x0203, 2)}, /* Alcatel L800MA */
{QMI_FIXED_INTF(0x2357, 0x0201, 4)}, /* TP-LINK HSUPA Modem MA180 */
--
2.11.0
^ permalink raw reply
* Re: [PATCH v2 1/2] netlink: add NLA_REJECT policy type
From: Marcelo Ricardo Leitner @ 2018-09-17 20:23 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, Michal Kubecek, Johannes Berg
In-Reply-To: <20180917095729.11185-1-johannes@sipsolutions.net>
On Mon, Sep 17, 2018 at 11:57:28AM +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> In some situations some netlink attributes may be used for output
> only (kernel->userspace) or may be reserved for future use. It's
> then helpful to be able to prevent userspace from using them in
> messages sent to the kernel, since they'd otherwise be ignored and
> any future will become impossible if this happens.
>
> Add NLA_REJECT to the policy which does nothing but reject (with
> EINVAL) validation of any messages containing this attribute.
> Allow for returning a specific extended ACK error message in the
> validation_data pointer.
>
> While at it clear up the documentation a bit - the NLA_BITFIELD32
> documentation was added to the list of len field descriptions.
>
> Also, use NL_SET_BAD_ATTR() in one place where it's open-coded.
>
> The specific case I have in mind now is a shared nested attribute
> containing request/response data, and it would be pointless and
> potentially confusing to have userspace include response data in
> the messages that actually contain a request.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> ---
> v2: preserve behaviour of overwriting the extack message, with
> either the generic or the specific one now
> ---
> include/net/netlink.h | 13 ++++++++++++-
> lib/nlattr.c | 23 ++++++++++++++++-------
> 2 files changed, 28 insertions(+), 8 deletions(-)
>
> diff --git a/include/net/netlink.h b/include/net/netlink.h
> index 0c154f98e987..b318b0a9f6c3 100644
> --- a/include/net/netlink.h
> +++ b/include/net/netlink.h
> @@ -180,6 +180,7 @@ enum {
> NLA_S32,
> NLA_S64,
> NLA_BITFIELD32,
> + NLA_REJECT,
> __NLA_TYPE_MAX,
> };
>
> @@ -208,9 +209,19 @@ enum {
> * NLA_MSECS Leaving the length field zero will verify the
> * given type fits, using it verifies minimum length
> * just like "All other"
> - * NLA_BITFIELD32 A 32-bit bitmap/bitselector attribute
> + * NLA_BITFIELD32 Unused
> + * NLA_REJECT Unused
> * All other Minimum length of attribute payload
> *
> + * Meaning of `validation_data' field:
> + * NLA_BITFIELD32 This is a 32-bit bitmap/bitselector attribute and
> + * validation data must point to a u32 value of valid
> + * flags
> + * NLA_REJECT This attribute is always rejected and validation data
> + * may point to a string to report as the error instead
> + * of the generic one in extended ACK.
> + * All other Unused
> + *
> * Example:
> * static const struct nla_policy my_policy[ATTR_MAX+1] = {
> * [ATTR_FOO] = { .type = NLA_U16 },
> diff --git a/lib/nlattr.c b/lib/nlattr.c
> index e335bcafa9e4..36d74b079151 100644
> --- a/lib/nlattr.c
> +++ b/lib/nlattr.c
> @@ -69,7 +69,8 @@ static int validate_nla_bitfield32(const struct nlattr *nla,
> }
>
> static int validate_nla(const struct nlattr *nla, int maxtype,
> - const struct nla_policy *policy)
> + const struct nla_policy *policy,
> + const char **error_msg)
> {
> const struct nla_policy *pt;
> int minlen = 0, attrlen = nla_len(nla), type = nla_type(nla);
> @@ -87,6 +88,11 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
> }
>
> switch (pt->type) {
> + case NLA_REJECT:
> + if (pt->validation_data && error_msg)
> + *error_msg = pt->validation_data;
> + return -EINVAL;
> +
> case NLA_FLAG:
> if (attrlen > 0)
> return -ERANGE;
> @@ -180,11 +186,10 @@ int nla_validate(const struct nlattr *head, int len, int maxtype,
> int rem;
>
> nla_for_each_attr(nla, head, len, rem) {
> - int err = validate_nla(nla, maxtype, policy);
> + int err = validate_nla(nla, maxtype, policy, NULL);
>
> if (err < 0) {
> - if (extack)
> - extack->bad_attr = nla;
> + NL_SET_BAD_ATTR(extack, nla);
> return err;
> }
> }
> @@ -250,11 +255,15 @@ int nla_parse(struct nlattr **tb, int maxtype, const struct nlattr *head,
> u16 type = nla_type(nla);
>
> if (type > 0 && type <= maxtype) {
> + static const char _msg[] = "Attribute failed policy validation";
> + const char *msg = _msg;
> +
> if (policy) {
> - err = validate_nla(nla, maxtype, policy);
> + err = validate_nla(nla, maxtype, policy, &msg);
> if (err < 0) {
> - NL_SET_ERR_MSG_ATTR(extack, nla,
> - "Attribute failed policy validation");
> + NL_SET_BAD_ATTR(extack, nla);
> + if (extack)
> + extack->_msg = msg;
> goto errout;
> }
> }
> --
> 2.14.4
>
^ permalink raw reply
* Re: [PATCH v2 2/2] netlink: add ethernet address policy types
From: Marcelo Ricardo Leitner @ 2018-09-17 20:26 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, Michal Kubecek, Johannes Berg
In-Reply-To: <20180917095729.11185-2-johannes@sipsolutions.net>
On Mon, Sep 17, 2018 at 11:57:29AM +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> Commonly, ethernet addresses are just using a policy of
> { .len = ETH_ALEN }
> which leaves userspace free to send more data than it should,
> which may hide bugs.
>
> Introduce NLA_EXACT_LEN which checks for exact size, rejecting
> the attribute if it's not exactly that length. Also add
> NLA_EXACT_LEN_WARN which requires the minimum length and will
> warn on longer attributes, for backward compatibility.
>
> Use these to define NLA_POLICY_ETH_ADDR (new strict policy) and
> NLA_POLICY_ETH_ADDR_COMPAT (compatible policy with warning);
> these are used like this:
>
> static const struct nla_policy <name>[...] = {
> [NL_ATTR_NAME] = NLA_POLICY_ETH_ADDR,
> ...
> };
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> ---
> v2: add only NLA_EXACT_LEN/NLA_EXACT_LEN_WARN and build on top
> of that for ethernet address validation, so it can be extended
> for other types (e.g. IPv6 addresses)
> ---
> include/net/netlink.h | 13 +++++++++++++
> lib/nlattr.c | 8 +++++++-
> 2 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/include/net/netlink.h b/include/net/netlink.h
> index b318b0a9f6c3..318b1ded3833 100644
> --- a/include/net/netlink.h
> +++ b/include/net/netlink.h
> @@ -181,6 +181,8 @@ enum {
> NLA_S64,
> NLA_BITFIELD32,
> NLA_REJECT,
> + NLA_EXACT_LEN,
> + NLA_EXACT_LEN_WARN,
> __NLA_TYPE_MAX,
> };
>
> @@ -211,6 +213,10 @@ enum {
> * just like "All other"
> * NLA_BITFIELD32 Unused
> * NLA_REJECT Unused
> + * NLA_EXACT_LEN Attribute must have exactly this length, otherwise
> + * it is rejected.
> + * NLA_EXACT_LEN_WARN Attribute should have exactly this length, a warning
> + * is logged if it is longer, shorter is rejected.
> * All other Minimum length of attribute payload
> *
> * Meaning of `validation_data' field:
> @@ -236,6 +242,13 @@ struct nla_policy {
> void *validation_data;
> };
>
> +#define NLA_POLICY_EXACT_LEN(_len) { .type = NLA_EXACT_LEN, .len = _len }
> +#define NLA_POLICY_EXACT_LEN_WARN(_len) { .type = NLA_EXACT_LEN_WARN, \
> + .len = _len }
> +
> +#define NLA_POLICY_ETH_ADDR NLA_POLICY_EXACT_LEN(ETH_ALEN)
> +#define NLA_POLICY_ETH_ADDR_COMPAT NLA_POLICY_EXACT_LEN_WARN(ETH_ALEN)
> +
> /**
> * struct nl_info - netlink source information
> * @nlh: Netlink message header of original request
> diff --git a/lib/nlattr.c b/lib/nlattr.c
> index 36d74b079151..bb6fe5ed4ecf 100644
> --- a/lib/nlattr.c
> +++ b/lib/nlattr.c
> @@ -82,12 +82,18 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
>
> BUG_ON(pt->type > NLA_TYPE_MAX);
>
> - if (nla_attr_len[pt->type] && attrlen != nla_attr_len[pt->type]) {
> + if ((nla_attr_len[pt->type] && attrlen != nla_attr_len[pt->type]) ||
> + (pt->type == NLA_EXACT_LEN_WARN && attrlen != pt->len)) {
> pr_warn_ratelimited("netlink: '%s': attribute type %d has an invalid length.\n",
> current->comm, type);
> }
>
> switch (pt->type) {
> + case NLA_EXACT_LEN:
> + if (attrlen != pt->len)
> + return -ERANGE;
> + break;
> +
> case NLA_REJECT:
> if (pt->validation_data && error_msg)
> *error_msg = pt->validation_data;
> --
> 2.14.4
>
^ permalink raw reply
* Re: [PATCH v2] kcm: remove any offset before parsing messages
From: Dominique Martinet @ 2018-09-18 1:57 UTC (permalink / raw)
To: David Miller; +Cc: doronrk, tom, davejwatson, netdev, linux-kernel
In-Reply-To: <20180917.184502.447385458615284933.davem@davemloft.net>
David Miller wrote on Mon, Sep 17, 2018:
> From: Dominique Martinet <asmadeus@codewreck.org>
> Date: Wed, 12 Sep 2018 07:36:42 +0200
>
> > Dominique Martinet wrote on Tue, Sep 11, 2018:
> >> Hmm, while trying to benchmark this, I sometimes got hangs in
> >> kcm_wait_data() for the last packet somehow?
> >> The sender program was done (exited (zombie) so I assumed the sender
> >> socket flushed), but the receiver was in kcm_wait_data in kcm_recvmsg
> >> indicating it parsed a header but there was no skb to peek at?
> >> But the sock is locked so this shouldn't be racy...
> >>
> >> I can get it fairly often with this patch and small messages with an
> >> offset, but I think it's just because the pull changes some timing - I
> >> can't hit it with just the clone, and I can hit it with a pull without
> >> clone as well.... And I don't see how pulling a cloned skb can impact
> >> the original socket, but I'm a bit fuzzy on this.
> >
> > This is weird, I cannot reproduce at all without that pull, even if I
> > add another delay there instead of the pull, so it's not just timing...
>
> I really can't apply this patch until you resolve this.
>
> It is weird, given your description, though...
Thanks for the reminder! I totally agree with you here and did not
expect this to be merged as it is (in retrospect, I probably should have
written something to that extent in the subject, "RFC"?)
I really don't have much time to give to that right now as I'm doing
this on my freetime, and the lack of reply has been rather demotivating
so it got pushed back a few times...
Given you did reply now I'll try to spend some time to figure that out
in the next couple of weeks but it might not make it for this cycle
depending on the number of rc we'll get and time you want this to soak
it -next.
(I can start by putting the pull back in netparser and try to reproduce,
it's really weird that I never got it to happen at the time...)
--
Dominique
^ permalink raw reply
* Re: [PATCH] net: bnxt: Fix a uninitialized variable warning.
From: zhong jiang @ 2018-09-18 2:00 UTC (permalink / raw)
To: Michael Chan; +Cc: Vasundhara Volam, David Miller, Netdev, open list
In-Reply-To: <CACKFLineQuBTUGaBLgRqSTEcVzyZaZAnzy0jOHREKdtCqmy6pQ@mail.gmail.com>
On 2018/9/18 1:36, Michael Chan wrote:
> On Mon, Sep 17, 2018 at 9:31 AM, zhong jiang <zhongjiang@huawei.com> wrote:
>> Fix the following compile warning:
>>
>> drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c:49:5: warning: ‘nvm_param.dir_type’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>> if (nvm_param.dir_type == BNXT_NVM_PORT_CFG)
>>
>> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
>> ---
>> drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
>> index f3b9fbc..ab88217 100644
>> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
>> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
>> @@ -31,7 +31,7 @@ static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
>> {
>> struct hwrm_nvm_get_variable_input *req = msg;
>> void *data_addr = NULL, *buf = NULL;
>> - struct bnxt_dl_nvm_param nvm_param;
>> + struct bnxt_dl_nvm_param nvm_param = {0};
>> int bytesize, idx = 0, rc, i;
>> dma_addr_t data_dma_addr;
>>
> I think it is better to return error if there is no param_id match
> after the for loop. The for loop will initialize nvm_param if there
> is param_id match.
Will do in v2. Thanks for review.
Sincerely,
zhong jiang
^ permalink raw reply
* Re: [PATCH] net: socionext: Fix two sleep-in-atomic-context bugs in ave_rxfifo_reset()
From: David Miller @ 2018-09-18 2:03 UTC (permalink / raw)
To: baijiaju1990
Cc: hayashi.kunihiko, yamada.masahiro, robh, andrew, netdev,
linux-kernel
In-Reply-To: <20180915040246.22703-1-baijiaju1990@gmail.com>
From: Jia-Ju Bai <baijiaju1990@gmail.com>
Date: Sat, 15 Sep 2018 12:02:46 +0800
> The driver may sleep with holding a spinlock.
> The function call paths (from bottom to top) in Linux-4.17 are:
>
> [FUNC] usleep_range
> drivers/net/ethernet/socionext/sni_ave.c, 892:
> usleep_range in ave_rxfifo_reset
> drivers/net/ethernet/socionext/sni_ave.c, 932:
> ave_rxfifo_reset in ave_irq_handler
>
> [FUNC] usleep_range
> drivers/net/ethernet/socionext/sni_ave.c, 888:
> usleep_range in ave_rxfifo_reset
> drivers/net/ethernet/socionext/sni_ave.c, 932:
> ave_rxfifo_reset in ave_irq_handler
>
> To fix these bugs, usleep_range() is replaced with udelay().
>
> These bugs are found by my static analysis tool DSAC.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Applied to net-next.
^ permalink raw reply
* [PATCH net-next] gianfar: remove duplicated include from gianfar.c
From: YueHaibing @ 2018-09-18 2:17 UTC (permalink / raw)
To: claudiu.manoil, davem; +Cc: linux-kernel, netdev, YueHaibing
Remove duplicated include.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/freescale/gianfar.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index 40a1a87..c488d31 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -102,8 +102,6 @@
#include <linux/phy_fixed.h>
#include <linux/of.h>
#include <linux/of_net.h>
-#include <linux/of_address.h>
-#include <linux/of_irq.h>
#include "gianfar.h"
--
2.7.0
^ permalink raw reply related
* Re: [bpf PATCH 1/3] bpf: sockmap only allow ESTABLISHED sock state
From: Y Song @ 2018-09-17 20:49 UTC (permalink / raw)
To: John Fastabend; +Cc: edumazet, Alexei Starovoitov, Daniel Borkmann, netdev
In-Reply-To: <20180917173149.21218.31436.stgit@john-Precision-Tower-5810>
On Mon, Sep 17, 2018 at 10:32 AM John Fastabend
<john.fastabend@gmail.com> wrote:
>
> After this patch we only allow socks that are in ESTABLISHED state or
> are being added via a sock_ops event that is transitioning into an
> ESTABLISHED state. By allowing sock_ops events we allow users to
> manage sockmaps directly from sock ops programs. The two supported
> sock_ops ops are BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB and
> BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB.
>
> Similar to TLS ULP this ensures sk_user_data is correct.
>
> Reported-by: Eric Dumazet <edumazet@google.com>
> Fixes: 1aa12bdf1bfb ("bpf: sockmap, add sock close() hook to remove socks")
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Yonghong Song <yhs@fb.com>
^ permalink raw reply
* Re: [PATCH] net: apm: xgene: force XGene enet driver to re-balance IRQ usage
From: David Miller @ 2018-09-18 2:35 UTC (permalink / raw)
To: ahs3; +Cc: netdev, linux-kernel, isubramanian, kchudgar, qnguyen
In-Reply-To: <20180917233533.28626-1-ahs3@redhat.com>
From: Al Stone <ahs3@redhat.com>
Date: Mon, 17 Sep 2018 17:35:33 -0600
> @@ -866,8 +866,11 @@ static int xgene_enet_napi(struct napi_struct *napi, const int budget)
> processed = xgene_enet_process_ring(ring, budget);
>
> if (processed != budget) {
> + struct irq_desc *desc = irq_to_desc(ring->irq);
> +
> napi_complete_done(napi, processed);
> - enable_irq(ring->irq);
> + if (desc && desc->depth > 0)
> + enable_irq(ring->irq);
I really can't accept a patch that grovels into IRQ layer internals
to work around a driver's IRQ enable/disable usage problem.
Sorry.
^ permalink raw reply
* Re: [bpf PATCH 2/3] bpf: sockmap, fix transition through disconnect without close
From: Y Song @ 2018-09-17 21:09 UTC (permalink / raw)
To: John Fastabend; +Cc: edumazet, Alexei Starovoitov, Daniel Borkmann, netdev
In-Reply-To: <20180917173155.21218.11026.stgit@john-Precision-Tower-5810>
On Mon, Sep 17, 2018 at 10:32 AM John Fastabend
<john.fastabend@gmail.com> wrote:
>
> It is possible (via shutdown()) for TCP socks to go trough TCP_CLOSE
> state via tcp_disconnect() without actually calling tcp_close which
> would then call our bpf_tcp_close() callback. Because of this a user
> could disconnect a socket then put it in a LISTEN state which would
> break our assumptions about sockets always being ESTABLISHED state.
>
> To resolve this rely on the unhash hook, which is called in the
> disconnect case, to remove the sock from the sockmap.
>
> Reported-by: Eric Dumazet <edumazet@google.com>
> Fixes: 1aa12bdf1bfb ("bpf: sockmap, add sock close() hook to remove socks")
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
> ---
> kernel/bpf/sockmap.c | 71 +++++++++++++++++++++++++++++++++++++-------------
> 1 file changed, 52 insertions(+), 19 deletions(-)
>
> diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
> index 998b7bd..f6ab7f3 100644
> --- a/kernel/bpf/sockmap.c
> +++ b/kernel/bpf/sockmap.c
> @@ -132,6 +132,7 @@ struct smap_psock {
> struct work_struct gc_work;
>
> struct proto *sk_proto;
> + void (*save_unhash)(struct sock *sk);
> void (*save_close)(struct sock *sk, long timeout);
> void (*save_data_ready)(struct sock *sk);
> void (*save_write_space)(struct sock *sk);
> @@ -143,6 +144,7 @@ static int bpf_tcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
> static int bpf_tcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t size);
> static int bpf_tcp_sendpage(struct sock *sk, struct page *page,
> int offset, size_t size, int flags);
> +static void bpf_tcp_unhash(struct sock *sk);
> static void bpf_tcp_close(struct sock *sk, long timeout);
>
> static inline struct smap_psock *smap_psock_sk(const struct sock *sk)
> @@ -184,6 +186,7 @@ static void build_protos(struct proto prot[SOCKMAP_NUM_CONFIGS],
> struct proto *base)
> {
> prot[SOCKMAP_BASE] = *base;
> + prot[SOCKMAP_BASE].unhash = bpf_tcp_unhash;
> prot[SOCKMAP_BASE].close = bpf_tcp_close;
> prot[SOCKMAP_BASE].recvmsg = bpf_tcp_recvmsg;
> prot[SOCKMAP_BASE].stream_memory_read = bpf_tcp_stream_read;
> @@ -217,6 +220,7 @@ static int bpf_tcp_init(struct sock *sk)
> return -EBUSY;
> }
>
> + psock->save_unhash = sk->sk_prot->unhash;
> psock->save_close = sk->sk_prot->close;
> psock->sk_proto = sk->sk_prot;
>
> @@ -305,30 +309,12 @@ static struct smap_psock_map_entry *psock_map_pop(struct sock *sk,
> return e;
> }
>
> -static void bpf_tcp_close(struct sock *sk, long timeout)
> +static void bpf_tcp_remove(struct sock *sk, struct smap_psock *psock)
> {
> - void (*close_fun)(struct sock *sk, long timeout);
> struct smap_psock_map_entry *e;
> struct sk_msg_buff *md, *mtmp;
> - struct smap_psock *psock;
> struct sock *osk;
>
> - lock_sock(sk);
> - rcu_read_lock();
> - psock = smap_psock_sk(sk);
> - if (unlikely(!psock)) {
> - rcu_read_unlock();
> - release_sock(sk);
> - return sk->sk_prot->close(sk, timeout);
> - }
> -
> - /* The psock may be destroyed anytime after exiting the RCU critial
> - * section so by the time we use close_fun the psock may no longer
> - * be valid. However, bpf_tcp_close is called with the sock lock
> - * held so the close hook and sk are still valid.
> - */
> - close_fun = psock->save_close;
> -
> if (psock->cork) {
> free_start_sg(psock->sock, psock->cork, true);
> kfree(psock->cork);
> @@ -379,6 +365,53 @@ static void bpf_tcp_close(struct sock *sk, long timeout)
> kfree(e);
> e = psock_map_pop(sk, psock);
> }
> +}
> +
> +static void bpf_tcp_unhash(struct sock *sk)
> +{
> + void (*unhash_fun)(struct sock *sk);
> + struct smap_psock *psock;
> +
> + rcu_read_lock();
> + psock = smap_psock_sk(sk);
> + if (unlikely(!psock)) {
> + rcu_read_unlock();
> + release_sock(sk);
Can socket be released here?
> + return sk->sk_prot->unhash(sk);
> + }
> +
> + /* The psock may be destroyed anytime after exiting the RCU critial
> + * section so by the time we use close_fun the psock may no longer
> + * be valid. However, bpf_tcp_close is called with the sock lock
> + * held so the close hook and sk are still valid.
> + */
the comments above are not correct. A copy-paste mistake?
> + unhash_fun = psock->save_unhash;
> + bpf_tcp_remove(sk, psock);
> + rcu_read_unlock();
> + unhash_fun(sk);
> +}
> +
> +static void bpf_tcp_close(struct sock *sk, long timeout)
> +{
> + void (*close_fun)(struct sock *sk, long timeout);
> + struct smap_psock *psock;
> +
> + lock_sock(sk);
> + rcu_read_lock();
> + psock = smap_psock_sk(sk);
> + if (unlikely(!psock)) {
> + rcu_read_unlock();
> + release_sock(sk);
> + return sk->sk_prot->close(sk, timeout);
> + }
> +
> + /* The psock may be destroyed anytime after exiting the RCU critial
> + * section so by the time we use close_fun the psock may no longer
> + * be valid. However, bpf_tcp_close is called with the sock lock
> + * held so the close hook and sk are still valid.
> + */
> + close_fun = psock->save_close;
> + bpf_tcp_remove(sk, psock);
> rcu_read_unlock();
> release_sock(sk);
> close_fun(sk, timeout);
>
^ permalink raw reply
* Re: [PATCH v2 net] net/ipv4: defensive cipso option parsing
From: David Miller @ 2018-09-18 2:38 UTC (permalink / raw)
To: snu; +Cc: netdev, aams, dwmw, yujuan.qi, paul, sveith, stable
In-Reply-To: <20180917174653.17046-1-snu@amazon.com>
From: Stefan Nuernberger <snu@amazon.com>
Date: Mon, 17 Sep 2018 19:46:53 +0200
> commit 40413955ee26 ("Cipso: cipso_v4_optptr enter infinite loop") fixed
> a possible infinite loop in the IP option parsing of CIPSO. The fix
> assumes that ip_options_compile filtered out all zero length options and
> that no other one-byte options beside IPOPT_END and IPOPT_NOOP exist.
> While this assumption currently holds true, add explicit checks for zero
> length and invalid length options to be safe for the future. Even though
> ip_options_compile should have validated the options, the introduction of
> new one-byte options can still confuse this code without the additional
> checks.
>
> Signed-off-by: Stefan Nuernberger <snu@amazon.com>
Applied to net-next.
This is not 'net' nor -stable material. I'm hesitent about this
change as-is, and ip_options_compile() is not changing semantics in
-stable in the way that you say can cause problems.
^ permalink raw reply
* Re: [RFC/fix] Re: libbpf build broken on musl libc (Alpine Linux)
From: Jakub Kicinski @ 2018-09-18 2:39 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Arnaldo Carvalho de Melo, Daniel Borkmann, Thomas Richter,
Hendrik Brueckner, Jiri Olsa, Namhyung Kim, linux-kernel, netdev
In-Reply-To: <20180918005256.7uutwda4s3ofoxpd@ast-mbp>
On Mon, 17 Sep 2018 17:52:59 -0700, Alexei Starovoitov wrote:
> LGPL-2.1 in the above?
Could we possibly make it dual licensed LGPL + BSD?
> The rest looks good to me.
> Should we take it via bpf-next tree?
> If you feel there is an urgency to fix musl build, we can take it via
> bpf tree too.
>
> Jakub, thoughts? you've been messing with strerror last..
Sorry for the mess, I didn't know libc compat is such a pain.
I kind of knowingly ignored the existing str_error_r(), as it didn't
seem excessively clean. Yet, two months later I have no better
ideas.. We could as well switch back to the XSI version, which we used
before I needed access to reallocarray() (I mean change the str_error()
to be a plain XSI wrapper).
Perhaps placing the new helper in libbpf_errno.c file would make
sense? The only reason for this separate file to exist is in fact to
make use of XSI-compliant strerror_r().
Also, I need to go relicense tools/include/tools/libc_compat.h ASAP
too :S
^ permalink raw reply
* Re: [PATCH v2] kcm: remove any offset before parsing messages
From: David Miller @ 2018-09-18 2:40 UTC (permalink / raw)
To: asmadeus; +Cc: doronrk, tom, davejwatson, netdev, linux-kernel
In-Reply-To: <20180918015723.GA26300@nautica>
From: Dominique Martinet <asmadeus@codewreck.org>
Date: Tue, 18 Sep 2018 03:57:23 +0200
> Given you did reply now I'll try to spend some time to figure that out
> in the next couple of weeks but it might not make it for this cycle
> depending on the number of rc we'll get and time you want this to soak
> it -next.
Great.
Remind me, is there actually any way for the bpf programs run in this
situation to even _see_ strp_msg(skb)->offset at all?
There isn't right? And the alternate proposal was to add such a
facility, right?
Just trying to remember all of the context, maybe it's good
information to add to the commit message?
^ permalink raw reply
* [PATCH net-next] cxgb4: remove duplicated include from cxgb4_main.c
From: YueHaibing @ 2018-09-18 2:41 UTC (permalink / raw)
To: davem, ganeshgr; +Cc: linux-kernel, netdev, YueHaibing
Remove duplicated include.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 2e1e286..1a93efa 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -62,7 +62,6 @@
#include <net/netevent.h>
#include <net/addrconf.h>
#include <net/bonding.h>
-#include <net/addrconf.h>
#include <linux/uaccess.h>
#include <linux/crash_dump.h>
#include <net/udp_tunnel.h>
--
2.7.0
^ permalink raw reply related
* Re: [PATCH net-next] gianfar: remove duplicated include from gianfar.c
From: David Miller @ 2018-09-18 2:41 UTC (permalink / raw)
To: yuehaibing; +Cc: claudiu.manoil, linux-kernel, netdev
In-Reply-To: <20180918021718.24400-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Tue, 18 Sep 2018 10:17:18 +0800
> Remove duplicated include.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied, thanks.
^ permalink raw reply
* [PATCH net-next] liquidio: remove duplicated include from lio_vf_rep.c
From: YueHaibing @ 2018-09-18 2:43 UTC (permalink / raw)
To: davem, derek.chickles, satananda.burla, felix.manlunas,
raghu.vatsavayi
Cc: linux-kernel, netdev, YueHaibing
Remove duplicated include.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c b/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c
index a9306164..96cf4a4 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c
@@ -27,7 +27,6 @@
#include "octeon_network.h"
#include <net/switchdev.h>
#include "lio_vf_rep.h"
-#include "octeon_network.h"
static int lio_vf_rep_open(struct net_device *ndev);
static int lio_vf_rep_stop(struct net_device *ndev);
--
2.7.0
^ permalink raw reply related
* Re: [PATCH net-next] cxgb4: remove duplicated include from cxgb4_main.c
From: David Miller @ 2018-09-18 2:44 UTC (permalink / raw)
To: yuehaibing; +Cc: ganeshgr, linux-kernel, netdev
In-Reply-To: <20180918024128.2708-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Tue, 18 Sep 2018 10:41:28 +0800
> Remove duplicated include.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] kcm: remove any offset before parsing messages
From: Dominique Martinet @ 2018-09-18 2:45 UTC (permalink / raw)
To: David Miller; +Cc: doronrk, tom, davejwatson, netdev, linux-kernel
In-Reply-To: <20180917.194059.1970452340378032090.davem@davemloft.net>
David Miller wrote on Mon, Sep 17, 2018:
> Remind me, is there actually any way for the bpf programs run in this
> situation to even _see_ strp_msg(skb)->offset at all?
No, they can see it, so it's possible to make a KCM program that works
right now if you are careful (I'm not sure why the offset within bpf is
different from the offset in the kernel though, it looks like the bpf
program skips the qos part of the control buffer)
> There isn't right? And the alternate proposal was to add such a
> facility, right?
The problem is that this isn't documented at all, and I could not find
any example doing that until Dave gave me one (I couldn't get it to work
because of the different offset).
The alternate proposal was to just document it, yes.
> Just trying to remember all of the context, maybe it's good
> information to add to the commit message?
Good idea, I'll add some more explanation there.
--
Dominique Martinet
^ permalink raw reply
* [PATCH 3/4] qed: remove duplicated include from qed_cxt.c
From: YueHaibing @ 2018-09-18 2:46 UTC (permalink / raw)
To: davem, Ariel.Elior, everest-linux-l2; +Cc: linux-kernel, netdev, YueHaibing
Remove duplicated include.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/qlogic/qed/qed_cxt.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_cxt.c b/drivers/net/ethernet/qlogic/qed/qed_cxt.c
index f1977aa..dc1c1b6 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_cxt.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_cxt.c
@@ -40,7 +40,6 @@
#include <linux/pci.h>
#include <linux/slab.h>
#include <linux/string.h>
-#include <linux/bitops.h>
#include "qed.h"
#include "qed_cxt.h"
#include "qed_dev_api.h"
--
2.7.0
^ permalink raw reply related
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