* 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 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 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 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 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 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] 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
* [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 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
* Re: [PATCH rdma-next 00/24] Extend DEVX functionality
From: Or Gerlitz @ 2018-09-17 20:13 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Jason Gunthorpe, RDMA mailing list, Yishai Hadas,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180917200702.GT3661@mtr-leonro.mtl.com>
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.
>
> 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
^ permalink raw reply
* Re: [PATCH rdma-next 00/24] Extend DEVX functionality
From: Leon Romanovsky @ 2018-09-17 20:07 UTC (permalink / raw)
To: Or Gerlitz
Cc: Doug Ledford, Jason Gunthorpe, RDMA mailing list, Yishai Hadas,
Saeed Mahameed, linux-netdev
In-Reply-To: <CAJ3xEMiTG4103+NO1d80n4fyF2BQTFOk9URBFkRG1EopU6vCaA@mail.gmail.com>
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.
I still prefer to hear answer from respective maintainer to whom this
series was sent.
Thanks
^ permalink raw reply
* Re: [PATCH net-next] net: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-18 1:30 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, netdev, dev
In-Reply-To: <20180917.080945.1667529660601929619.davem@davemloft.net>
On 2018/9/17 23:09, David Miller wrote:
>
> Please don't do this.
>
> The hard part of fixing this is not what you are doing, changing the
> return type.
>
> The hard part is fixing each and every function to actually return
> values which are members of the netdev_tx_t enumeration.
>
> Please fix each and every function properly.
Ok, I will do it, thank you for review.
>
> Thank you.
>
> .
>
^ permalink raw reply
* [PATCH net,stable] qmi_wwan: set DTR for modems in forced USB2 mode
From: Bjørn Mork @ 2018-09-17 20:00 UTC (permalink / raw)
To: netdev; +Cc: linux-usb, Fred Veldini, Deshu Wen, Bjørn Mork
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 related
* Re: [PATCH ethtool] ethtool: support combinations of FEC modes
From: John W. Linville @ 2018-09-17 19:52 UTC (permalink / raw)
To: Edward Cree
Cc: netdev, Ganesh Goudar, Jakub Kicinski, Dustin Byford,
Dirk van der Merwe
In-Reply-To: <518b8b8b-0151-1053-3798-6009044ed53a@solarflare.com>
On Wed, Sep 05, 2018 at 06:54:57PM +0100, Edward Cree wrote:
> Of the three drivers that currently support FEC configuration, two (sfc
> and cxgb4[vf]) accept configurations with more than one bit set in the
> feccmd.fec bitmask. (The precise semantics of these combinations vary.)
> Thus, this patch adds the ability to specify such combinations through a
> comma-separated list of FEC modes in the 'encoding' argument on the
> command line.
>
> Also adds --set-fec tests to test-cmdline.c, and corrects the man page
> (the encoding argument is not optional) while updating it.
>
> Signed-off-by: Edward Cree <ecree@solarflare.com>
> ---
> I've CCed the maintainers of the other drivers (cxgb4, nfp) that support
> --set-fec, in case they have opinions on this.
> I'm not totally happy with the man page changebar; it might be clearer
> just to leave the comma-less version in the syntax synopsis and only
> mention the commas in the running-text.
LGTM -- queued for next release...thanks!
John
> ethtool.8.in | 11 ++++++++---
> ethtool.c | 50 +++++++++++++++++++++++++++++++++++++++-----------
> test-cmdline.c | 9 +++++++++
> 3 files changed, 56 insertions(+), 14 deletions(-)
>
> diff --git a/ethtool.8.in b/ethtool.8.in
> index c8a902a..414eaa1 100644
> --- a/ethtool.8.in
> +++ b/ethtool.8.in
> @@ -389,7 +389,8 @@ ethtool \- query or control network driver and hardware settings
> .HP
> .B ethtool \-\-set\-fec
> .I devname
> -.B4 encoding auto off rs baser
> +.B encoding
> +.BR auto | off | rs | baser [ , ...]
> .
> .\" Adjust lines (i.e. full justification) and hyphenate.
> .ad
> @@ -1119,8 +1120,12 @@ current FEC mode, the driver or firmware must take the link down
> administratively and report the problem in the system logs for users to correct.
> .RS 4
> .TP
> -.A4 encoding auto off rs baser
> -Sets the FEC encoding for the device.
> +.BR encoding\ auto | off | rs | baser [ , ...]
> +
> +Sets the FEC encoding for the device. Combinations of options are specified as
> +e.g.
> +.B auto,rs
> +; the semantics of such combinations vary between drivers.
> .TS
> nokeep;
> lB l.
> diff --git a/ethtool.c b/ethtool.c
> index e8b7703..9997930 100644
> --- a/ethtool.c
> +++ b/ethtool.c
> @@ -4967,20 +4967,48 @@ static int do_set_phy_tunable(struct cmd_context *ctx)
>
> static int fecmode_str_to_type(const char *str)
> {
> + if (!strcasecmp(str, "auto"))
> + return ETHTOOL_FEC_AUTO;
> + if (!strcasecmp(str, "off"))
> + return ETHTOOL_FEC_OFF;
> + if (!strcasecmp(str, "rs"))
> + return ETHTOOL_FEC_RS;
> + if (!strcasecmp(str, "baser"))
> + return ETHTOOL_FEC_BASER;
> +
> + return 0;
> +}
> +
> +/* Takes a comma-separated list of FEC modes, returns the bitwise OR of their
> + * corresponding ETHTOOL_FEC_* constants.
> + * Accepts repetitions (e.g. 'auto,auto') and trailing comma (e.g. 'off,').
> + */
> +static int parse_fecmode(const char *str)
> +{
> int fecmode = 0;
> + char buf[6];
>
> if (!str)
> - return fecmode;
> -
> - if (!strcasecmp(str, "auto"))
> - fecmode |= ETHTOOL_FEC_AUTO;
> - else if (!strcasecmp(str, "off"))
> - fecmode |= ETHTOOL_FEC_OFF;
> - else if (!strcasecmp(str, "rs"))
> - fecmode |= ETHTOOL_FEC_RS;
> - else if (!strcasecmp(str, "baser"))
> - fecmode |= ETHTOOL_FEC_BASER;
> + return 0;
> + while (*str) {
> + size_t next;
> + int mode;
>
> + next = strcspn(str, ",");
> + if (next >= 6) /* Bad mode, longest name is 5 chars */
> + return 0;
> + /* Copy into temp buffer and nul-terminate */
> + memcpy(buf, str, next);
> + buf[next] = 0;
> + mode = fecmode_str_to_type(buf);
> + if (!mode) /* Bad mode encountered */
> + return 0;
> + fecmode |= mode;
> + str += next;
> + /* Skip over ',' (but not nul) */
> + if (*str)
> + str++;
> + }
> return fecmode;
> }
>
> @@ -5028,7 +5056,7 @@ static int do_sfec(struct cmd_context *ctx)
> if (!fecmode_str)
> exit_bad_args();
>
> - fecmode = fecmode_str_to_type(fecmode_str);
> + fecmode = parse_fecmode(fecmode_str);
> if (!fecmode)
> exit_bad_args();
>
> diff --git a/test-cmdline.c b/test-cmdline.c
> index a94edea..9c51cca 100644
> --- a/test-cmdline.c
> +++ b/test-cmdline.c
> @@ -266,6 +266,15 @@ static struct test_case {
> { 0, "--set-eee devname tx-timer 42 advertise 0x4321" },
> { 1, "--set-eee devname tx-timer foo" },
> { 1, "--set-eee devname advertise foo" },
> + { 1, "--set-fec devname" },
> + { 0, "--set-fec devname encoding auto" },
> + { 0, "--set-fec devname encoding off," },
> + { 0, "--set-fec devname encoding baser,rs" },
> + { 0, "--set-fec devname encoding auto,auto," },
> + { 1, "--set-fec devname encoding foo" },
> + { 1, "--set-fec devname encoding auto,foo" },
> + { 1, "--set-fec devname encoding auto,," },
> + { 1, "--set-fec devname auto" },
> /* can't test --set-priv-flags yet */
> { 0, "-h" },
> { 0, "--help" },
>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [bpf PATCH v2 2/3] bpf: sockmap, fix transition through disconnect without close
From: John Fastabend @ 2018-09-17 19:52 UTC (permalink / raw)
To: edumazet, ast, daniel; +Cc: netdev
In-Reply-To: <20180917175922.3870.69188.stgit@john-Precision-Tower-5810>
On 09/17/2018 10:59 AM, John Fastabend 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.
>
Sorry for the noise will need a v3 actually.
> 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(-)
[...]
> +}
> +
> +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);
^^^^^^^^^^^^^^^^^
> + return sk->sk_prot->unhash(sk);
if (sk->sk_prot->unhash) ...
else return;
Thanks,
John
^ permalink raw reply
* Re: [PATCH rdma-next 00/24] Extend DEVX functionality
From: Or Gerlitz @ 2018-09-17 19:51 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Jason Gunthorpe, RDMA mailing list, Yishai Hadas,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180917193426.GR3661@mtr-leonro.mtl.com>
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?
^ permalink raw reply
* Re: [PATCH rdma-next 00/24] Extend DEVX functionality
From: Leon Romanovsky @ 2018-09-17 19:34 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe
Cc: RDMA mailing list, Yishai Hadas, Saeed Mahameed, linux-netdev
In-Reply-To: <20180917110418.18937-1-leon@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4657 bytes --]
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.
Thanks
> IB/mlx5: Set uid as part of CQ creation
> IB/mlx5: Set uid as part of QP creation
> IB/mlx5: Set uid as part of RQ commands
> IB/mlx5: Set uid as part of SQ commands
> IB/mlx5: Set uid as part of TIR commands
> IB/mlx5: Set uid as part of TIS commands
> IB/mlx5: Set uid as part of RQT commands
> IB/mlx5: Set uid as part of PD commands
> IB/mlx5: Set uid as part of TD commands
> IB/mlx5: Set uid as part of SRQ commands
> IB/mlx5: Set uid as part of DCT commands
> IB/mlx5: Set uid as part of XRCD commands
> IB/mlx5: Set uid as part of MCG commands
> IB/mlx5: Set valid umem bit on DEVX
> IB/mlx5: Expose RAW QP device handles to user space
> IB/mlx5: Manage device uid for DEVX white list commands
> IB/mlx5: Enable DEVX white list commands
> IB/mlx5: Enable DEVX on IB
>
> drivers/infiniband/hw/mlx5/cmd.c | 129 ++++++++++++++++++
> drivers/infiniband/hw/mlx5/cmd.h | 14 ++
> drivers/infiniband/hw/mlx5/cq.c | 1 +
> drivers/infiniband/hw/mlx5/devx.c | 182 +++++++++++++++++++++++---
> drivers/infiniband/hw/mlx5/main.c | 80 +++++++----
> drivers/infiniband/hw/mlx5/mlx5_ib.h | 15 +--
> drivers/infiniband/hw/mlx5/qp.c | 141 +++++++++++++++-----
> drivers/infiniband/hw/mlx5/srq.c | 1 +
> drivers/net/ethernet/mellanox/mlx5/core/cq.c | 4 +
> drivers/net/ethernet/mellanox/mlx5/core/qp.c | 81 ++++++++----
> drivers/net/ethernet/mellanox/mlx5/core/srq.c | 30 ++++-
> include/linux/mlx5/cq.h | 1 +
> include/linux/mlx5/driver.h | 1 +
> include/linux/mlx5/mlx5_ifc.h | 135 +++++++++++--------
> include/linux/mlx5/qp.h | 1 +
> include/linux/mlx5/srq.h | 1 +
> include/uapi/rdma/mlx5-abi.h | 13 ++
> 17 files changed, 657 insertions(+), 173 deletions(-)
>
> --
> 2.14.4
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-binding: mediatek: Add binding document for MediaTek GMAC
From: biao huang @ 2018-09-18 1:14 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: davem, robh+dt, honghui.zhang, yt.shen, liguo.zhang, mark.rutland,
sean.wang, nelson.chang, matthias.bgg, netdev, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <fb327132-0830-9df0-434e-06bb0033bac4@cogentembedded.com>
On Mon, 2018-09-17 at 11:33 +0300, Sergei Shtylyov wrote:
> On 9/17/2018 9:29 AM, Biao Huang wrote:
>
> > The commit adds the device tree binding documentation for the MediaTek
> > GMAC found on Mediatek MT2712.
> >
> > Signed-off-by: Biao Huang <biao.huang@mediatek.com>
> > ---
> > .../devicetree/bindings/net/mediatek-gmac.txt | 45 ++++++++++++++++++++
> > 1 file changed, 45 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/net/mediatek-gmac.txt
> >
> > diff --git a/Documentation/devicetree/bindings/net/mediatek-gmac.txt b/Documentation/devicetree/bindings/net/mediatek-gmac.txt
> > new file mode 100644
> > index 0000000..14876ed
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/mediatek-gmac.txt
> > @@ -0,0 +1,45 @@
> > +MediaTek Gigabit Ethernet controller
> > +=========================================
> > +
> > +The gigabit ethernet controller can be found on MediaTek SoCs.
> > +
> > +* Ethernet controller node
> > +
> > +Required properties:
> > +- compatible: Should be
> > + "mediatek,mt2712-eth": for MT2712 SoC
> > +- reg: Address and length of the register set for the device
> > +- interrupts: Should contain the MAC interrupts
> > +- interrupt-names: the name of interrupt in the interrupts property. These are
> > + "macirq": For MT2712 SoC
> > +- clocks: the clock used by the controller
> > +- clock-names: the names of the clock listed in the clocks property. These are
> > + "axi", "apb", "mac_ext", "ptp", "ptp_parent", "ptp_top": For MT2712 SoC
> > +- mac-address: See ethernet.txt in the same directory
> > +- power-domains: phandle to the power domain that the ethernet is part of
>
> This (required) prop is absent in your example.
thanks for your comments, power-domains is not a required property, and
I'll modify this property in next version.
>
> > +- phy-mode: See ethernet.txt file in the same directory.
> > +- reset-gpio: gpio number for phy reset.
> > +
> > +Example:
> > +
> > +eth: eth@1101c000 {
>
> eth: ethernet@1101c000 {
>
> > + compatible = "mediatek,mt2712-eth";
> > + reg = <0 0x1101c000 0 0x1200>;
> > + interrupts = <GIC_SPI 237 IRQ_TYPE_LEVEL_LOW>;
> > + interrupt-names = "macirq";
> > + phy-mode ="rgmii";
> > + mac-address = [00 55 7b b5 7d f7];
> > + clock-names = "axi",
> > + "apb",
> > + "mac_ext",
> > + "ptp",
> > + "ptp_parent",
> > + "ptp_top";
> > + clocks = <&pericfg CLK_PERI_GMAC>,
> > + <&pericfg CLK_PERI_GMAC_PCLK>,
> > + <&topckgen CLK_TOP_ETHER_125M_SEL>,
> > + <&topckgen CLK_TOP_ETHER_50M_SEL>,
> > + <&topckgen CLK_TOP_APLL1_D3>,
> > + <&topckgen CLK_TOP_APLL1>;
> > + reset-gpio = <&pio 87 GPIO_ACTIVE_HIGH>;
> > + };
>
> MBR, Sergei
Best Regards!
Biao
^ permalink raw reply
* Re: [PATCH net-next v3 02/17] zinc: introduce minimal cryptography library
From: Jason A. Donenfeld @ 2018-09-18 0:56 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Ard Biesheuvel, Andrew Lutomirski, David Miller, Andrew Lunn,
Eric Biggers, Greg Kroah-Hartman, LKML, Netdev, Samuel Neves,
Jean-Philippe Aumasson, Linux Crypto Mailing List
In-Reply-To: <63AAE78E-25D7-46E7-84AB-5D0DFD0F1BF2@amacapital.net>
Hey Andy,
On Mon, Sep 17, 2018 at 6:18 PM Andy Lutomirski <luto@amacapital.net> wrote:
> I think it’s fine for later. It’s potentially useful for benchmarking and debugging.
I went ahead and added it anyway in the end. It was really quite easy
to do, and it sets a good template for future primitives that are
added to Zinc.
Meanwhile, I've fully triaged the regression Martin found, and in the
same test he performed, the Zinc code now runs faster than the old
code (which should be no surprise).
I've also finished getting rid of -include, per your suggestion, and
modularizing each algorithm to be loadable independently, per your
suggestion.
All and all, v5 is turning out really well, and I'll probably submit
it sometime soon. My tree was just added to the kbuild test bot, so
I'll hopefully get an email about any breakage *before* I submit this
time.
Regards,
Jason
^ permalink raw reply
* Re: [RFC/fix] Re: libbpf build broken on musl libc (Alpine Linux)
From: Alexei Starovoitov @ 2018-09-18 0:52 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Jakub Kicinski, Daniel Borkmann, Thomas Richter,
Hendrik Brueckner, Jiri Olsa, Namhyung Kim, linux-kernel, netdev
In-Reply-To: <20180917151636.GA21790@kernel.org>
On Mon, Sep 17, 2018 at 12:16:36PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Sep 13, 2018 at 11:56:31AM -0700, Alexei Starovoitov escreveu:
> > On Thu, Sep 13, 2018 at 03:32:40PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Please do some testing with my perf/libbpf+str_error_r branch, it has
> > > two patches to get this fixed, the one I sent and a prep one making
> > > libbpf link against libapi.
>
> > > [acme@jouet perf]$ git log --oneline -2
> > > a7ab924b7fec (HEAD -> perf/urgent, acme.korg/perf/libbpf+str_error_r) tools lib bpf: Use str_error_r() to fix the build in Alpine Linux
> > > fb4a79e04c2b tools lib bpf: Build and link to tools/lib/api/
>
> > https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/commit/?h=perf/libbpf%2bstr_error_r&id=fb4a79e04c2b37ee873a3b31a3250925cf466fff
> > we cannot do this.
> > lib/api is GPL we cannot use it in LGPL library.
>
> So, look at this second attempt, are you ok with it?
>
> Builds with all the Alpine Linux test build containers and some more,
> still building with all the others:
>
> 1 alpine:3.4 : Ok gcc (Alpine 5.3.0) 5.3.0
> 2 alpine:3.5 : Ok gcc (Alpine 6.2.1) 6.2.1 20160822
> 3 alpine:3.6 : Ok gcc (Alpine 6.3.0) 6.3.0
> 4 alpine:3.7 : Ok gcc (Alpine 6.4.0) 6.4.0
> 5 alpine:3.8 : Ok gcc (Alpine 6.4.0) 6.4.0
> 6 alpine:edge : Ok gcc (Alpine 6.4.0) 6.4.0
> 7 amazonlinux:1 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28)
> 8 amazonlinux:2 : Ok gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
> 9 android-ndk:r12b-arm : Ok arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
> 10 android-ndk:r15c-arm : Ok arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
> 11 centos:5 : Ok gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55)
> 12 centos:6 : Ok gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23)
> 13 centos:7 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28)
> 14 debian:7 : Ok gcc (Debian 4.7.2-5) 4.7.2
> 15 debian:8 : Ok gcc (Debian 4.9.2-10+deb8u1) 4.9.2
> 16 debian:9 : Ok gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
> 17 debian:experimental : Ok gcc (Debian 8.2.0-4) 8.2.0
> 18 debian:experimental-x-arm64 : Ok aarch64-linux-gnu-gcc (Debian 8.2.0-4) 8.2.0
> 19 debian:experimental-x-mips : Ok mips-linux-gnu-gcc (Debian 8.2.0-4) 8.2.0
>
> commit 1ca0d8249e5bd335b1c33a33569e4ed94025128e
> Author: Arnaldo Carvalho de Melo <acme@redhat.com>
> Date: Fri Sep 14 16:47:14 2018 -0300
>
> tools lib bpf: Provide wrapper for strerror_r to build in !_GNU_SOURCE systems
>
> Same problem that got fixed in a similar fashion in tools/perf/ in
> c8b5f2c96d1b ("tools: Introduce str_error_r()"), fix it in the same
> way, licensing needs to be sorted out to libbpf to use libapi, so,
> for this simple case, just get the same wrapper in tools/lib/bpf.
>
> This makes libbpf and its users (bpftool, selftests, perf) to build
> again in Alpine Linux 3.[45678] and edge.
>
> Cc: Adrian Hunter <adrian.hunter@intel.com>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: David Ahern <dsahern@gmail.com>
> Cc: Hendrik Brueckner <brueckner@linux.ibm.com>
> Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
> Cc: Jiri Olsa <jolsa@kernel.org>
> Cc: Martin KaFai Lau <kafai@fb.com>
> Cc: Namhyung Kim <namhyung@kernel.org>
> Cc: Quentin Monnet <quentin.monnet@netronome.com>
> Cc: Thomas Richter <tmricht@linux.ibm.com>
> Cc: Wang Nan <wangnan0@huawei.com>
> Cc: Yonghong Song <yhs@fb.com>
> Fixes: 1ce6a9fc1549 ("bpf: fix build error in libbpf with EXTRA_CFLAGS="-Wp, -D_FORTIFY_SOURCE=2 -O2"")
> Link: https://lkml.kernel.org/n/tip-i8ckf6s06e7tayw7xxhhhkux@git.kernel.org
> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>
> diff --git a/tools/lib/bpf/Build b/tools/lib/bpf/Build
> index 13a861135127..6eb9bacd1948 100644
> --- a/tools/lib/bpf/Build
> +++ b/tools/lib/bpf/Build
> @@ -1 +1 @@
> -libbpf-y := libbpf.o bpf.o nlattr.o btf.o libbpf_errno.o
> +libbpf-y := libbpf.o bpf.o nlattr.o btf.o libbpf_errno.o str_error.o
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 2abd0f112627..bdb94939fd60 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -50,6 +50,7 @@
> #include "libbpf.h"
> #include "bpf.h"
> #include "btf.h"
> +#include "str_error.h"
>
> #ifndef EM_BPF
> #define EM_BPF 247
> @@ -469,7 +470,7 @@ static int bpf_object__elf_init(struct bpf_object *obj)
> obj->efile.fd = open(obj->path, O_RDONLY);
> if (obj->efile.fd < 0) {
> char errmsg[STRERR_BUFSIZE];
> - char *cp = strerror_r(errno, errmsg, sizeof(errmsg));
> + char *cp = str_error(errno, errmsg, sizeof(errmsg));
>
> pr_warning("failed to open %s: %s\n", obj->path, cp);
> return -errno;
> @@ -810,8 +811,7 @@ static int bpf_object__elf_collect(struct bpf_object *obj)
> data->d_size, name, idx);
> if (err) {
> char errmsg[STRERR_BUFSIZE];
> - char *cp = strerror_r(-err, errmsg,
> - sizeof(errmsg));
> + char *cp = str_error(-err, errmsg, sizeof(errmsg));
>
> pr_warning("failed to alloc program %s (%s): %s",
> name, obj->path, cp);
> @@ -1140,7 +1140,7 @@ bpf_object__create_maps(struct bpf_object *obj)
>
> *pfd = bpf_create_map_xattr(&create_attr);
> if (*pfd < 0 && create_attr.btf_key_type_id) {
> - cp = strerror_r(errno, errmsg, sizeof(errmsg));
> + cp = str_error(errno, errmsg, sizeof(errmsg));
> pr_warning("Error in bpf_create_map_xattr(%s):%s(%d). Retrying without BTF.\n",
> map->name, cp, errno);
> create_attr.btf_fd = 0;
> @@ -1155,7 +1155,7 @@ bpf_object__create_maps(struct bpf_object *obj)
> size_t j;
>
> err = *pfd;
> - cp = strerror_r(errno, errmsg, sizeof(errmsg));
> + cp = str_error(errno, errmsg, sizeof(errmsg));
> pr_warning("failed to create map (name: '%s'): %s\n",
> map->name, cp);
> for (j = 0; j < i; j++)
> @@ -1339,7 +1339,7 @@ load_program(enum bpf_prog_type type, enum bpf_attach_type expected_attach_type,
> }
>
> ret = -LIBBPF_ERRNO__LOAD;
> - cp = strerror_r(errno, errmsg, sizeof(errmsg));
> + cp = str_error(errno, errmsg, sizeof(errmsg));
> pr_warning("load bpf program failed: %s\n", cp);
>
> if (log_buf && log_buf[0] != '\0') {
> @@ -1654,7 +1654,7 @@ static int check_path(const char *path)
>
> dir = dirname(dname);
> if (statfs(dir, &st_fs)) {
> - cp = strerror_r(errno, errmsg, sizeof(errmsg));
> + cp = str_error(errno, errmsg, sizeof(errmsg));
> pr_warning("failed to statfs %s: %s\n", dir, cp);
> err = -errno;
> }
> @@ -1690,7 +1690,7 @@ int bpf_program__pin_instance(struct bpf_program *prog, const char *path,
> }
>
> if (bpf_obj_pin(prog->instances.fds[instance], path)) {
> - cp = strerror_r(errno, errmsg, sizeof(errmsg));
> + cp = str_error(errno, errmsg, sizeof(errmsg));
> pr_warning("failed to pin program: %s\n", cp);
> return -errno;
> }
> @@ -1708,7 +1708,7 @@ static int make_dir(const char *path)
> err = -errno;
>
> if (err) {
> - cp = strerror_r(-err, errmsg, sizeof(errmsg));
> + cp = str_error(-err, errmsg, sizeof(errmsg));
> pr_warning("failed to mkdir %s: %s\n", path, cp);
> }
> return err;
> @@ -1770,7 +1770,7 @@ int bpf_map__pin(struct bpf_map *map, const char *path)
> }
>
> if (bpf_obj_pin(map->fd, path)) {
> - cp = strerror_r(errno, errmsg, sizeof(errmsg));
> + cp = str_error(errno, errmsg, sizeof(errmsg));
> pr_warning("failed to pin map: %s\n", cp);
> return -errno;
> }
> diff --git a/tools/lib/bpf/str_error.c b/tools/lib/bpf/str_error.c
> new file mode 100644
> index 000000000000..b8798114a357
> --- /dev/null
> +++ b/tools/lib/bpf/str_error.c
> @@ -0,0 +1,18 @@
> +// SPDX-License-Identifier: LGPL-2.1
> +#undef _GNU_SOURCE
> +#include <string.h>
> +#include <stdio.h>
> +#include "str_error.h"
> +
> +/*
> + * Wrapper to allow for building in non-GNU systems such as Alpine Linux's musl
> + * libc, while checking strerror_r() return to avoid having to check this in
> + * all places calling it.
> + */
> +char *str_error(int err, char *dst, int len)
> +{
> + int ret = strerror_r(err, dst, len);
> + if (ret)
> + snprintf(dst, len, "ERROR: strerror_r(%d)=%d", err, ret);
> + return dst;
> +}
> diff --git a/tools/lib/bpf/str_error.h b/tools/lib/bpf/str_error.h
> new file mode 100644
> index 000000000000..b9a22564ddc6
> --- /dev/null
> +++ b/tools/lib/bpf/str_error.h
> @@ -0,0 +1,6 @@
> +// SPDX-License-Identifier: GPL-2.1
LGPL-2.1 in the above?
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..
^ permalink raw reply
* [PATCH] docs: fix some broken documentation references
From: Mauro Carvalho Chehab @ 2018-09-17 19:02 UTC (permalink / raw)
To: linux-kernel
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Jonathan Corbet, Jan Kara,
Stephen Hemminger, David S. Miller, Michael Ellerman,
Greg Kroah-Hartman, Andrew Morton, Arnd Bergmann, linux-doc,
linux-ext4, bridge, netdev
Some documentation files received recent changes and are
pointing to wrong places.
Those references can easily fixed with the help of a
script:
$ ./scripts/documentation-file-ref-check --fix
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/filesystems/dax.txt | 2 +-
Documentation/filesystems/ext2.txt | 2 +-
MAINTAINERS | 4 ++--
net/bridge/Kconfig | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/filesystems/dax.txt b/Documentation/filesystems/dax.txt
index 70cb68bed2e8..bc393e0a22b8 100644
--- a/Documentation/filesystems/dax.txt
+++ b/Documentation/filesystems/dax.txt
@@ -75,7 +75,7 @@ exposure of uninitialized data through mmap.
These filesystems may be used for inspiration:
- ext2: see Documentation/filesystems/ext2.txt
-- ext4: see Documentation/filesystems/ext4.txt
+- ext4: see Documentation/filesystems/ext4/ext4.rst
- xfs: see Documentation/filesystems/xfs.txt
diff --git a/Documentation/filesystems/ext2.txt b/Documentation/filesystems/ext2.txt
index 81c0becab225..a45c9fc0747b 100644
--- a/Documentation/filesystems/ext2.txt
+++ b/Documentation/filesystems/ext2.txt
@@ -358,7 +358,7 @@ and are copied into the filesystem. If a transaction is incomplete at
the time of the crash, then there is no guarantee of consistency for
the blocks in that transaction so they are discarded (which means any
filesystem changes they represent are also lost).
-Check Documentation/filesystems/ext4.txt if you want to read more about
+Check Documentation/filesystems/ext4/ext4.rst if you want to read more about
ext4 and journaling.
References
diff --git a/MAINTAINERS b/MAINTAINERS
index 9989925f658d..078a4cf6d064 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -840,7 +840,7 @@ ANALOG DEVICES INC ADGS1408 DRIVER
M: Mircea Caprioru <mircea.caprioru@analog.com>
S: Supported
F: drivers/mux/adgs1408.c
-F: Documentation/devicetree/bindings/mux/adgs1408.txt
+F: Documentation/devicetree/bindings/mux/adi,adgs1408.txt
ANALOG DEVICES INC ADP5061 DRIVER
M: Stefan Popa <stefan.popa@analog.com>
@@ -5515,7 +5515,7 @@ W: http://ext4.wiki.kernel.org
Q: http://patchwork.ozlabs.org/project/linux-ext4/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
S: Maintained
-F: Documentation/filesystems/ext4.txt
+F: Documentation/filesystems/ext4/ext4.rst
F: fs/ext4/
Extended Verification Module (EVM)
diff --git a/net/bridge/Kconfig b/net/bridge/Kconfig
index aa0d3b2f1bb7..3625d6ade45c 100644
--- a/net/bridge/Kconfig
+++ b/net/bridge/Kconfig
@@ -17,7 +17,7 @@ config BRIDGE
other third party bridge products.
In order to use the Ethernet bridge, you'll need the bridge
- configuration tools; see <file:Documentation/networking/bridge.txt>
+ configuration tools; see <file:Documentation/networking/bridge.rst>
for location. Please read the Bridge mini-HOWTO for more
information.
--
2.17.1
^ permalink raw reply related
* linux-next: manual merge of the net-next tree with the jc_docs tree
From: Stephen Rothwell @ 2018-09-18 0:14 UTC (permalink / raw)
To: David Miller, Networking, Jonathan Corbet
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Henrik Austad,
Tobin C. Harding
[-- Attachment #1: Type: text/plain, Size: 754 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
Documentation/networking/00-INDEX
between commit:
a7ddcea58ae2 ("Drop all 00-INDEX files from Documentation/")
from the jc_docs tree and commit:
a20625e49dde ("docs: net: Remove TCP congestion document")
from the net-next tree.
I fixed it up (I just removed the file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2018-09-18 0:11 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Daniel Borkmann, Vakul Garg
[-- Attachment #1: Type: text/plain, Size: 3248 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
tools/testing/selftests/net/tls.c
between commit:
50c6b58a814d ("tls: fix currently broken MSG_PEEK behavior")
from the net tree and commit:
c2ad647c6442 ("selftests/tls: Add test for recv(PEEK) spanning across multiple records")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc tools/testing/selftests/net/tls.c
index 8fdfeafaf8c0,96fc6fe70293..000000000000
--- a/tools/testing/selftests/net/tls.c
+++ b/tools/testing/selftests/net/tls.c
@@@ -502,55 -502,28 +502,77 @@@ TEST_F(tls, recv_peek_multiple
EXPECT_EQ(memcmp(test_str, buf, send_len), 0);
}
+TEST_F(tls, recv_peek_multiple_records)
+{
+ char const *test_str = "test_read_peek_mult_recs";
+ char const *test_str_first = "test_read_peek";
+ char const *test_str_second = "_mult_recs";
+ int len;
+ char buf[64];
+
+ len = strlen(test_str_first);
+ EXPECT_EQ(send(self->fd, test_str_first, len, 0), len);
+
+ len = strlen(test_str_second) + 1;
+ EXPECT_EQ(send(self->fd, test_str_second, len, 0), len);
+
+ len = sizeof(buf);
+ memset(buf, 0, len);
+ EXPECT_NE(recv(self->cfd, buf, len, MSG_PEEK), -1);
+
+ /* MSG_PEEK can only peek into the current record. */
+ len = strlen(test_str_first) + 1;
+ EXPECT_EQ(memcmp(test_str_first, buf, len), 0);
+
+ len = sizeof(buf);
+ memset(buf, 0, len);
+ EXPECT_NE(recv(self->cfd, buf, len, 0), -1);
+
+ /* Non-MSG_PEEK will advance strparser (and therefore record)
+ * however.
+ */
+ len = strlen(test_str) + 1;
+ EXPECT_EQ(memcmp(test_str, buf, len), 0);
+
+ /* MSG_MORE will hold current record open, so later MSG_PEEK
+ * will see everything.
+ */
+ len = strlen(test_str_first);
+ EXPECT_EQ(send(self->fd, test_str_first, len, MSG_MORE), len);
+
+ len = strlen(test_str_second) + 1;
+ EXPECT_EQ(send(self->fd, test_str_second, len, 0), len);
+
+ len = sizeof(buf);
+ memset(buf, 0, len);
+ EXPECT_NE(recv(self->cfd, buf, len, MSG_PEEK), -1);
+
+ len = strlen(test_str) + 1;
+ EXPECT_EQ(memcmp(test_str, buf, len), 0);
+}
+
+ TEST_F(tls, recv_peek_large_buf_mult_recs)
+ {
+ char const *test_str = "test_read_peek_mult_recs";
+ char const *test_str_first = "test_read_peek";
+ char const *test_str_second = "_mult_recs";
+ int len;
+ char buf[64];
+
+ len = strlen(test_str_first);
+ EXPECT_EQ(send(self->fd, test_str_first, len, 0), len);
+
+ len = strlen(test_str_second) + 1;
+ EXPECT_EQ(send(self->fd, test_str_second, len, 0), len);
+
+ len = sizeof(buf);
+ memset(buf, 0, len);
+ EXPECT_NE(recv(self->cfd, buf, len, MSG_PEEK), -1);
+
+ len = strlen(test_str) + 1;
+ EXPECT_EQ(memcmp(test_str, buf, len), 0);
+ }
+
TEST_F(tls, pollin)
{
char const *test_str = "test_poll";
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] net: apm: xgene: force XGene enet driver to re-balance IRQ usage
From: Al Stone @ 2018-09-17 23:35 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: Al Stone, Iyappan Subramanian, Keyur Chudgar, Quan Nguyen,
David S . Miller
When using the user-space command 'tuned-adm profile network-latency',
the XGene enet driver will cause a hang trying to enable IRQs while
the system is trying to tune itself to be more responsive to network
traffic; dmesg will even tell us that the enables/disables are not
in balance. With this fix, we force the driver to only enable_irq()
when there has been a previous disable_irq() -- i.e., force the number
of calls to each to be balanced. This allows the kernel to continue
operating.
In an ideal world, the XGene enet driver would be restructured to avoid
this problem (it seems to be an artifact of when additional packets
arrive and differences of opinion in how the NIC responds under those
circumstances, some of which is controlled by firmware). In the XGene2
driver, this is not an issue.
However, the XGene (aka Mustang) where this NIC is used is most likely
at the end of its useful life (APM which originally created the XGene
has completely morphed into a new company). It is unlikely the driver
restructuring that is needed will ever be done. There are, however,
a bunch of these machines out in the real world, and there are many
of us still using them daily (me, for example). So, while this patch
is not the ideal way to repair the NIC driver, it does work and allows
us to continue using these boxes for a while longer.
Cc: Iyappan Subramanian <isubramanian@apm.com>
Cc: Keyur Chudgar <kchudgar@apm.com>
Cc: Quan Nguyen <qnguyen@apm.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Al Stone <ahs3@redhat.com>
---
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
index 3b889efddf78..90fb87f7e24e 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -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);
}
return processed;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net] net/ipv4: defensive cipso option parsing
From: Nuernberger, Stefan @ 2018-09-17 18:02 UTC (permalink / raw)
To: paul@paul-moore.com
Cc: netdev@vger.kernel.org, Nuernberger, Stefan,
yujuan.qi@mediatek.com, Shah, Amit, stable@vger.kernel.org
In-Reply-To: <CAHC9VhQ+VKPFmx3R7Ty60KAJhiZwnc2-ZKRYG9w2NSAH7vgnoQ@mail.gmail.com>
On Mon, 2018-09-17 at 12:35 -0400, Paul Moore wrote:
> On Mon, Sep 17, 2018 at 11:12 AM Stefan Nuernberger <snu@amazon.com>
> wrote:
> >
> > 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>
> > Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
> > Reviewed-by: Simon Veith <sveith@amazon.de>
> > Cc: stable@vger.kernel.org
> > ---
> > net/ipv4/cipso_ipv4.c | 10 ++++++++--
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
> > index 82178cc69c96..f291b57b8474 100644
> > --- a/net/ipv4/cipso_ipv4.c
> > +++ b/net/ipv4/cipso_ipv4.c
> > @@ -1512,7 +1512,7 @@ static int cipso_v4_parsetag_loc(const struct
> > cipso_v4_doi *doi_def,
> > *
> > * Description:
> > * Parse the packet's IP header looking for a CIPSO
> > option. Returns a pointer
> > - * to the start of the CIPSO option on success, NULL if one if not
> > found.
> > + * to the start of the CIPSO option on success, NULL if one is not
> > found.
> > *
> > */
> > unsigned char *cipso_v4_optptr(const struct sk_buff *skb)
> > @@ -1522,9 +1522,11 @@ unsigned char *cipso_v4_optptr(const struct
> > sk_buff *skb)
> > int optlen;
> > int taglen;
> >
> > - for (optlen = iph->ihl*4 - sizeof(struct iphdr); optlen >
> > 0; ) {
> > + for (optlen = iph->ihl*4 - sizeof(struct iphdr); optlen >
> > 1; ) {
> > switch (optptr[0]) {
> > case IPOPT_CIPSO:
> > + if (!optptr[1] || optptr[1] > optlen)
> > + return NULL;
> > return optptr;
> > case IPOPT_END:
> > return NULL;
> > @@ -1534,6 +1536,10 @@ unsigned char *cipso_v4_optptr(const struct
> > sk_buff *skb)
> > default:
> > taglen = optptr[1];
> > }
> > +
> > + if (!taglen || taglen > optlen)
> > + break;
> I tend to think that you reach a point where you simply need to trust
> that the stack is doing the right thing and that by the time you hit
> a
> certain point you can safely assume that the packet is well formed,
> but I'm not going to fight about that here.
>
> Regardless of the above, I don't like how you're doing the option
> length check twice in this code, that looks ugly to me, I think we
> can
> do better. How about something like this:
>
> for (...) {
> switch(optptr[0]) {
> case IPOPT_END:
> return NULL;
> case IPOPT_NOOP:
> taglen = 1;
> default:
> taglen = optptr[1];
> }
> if (taglen == 0 || taglen > optlen)
> return NULL;
> if (optptr[0] == IPOPT_CIPSO)
> return optptr;
> ....
> }
>
You're right, that looks much better. I sent around a new patch.
> >
> > optlen -= taglen;
> > optptr += taglen;
> > }
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
^ 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