* Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions
From: Kees Cook @ 2017-05-22 23:07 UTC (permalink / raw)
To: Djalal Harouni
Cc: Solar Designer, linux-kernel, Network Development, LSM List,
kernel-hardening@lists.openwall.com, Andy Lutomirski,
Andrew Morton, Rusty Russell, Serge E. Hallyn, Jessica Yu,
David S. Miller, James Morris, Paul Moore, Stephen Smalley,
Greg Kroah-Hartman, Tetsuo Handa, Ingo Molnar, Linux API
In-Reply-To: <CAEiveUdb=yc5Gt_+pU_hfNdoNBP0JsUL1QUydNZgc2tD7n1h1w@mail.gmail.com>
On Mon, May 22, 2017 at 12:55 PM, Djalal Harouni <tixxdz@gmail.com> wrote:
> On Mon, May 22, 2017 at 6:43 PM, Solar Designer <solar@openwall.com> wrote:
>> On Mon, May 22, 2017 at 03:49:15PM +0200, Djalal Harouni wrote:
>>> On Mon, May 22, 2017 at 2:08 PM, Solar Designer <solar@openwall.com> wrote:
>>> > On Mon, May 22, 2017 at 01:57:03PM +0200, Djalal Harouni wrote:
>>> >> *) When modules_autoload_mode is set to (2), automatic module loading is
>>> >> disabled for all. Once set, this value can not be changed.
>>> >
>>> > What purpose does this securelevel-like property ("Once set, this value
>>> > can not be changed.") serve here? I think this mode 2 is needed, but
>>> > without this extra property, which is bypassable by e.g. explicitly
>>> > loaded kernel modules anyway (and that's OK).
>>>
>>> My reasoning about "Once set, this value can not be changed" is mainly for:
>>>
>>> If you have some systems where modules are not updated for any given
>>> reason, then the only one who will be able to load a module is an
>>> administrator, basically this is a shortcut for:
>>>
>>> * Apps/services can run with CAP_NET_ADMIN but they are not allowed to
>>> auto-load 'netdev' modules.
>>>
>>> * Explicitly loading modules can be guarded by seccomp filters *per*
>>> app, so even if these apps have
>>> CAP_SYS_MODULE they won't be able to explicitly load modules, one
>>> has to remount some sysctl /proc/ entries read-only here and remove
>>> CAP_SYS_ADMIN for all apps anyway.
>>>
>>> This mainly serves the purpose of these systems that do not receive
>>> updates, if I don't want to expose those kernel interfaces what should
>>> I do ? then if I want to unload old versions and replace them with new
>>> ones what operation should be allowed ? and only real root of the
>>> system can do it. Hence, the "Once set, this value can not be changed"
>>> is more of a shortcut, also the idea was put in my mind based on how
>>> "modules_disabled" is disabled forever, and some other interfaces. I
>>> would say: it is easy to handle a transition from 1) "hey this system
>>> is still up to date, some features should be exposed" to 2) "this
>>> system is not up to date anymore, only root should expose some
>>> features..."
>>>
>>> Hmm, I am not sure if this answers your question ? :-)
>>
>> This answers my question, but in a way that I summarize as "there's no
>> good reason to include this securelevel-like property".
>>
>
> Hmm, sorry I did forget to add in my previous comment that with such
> systems, CAP_SYS_MODULE can be used to reset the
> "modules_autoload_mode" sysctl back from mode 2 to mode 1, even if we
> disable it privileged tasks can be triggered to overwrite the sysctl
> flag and get it back unless /proc is read-only... that's one of the
> points, it should not be so easy to relax it.
I'm on the fence. For modules_disabled and Yama, it was tied to
CAP_SYS_ADMIN, basically designed to be a at-boot setting that could
not later be undone by an attacker gaining that privilege, keeping
them out of either kernel memory or existing user process memory.
Here, it's CAP_SYS_MODULE... it's hard to imagine the situation where
a CAP_SYS_MODULE-capable process could write to this sysctl but NOT
issue direct modprobe requests, but it's _possible_ via crazy symlink
games to trick capable processes into writing to sysctls. We've seen
this multiple times before, and it's a way for attackers to turn a
single privileged write into a privileged exec.
I might turn the question around, though: why would we want to have it
changeable at this setting?
I'm fine leaving that piece off, either way.
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* Re: [PATCH net-next 2/2] samples/bpf: add samples for HW_CACHE / RAW events
From: David Miller @ 2017-05-22 23:26 UTC (permalink / raw)
To: ast; +Cc: peterz, bgregg, daniel, qinteng, netdev, linux-kernel,
kernel-team
In-Reply-To: <20170522224840.810121-3-ast@fb.com>
From: Alexei Starovoitov <ast@fb.com>
Date: Mon, 22 May 2017 15:48:40 -0700
> @@ -31,7 +31,7 @@ static unsigned long long (*bpf_get_current_uid_gid)(void) =
> (void *) BPF_FUNC_get_current_uid_gid;
> static int (*bpf_get_current_comm)(void *buf, int buf_size) =
> (void *) BPF_FUNC_get_current_comm;
> -static int (*bpf_perf_event_read)(void *map, int index) =
> +static u64 (*bpf_perf_event_read)(void *map, u64 flags) =
> (void *) BPF_FUNC_perf_event_read;
If the second argument really is "u64 flags", then please update
the comments in tools/include/uapi/linux/bpf.h as well.
Thank you.
^ permalink raw reply
* [PATCH v2 netdev] net: phy: marvell: Limit errata to 88m1101
From: Andrew Lunn @ 2017-05-22 23:28 UTC (permalink / raw)
To: David Miller
Cc: Daniel Walker, Harini Katakam, Florian Fainelli, netdev,
Andrew Lunn
The 88m1101 has an errata when configuring autoneg. However, it was
being applied to many other Marvell PHYs as well. Limit its scope to
just the 88m1101.
Fixes: 76884679c644 ("phylib: Add support for Marvell 88e1111S and 88e1145")
Reported-by: Daniel Walker <danielwa@cisco.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
v2:
Forgot netdev
drivers/net/phy/marvell.c | 67 ++++++++++++++++++++++++++---------------------
1 file changed, 37 insertions(+), 30 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 88cd97b44ba6..77221d3f254f 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -267,35 +267,6 @@ static int marvell_config_aneg(struct phy_device *phydev)
{
int err;
- /* The Marvell PHY has an errata which requires
- * that certain registers get written in order
- * to restart autonegotiation
- */
- err = phy_write(phydev, MII_BMCR, BMCR_RESET);
-
- if (err < 0)
- return err;
-
- err = phy_write(phydev, 0x1d, 0x1f);
- if (err < 0)
- return err;
-
- err = phy_write(phydev, 0x1e, 0x200c);
- if (err < 0)
- return err;
-
- err = phy_write(phydev, 0x1d, 0x5);
- if (err < 0)
- return err;
-
- err = phy_write(phydev, 0x1e, 0);
- if (err < 0)
- return err;
-
- err = phy_write(phydev, 0x1e, 0x100);
- if (err < 0)
- return err;
-
err = marvell_set_polarity(phydev, phydev->mdix_ctrl);
if (err < 0)
return err;
@@ -328,6 +299,42 @@ static int marvell_config_aneg(struct phy_device *phydev)
return 0;
}
+static int m88e1101_config_aneg(struct phy_device *phydev)
+{
+ int err;
+
+ /* This Marvell PHY has an errata which requires
+ * that certain registers get written in order
+ * to restart autonegotiation
+ */
+ err = phy_write(phydev, MII_BMCR, BMCR_RESET);
+
+ if (err < 0)
+ return err;
+
+ err = phy_write(phydev, 0x1d, 0x1f);
+ if (err < 0)
+ return err;
+
+ err = phy_write(phydev, 0x1e, 0x200c);
+ if (err < 0)
+ return err;
+
+ err = phy_write(phydev, 0x1d, 0x5);
+ if (err < 0)
+ return err;
+
+ err = phy_write(phydev, 0x1e, 0);
+ if (err < 0)
+ return err;
+
+ err = phy_write(phydev, 0x1e, 0x100);
+ if (err < 0)
+ return err;
+
+ return marvell_config_aneg(phydev);
+}
+
static int m88e1111_config_aneg(struct phy_device *phydev)
{
int err;
@@ -1960,7 +1967,7 @@ static struct phy_driver marvell_drivers[] = {
.flags = PHY_HAS_INTERRUPT,
.probe = marvell_probe,
.config_init = &marvell_config_init,
- .config_aneg = &marvell_config_aneg,
+ .config_aneg = &m88e1101_config_aneg,
.read_status = &genphy_read_status,
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net-next 00/20] net: dsa: distribute switch events
From: David Miller @ 2017-05-22 23:31 UTC (permalink / raw)
To: f.fainelli; +Cc: vivien.didelot, netdev, linux-kernel, kernel, andrew
In-Reply-To: <ce634f83-35b0-abbf-a18b-61d3feccc097@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 22 May 2017 13:01:06 -0700
> For this entire series:
>
> Tested-by: Florian Fainelli <f.fainelli@gmail.com>
>
> on a 7445 (bcm-sf2), normal bridging still worked, and bridging with
> VLAN filtering also did, just like adding VLANs to user-facing ports
> also did.
>
> Great job!
Series applied, thanks.
Andrew, if you have any feedback or have any reservations about what
this series is doing, don't worry. I'm sure you can work it out with
Vivien and he'll make whatever changes are necessary to make you happy
about it.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 2/2] samples/bpf: add samples for HW_CACHE / RAW events
From: Alexei Starovoitov @ 2017-05-22 23:35 UTC (permalink / raw)
To: David Miller
Cc: peterz, bgregg, daniel, qinteng, netdev, linux-kernel,
kernel-team
In-Reply-To: <20170522.192651.252662920166760334.davem@davemloft.net>
On 5/22/17 4:26 PM, David Miller wrote:
> From: Alexei Starovoitov <ast@fb.com>
> Date: Mon, 22 May 2017 15:48:40 -0700
>
>> @@ -31,7 +31,7 @@ static unsigned long long (*bpf_get_current_uid_gid)(void) =
>> (void *) BPF_FUNC_get_current_uid_gid;
>> static int (*bpf_get_current_comm)(void *buf, int buf_size) =
>> (void *) BPF_FUNC_get_current_comm;
>> -static int (*bpf_perf_event_read)(void *map, int index) =
>> +static u64 (*bpf_perf_event_read)(void *map, u64 flags) =
>> (void *) BPF_FUNC_perf_event_read;
>
> If the second argument really is "u64 flags", then please update
> the comments in tools/include/uapi/linux/bpf.h as well.
of course.
As independent patch, I assume.
For both tools/include/uapi/...bpf.h and include/uapi/...bpf.h
It has some info:
/* BPF_FUNC_perf_event_output and BPF_FUNC_perf_event_read flags. */
#define BPF_F_INDEX_MASK 0xffffffffULL
#define BPF_F_CURRENT_CPU BPF_F_INDEX_MASK
yet perf_event_read() is least documented. hmm.
* u64 bpf_perf_event_read(&map, index)
* Return: Number events read or error code
that needs to be fixed.
^ permalink raw reply
* Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions
From: Andy Lutomirski @ 2017-05-22 23:38 UTC (permalink / raw)
To: Kees Cook
Cc: Djalal Harouni, Solar Designer, linux-kernel, Network Development,
LSM List, kernel-hardening@lists.openwall.com, Andy Lutomirski,
Andrew Morton, Rusty Russell, Serge E. Hallyn, Jessica Yu,
David S. Miller, James Morris, Paul Moore, Stephen Smalley,
Greg Kroah-Hartman, Tetsuo Handa, Ingo Molnar
In-Reply-To: <CAGXu5jKGnG74KE-k9JPaH1bNqT5nbVioaeu_5sAKQ+4kgp-0Ng@mail.gmail.com>
On Mon, May 22, 2017 at 4:07 PM, Kees Cook <keescook@chromium.org> wrote:
> On Mon, May 22, 2017 at 12:55 PM, Djalal Harouni <tixxdz@gmail.com> wrote:
>> On Mon, May 22, 2017 at 6:43 PM, Solar Designer <solar@openwall.com> wrote:
>>> On Mon, May 22, 2017 at 03:49:15PM +0200, Djalal Harouni wrote:
>>>> On Mon, May 22, 2017 at 2:08 PM, Solar Designer <solar@openwall.com> wrote:
>>>> > On Mon, May 22, 2017 at 01:57:03PM +0200, Djalal Harouni wrote:
>>>> >> *) When modules_autoload_mode is set to (2), automatic module loading is
>>>> >> disabled for all. Once set, this value can not be changed.
>>>> >
>>>> > What purpose does this securelevel-like property ("Once set, this value
>>>> > can not be changed.") serve here? I think this mode 2 is needed, but
>>>> > without this extra property, which is bypassable by e.g. explicitly
>>>> > loaded kernel modules anyway (and that's OK).
>>>>
>>>> My reasoning about "Once set, this value can not be changed" is mainly for:
>>>>
>>>> If you have some systems where modules are not updated for any given
>>>> reason, then the only one who will be able to load a module is an
>>>> administrator, basically this is a shortcut for:
>>>>
>>>> * Apps/services can run with CAP_NET_ADMIN but they are not allowed to
>>>> auto-load 'netdev' modules.
>>>>
>>>> * Explicitly loading modules can be guarded by seccomp filters *per*
>>>> app, so even if these apps have
>>>> CAP_SYS_MODULE they won't be able to explicitly load modules, one
>>>> has to remount some sysctl /proc/ entries read-only here and remove
>>>> CAP_SYS_ADMIN for all apps anyway.
>>>>
>>>> This mainly serves the purpose of these systems that do not receive
>>>> updates, if I don't want to expose those kernel interfaces what should
>>>> I do ? then if I want to unload old versions and replace them with new
>>>> ones what operation should be allowed ? and only real root of the
>>>> system can do it. Hence, the "Once set, this value can not be changed"
>>>> is more of a shortcut, also the idea was put in my mind based on how
>>>> "modules_disabled" is disabled forever, and some other interfaces. I
>>>> would say: it is easy to handle a transition from 1) "hey this system
>>>> is still up to date, some features should be exposed" to 2) "this
>>>> system is not up to date anymore, only root should expose some
>>>> features..."
>>>>
>>>> Hmm, I am not sure if this answers your question ? :-)
>>>
>>> This answers my question, but in a way that I summarize as "there's no
>>> good reason to include this securelevel-like property".
>>>
>>
>> Hmm, sorry I did forget to add in my previous comment that with such
>> systems, CAP_SYS_MODULE can be used to reset the
>> "modules_autoload_mode" sysctl back from mode 2 to mode 1, even if we
>> disable it privileged tasks can be triggered to overwrite the sysctl
>> flag and get it back unless /proc is read-only... that's one of the
>> points, it should not be so easy to relax it.
>
> I'm on the fence. For modules_disabled and Yama, it was tied to
> CAP_SYS_ADMIN, basically designed to be a at-boot setting that could
> not later be undone by an attacker gaining that privilege, keeping
> them out of either kernel memory or existing user process memory.
> Here, it's CAP_SYS_MODULE... it's hard to imagine the situation where
> a CAP_SYS_MODULE-capable process could write to this sysctl but NOT
> issue direct modprobe requests, but it's _possible_ via crazy symlink
> games to trick capable processes into writing to sysctls. We've seen
> this multiple times before, and it's a way for attackers to turn a
> single privileged write into a privileged exec.
>
> I might turn the question around, though: why would we want to have it
> changeable at this setting?
>
> I'm fine leaving that piece off, either way.
I think that having the un-resettable mode is unnecessary. We should
have option that disables loading modules entirely and cannot be
unset. (That means no explicit loads and not implicit loads.) Maybe
we already have this. Otherwise, tightening caps needed for implicit
loads should just be a normal yes/no setting IMO.
^ permalink raw reply
* Re: [PATCH net-next 2/2] samples/bpf: add samples for HW_CACHE / RAW events
From: David Miller @ 2017-05-22 23:40 UTC (permalink / raw)
To: ast; +Cc: peterz, bgregg, daniel, qinteng, netdev, linux-kernel,
kernel-team
In-Reply-To: <63c0ec55-9cb7-50a0-2020-fe17283e532b@fb.com>
From: Alexei Starovoitov <ast@fb.com>
Date: Mon, 22 May 2017 16:35:07 -0700
> yet perf_event_read() is least documented. hmm.
> * u64 bpf_perf_event_read(&map, index)
> * Return: Number events read or error code
>
> that needs to be fixed.
That's exactly what I was talking about :-)
^ permalink raw reply
* Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions
From: Kees Cook @ 2017-05-22 23:52 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Djalal Harouni, Solar Designer, linux-kernel, Network Development,
LSM List, kernel-hardening@lists.openwall.com, Andrew Morton,
Rusty Russell, Serge E. Hallyn, Jessica Yu, David S. Miller,
James Morris, Paul Moore, Stephen Smalley, Greg Kroah-Hartman,
Tetsuo Handa, Ingo Molnar, Linux API
In-Reply-To: <CALCETrXyf3vM+NdFNcjwaOZs1KFJomuTL0DobXoH9Z68k8dknQ@mail.gmail.com>
On Mon, May 22, 2017 at 4:38 PM, Andy Lutomirski <luto@kernel.org> wrote:
> I think that having the un-resettable mode is unnecessary. We should
> have option that disables loading modules entirely and cannot be
> unset. (That means no explicit loads and not implicit loads.) Maybe
> we already have this. Otherwise, tightening caps needed for implicit
> loads should just be a normal yes/no setting IMO.
Yup, /proc/sys/kernel/modules_disabled already does this.
--
Kees Cook
Pixel Security
^ permalink raw reply
* Re: [PATCH 00/12] Netfilter/IPVS fixes for net
From: David Miller @ 2017-05-22 23:54 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <20170521222538.GA2370@salvia>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Mon, 22 May 2017 00:25:38 +0200
> Could you merge net into net-next as well? I have several patches for
> net-next that need to apply on these fixes. No rush BTW.
Sure, no problem.
As soon as Linus takes in my pull request from today, I will do this
and let you know.
^ permalink raw reply
* Re: [patch net-next RFC] net: sched: cls_api: make reclassify return all the way back to the original tp
From: Cong Wang @ 2017-05-22 23:57 UTC (permalink / raw)
To: Jiri Pirko
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
David Ahern, Eric Dumazet, Stephen Hemminger, Daniel Borkmann,
Alexander Duyck, Simon Horman, mlxsw
In-Reply-To: <20170522150942.1703-1-jiri@resnulli.us>
On Mon, May 22, 2017 at 8:09 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> With the introduction of chain goto action, the reclassification would
> cause the re-iteration of the actual chain. But it perhaps makes more
> sense to restart the whole thing. Thoughts?
I think reclassification is meant to restart the whole logic rather
than just one chain. So your patch makes sense to me, but not
sure if there is any corner case I miss.
^ permalink raw reply
* Re: [PATCH net 1/3] vlan: Fix tcp checksums offloads for Q-in-Q vlan.
From: David Miller @ 2017-05-22 23:59 UTC (permalink / raw)
To: vyasevich; +Cc: netdev, vyasevic, makita.toshiaki
In-Reply-To: <1495114265-23368-2-git-send-email-vyasevic@redhat.com>
From: Vladislav Yasevich <vyasevich@gmail.com>
Date: Thu, 18 May 2017 09:31:03 -0400
> It appears that since commit 8cb65d000, Q-in-Q vlans have been
> broken. The series that commit is part of enabled TSO and checksum
> offloading on Q-in-Q vlans. However, most HW we support can't handle
> it. To work around the issue, the above commit added a function that
> turns off offloads on Q-in-Q devices, but it left the checksum offload.
> That will cause issues with most older devices that supprort very basic
> checksum offload capabilities as well as some newer devices (we've
> reproduced te problem with both be2net and bnx).
>
> To solve this for everyone, turn off checksum offloading feature
> by default when sending Q-in-Q traffic. Devices that are proven to
> work can provided a corrected ndo_features_check implemetation.
>
> Fixes: 8cb65d000 ("net: Move check for multiple vlans to drivers")
> CC: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
This is a tough one. I can certainly sympathize with your frustration
trying to track this down.
Clearing NETIF_F_HW_CSUM completely is the most conservative change.
However, for all the (perhaps many) cards upon which the checksumming
does work properly in Q-in-Q situations, this change could be
introducing non-trivial performance regressions.
So I think Toshiaki's suggestion to drop IP_CSUM and IPV6_CSUM is,
on balance, the best way forward.
Thanks.
^ permalink raw reply
* [PATCH net-next] bpf: update perf event helper function signature and documentation
From: Teng Qin @ 2017-05-23 0:39 UTC (permalink / raw)
To: David S . Miller
Cc: Peter Zijlstra, Brendan Gregg, Daniel Borkmann,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Kernel Team,
Alexei Starovoitov
From: Teng Qin <qinteng@fb.com>
This commit updates function signature of the bpf_perf_event_output and
bpf_perf_event_read helpers to match their implementation. Also updates
their documentation in the header files.
Signed-off-by: Teng Qin <qinteng@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
include/uapi/linux/bpf.h | 11 +++++++----
samples/bpf/bpf_helpers.h | 5 ++---
tools/include/uapi/linux/bpf.h | 11 +++++++----
3 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 94dfa9d..e78aece 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -313,8 +313,11 @@ union bpf_attr {
* @flags: room for future extensions
* Return: 0 on success or negative error
*
- * u64 bpf_perf_event_read(&map, index)
- * Return: Number events read or error code
+ * u64 bpf_perf_event_read(map, flags)
+ * read perf event counter value
+ * @map: pointer to perf_event_array map
+ * @flags: index of event in the map or bitmask flags
+ * Return: value of perf event counter read or error code
*
* int bpf_redirect(ifindex, flags)
* redirect to another netdev
@@ -328,11 +331,11 @@ union bpf_attr {
* @skb: pointer to skb
* Return: realm if != 0
*
- * int bpf_perf_event_output(ctx, map, index, data, size)
+ * int bpf_perf_event_output(ctx, map, flags, data, size)
* output perf raw sample
* @ctx: struct pt_regs*
* @map: pointer to perf_event_array map
- * @index: index of event in the map
+ * @flags: index of event in the map or bitmask flags
* @data: data on stack to be output as raw data
* @size: size of data
* Return: 0 on success or negative error
diff --git a/samples/bpf/bpf_helpers.h b/samples/bpf/bpf_helpers.h
index 9a9c95f..a94ce42 100644
--- a/samples/bpf/bpf_helpers.h
+++ b/samples/bpf/bpf_helpers.h
@@ -37,9 +37,8 @@ static int (*bpf_clone_redirect)(void *ctx, int ifindex, int flags) =
(void *) BPF_FUNC_clone_redirect;
static int (*bpf_redirect)(int ifindex, int flags) =
(void *) BPF_FUNC_redirect;
-static int (*bpf_perf_event_output)(void *ctx, void *map,
- unsigned long long flags, void *data,
- int size) =
+static int (*bpf_perf_event_output)(void *ctx, void *map, u64 flags,
+ void *data, int size) =
(void *) BPF_FUNC_perf_event_output;
static int (*bpf_get_stackid)(void *ctx, void *map, int flags) =
(void *) BPF_FUNC_get_stackid;
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 94dfa9d..e78aece 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -313,8 +313,11 @@ union bpf_attr {
* @flags: room for future extensions
* Return: 0 on success or negative error
*
- * u64 bpf_perf_event_read(&map, index)
- * Return: Number events read or error code
+ * u64 bpf_perf_event_read(map, flags)
+ * read perf event counter value
+ * @map: pointer to perf_event_array map
+ * @flags: index of event in the map or bitmask flags
+ * Return: value of perf event counter read or error code
*
* int bpf_redirect(ifindex, flags)
* redirect to another netdev
@@ -328,11 +331,11 @@ union bpf_attr {
* @skb: pointer to skb
* Return: realm if != 0
*
- * int bpf_perf_event_output(ctx, map, index, data, size)
+ * int bpf_perf_event_output(ctx, map, flags, data, size)
* output perf raw sample
* @ctx: struct pt_regs*
* @map: pointer to perf_event_array map
- * @index: index of event in the map
+ * @flags: index of event in the map or bitmask flags
* @data: data on stack to be output as raw data
* @size: size of data
* Return: 0 on success or negative error
--
2.9.3
^ permalink raw reply related
* [PATCH net-next] net: rfs: Don't reset RFS entries when nothing changed
From: gfree.wind @ 2017-05-23 0:45 UTC (permalink / raw)
To: davem, netdev; +Cc: Gao Feng
From: Gao Feng <gfree.wind@vip.163.com>
When the new RFS table size specified by sysctl equals the old one,
there is nothing changed actually. So it is unnecessary to reset the
RFS table entris.
Signed-off-by: Gao Feng <gfree.wind@vip.163.com>
---
net/core/sysctl_net_core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index ea23254..80b6a7e 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -69,11 +69,12 @@ static int rps_sock_flow_sysctl(struct ctl_table *table, int write,
}
rps_cpu_mask = roundup_pow_of_two(nr_cpu_ids) - 1;
sock_table->mask = size - 1;
+
+ for (i = 0; i < size; i++)
+ sock_table->ents[i] = RPS_NO_CPU;
} else
sock_table = orig_sock_table;
- for (i = 0; i < size; i++)
- sock_table->ents[i] = RPS_NO_CPU;
} else
sock_table = NULL;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] net: ieee802154: fix net_device reference release too early
From: zhanglin496 @ 2017-05-23 1:45 UTC (permalink / raw)
To: stefan; +Cc: aar, davem, linux-wpan, netdev, linux-kernel
Hello.
Sorry too late to reply.
>
> Hello.
>
> On Thu, 2017-05-18 at 15:14, Stefan Schmidt wrote:
> > Hello.
> >
> > On Thu, 2017-05-18 at 15:50, linzhang wrote:
> > > This patch fixes the kernel oops when release net_device reference in
> > > advance. In function raw_sendmsg(i think the dgram_sendmsg has the same
> > > problem), there is a race condition between dev_put and dev_queue_xmit
> > > when the device is gong that maybe lead to dev_queue_ximt to see
> > > an illegal net_device pointer.
> > >
> >
> > You have a test case to reproduce this oops? I fear I have not seen
> > one.
>
> If you have a test case handy adding it to the commit would be handy. If you do
> not have one around we can do without.
>
My test kernel is 3.13.0-32.
Becasue i am not have a real 802154 device, so i change lowpan_newlink
function to this:
/* find and hold real wpan device */
real_dev = dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));
if (!real_dev)
return -ENODEV;
// if (real_dev->type != ARPHRD_IEEE802154) {
// dev_put(real_dev);
// return -EINVAL;
// }
lowpan_dev_info(dev)->real_dev = real_dev;
lowpan_dev_info(dev)->fragment_tag = 0;
mutex_init(&lowpan_dev_info(dev)->dev_list_mtx);
Also, in order to simulate preempt, i change the raw_sendmsg function to this:
skb->dev = dev;
skb->sk = sk;
skb->protocol = htons(ETH_P_IEEE802154);
dev_put(dev);
//simulate preempt
schedule_timeout_uninterruptible(30 * HZ);
err = dev_queue_xmit(skb);
if (err > 0)
err = net_xmit_errno(err);
and this is my userspace test code named test_send_data:
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/socket.h>
int main(int argc, char **argv)
{
char buf[127];
int sockfd;
sockfd = socket(AF_IEEE802154, SOCK_RAW, 0);
if (sockfd < 0) {
printf("create sockfd error: %s\n", strerror(errno));
return -1;
}
send(sockfd, buf, sizeof(buf), 0);
return 0;
}
This is my test case:
root@zhanglin-x-computer:~/develop/802154# uname -a
Linux zhanglin-x-computer 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15
03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
root@zhanglin-x-computer:~/develop/802154# ip link add link eth0 name
lowpan0 type lowpan
root@zhanglin-x-computer:~/develop/802154#
//keep the lowpan0 device down
root@zhanglin-x-computer:~/develop/802154# ./test_send_data &
//wait a while
root@zhanglin-x-computer:~/develop/802154# ip link del link dev lowpan0
//the device is gone
//oops
[381.303307] general protection fault: 0000 [#1]SMP
[381.303407] Modules linked in: af_802154 6lowpan bnep rfcomm
bluetooth nls_iso8859_1 snd_hda_codec_hdmi snd_hda_codec_realtek
rts5139(C) snd_hda_intel
snd_had_codec snd_hwdep snd_pcm snd_page_alloc snd_seq_midi
snd_seq_midi_event snd_rawmidi snd_req intel_rapl snd_seq_device
coretemp i915 kvm_intel
kvm snd_timer snd crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
cypted drm_kms_helper drm i2c_algo_bit soundcore video mac_hid
parport_pc ppdev ip parport hid_generic
usbhid hid ahci r8169 mii libahdi
[381.304286] CPU:1 PID: 2524 Commm: 1 Tainted: G C 0 3.13.0-32-generic
#57-Ubuntu
[381.304409] Hardware name: Haier Haier DT Computer/Haier DT Codputer,
BIOS FIBT19H02_X64 06/09/2014
[381.304546] tasks: ffff000096965fc0 ti: ffffB0013779c000 task.ti:
ffffB8013779c000
[381.304659] RIP: 0010:[<ffffffff01621fe1>] [<ffffffff81621fe1>]
__dev_queue_ximt+0x61/0x500
[381.304798] RSP: 0018:ffffB8013779dca0 EFLAGS: 00010202
[381.304880] RAX: 272b031d57565351 RBX: 0000000000000000 RCX: ffff8800968f1a00
[381.304987] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8800968f1a00
[381.305095] RBP: ffff8e013773dce0 R08: 0000000000000266 R09: 0000000000000004
[381.305202] R10: 0000000000000004 R11: 0000000000000005 R12: ffff88013902e000
[381.305310] R13: 000000000000007f R14: 000000000000007f R15: ffff8800968f1a00
[381.305418] FS: 00007fc57f50f740(0000) GS: ffff88013fc80000(0000)
knlGS: 0000000000000000
[381.305540] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[381.305627] CR2: 00007fad0841c000 CR3: 00000001368dd000 CR4: 00000000001007e0
[361.905734] Stack:
[381.305768] 00000000002052d0 000000003facb30a ffff88013779dcc0
ffff880137764000
[381.305898] ffff88013779de70 000000000000007f 000000000000007f
ffff88013902e000
[381.306026] ffff88013779dcf0 ffffffff81622490 ffff88013779dd39
ffffffffa03af9f1
[381.306155] Call Trace:
[381.306202] [<ffffffff81622490>] dev_queue_xmit+0x10/0x20
[381.306294] [<ffffffffa03af9f1>] raw_sendmsg+0x1b1/0x270 [af_802154]
[381.306396] [<ffffffffa03af054>] ieee802154_sock_sendmsg+0x14/0x20 [af_802154]
[381.306512] [<ffffffff816079eb>] sock_sendmsg+0x8b/0xc0
[381.306600] [<ffffffff811d52a5>] ? __d_alloc+0x25/0x180
[381.306687] [<ffffffff811a1f56>] ? kmem_cache_alloc_trace+0x1c6/0x1f0
[381.306791] [<ffffffff81607b91>] SYSC_sendto+0x121/0x1c0
[381.306878] [<ffffffff8109ddf4>] ? vtime_account_user+x54/0x60
[381.306975] [<ffffffff81020d45>] ? syscall_trace_enter+0x145/0x250
[381.307073] [<ffffffff816086ae>] SyS_sendto+0xe/0x10
[381.307156] [<ffffffff8172c87f>] tracesys+0xe1/0xe6
[381.307233] Code: c6 a1 a4 ff 41 8b 57 78 49 8b 47 20 85 d2 48 8b 80
78 07 00 00 75 21 49 8b 57 18 48 85 d2 74 18 48 85 c0 74 13 8b 92 ac
01 00 00 <3b> 50 10 73 08 8b 44 90 14 41 89 47 78 41 f6 84 24 d5 00 00
00
[381.307801] RIP [<ffffffff81621fe1>] _dev_queue_xmit+0x61/0x500
[381.307901] RSP <ffff88013779dca0>
[381.347512] Kernel panic - not syncing: Fatal exception in interrupt
[381.347747] drm_kms_helper: panic occurred, switching back to text console
> > > So i think that dev_put should be behind of the dev_queue_xmit.
> > >
> > > Also, explicit set skb->sk is needless, sock_alloc_send_skb is
> > > already set it.
> >
> > You could have put this fixup in a different patch.
>
Thanks, i will repost it.
> I actually would request you to split this into two patches. One for the
> removal of the sk setting and one for the race condition fix.
>
> > > Signed-off-by: linzhang <xiaolou4617@gmail.com>
> >
> > This looks more like a username instead of a real name. If you have Lin
> > Zhang as you English real name that would be better here. :)
>
> This would be also appreciated.
Yes, my real name is Lin Zhang, sorry to make you confusion.
> > > ---
> > > net/ieee802154/socket.c | 10 ++++------
> > > 1 file changed, 4 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/net/ieee802154/socket.c b/net/ieee802154/socket.c
> > > index eedba76..a60658c 100644
> > > --- a/net/ieee802154/socket.c
> > > +++ b/net/ieee802154/socket.c
> > > @@ -301,15 +301,14 @@ static int raw_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
> > > goto out_skb;
> > >
> > > skb->dev = dev;
> > > - skb->sk = sk;
> > > skb->protocol = htons(ETH_P_IEEE802154);
> > >
> > > - dev_put(dev);
> > > -
> > > err = dev_queue_xmit(skb);
> > > if (err > 0)
> > > err = net_xmit_errno(err);
> > >
> > > + dev_put(dev);
> > > +
> > > return err ?: size;
> > >
> > > out_skb:
> > > @@ -690,15 +689,14 @@ static int dgram_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
> > > goto out_skb;
> > >
> > > skb->dev = dev;
> > > - skb->sk = sk;
> > > skb->protocol = htons(ETH_P_IEEE802154);
> > >
> > > - dev_put(dev);
> > > -
> > > err = dev_queue_xmit(skb);
> > > if (err > 0)
> > > err = net_xmit_errno(err);
> > >
> > > + dev_put(dev);
> > > +
> > > return err ?: size;
> >
> > Going to give this a test ride here now.
>
> I gave it a ride in my testbed and I encountered no problems. While I have never
> seen the race and oops myself doing the dev_put before the xmit can surely lead to
> such a race and the fix is valid.
>
> Once you have done the changes requested above and re-submit your two patches you can
> add my
>
> Acked-by: Stefan Schmidt <stefan@osg.samsung.com>
>
> to both of them.
>
> regards
> Stefan Schmidt
In my opinion, there is always exist a chance that the device is gong
before call dev_queue_xmit.
I think the latest kernel is have the same problem. If you have a real 802154 device,
maybe use the test case as above, thanks.
Please forgive me for my weak English.
Thanks for reviewing!
regards
^ permalink raw reply
* RE: [PATCH] net: fec: add post PHY reset delay DT property
From: Andy Duan @ 2017-05-23 2:04 UTC (permalink / raw)
To: Quentin Schulz, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org
In-Reply-To: <20170522091517.6857-1-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
From: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> Sent: Monday, May 22, 2017 5:15 PM
>Some PHY require to wait for a bit after the reset GPIO has been toggled. This
>adds support for the DT property `phy-reset-post-delay` which gives the delay
>in milliseconds to wait after reset.
>
>If the DT property is not given, no delay is observed. Post reset delay greater
>than 1000ms are invalid and are default to 1ms.
>
>Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>---
> Documentation/devicetree/bindings/net/fsl-fec.txt | 5 +++++
> drivers/net/ethernet/freescale/fec_main.c | 17 +++++++++++++++--
> 2 files changed, 20 insertions(+), 2 deletions(-)
>
>diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt
>b/Documentation/devicetree/bindings/net/fsl-fec.txt
>index a1e3693cca16..8795e8ca5793 100644
>--- a/Documentation/devicetree/bindings/net/fsl-fec.txt
>+++ b/Documentation/devicetree/bindings/net/fsl-fec.txt
>@@ -15,6 +15,11 @@ Optional properties:
> - phy-reset-active-high : If present then the reset sequence using the GPIO
> specified in the "phy-reset-gpios" property is reversed (H=reset state,
> L=operation state).
>+- phy-reset-post-delay : Post reset delay in milliseconds. If present
>+then
>+ a delay of phy-reset-post-delay milliseconds will be observed after
>+the
>+ phy-reset-gpios has been toggled. Can be omitted thus no delay is
>+ observed. Delay is in range of 1ms to 1000ms. If given delay is
>+higher
>+ than 1000ms, 1ms delay is done instead.
> - phy-supply : regulator that powers the Ethernet PHY.
> - phy-handle : phandle to the PHY device connected to this device.
> - fixed-link : Assume a fixed link. See fixed-link.txt in the same directory.
>diff --git a/drivers/net/ethernet/freescale/fec_main.c
>b/drivers/net/ethernet/freescale/fec_main.c
>index 56a563f90b0b..00a7fd0bcd59 100644
>--- a/drivers/net/ethernet/freescale/fec_main.c
>+++ b/drivers/net/ethernet/freescale/fec_main.c
>@@ -3192,7 +3192,7 @@ static int fec_reset_phy(struct platform_device
>*pdev) {
> int err, phy_reset;
> bool active_high = false;
>- int msec = 1;
>+ int msec = 1, phy_post_delay = 0;
> struct device_node *np = pdev->dev.of_node;
>
> if (!np)
>@@ -3210,7 +3210,6 @@ static int fec_reset_phy(struct platform_device
>*pdev)
> return 0;
>
> active_high = of_property_read_bool(np, "phy-reset-active-high");
>-
No necessary change here.
> err = devm_gpio_request_one(&pdev->dev, phy_reset,
> active_high ? GPIOF_OUT_INIT_HIGH :
>GPIOF_OUT_INIT_LOW,
> "phy-reset");
>@@ -3219,6 +3218,11 @@ static int fec_reset_phy(struct platform_device
>*pdev)
> return err;
> }
>
>+ err = of_property_read_u32(np, "phy-reset-post-delay",
>&phy_post_delay);
>+ /* valid reset duration should be less than 1s */
>+ if (!err && phy_post_delay > 1000)
>+ phy_post_delay = 1;
>+
Put the dt parse before . devm_gpio_request_one() that seems better.
Others are fine.
> if (msec > 20)
> msleep(msec);
> else
>@@ -3226,6 +3230,15 @@ static int fec_reset_phy(struct platform_device
>*pdev)
>
> gpio_set_value_cansleep(phy_reset, !active_high);
>
>+ if (!phy_post_delay)
>+ return 0;
>+
>+ if (phy_post_delay > 20)
>+ msleep(phy_post_delay);
>+ else
>+ usleep_range(phy_post_delay * 1000,
>+ phy_post_delay * 1000 + 1000);
>+
> return 0;
> }
> #else /* CONFIG_OF */
>--
>2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
From: Shubham Bansal @ 2017-05-23 2:58 UTC (permalink / raw)
To: Kees Cook
Cc: Daniel Borkmann, David Miller, Mircea Gherzan,
Network Development, kernel-hardening@lists.openwall.com,
linux-arm-kernel@lists.infradead.org, ast
In-Reply-To: <CAGXu5jLYunVCJGCfHPebKDaoQ71hdMGq4HhdDxTYpBQw_HXUYQ@mail.gmail.com>
Hi,
On testing the eBPF JIT with CONFIG_FRAME_POINTER I got the following
crash for non jitted testcase.
[ 72.032494] test_bpf: #267 BPF_MAXINSNS: Call heavy transformations
jited:0 1112799
[ 92.304815] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
[insmod:104]
[ 92.305050] Modules linked in: test_bpf(+)
[ 92.305516] CPU: 0 PID: 104 Comm: insmod Not tainted
4.11.0-10603-g13e0988-dirty #21
[ 92.305630] Hardware name: ARM-Versatile Express
[ 92.305943] task: c75d5280 task.stack: c61b8000
[ 92.306383] PC is at __bpf_prog_run+0x818/0x17a8
[ 92.306449] LR is at __bpf_prog_run+0xab8/0x17a8
[ 92.306510] pc : [<c0407c08>] lr : [<c0407ea8>] psr: 20000013
[ 92.306510] sp : c61b9a88 ip : c61b9a88 fp : c61b9d4c
[ 92.306629] r10: c0404104 r9 : 00000000 r8 : 00000000
[ 92.306744] r7 : c0e0b500 r6 : c0c39bb0 r5 : c61b9ad0 r4 : ca314840
[ 92.306882] r3 : c0e0b7fc r2 : 00000000 r1 : c61b9ad8 r0 : 00000000
[ 92.307070] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 92.307285] Control: 10c5387d Table: 661e0059 DAC: 00000051
[ 92.307503] CPU: 0 PID: 104 Comm: insmod Not tainted
4.11.0-10603-g13e0988-dirty #21
[ 92.307575] Hardware name: ARM-Versatile Express
[ 92.307651] Backtrace:
[ 92.307868] [<c030caec>] (dump_backtrace) from [<c030cda8>]
(show_stack+0x18/0x1c)
[ 92.308003] r7:c1503db8 r6:60000193 r5:00000000 r4:c1570f30
[ 92.308085] [<c030cd90>] (show_stack) from [<c064b198>]
(dump_stack+0x90/0xa4)
[ 92.308195] [<c064b108>] (dump_stack) from [<c030900c>] (show_regs+0x14/0x18)
[ 92.308281] r7:c1503db8 r6:c14488b8 r5:c16aaea0 r4:c61b8000
[ 92.308346] [<c0308ff8>] (show_regs) from [<c03df2a4>]
(watchdog_timer_fn+0x24c/0x2c4)
[ 92.308423] [<c03df058>] (watchdog_timer_fn) from [<c03b70d8>]
(__hrtimer_run_queues+0x180/0x318)
[ 92.308514] r10:c03df058 r9:00000003 r8:c1503cbc r7:c7ead580
r6:c7ead5c0 r5:c61b8000
[ 92.308578] r4:c7ead8d8
[ 92.308635] [<c03b6f58>] (__hrtimer_run_queues) from [<c03b74e8>]
(hrtimer_interrupt+0xb4/0x204)
[ 92.308728] r10:7fffffff r9:00000003 r8:c7ead5f8 r7:c7ead618
r6:c7ead638 r5:c1448580
[ 92.308789] r4:c7ead580
[ 92.308835] [<c03b7434>] (hrtimer_interrupt) from [<c03113fc>]
(twd_handler+0x38/0x48)
[ 92.308914] r10:c0404104 r9:00000010 r8:c1504330 r7:00000001
r6:c701e900 r5:00000000
[ 92.308974] r4:00000001
[ 92.309021] [<c03113c4>] (twd_handler) from [<c03a1238>]
(handle_percpu_devid_irq+0x90/0x244)
[ 92.309091] r5:00000000 r4:c7020540
[ 92.309165] [<c03a11a8>] (handle_percpu_devid_irq) from
[<c039c148>] (generic_handle_irq+0x2c/0x3c)
[ 92.309254] r10:c0404104 r9:c8803100 r8:c7004a00 r7:00000001
r6:00000000 r5:00000000
[ 92.309319] r4:c1449ed0 r3:c03a11a8
[ 92.309369] [<c039c11c>] (generic_handle_irq) from [<c039c6f0>]
(__handle_domain_irq+0x64/0xbc)
[ 92.309445] [<c039c68c>] (__handle_domain_irq) from [<c0301808>]
(gic_handle_irq+0x5c/0xa0)
[ 92.309525] r9:c8803100 r8:c8802100 r7:c61b9a38 r6:c880210c
r5:c1571848 r4:c1504330
[ 92.309596] [<c03017ac>] (gic_handle_irq) from [<c030d98c>]
(__irq_svc+0x6c/0x90)
[ 92.309731] Exception stack(0xc61b9a38 to 0xc61b9a80)
[ 92.309943] 9a20:
00000000 c61b9ad8
[ 92.310184] 9a40: 00000000 c0e0b7fc ca314840 c61b9ad0 c0c39bb0
c0e0b500 00000000 00000000
[ 92.310377] 9a60: c0404104 c61b9d4c c61b9a88 c61b9a88 c0407ea8
c0407c08 20000013 ffffffff
[ 92.310595] r9:c61b8000 r8:00000000 r7:c61b9a6c r6:ffffffff
r5:20000013 r4:c0407c08
[ 92.311103] [<c04073f0>] (__bpf_prog_run) from [<bf15759c>]
(test_bpf_init+0x59c/0x1000 [test_bpf])
[ 92.311262] r10:bf123094 r9:ca2fa020 r8:00000000 r7:bf123128
r6:53edefe8 r5:ca2fa000
[ 92.311325] r4:00000555
[ 92.311382] [<bf157000>] (test_bpf_init [test_bpf]) from
[<c0301f7c>] (do_one_initcall+0x4c/0x174)
[ 92.311468] r10:bf154640 r9:c61c2524 r8:39e3db1c r7:00000001
r6:00000000 r5:bf157000
[ 92.311529] r4:ffffe000
[ 92.311575] [<c0301f30>] (do_one_initcall) from [<c042a5b0>]
(do_init_module+0x6c/0x1fc)
[ 92.311673] r9:c61c2524 r8:39e3db1c r6:c61c2480 r5:00000001 r4:bf154640
[ 92.311744] [<c042a544>] (do_init_module) from [<c03d393c>]
(load_module+0x1f8c/0x2394)
[ 92.311815] r6:c61c2500 r5:00000001 r4:c61b9f34
[ 92.311898] [<c03d19b0>] (load_module) from [<c03d3ea0>]
(SyS_init_module+0x15c/0x174)
[ 92.311979] r10:00000051 r9:00000000 r8:00160fda r7:c61b8000
r6:c95a6a18 r5:b6fbca20
[ 92.312040] r4:00006a18
[ 92.312087] [<c03d3d44>] (SyS_init_module) from [<c0308260>]
(ret_fast_syscall+0x0/0x3c)
[ 92.312196] r10:00000000 r9:c61b8000 r8:c0308424 r7:00000080
r6:756e694c r5:00156a18
[ 92.312277] r4:00000000
[ 93.835343] 1065840 PASS
Does this look like a bug? I will send the separate mail if it does.
Let me know.
Best,
Shubham Bansal
On Tue, May 23, 2017 at 1:35 AM, Kees Cook <keescook@chromium.org> wrote:
> On Mon, May 22, 2017 at 10:04 AM, Shubham Bansal
> <illusionist.neo@gmail.com> wrote:
>> These all benchmarks are for ARMv7.
>
> Thanks! In the future, try to avoid the white-space damage
> (line-wrapping). And it looks like you've still got debugging turned
> on in your jit code:
>
> [ 56.176033] test_bpf: #21 LD_CPU
> [ 56.176329] bpf_jit: *** NOT YET: opcode 85 ***
> [ 56.176565] jited:0 2639 702 PASS
>
> That breaks the test report line. After I cleaned these up and parsed
> the results, they look great. Most things are half the speed of the
> interpreter, if not better. Only the LD_ABS suffered, and that's
> mainly the const blinding, I assume.
>
> Please post your current patch. Thanks for this!
>
> -Kees
>
> --
> Kees Cook
> Pixel Security
^ permalink raw reply
* Re: [PATCH net-next] net: rfs: Don't reset RFS entries when nothing changed
From: David Miller @ 2017-05-23 3:02 UTC (permalink / raw)
To: gfree.wind; +Cc: netdev
In-Reply-To: <1495500311-81095-1-git-send-email-gfree.wind@vip.163.com>
From: gfree.wind@vip.163.com
Date: Tue, 23 May 2017 08:45:11 +0800
> From: Gao Feng <gfree.wind@vip.163.com>
>
> When the new RFS table size specified by sysctl equals the old one,
> there is nothing changed actually. So it is unnecessary to reset the
> RFS table entris.
>
> Signed-off-by: Gao Feng <gfree.wind@vip.163.com>
It seems like an intentional feature to be able to reset the
table by simply writing the same value to the sysfs knob.
I'm not applying this, sorry.
^ permalink raw reply
* Re: [PATCH net-next] bpf: update perf event helper function signature and documentation
From: David Miller @ 2017-05-23 3:08 UTC (permalink / raw)
To: qinteng; +Cc: peterz, bgregg, daniel, netdev, linux-kernel, Kernel-team, ast
In-Reply-To: <E796EF36-C195-4FFA-AAA0-A1F9E7730349@fb.com>
From: Teng Qin <qinteng@fb.com>
Date: Tue, 23 May 2017 00:39:34 +0000
> diff --git a/samples/bpf/bpf_helpers.h b/samples/bpf/bpf_helpers.h
> index 9a9c95f..a94ce42 100644
> --- a/samples/bpf/bpf_helpers.h
> +++ b/samples/bpf/bpf_helpers.h
> @@ -37,9 +37,8 @@ static int (*bpf_clone_redirect)(void *ctx, int ifindex, int flags) =
> (void *) BPF_FUNC_clone_redirect;
> static int (*bpf_redirect)(int ifindex, int flags) =
> (void *) BPF_FUNC_redirect;
> -static int (*bpf_perf_event_output)(void *ctx, void *map,
> - unsigned long long flags, void *data,
> - int size) =
> +static int (*bpf_perf_event_output)(void *ctx, void *map, u64 flags,
> + void *data, int size) =
> (void *) BPF_FUNC_perf_event_output;
> static int (*bpf_get_stackid)(void *ctx, void *map, int flags) =
> (void *) BPF_FUNC_get_stackid;
I think we've been intentionally avoiding the use of "u64", "u32",
etc. in this file.
But what do I know.
^ permalink raw reply
* Re:Re: [PATCH net-next] net: rfs: Don't reset RFS entries when nothing changed
From: Gao Feng @ 2017-05-23 3:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20170522.230220.402998640470537222.davem@davemloft.net>
At 2017-05-23 11:02:20, "David Miller" <davem@davemloft.net> wrote:
>From: gfree.wind@vip.163.com
>Date: Tue, 23 May 2017 08:45:11 +0800
>
>> From: Gao Feng <gfree.wind@vip.163.com>
>>
>> When the new RFS table size specified by sysctl equals the old one,
>> there is nothing changed actually. So it is unnecessary to reset the
>> RFS table entris.
>>
>> Signed-off-by: Gao Feng <gfree.wind@vip.163.com>
>
>It seems like an intentional feature to be able to reset the
>table by simply writing the same value to the sysfs knob.
>
>I'm not applying this, sorry.
It is ok.
I just thought maybe it was used to reset, but I didn't find any comment and tips by google.
Regards
Feng
^ permalink raw reply
* Re: [PATCH net-next] bpf: update perf event helper function signature and documentation
From: Teng Qin @ 2017-05-23 3:17 UTC (permalink / raw)
To: David Miller
Cc: peterz@infradead.org, bgregg@netflix.com, daniel@iogearbox.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Kernel Team,
Alexei Starovoitov
In-Reply-To: <20170522.230849.1056416550811494880.davem@davemloft.net>
On 5/22/17, 20:08, "David Miller" <davem@davemloft.net> wrote:
From: Teng Qin <qinteng@fb.com>
Date: Tue, 23 May 2017 00:39:34 +0000
> diff --git a/samples/bpf/bpf_helpers.h b/samples/bpf/bpf_helpers.h
> index 9a9c95f..a94ce42 100644
> --- a/samples/bpf/bpf_helpers.h
> +++ b/samples/bpf/bpf_helpers.h
> @@ -37,9 +37,8 @@ static int (*bpf_clone_redirect)(void *ctx, int ifindex, int flags) =
> (void *) BPF_FUNC_clone_redirect;
> static int (*bpf_redirect)(int ifindex, int flags) =
> (void *) BPF_FUNC_redirect;
> -static int (*bpf_perf_event_output)(void *ctx, void *map,
> - unsigned long long flags, void *data,
> - int size) =
> +static int (*bpf_perf_event_output)(void *ctx, void *map, u64 flags,
> + void *data, int size) =
> (void *) BPF_FUNC_perf_event_output;
> static int (*bpf_get_stackid)(void *ctx, void *map, int flags) =
> (void *) BPF_FUNC_get_stackid;
I think we've been intentionally avoiding the use of "u64", "u32",
etc. in this file.
But what do I know.
Alexei said it was due to Clang not taking u64, u32 etc. for compilation.
I didn’t know the context and just used them. But apparently, something
changed and now they build and run OK......
^ permalink raw reply
* Re: Deleting a dynamic mac entry..
From: Toshiaki Makita @ 2017-05-23 3:17 UTC (permalink / raw)
To: Manohar Kumar; +Cc: netdev, bridge
In-Reply-To: <CA+N+6-xY7+coc6zFqzP665WMhbGFFMHOfre9wNxRAcSF2Bthzw@mail.gmail.com>
On 2017/05/21 11:28, Manohar Kumar wrote:
> Hello,
>
> In 3.19 the following bridge fdb command to delete a dynamically
> learned entry fails..
>
> root@net-3:~# bridge fdb show | grep 02:42:0a:ff:00:06
> 02:42:0a:ff:00:06 dev vxlan0 master br0
> root@net-3:~# bridge fdb del 02:42:0a:ff:00:06 dev vxlan0 master
> RTNETLINK answers: No such file or directory
>
> It works in 4.4.
>
> Can someone please point to the patch that made this change ?
25d3b493a52d ("bridge: Fix inability to add non-vlan fdb entry") might
be what you are looking for, but you might want to do git-bisect to
track down any regression or fix.
> In kernels without this patch is there an alternative to delete
> (actually I want to do it programmatically) dynamic mac entries ?
If 25d3b493a52d is causing your problem, set default_pvid to 0 in order
to disable default_pvid, and delete any vlans which is already
configured in bridge's vlan_filtering. Then, delete the fdb entry.
Toshiaki Makita
^ permalink raw reply
* Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
From: Shubham Bansal @ 2017-05-23 3:34 UTC (permalink / raw)
To: Florian Fainelli
Cc: Kees Cook, Daniel Borkmann, kernel-hardening@lists.openwall.com,
Network Development, ast, Mircea Gherzan, David Miller,
linux-arm-kernel@lists.infradead.org, nschichan, andrew
In-Reply-To: <8c53012b-cb81-5228-de79-f55457d1cf69@gmail.com>
Hi Florian,
>> I think it is fine to only target ARMv7. It is harder and harder to
>> find devices on v5 or v6 CPUs that would want to be using BPF JIT,
>> IMO.
>
> There are still a ton of Marvell-based routers out there (e.g: Kirkwood,
> Orion5x) that are ARMv5 and that prompted Nicholas (hey there) to fix
> the cBPF JIT a while ago. I don't think you can just ignore those, it's
> fine not to target them initially, but arguably, QEMU has decent support
> for some ARMv5 platforms that could be used for testing as well
> (realview-eb, versatileab/pbm.
I am using busybox to get the rootfs. Here is what I am doing :-
1. ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make -j4 (for kernel
build as well as busybox build)
2. qemu-system-arm -M vexpress-a9 -dtb
./linux/arch/arm/boot/dts/versatile-ab.dts -kernel ./linux/arch/a
rm/boot/zImage -append "root=/dev/mmcblk0 console=ttyAMA0" -sd
./a9rootfs.ext3 --nographic
Can you help me with running qemu for ARMv5 and ARMv6 ?
>> When they "disappear", it's because there isn't a prerequisite met. I
>> either read the Kconfig files or use "make menuconfig" and "search" to
>> tell me where a config is defined and what is needed to meet the
>> prerequisites.
>>
>> In the case of CPU_BIG_ENDIAN, you need ARCH_SUPPORTS_BIG_ENDIAN,
>> which appears to be only ARCH_IXP4XX. I don't think you're going to
>> find an emulator that will handle this, so I'd suggest ignoring this
>> config for now unless you can find someone with that hardware that you
>> can work with to test it.
>>
>> In the case of CONFIG_FRAME_POINTER, I assume you built a
>> THUMB2_KERNEL? I'd read the notes in arch/arm/Kconfig.debug for
>> 'config FRAME_POINTER'.
>
> It sounds like we are at the point where Shubham's patches should be
> posted so people could test/fix on earlier ARM devices for instance.
>
I would post them as soon as I test them on ARMv5 and ARMv6. If you
can help me with that, please let me know.
> Thanks
> --
> Florian
-Shubham
^ permalink raw reply
* Re: [PATCH 00/12] Netfilter/IPVS fixes for net
From: David Miller @ 2017-05-23 4:02 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <20170522.195444.1331021340581014126.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Mon, 22 May 2017 19:54:44 -0400 (EDT)
> From: Pablo Neira Ayuso <pablo@netfilter.org>
> Date: Mon, 22 May 2017 00:25:38 +0200
>
>> Could you merge net into net-next as well? I have several patches for
>> net-next that need to apply on these fixes. No rush BTW.
>
> Sure, no problem.
>
> As soon as Linus takes in my pull request from today, I will do this
> and let you know.
This is now done.
^ permalink raw reply
* Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
From: Kees Cook @ 2017-05-23 4:22 UTC (permalink / raw)
To: Shubham Bansal
Cc: Florian Fainelli, Daniel Borkmann,
kernel-hardening@lists.openwall.com, Network Development, ast,
Mircea Gherzan, David Miller,
linux-arm-kernel@lists.infradead.org, Nicolas Schichan, andrew
In-Reply-To: <CAHgaXdL2qReJF1Aw08k3C+OiC-3AOy3VeYmQ1Hs7vKcrfGQnvA@mail.gmail.com>
On Mon, May 22, 2017 at 8:34 PM, Shubham Bansal
<illusionist.neo@gmail.com> wrote:
> I would post them as soon as I test them on ARMv5 and ARMv6. If you
> can help me with that, please let me know.
Please post what you have: it would be better to see what you've got
now in case additional changes are needed so you don't have to do it
again on v5 and v6. Also, it means other people with real v5 and v6
hardware could test for you if they were so inclined, and you won't
need to be blocked on doing the tests in qemu.
You can send it as an "RFC" in the subject, just to make sure people
know it's not considered fully done. :)
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
From: Kees Cook @ 2017-05-23 4:27 UTC (permalink / raw)
To: Shubham Bansal
Cc: Daniel Borkmann, David Miller, Mircea Gherzan,
Network Development, kernel-hardening@lists.openwall.com,
linux-arm-kernel@lists.infradead.org, ast
In-Reply-To: <CAHgaXd+5h7aMxF83EEkD3iRyeZ1JxAX2oFYJdy3GtcNOWRsBGw@mail.gmail.com>
On Mon, May 22, 2017 at 7:58 PM, Shubham Bansal
<illusionist.neo@gmail.com> wrote:
> On testing the eBPF JIT with CONFIG_FRAME_POINTER I got the following
> crash for non jitted testcase.
It's just a softlockup WARN, not a crash, and I think it'd to be
expected given the large runtime test_bpf reports:
> [ 72.032494] test_bpf: #267 BPF_MAXINSNS: Call heavy transformations
> jited:0 1112799
> [ 92.304815] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
> [insmod:104]
> ...
> [ 93.835343] 1065840 PASS
https://www.kernel.org/doc/Documentation/lockup-watchdogs.txt
You can raise the softlockup time-out by changing the number of
seconds here: /proc/sys/kernel/watchdog_thresh I think the softlockup
is counting the entire runtime of the bpf_tests run, so if it takes 30
seconds to run, put at least 15 into /proc/sys/kernel/watchdog_thresh
-Kees
--
Kees Cook
Pixel Security
^ 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