* 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
* [bpf PATCH v2 3/3] bpf: test_maps, only support ESTABLISHED socks
From: John Fastabend @ 2018-09-17 17:59 UTC (permalink / raw)
To: edumazet, ast, daniel; +Cc: netdev
In-Reply-To: <20180917175801.3870.61111.stgit@john-Precision-Tower-5810>
Ensure that sockets added to a sock{map|hash} that is not in the
ESTABLISHED state is rejected.
Fixes: 1aa12bdf1bfb ("bpf: sockmap, add sock close() hook to remove socks")
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
tools/testing/selftests/bpf/test_maps.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/bpf/test_maps.c b/tools/testing/selftests/bpf/test_maps.c
index 6f54f84..0f2090f 100644
--- a/tools/testing/selftests/bpf/test_maps.c
+++ b/tools/testing/selftests/bpf/test_maps.c
@@ -580,7 +580,11 @@ static void test_sockmap(int tasks, void *data)
/* Test update without programs */
for (i = 0; i < 6; i++) {
err = bpf_map_update_elem(fd, &i, &sfd[i], BPF_ANY);
- if (err) {
+ if (i < 2 && !err) {
+ printf("Allowed update sockmap '%i:%i' not in ESTABLISHED\n",
+ i, sfd[i]);
+ goto out_sockmap;
+ } else if (i > 1 && err) {
printf("Failed noprog update sockmap '%i:%i'\n",
i, sfd[i]);
goto out_sockmap;
@@ -741,7 +745,7 @@ static void test_sockmap(int tasks, void *data)
}
/* Test map update elem afterwards fd lives in fd and map_fd */
- for (i = 0; i < 6; i++) {
+ for (i = 2; i < 6; i++) {
err = bpf_map_update_elem(map_fd_rx, &i, &sfd[i], BPF_ANY);
if (err) {
printf("Failed map_fd_rx update sockmap %i '%i:%i'\n",
@@ -845,7 +849,7 @@ static void test_sockmap(int tasks, void *data)
}
/* Delete the elems without programs */
- for (i = 0; i < 6; i++) {
+ for (i = 2; i < 6; i++) {
err = bpf_map_delete_elem(fd, &i);
if (err) {
printf("Failed delete sockmap %i '%i:%i'\n",
^ permalink raw reply related
* [bpf PATCH v2 2/3] bpf: sockmap, fix transition through disconnect without close
From: John Fastabend @ 2018-09-17 17:59 UTC (permalink / raw)
To: edumazet, ast, daniel; +Cc: netdev
In-Reply-To: <20180917175801.3870.61111.stgit@john-Precision-Tower-5810>
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 1f97b55..7deb362 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);
+ 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.
+ */
+ 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 related
* [bpf PATCH v2 1/3] bpf: sockmap only allow ESTABLISHED sock state
From: John Fastabend @ 2018-09-17 17:59 UTC (permalink / raw)
To: edumazet, ast, daniel; +Cc: netdev
In-Reply-To: <20180917175801.3870.61111.stgit@john-Precision-Tower-5810>
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>
---
kernel/bpf/sockmap.c | 31 ++++++++++++++++++++++++++++++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
index 488ef96..1f97b55 100644
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -2097,8 +2097,12 @@ static int sock_map_update_elem(struct bpf_map *map,
return -EINVAL;
}
+ /* ULPs are currently supported only for TCP sockets in ESTABLISHED
+ * state.
+ */
if (skops.sk->sk_type != SOCK_STREAM ||
- skops.sk->sk_protocol != IPPROTO_TCP) {
+ skops.sk->sk_protocol != IPPROTO_TCP ||
+ skops.sk->sk_state != TCP_ESTABLISHED) {
fput(socket->file);
return -EOPNOTSUPP;
}
@@ -2453,6 +2457,16 @@ static int sock_hash_update_elem(struct bpf_map *map,
return -EINVAL;
}
+ /* ULPs are currently supported only for TCP sockets in ESTABLISHED
+ * state.
+ */
+ if (skops.sk->sk_type != SOCK_STREAM ||
+ skops.sk->sk_protocol != IPPROTO_TCP ||
+ skops.sk->sk_state != TCP_ESTABLISHED) {
+ fput(socket->file);
+ return -EOPNOTSUPP;
+ }
+
lock_sock(skops.sk);
preempt_disable();
rcu_read_lock();
@@ -2543,10 +2557,22 @@ struct sock *__sock_hash_lookup_elem(struct bpf_map *map, void *key)
.map_check_btf = map_check_no_btf,
};
+static bool bpf_is_valid_sock_op(struct bpf_sock_ops_kern *ops)
+{
+ return ops->op == BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB ||
+ ops->op == BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB;
+}
BPF_CALL_4(bpf_sock_map_update, struct bpf_sock_ops_kern *, bpf_sock,
struct bpf_map *, map, void *, key, u64, flags)
{
WARN_ON_ONCE(!rcu_read_lock_held());
+
+ /* ULPs are currently supported only for TCP sockets in ESTABLISHED
+ * state. This checks that the sock ops triggering the update is
+ * one indicating we are (or will be soon) in an ESTABLISHED state.
+ */
+ if (!bpf_is_valid_sock_op(bpf_sock))
+ return -EOPNOTSUPP;
return sock_map_ctx_update_elem(bpf_sock, map, key, flags);
}
@@ -2565,6 +2591,9 @@ struct sock *__sock_hash_lookup_elem(struct bpf_map *map, void *key)
struct bpf_map *, map, void *, key, u64, flags)
{
WARN_ON_ONCE(!rcu_read_lock_held());
+
+ if (!bpf_is_valid_sock_op(bpf_sock))
+ return -EOPNOTSUPP;
return sock_hash_ctx_update_elem(bpf_sock, map, key, flags);
}
^ permalink raw reply related
* [bpf PATCH v2 0/3] bpf, sockmap ESTABLISHED state only
From: John Fastabend @ 2018-09-17 17:59 UTC (permalink / raw)
To: edumazet, ast, daniel; +Cc: netdev
Eric noted that using the close callback is not sufficient
to catch all transitions from ESTABLISHED state to a LISTEN
state. So this series does two things. First, only allow
adding socks in ESTABLISH state and second use unhash callback
to catch tcp_disconnect() transitions.
v2: Added check for ESTABLISH state in hash update sockmap as well.
Thanks,
John
---
John Fastabend (3):
bpf: sockmap only allow ESTABLISHED sock state
bpf: sockmap, fix transition through disconnect without close
bpf: test_maps, only support ESTABLISHED socks
kernel/bpf/sockmap.c | 102 +++++++++++++++++++++++++------
tools/testing/selftests/bpf/test_maps.c | 10 ++-
2 files changed, 89 insertions(+), 23 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next] ravb: do not write 1 to reserved bits
From: Sergei Shtylyov @ 2018-09-17 17:58 UTC (permalink / raw)
To: Simon Horman, David Miller
Cc: Magnus Damm, netdev, linux-renesas-soc, Kazuya Mizuguchi
In-Reply-To: <20180917151911.25450-1-horms+renesas@verge.net.au>
On 09/17/2018 06:19 PM, Simon Horman wrote:
> From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
>
> EtherAVB hardware requires 0 to be written to status register bits in
> order to clear them, however, care must be taken not to:
>
> 1. Clear other bits, by writing zero to them
> 2. Write one to reserved bits
>
> This patch corrects the ravb driver with respect to the second point above.
> This is done by defining reserved bit masks for the affected registers and,
> after auditing the code, ensure all sites that may write a one to a
> reserved bit use are suitably masked.
>
> Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> v2 [Simon Horman]
> * Cover ravb_timestamp_interrupt() by this change
> * Use enum value rather than #define for reserved masks
> * Reword changelog
>
> v1 [Kazuya Mizuguchi]
> ---
> drivers/net/ethernet/renesas/ravb.h | 6 ++++++
> drivers/net/ethernet/renesas/ravb_main.c | 11 ++++++-----
> drivers/net/ethernet/renesas/ravb_ptp.c | 2 +-
> 3 files changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/renesas/ravb.h b/drivers/net/ethernet/renesas/ravb.h
> index 1470fc12282b..bca219edcf94 100644
> --- a/drivers/net/ethernet/renesas/ravb.h
> +++ b/drivers/net/ethernet/renesas/ravb.h
> @@ -428,6 +428,7 @@ enum EIS_BIT {
> EIS_CULF1 = 0x00000080,
> EIS_TFFF = 0x00000100,
> EIS_QFS = 0x00010000,
> + EIS_RESERVED = (u32)(GENMASK(31, 17) | GENMASK(15, 11)),
Are you sure those (u32) casts are necessary? Happily builds in both 32- and 64-bit
mode without them...
[...]
> @@ -528,6 +530,7 @@ enum RIS2_BIT {
> RIS2_QFF16 = 0x00010000,
> RIS2_QFF17 = 0x00020000,
> RIS2_RFFF = 0x80000000,
> + RIS2_RESERVED = (u32)GENMASK_ULL(30, 18),
Why GENMASK_ULL() suddenly? Doesn't seem needed at all...
[...]
> @@ -544,6 +547,8 @@ enum TIS_BIT {
> TIS_FTF1 = 0x00000002, /* Undocumented? */
> TIS_TFUF = 0x00000100,
> TIS_TFWF = 0x00000200,
> + TIS_RESERVED = (u32)(GENMASK_ULL(31, 20) | GENMASK_ULL(15, 12) | \
> + GENMASK_ULL(7, 4))
Same question.
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH net] net: phy: sfp: Prevent NULL deference of socket_ops
From: Russell King - ARM Linux @ 2018-09-17 23:13 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, Andrew Lunn, David S. Miller, open list
In-Reply-To: <3abb0233-4234-ca8c-31ac-8a6b9e123064@gmail.com>
On Mon, Sep 17, 2018 at 10:30:52AM -0700, Florian Fainelli wrote:
> On 09/15/2018 12:32 AM, Russell King - ARM Linux wrote:
> > On Fri, Sep 14, 2018 at 04:01:31PM -0700, Florian Fainelli wrote:
> >> In case we have specified a SFP and an I2C phandle in the Device Tree,
> >> but we somehow failed to look up the I2C adapter (e.g: the driver is not
> >> enabled), we will leave dangling socket_ops, and the sfp_bus will still
> >> have been registered. We can then observe NULL pointer dereferences
> >> while doing ethtool -m:
> >>
> >> [ 20.218613] Unable to handle kernel NULL pointer dereference at virtual address 00000008
> >> [ 20.226977] pgd = (ptrval)
> >> [ 20.229785] [00000008] *pgd=7c400831, *pte=00000000, *ppte=00000000
> >> [ 20.236274] Internal error: Oops: 17 [#1] SMP ARM
> >> [ 20.241122] Modules linked in:
> >> [ 20.244278] CPU: 0 PID: 1480 Comm: ethtool Not tainted 4.19.0-rc3 #138
> >> [ 20.251013] Hardware name: Broadcom Northstar Plus SoC
> >> [ 20.256316] PC is at sfp_get_module_info+0x8/0x10
> >> [ 20.261172] LR is at dev_ethtool+0x218c/0x2afc
> >>
> >> Specifically guard against that.
> >
> > The other alternative to this would be to only set ndev->sfp_bus when
> > the bus moves to registered state, which would probably be a saner
> > alternative than to add an additional layer of tests. IOW:
>
> Indeed, your patch works for me:
>
> Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Thanks, I'll re-send it properly for davem tomorrow.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
^ permalink raw reply
* [bpf PATCH 3/3] bpf: test_maps, only support ESTABLISHED socks
From: John Fastabend @ 2018-09-17 17:32 UTC (permalink / raw)
To: edumazet, ast, daniel; +Cc: netdev
In-Reply-To: <20180917172946.21218.66049.stgit@john-Precision-Tower-5810>
Ensure that sockets added to a sock{map|hash} that is not in the
ESTABLISHED state is rejected.
Fixes: 1aa12bdf1bfb ("bpf: sockmap, add sock close() hook to remove socks")
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
tools/testing/selftests/bpf/test_maps.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/bpf/test_maps.c b/tools/testing/selftests/bpf/test_maps.c
index 6f54f84..0f2090f 100644
--- a/tools/testing/selftests/bpf/test_maps.c
+++ b/tools/testing/selftests/bpf/test_maps.c
@@ -580,7 +580,11 @@ static void test_sockmap(int tasks, void *data)
/* Test update without programs */
for (i = 0; i < 6; i++) {
err = bpf_map_update_elem(fd, &i, &sfd[i], BPF_ANY);
- if (err) {
+ if (i < 2 && !err) {
+ printf("Allowed update sockmap '%i:%i' not in ESTABLISHED\n",
+ i, sfd[i]);
+ goto out_sockmap;
+ } else if (i > 1 && err) {
printf("Failed noprog update sockmap '%i:%i'\n",
i, sfd[i]);
goto out_sockmap;
@@ -741,7 +745,7 @@ static void test_sockmap(int tasks, void *data)
}
/* Test map update elem afterwards fd lives in fd and map_fd */
- for (i = 0; i < 6; i++) {
+ for (i = 2; i < 6; i++) {
err = bpf_map_update_elem(map_fd_rx, &i, &sfd[i], BPF_ANY);
if (err) {
printf("Failed map_fd_rx update sockmap %i '%i:%i'\n",
@@ -845,7 +849,7 @@ static void test_sockmap(int tasks, void *data)
}
/* Delete the elems without programs */
- for (i = 0; i < 6; i++) {
+ for (i = 2; i < 6; i++) {
err = bpf_map_delete_elem(fd, &i);
if (err) {
printf("Failed delete sockmap %i '%i:%i'\n",
^ permalink raw reply related
* [bpf PATCH 2/3] bpf: sockmap, fix transition through disconnect without close
From: John Fastabend @ 2018-09-17 17:31 UTC (permalink / raw)
To: edumazet, ast, daniel; +Cc: netdev
In-Reply-To: <20180917172946.21218.66049.stgit@john-Precision-Tower-5810>
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);
+ 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.
+ */
+ 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 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