* [PATCH iproute2 net-next v3 1/6] utils: Implement get_s64()
From: Vinicius Costa Gomes @ 2018-10-05 23:25 UTC (permalink / raw)
To: netdev
Cc: Vinicius Costa Gomes, jhs, xiyou.wangcong, jiri,
jesus.sanchez-palencia, ilias.apalodimas, simon.fok
In-Reply-To: <20181005232522.4848-1-vinicius.gomes@intel.com>
Add this helper to read signed 64-bit integers from a string.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
---
include/utils.h | 1 +
lib/utils.c | 21 +++++++++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/include/utils.h b/include/utils.h
index 8cb4349e..58574a05 100644
--- a/include/utils.h
+++ b/include/utils.h
@@ -139,6 +139,7 @@ int get_time_rtt(unsigned *val, const char *arg, int *raw);
#define get_byte get_u8
#define get_ushort get_u16
#define get_short get_s16
+int get_s64(__s64 *val, const char *arg, int base);
int get_u64(__u64 *val, const char *arg, int base);
int get_u32(__u32 *val, const char *arg, int base);
int get_s32(__s32 *val, const char *arg, int base);
diff --git a/lib/utils.c b/lib/utils.c
index e87ecf31..1b84b801 100644
--- a/lib/utils.c
+++ b/lib/utils.c
@@ -383,6 +383,27 @@ int get_u8(__u8 *val, const char *arg, int base)
return 0;
}
+int get_s64(__s64 *val, const char *arg, int base)
+{
+ long res;
+ char *ptr;
+
+ errno = 0;
+
+ if (!arg || !*arg)
+ return -1;
+ res = strtoll(arg, &ptr, base);
+ if (!ptr || ptr == arg || *ptr)
+ return -1;
+ if ((res == LLONG_MIN || res == LLONG_MAX) && errno == ERANGE)
+ return -1;
+ if (res > INT64_MAX || res < INT64_MIN)
+ return -1;
+
+ *val = res;
+ return 0;
+}
+
int get_s32(__s32 *val, const char *arg, int base)
{
long res;
--
2.19.0
^ permalink raw reply related
* [PATCH iproute2 net-next v3 2/6] include: Add helper to retrieve a __s64 from a netlink msg
From: Vinicius Costa Gomes @ 2018-10-05 23:25 UTC (permalink / raw)
To: netdev
Cc: Vinicius Costa Gomes, jhs, xiyou.wangcong, jiri,
jesus.sanchez-palencia, ilias.apalodimas, simon.fok
In-Reply-To: <20181005232522.4848-1-vinicius.gomes@intel.com>
This allows signed 64-bit integers to be retrieved from a netlink
message.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
---
include/libnetlink.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/include/libnetlink.h b/include/libnetlink.h
index 9d9249e6..ffc49e56 100644
--- a/include/libnetlink.h
+++ b/include/libnetlink.h
@@ -185,6 +185,13 @@ static inline __u64 rta_getattr_u64(const struct rtattr *rta)
memcpy(&tmp, RTA_DATA(rta), sizeof(__u64));
return tmp;
}
+static inline __s64 rta_getattr_s64(const struct rtattr *rta)
+{
+ __s64 tmp;
+
+ memcpy(&tmp, RTA_DATA(rta), sizeof(tmp));
+ return tmp;
+}
static inline const char *rta_getattr_str(const struct rtattr *rta)
{
return (const char *)RTA_DATA(rta);
--
2.19.0
^ permalink raw reply related
* [PATCH iproute2 net-next v3 3/6] libnetlink: Add helper for getting a __s32 from netlink msgs
From: Vinicius Costa Gomes @ 2018-10-05 23:25 UTC (permalink / raw)
To: netdev
Cc: Jesus Sanchez-Palencia, jhs, xiyou.wangcong, jiri,
ilias.apalodimas, simon.fok
In-Reply-To: <20181005232522.4848-1-vinicius.gomes@intel.com>
From: Jesus Sanchez-Palencia <jesus.sanchez-palencia@intel.com>
This function retrieves a signed 32-bit integer from a netlink message
and returns it.
Signed-off-by: Jesus Sanchez-Palencia <jesus.sanchez-palencia@intel.com>
---
include/libnetlink.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/libnetlink.h b/include/libnetlink.h
index ffc49e56..c44c3c72 100644
--- a/include/libnetlink.h
+++ b/include/libnetlink.h
@@ -185,6 +185,10 @@ static inline __u64 rta_getattr_u64(const struct rtattr *rta)
memcpy(&tmp, RTA_DATA(rta), sizeof(__u64));
return tmp;
}
+static inline __s32 rta_getattr_s32(const struct rtattr *rta)
+{
+ return *(__s32 *)RTA_DATA(rta);
+}
static inline __s64 rta_getattr_s64(const struct rtattr *rta)
{
__s64 tmp;
--
2.19.0
^ permalink raw reply related
* [PATCH iproute2 net-next v3 0/6] Introduce the taprio scheduler
From: Vinicius Costa Gomes @ 2018-10-05 23:25 UTC (permalink / raw)
To: netdev
Cc: Vinicius Costa Gomes, jhs, xiyou.wangcong, jiri,
jesus.sanchez-palencia, ilias.apalodimas, simon.fok
Hi,
Changes from v2:
- Used the variable name (instead of the variable type) in a
sizeof() operator in patch 2/6 (Ilias Apalodimas);
Changes from v1:
- Removed references to the "H" (Set-Gates-And-Hold-MAC) and "R"
(Set-Gates-And-Release-MAC) commands, as these commands will only
be used when Frame Preemption support is added (David Ahern);
- Moved the functions that print and read commands to be closer (David
Ahern);
Changes from RFC:
- Removed support for the sched-file parameter, in favor of
supporting the batch mode feature;
This is the iproute2 side of the taprio v1 series.
Please see the kernel side cover letter for more information about how
to test this.
Cheers,
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2018-10-06 5:20 UTC (permalink / raw)
To: gregkh; +Cc: akpm, netdev, linux-kernel
I know this is really soon after the previous net pull request, but I want
to get this in for the BPF 32-bit right shift truncation fix.
1) Fix truncation of 32-bit right shift in bpf, from Jann Horn.
2) Fix memory leak in wireless wext compat, from Stefan Seyfried.
3) Use after free in cfg80211's reg_process_hint(), from Yu Zhao.
4) Need to cancel pending work when unbinding in smsc75xx otherwise
we oops, also from Yu Zhao.
5) Don't allow enslaving a team device to itself, from Ido Schimmel.
6) Fix backwards compat with older userspace for rtnetlink FDB dumps.
From Mauricio Faria.
7) Add validation of tc policy netlink attributes, from David Ahern.
8) Fix RCU locking in rawv6_send_hdrinc(), from Wei Wang.
Please pull, thanks a lot!
The following changes since commit cec4de302c5ff2c5eb3bfcb0c4845a095f5149b9:
Merge gitolite.kernel.org:/pub/scm/linux/kernel/git/davem/net (2018-10-03 16:09:11 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to 35f3625c21852ad839f20c91c7d81c4c1101e207:
net: mvpp2: Extract the correct ethtype from the skb for tx csum offload (2018-10-05 14:52:43 -0700)
----------------------------------------------------------------
Baruch Siach (1):
net: phy: phylink: fix SFP interface autodetection
David Ahern (1):
net: sched: Add policy validation for tc attributes
David S. Miller (4):
Merge branch 'mlxsw-fixes'
Merge tag 'mac80211-for-davem-2018-10-04' of git://git.kernel.org/.../jberg/mac80211
Merge branch 'bnxt_en-fixes'
Merge git://git.kernel.org/.../bpf/bpf
Davide Caratti (1):
be2net: don't flip hw_features when VXLANs are added/deleted
Felix Fietkau (1):
mac80211: fix setting IEEE80211_KEY_FLAG_RX_MGMT for AP mode keys
Flavio Leitner (1):
openvswitch: load NAT helper
Florian Fainelli (1):
net: dsa: b53: Keep CPU port as tagged in all VLANs
Ido Schimmel (2):
mlxsw: spectrum: Delete RIF when VLAN device is removed
team: Forbid enslaving team device to itself
Jann Horn (1):
bpf: 32-bit RSH verification must truncate input before the ALU op
Jianfeng Tan (1):
net/packet: fix packet drop as of virtio gso
Mauricio Faria de Oliveira (1):
rtnetlink: fix rtnl_fdb_dump() for ndmsg header
Maxime Chevallier (1):
net: mvpp2: Extract the correct ethtype from the skb for tx csum offload
Michael Chan (1):
bnxt_en: Fix VNIC reservations on the PF.
Nir Dotan (1):
mlxsw: pci: Derive event type from event queue number
Roman Gushchin (2):
bpf: harden flags check in cgroup_storage_update_elem()
bpf: don't accept cgroup local storage with zero value size
Shanthosh RK (1):
net: bpfilter: Fix type cast and pointer warnings
Stefan Seyfried (1):
cfg80211: fix wext-compat memory leak
Vasundhara Volam (2):
bnxt_en: Fix enables field in HWRM_QUEUE_COS2BW_CFG request
bnxt_en: get the reduced max_irqs by the ones used by RDMA
Venkat Duvvuru (1):
bnxt_en: free hwrm resources, if driver probe fails.
Wei Wang (1):
ipv6: take rcu lock in rawv6_send_hdrinc()
Wenwen Wang (2):
net: cxgb3_main: fix a missing-check bug
yam: fix a missing-check bug
Yu Zhao (2):
cfg80211: fix use-after-free in reg_process_hint()
net/usb: cancel pending work when unbinding smsc75xx
drivers/net/dsa/b53/b53_common.c | 4 ++--
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 14 ++++++++------
drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c | 6 +++---
drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 17 +++++++++++++++++
drivers/net/ethernet/emulex/benet/be_main.c | 5 +----
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 9 +++++----
drivers/net/ethernet/mellanox/mlxsw/pci.c | 11 +++++++----
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 2 ++
drivers/net/hamradio/yam.c | 4 ++++
drivers/net/phy/phylink.c | 48 ++++++++++++++++++++++++++++--------------------
drivers/net/team/team.c | 6 ++++++
drivers/net/usb/smsc75xx.c | 1 +
include/linux/virtio_net.h | 18 ++++++++++++++++++
kernel/bpf/local_storage.c | 5 ++++-
kernel/bpf/verifier.c | 10 +++++++++-
net/bpfilter/bpfilter_kern.c | 4 ++--
net/core/rtnetlink.c | 29 ++++++++++++++++++++---------
net/ipv6/raw.c | 29 ++++++++++++++++++++---------
net/mac80211/cfg.c | 2 +-
net/openvswitch/conntrack.c | 4 ++++
net/packet/af_packet.c | 11 +++++++----
net/sched/sch_api.c | 24 ++++++++++++++++++++----
net/wireless/reg.c | 7 ++++---
net/wireless/wext-compat.c | 14 ++++++++++----
24 files changed, 203 insertions(+), 81 deletions(-)
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: emit audit messages upon successful prog load and unload
From: Jiri Olsa @ 2018-10-05 22:05 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Jesper Dangaard Brouer, Daniel Borkmann, ast, netdev, Jiri Olsa,
acme
In-Reply-To: <20181005184434.uphwrbqkfx2isbx4@ast-mbp.dhcp.thefacebook.com>
On Fri, Oct 05, 2018 at 11:44:35AM -0700, Alexei Starovoitov wrote:
> On Fri, Oct 05, 2018 at 08:14:09AM +0200, Jiri Olsa wrote:
> > On Thu, Oct 04, 2018 at 03:10:15PM -0700, Alexei Starovoitov wrote:
> > > On Thu, Oct 04, 2018 at 10:22:31PM +0200, Jesper Dangaard Brouer wrote:
> > > > On Thu, 4 Oct 2018 21:41:17 +0200 Daniel Borkmann <daniel@iogearbox.net> wrote:
> > > >
> > > > > On 10/04/2018 08:39 PM, Jesper Dangaard Brouer wrote:
> > > > > > On Thu, 4 Oct 2018 10:11:43 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> > > > > >> On Thu, Oct 04, 2018 at 03:50:38PM +0200, Daniel Borkmann wrote:
> > > > [...]
> > > > > >>
> > > > > >> If the purpose of the patch is to give user space visibility into
> > > > > >> bpf prog load/unload as a notification, then I completely agree that
> > > > > >> some notification mechanism is necessary.
> > > > >
> > > > > Yeah, I did only regard it as only that, nothing more. Some means
> > > > > of timeline and notification that can be kept in a record in user
> > > > > space and later retrieved e.g. for introspection on what has been
> > > > > loaded.
> > > > >
> > > > > >> I've started working on such mechanism via perf ring buffer which is
> > > > > >> the fastest mechanism we have in the kernel so far.
> > > > > >> See long discussion here: https://patchwork.ozlabs.org/patch/971970/
> >
> > cool, could you please CC me if there's another version
> > of that patchset?
>
> will do.
thanks
>
> > > > >
> > > > > That one is definitely needed in any case to resolve the kallsyms
> > > > > limitations, and it does have overlap in that in either case we
> > > > > want to look at past BPF programs that have been unloaded in the
> > > > > meantime, so I don't have a strong preference either way, and the
> > > > > former is needed in any case. Though thought was that audit might
> > > > > be an option for those not running profiling daemons 24/7, but
> > > > > presumably bpftool could be extended to record these events as
> > > > > well if we don't want to reuse audit infra.
> > > >
> > > > Yes, exactly, I don't want to run a profiling daemon 24/7 to record
> > > > these events. I do acknowledge that this perf event is relevant,
> > > > especially for catching the kernel symbols (I need that myself), but it
> > > > does not cover my use-case.
> > > >
> > > > My use-case is to 24/7 collect and keep records in userspace, and have a
> > > > timeline of these notifications, for later retrieval. The idea is that
> > > > our support engineers can look at these records when troubleshooting
> > > > the system. And the plan is also to collect these records as part of
> > > > our sosreport tool, which is part of the support case.
> > >
> > > I don't think you're implying that prog load/unload should be spamming dmesg
> > > and auditd not even running...
> >
> > I think the problem Jesper implied is that in order to collect
> > those logs you'll need perf tool running all the time.. which
> > it's not equipped for yet
>
> I'm not proposing to run 'perf' binary all the time.
> Setting up perf ring buffer just for these new bpf prog load/unload events
> and epolling it is simple enough to do from any application including auditd.
> selftests/bpf/ do it for bpf output events.
ok, did not think about the possibility to teach auditd talk to perf,
time to get that tool evsel/evlist/rb library ready ;-)
jirka
^ permalink raw reply
* Re: [PATCH net-next 05/19] net: usb: aqc111: Introduce PHY access
From: Andrew Lunn @ 2018-10-05 22:04 UTC (permalink / raw)
To: Igor Russkikh
Cc: David S . Miller, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, Dmitry Bezrukov
In-Reply-To: <6b4837b970d7709bc2e11d89a7e21e5f10584e30.1538734658.git.igor.russkikh@aquantia.com>
On Fri, Oct 05, 2018 at 10:24:53AM +0000, Igor Russkikh wrote:
> From: Dmitry Bezrukov <dmitry.bezrukov@aquantia.com>
>
> Implement PHY power up/down sequences.
> AQC111, depending on FW used, may has PHY being controlled either
> directly (dpa = 1) or via vendor command interface (dpa = 0).
Hi Igor
dpa is not a very descriptive name.
Once we figure out if phylib is going to be used, or even phylink, i
suggest you rename this to something like aqc111_data->use_phylib.
> @@ -172,6 +211,8 @@ static void aqc111_unbind(struct usbnet *dev, struct usb_interface *intf)
> u8 reg8;
> u16 reg16;
>
> + struct aqc111_data *aqc111_data = (struct aqc111_data *)dev->data[0];
Having to do this cast all the time is quiet ugly. It seems like some
other usb_net drivers use netdev_priv().
> +
> /* Force bz */
g/> reg16 = SFR_PHYPWR_RSTCTL_BZ;
> aqc111_write_cmd_nopm(dev, AQ_ACCESS_MAC, SFR_PHYPWR_RSTCTL,
> @@ -179,12 +220,52 @@ static void aqc111_unbind(struct usbnet *dev, struct usb_interface *intf)
> reg16 = 0;
> aqc111_write_cmd_nopm(dev, AQ_ACCESS_MAC, SFR_PHYPWR_RSTCTL,
> 2, 2, ®16);
> +
> + /* Power down ethernet PHY */
> + if (aqc111_data->dpa) {
> + reg8 = 0x00;
> + aqc111_write_cmd_nopm(dev, AQ_PHY_POWER, 0,
> + 0, 1, ®8);
> + } else {
> + aqc111_data->phy_ops.low_power = 1;
> + aqc111_data->phy_ops.phy_power = 0;
> + aqc111_write_cmd_nopm(dev, AQ_PHY_OPS, 0, 0,
> + 4, &aqc111_data->phy_ops);
> + }
> +
> + kfree(aqc111_data);
> }
>
> +struct aqc111_phy_options {
> + union {
> + struct {
> + u8 adv_100M: 1;
> + u8 adv_1G: 1;
> + u8 adv_2G5: 1;
> + u8 adv_5G: 1;
> + u8 rsvd1: 4;
> + };
> + u8 advertising;
> + };
> + union {
> + struct {
> + u8 eee_100M: 1;
> + u8 eee_1G: 1;
> + u8 eee_2G5: 1;
> + u8 eee_5G: 1;
> + u8 rsvd2: 4;
> + };
> + u8 eee;
> + };
> + union {
> + struct {
> + u8 pause: 1;
> + u8 asym_pause: 1;
> + u8 low_power: 1;
> + u8 phy_power: 1;
> + u8 wol: 1;
> + u8 downshift: 1;
> + u8 rsvd4: 2;
> + };
> + u8 phy_ctrl1;
> + };
> + union {
> + struct {
> + u8 dsh_ret_cnt: 4;
> + u8 magic_packet:1;
> + u8 rsvd5: 3;
The indentation looks wrong here.
> + };
> + u8 phy_ctrl2;
> + };
> +};
> +
> +struct aqc111_data {
> + struct {
> + u8 major;
> + u8 minor;
> + u8 rev;
> + } fw_ver;
> + u8 dpa; /*direct PHY access*/
> + struct aqc111_phy_options phy_ops;
> +} __packed;
Why pack this? Do you send it to the firmware?
Andrew
^ permalink raw reply
* Re: [PATCH net-next] rtnetlink: fix rtnl_fdb_dump() for shorter family headers
From: David Miller @ 2018-10-05 21:59 UTC (permalink / raw)
To: mfo; +Cc: dsahern, netdev
In-Reply-To: <CAO9xwp2Hbzz+vyiovwTEK+Z85TGdE8OpLPYhgqqAzr9Y0bHmeQ@mail.gmail.com>
From: Mauricio Faria de Oliveira <mfo@canonical.com>
Date: Fri, 5 Oct 2018 18:46:47 -0300
> On Fri, Oct 5, 2018 at 6:24 PM David Ahern <dsahern@gmail.com> wrote:
>>
>> On 10/5/18 3:22 PM, David Miller wrote:
>> > From: Mauricio Faria de Oliveira <mfo@canonical.com>
>> > Date: Mon, 1 Oct 2018 22:50:32 -0300
>> >
>> >> On Mon, Oct 1, 2018 at 12:38 PM Mauricio Faria de Oliveira
>> >> <mfo@canonical.com> wrote:
>> >>> Ok, thanks for your suggestions.
>> >>> I'll do some research/learning on them, and give it a try for a v2.
>> >>
>> >> FYI, that is "[PATCH v2 net-next] rtnetlink: fix rtnl_fdb_dump() for
>> >> ndmsg header".
>> >>
>> >> BTW, could please advise whether this should be net or net-next? It's a bug fix,
>> >> but it's late in the cycle, and this is not urgent (the problem has been around
>> >> since v4.12), so not sure it's really needed for v4.19.
>> >
>> > I've applied this to net and queued it up for -stable, thanks.
>> >
>
> Thanks.
>
>> there was a v2 for this problem. I reviewed it and been testing it as
>> part of the strict dump patches.
>
> The v2 is the applied patch :- ) [1]
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=bd961c9bc66497f0c63f4ba1d02900bb85078366
Oh right, I did apply v2.
^ permalink raw reply
* Re: [PATCH net-next] rtnetlink: fix rtnl_fdb_dump() for shorter family headers
From: David Miller @ 2018-10-05 21:58 UTC (permalink / raw)
To: dsahern; +Cc: mfo, netdev
In-Reply-To: <f64e7857-739d-0c06-6a3f-57db11ad1566@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Fri, 5 Oct 2018 15:24:29 -0600
> On 10/5/18 3:22 PM, David Miller wrote:
>> From: Mauricio Faria de Oliveira <mfo@canonical.com>
>> Date: Mon, 1 Oct 2018 22:50:32 -0300
>>
>>> On Mon, Oct 1, 2018 at 12:38 PM Mauricio Faria de Oliveira
>>> <mfo@canonical.com> wrote:
>>>> Ok, thanks for your suggestions.
>>>> I'll do some research/learning on them, and give it a try for a v2.
>>>
>>> FYI, that is "[PATCH v2 net-next] rtnetlink: fix rtnl_fdb_dump() for
>>> ndmsg header".
>>>
>>> BTW, could please advise whether this should be net or net-next? It's a bug fix,
>>> but it's late in the cycle, and this is not urgent (the problem has been around
>>> since v4.12), so not sure it's really needed for v4.19.
>>
>> I've applied this to net and queued it up for -stable, thanks.
>>
>
> there was a v2 for this problem. I reviewed it and been testing it as
> part of the strict dump patches.
Oh crap, sorry, please send me a relative fixup :-/
^ permalink raw reply
* Re: [PATCH net-next 00/20] rtnetlink: Add support for rigid checking of data in dump request
From: David Miller @ 2018-10-05 21:58 UTC (permalink / raw)
To: dsahern; +Cc: dsahern, netdev, christian, jbenc, stephen
In-Reply-To: <73fb03a7-ab31-f6a4-d961-bcc42dccf68f@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Fri, 5 Oct 2018 15:18:11 -0600
> One thing I missed in the rfc and v1 versions is strict attribute
> parsing -- ie., there should be nothing remaining after nla_parse is
> done. I have a new patch that adds an nlmsg_parse_strict and
> nla_parse_strict that returns -EINVAL (with extack filled in) if that
> happens. The new patch pushes the set over 20.
>
> I can peel off the first 3 patches from this set which add extack to the
> dumps and down to nlmsg_parse and send those separately if preferred.
Don't worry about it, just send the whole thing.
My rule with patch series sizes is "be reasonable", rather than a
strict number requirement.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] selftests: net: Clean up an unused variable
From: David Miller @ 2018-10-05 21:53 UTC (permalink / raw)
To: jakub; +Cc: netdev
In-Reply-To: <20181005081957.8287-1-jakub@cloudflare.com>
From: Jakub Sitnicki <jakub@cloudflare.com>
Date: Fri, 5 Oct 2018 10:19:57 +0200
> Address compiler warning:
>
> ip_defrag.c: In function 'send_udp_frags':
> ip_defrag.c:206:16: warning: unused variable 'udphdr' [-Wunused-variable]
> struct udphdr udphdr;
> ^~~~~~
>
> Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH v6 04/15] octeontx2-af: Add mailbox support infra
From: David Miller @ 2018-10-05 21:50 UTC (permalink / raw)
To: sunil.kovvuri; +Cc: netdev, arnd, linux-soc, sgoutham, amakarov, lbartosik
In-Reply-To: <1538677318-5002-5-git-send-email-sunil.kovvuri@gmail.com>
From: sunil.kovvuri@gmail.com
Date: Thu, 4 Oct 2018 23:51:47 +0530
> +int otx2_mbox_init(struct otx2_mbox *mbox, void *hwbase, struct pci_dev *pdev,
> + void *reg_base, int direction, int ndevs)
> +{
> + int devid;
> + struct otx2_mbox_dev *mdev;
Please order local variable declarations from longest to shortest line.
Please audit your entire series for this problem.
> +int otx2_mbox_busy_poll_for_rsp(struct otx2_mbox *mbox, int devid)
> +{
> + struct otx2_mbox_dev *mdev = &mbox->dev[devid];
> + unsigned long timeout = jiffies + 1 * HZ;
> +
> + while (!time_after(jiffies, timeout)) {
> + if (mdev->num_msgs == mdev->msgs_acked)
> + return 0;
> + cpu_relax();
> + }
> + return -EIO;
> +}
Probably not a good idea to poll something in the kernel for an entire
second. Please add a preemption point like a usleep() or similar.
cpu_relax() does not yield the cpu to the scheduler.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next] rtnetlink: fix rtnl_fdb_dump() for shorter family headers
From: Mauricio Faria de Oliveira @ 2018-10-05 21:46 UTC (permalink / raw)
To: David Ahern; +Cc: davem, netdev
In-Reply-To: <f64e7857-739d-0c06-6a3f-57db11ad1566@gmail.com>
On Fri, Oct 5, 2018 at 6:24 PM David Ahern <dsahern@gmail.com> wrote:
>
> On 10/5/18 3:22 PM, David Miller wrote:
> > From: Mauricio Faria de Oliveira <mfo@canonical.com>
> > Date: Mon, 1 Oct 2018 22:50:32 -0300
> >
> >> On Mon, Oct 1, 2018 at 12:38 PM Mauricio Faria de Oliveira
> >> <mfo@canonical.com> wrote:
> >>> Ok, thanks for your suggestions.
> >>> I'll do some research/learning on them, and give it a try for a v2.
> >>
> >> FYI, that is "[PATCH v2 net-next] rtnetlink: fix rtnl_fdb_dump() for
> >> ndmsg header".
> >>
> >> BTW, could please advise whether this should be net or net-next? It's a bug fix,
> >> but it's late in the cycle, and this is not urgent (the problem has been around
> >> since v4.12), so not sure it's really needed for v4.19.
> >
> > I've applied this to net and queued it up for -stable, thanks.
> >
Thanks.
> there was a v2 for this problem. I reviewed it and been testing it as
> part of the strict dump patches.
The v2 is the applied patch :- ) [1]
[1] https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=bd961c9bc66497f0c63f4ba1d02900bb85078366
cheers,
--
Mauricio Faria de Oliveira
^ permalink raw reply
* Re: [PATCH net] ipv6: take rcu lock in rawv6_send_hdrinc()
From: David Miller @ 2018-10-05 21:46 UTC (permalink / raw)
To: weiwan; +Cc: netdev, edumazet
In-Reply-To: <20181004171237.181701-1-tracywwnj@gmail.com>
From: Wei Wang <weiwan@google.com>
Date: Thu, 4 Oct 2018 10:12:37 -0700
> From: Wei Wang <weiwan@google.com>
>
> In rawv6_send_hdrinc(), in order to avoid an extra dst_hold(), we
> directly assign the dst to skb and set passed in dst to NULL to avoid
> double free.
> However, in error case, we free skb and then do stats update with the
> dst pointer passed in. This causes use-after-free on the dst.
> Fix it by taking rcu read lock right before dst could get released to
> make sure dst does not get freed until the stats update is done.
> Note: we don't have this issue in ipv4 cause dst is not used for stats
> update in v4.
>
> Syzkaller reported following crash:
...
> Fixes: 1789a640f556 ("raw: avoid two atomics in xmit")
> Signed-off-by: Wei Wang <weiwan@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next v3 0/9] vrf: allow simultaneous service instances in default and other VRFs
From: David Miller @ 2018-10-05 21:43 UTC (permalink / raw)
To: mmanning; +Cc: netdev, dsahern
In-Reply-To: <20181004151214.8522-1-mmanning@vyatta.att-mail.com>
David, please review this series.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] typo fix in Documentation/networking/af_xdp.rst
From: Konrad Djimeli @ 2018-10-05 21:43 UTC (permalink / raw)
To: Björn Töpel; +Cc: Netdev
In-Reply-To: <CAJ+HfNiSn5ehkArKMgO3P-xwnDedVJvOTQqHw0-st9y8PuoH_w@mail.gmail.com>
On 2018-10-04 19:38, Björn Töpel wrote:
> Den tors 4 okt. 2018 kl 19:03 skrev Konrad Djimeli <kdjimeli@igalia.com>:
>>
>> Fix a simple typo: Completetion -> Completion
>>
>> Signed-off-by: Konrad Djimeli <kdjimeli@igalia.com>
>> ---
>> Changes in v2:
>> - Update line below to be same length as text above
>>
>> Documentation/networking/af_xdp.rst | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/networking/af_xdp.rst b/Documentation/networking/af_xdp.rst
>> index ff929cfab4f4..4ae4f9d8f8fe 100644
>> --- a/Documentation/networking/af_xdp.rst
>> +++ b/Documentation/networking/af_xdp.rst
>> @@ -159,8 +159,8 @@ log2(2048) LSB of the addr will be masked off, meaning that 2048, 2050
>> and 3000 refers to the same chunk.
>>
>>
>> -UMEM Completetion Ring
>> -~~~~~~~~~~~~~~~~~~~~~~
>> +UMEM Completion Ring
>> +~~~~~~~~~~~~~~~~~~~~
>>
>> The Completion Ring is used transfer ownership of UMEM frames from
>> kernel-space to user-space. Just like the Fill ring, UMEM indicies are
>> --
>> 2.17.1
>>
>
> Thanks Konrad! For future patches, you should tag your patch with
> 'bpf' or 'bpf-next' as pointed out in
> Documentation/bpf/bpf_devel_QA.rst. I guess this should go to 'bpf'.
>
> Acked-by: Björn Töpel <bjorn.topel@intel.com>
Thanks a lot, I would keep that in mind for future contributions.
^ permalink raw reply
* Re: [PATCH net-next] socket: Tighten no-error check in bind()
From: David Miller @ 2018-10-05 21:35 UTC (permalink / raw)
To: jakub; +Cc: netdev
In-Reply-To: <20181004090940.4002-1-jakub@cloudflare.com>
From: Jakub Sitnicki <jakub@cloudflare.com>
Date: Thu, 4 Oct 2018 11:09:40 +0200
> move_addr_to_kernel() returns only negative values on error, or zero on
> success. Rewrite the error check to an idiomatic form to avoid confusing
> the reader.
>
> Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] net: sched: Add policy validation for tc attributes
From: David Miller @ 2018-10-05 21:27 UTC (permalink / raw)
To: dsahern; +Cc: netdev, jiri, xiyou.wangcong, jhs, dsahern
In-Reply-To: <20181003220536.16123-1-dsahern@kernel.org>
From: David Ahern <dsahern@kernel.org>
Date: Wed, 3 Oct 2018 15:05:36 -0700
> From: David Ahern <dsahern@gmail.com>
>
> A number of TC attributes are processed without proper validation
> (e.g., length checks). Add a tca policy for all input attributes and use
> when invoking nlmsg_parse.
>
> The 2 Fixes tags below cover the latest additions. The other attributes
> are a string (KIND), nested attribute (OPTIONS which does seem to have
> validation in most cases), for dumps only or a flag.
>
> Fixes: 5bc1701881e39 ("net: sched: introduce multichain support for filters")
> Fixes: d47a6b0e7c492 ("net: sched: introduce ingress/egress block index attributes for qdisc")
> Signed-off-by: David Ahern <dsahern@gmail.com>
Applied and queued up for -stable, thanks David.
^ permalink raw reply
* Re: [PATCH net-next] rtnetlink: fix rtnl_fdb_dump() for shorter family headers
From: David Ahern @ 2018-10-05 21:24 UTC (permalink / raw)
To: David Miller, mfo; +Cc: netdev
In-Reply-To: <20181005.142230.532758670209479583.davem@davemloft.net>
On 10/5/18 3:22 PM, David Miller wrote:
> From: Mauricio Faria de Oliveira <mfo@canonical.com>
> Date: Mon, 1 Oct 2018 22:50:32 -0300
>
>> On Mon, Oct 1, 2018 at 12:38 PM Mauricio Faria de Oliveira
>> <mfo@canonical.com> wrote:
>>> Ok, thanks for your suggestions.
>>> I'll do some research/learning on them, and give it a try for a v2.
>>
>> FYI, that is "[PATCH v2 net-next] rtnetlink: fix rtnl_fdb_dump() for
>> ndmsg header".
>>
>> BTW, could please advise whether this should be net or net-next? It's a bug fix,
>> but it's late in the cycle, and this is not urgent (the problem has been around
>> since v4.12), so not sure it's really needed for v4.19.
>
> I've applied this to net and queued it up for -stable, thanks.
>
there was a v2 for this problem. I reviewed it and been testing it as
part of the strict dump patches.
^ permalink raw reply
* Re: [PATCH net-next] rtnetlink: fix rtnl_fdb_dump() for shorter family headers
From: David Miller @ 2018-10-05 21:22 UTC (permalink / raw)
To: mfo; +Cc: dsahern, netdev
In-Reply-To: <CAO9xwp1rpcCGYo=cYjM5pnK4PZgZG0gpzWZSZ=V9EWiSWtmHZw@mail.gmail.com>
From: Mauricio Faria de Oliveira <mfo@canonical.com>
Date: Mon, 1 Oct 2018 22:50:32 -0300
> On Mon, Oct 1, 2018 at 12:38 PM Mauricio Faria de Oliveira
> <mfo@canonical.com> wrote:
>> Ok, thanks for your suggestions.
>> I'll do some research/learning on them, and give it a try for a v2.
>
> FYI, that is "[PATCH v2 net-next] rtnetlink: fix rtnl_fdb_dump() for
> ndmsg header".
>
> BTW, could please advise whether this should be net or net-next? It's a bug fix,
> but it's late in the cycle, and this is not urgent (the problem has been around
> since v4.12), so not sure it's really needed for v4.19.
I've applied this to net and queued it up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: mc88e6xxx: Fix 88E6141/6341 2500mbps SERDES speed
From: Andrew Lunn @ 2018-10-05 21:20 UTC (permalink / raw)
To: Marek Behún; +Cc: netdev, Florian Fainelli, David S . Miller
In-Reply-To: <20181005144227.32220-1-marek.behun@nic.cz>
On Fri, Oct 05, 2018 at 04:42:27PM +0200, Marek Behún wrote:
> The port_set_speed method for the Topaz family must not be the same
> as for Peridot family, since on Topaz port 5 is the SERDES port and it
> can be set to 2500mbps speed mode.
>
> This patch adds a new method for the Topaz family, allowing the alt_bit
> mode only for port 0 and the 2500 mbps mode for port 5.
>
> diff --git a/drivers/net/dsa/mv88e6xxx/port.c b/drivers/net/dsa/mv88e6xxx/port.c
> index 92945841c8e8..cd7db60a508b 100644
> --- a/drivers/net/dsa/mv88e6xxx/port.c
> +++ b/drivers/net/dsa/mv88e6xxx/port.c
> @@ -228,8 +228,11 @@ static int mv88e6xxx_port_set_speed(struct mv88e6xxx_chip *chip, int port,
> ctrl = MV88E6XXX_PORT_MAC_CTL_SPEED_1000;
> break;
> case 2500:
> - ctrl = MV88E6390_PORT_MAC_CTL_SPEED_10000 |
> - MV88E6390_PORT_MAC_CTL_ALTSPEED;
> + if (alt_bit)
> + ctrl = MV88E6390_PORT_MAC_CTL_SPEED_10000 |
> + MV88E6390_PORT_MAC_CTL_ALTSPEED;
> + else
> + ctrl = MV88E6390_PORT_MAC_CTL_SPEED_10000;
> break;
> case 10000:
> /* all bits set, fall through... */
> @@ -291,6 +294,24 @@ int mv88e6185_port_set_speed(struct mv88e6xxx_chip *chip, int port, int speed)
> return mv88e6xxx_port_set_speed(chip, port, speed, false, false);
> }
>
> +/* Support 10, 100, 200, 1000, 2500 Mbps (e.g. 88E6341) */
> +int mv88e6341_port_set_speed(struct mv88e6xxx_chip *chip, int port, int speed)
> +{
> + if (speed == SPEED_MAX)
> + speed = port < 5 ? 1000 : 2500;
> +
> + if (speed > 2500)
> + return -EOPNOTSUPP;
> +
> + if (speed == 200 && port != 0)
> + return -EOPNOTSUPP;
> +
> + if (speed == 2500 && port < 5)
> + return -EOPNOTSUPP;
> +
> + return mv88e6xxx_port_set_speed(chip, port, speed, !port, true);
Hi Marek
I'm confused.
The alt bit is used for configuring 2500. You say 2500 is only
supported on port 5. But !port is only true for port 0?
Andrew
^ permalink raw reply
* Re: [PATCH net-next 00/20] rtnetlink: Add support for rigid checking of data in dump request
From: David Ahern @ 2018-10-05 21:18 UTC (permalink / raw)
To: David Ahern, netdev, davem; +Cc: christian, jbenc, stephen
In-Reply-To: <20181004213355.14899-1-dsahern@kernel.org>
On 10/4/18 3:33 PM, David Ahern wrote:
> From: David Ahern <dsahern@gmail.com>
...
> This patch set addresses the problem by adding a new socket flag,
> NETLINK_DUMP_STRICT_CHK, that userspace can use with setsockopt to
> request strict checking of headers and attributes on dump requests and
> hence unlock the ability to use kernel side filters as they are added.
...
> David Ahern (20):
> netlink: Pass extack to dump handlers
> netlink: Add extack message to nlmsg_parse for invalid header length
> net: Add extack to nlmsg_parse
> net/ipv6: Refactor address dump to push inet6_fill_args to
> in6_dump_addrs
> netlink: Add new socket option to enable strict checking on dumps
> net/ipv4: Update inet_dump_ifaddr for strict data checking
> net/ipv6: Update inet6_dump_addr for strict data checking
> rtnetlink: Update rtnl_dump_ifinfo for strict data checking
> rtnetlink: Update rtnl_bridge_getlink for strict data checking
> rtnetlink: Update rtnl_stats_dump for strict data checking
> rtnetlink: Update inet6_dump_ifinfo for strict data checking
> rtnetlink: Update ipmr_rtm_dumplink for strict data checking
> rtnetlink: Update fib dumps for strict data checking
> net/neighbor: Update neigh_dump_info for strict data checking
> net/neighbor: Update neightbl_dump_info for strict data checking
> net/namespace: Update rtnl_net_dumpid for strict data checking
> net/fib_rules: Update fib_nl_dumprule for strict data checking
> net/ipv6: Update ip6addrlbl_dump for strict data checking
> net: Update netconf dump handlers for strict data checking
> net/bridge: Update br_mdb_dump for strict data checking
>
One thing I missed in the rfc and v1 versions is strict attribute
parsing -- ie., there should be nothing remaining after nla_parse is
done. I have a new patch that adds an nlmsg_parse_strict and
nla_parse_strict that returns -EINVAL (with extack filled in) if that
happens. The new patch pushes the set over 20.
I can peel off the first 3 patches from this set which add extack to the
dumps and down to nlmsg_parse and send those separately if preferred.
^ permalink raw reply
* Re: [PATCH 1/3] bpf: allow zero-initializing hash map seed
From: Alexei Starovoitov @ 2018-10-05 21:07 UTC (permalink / raw)
To: Jann Horn
Cc: lmb, Alexei Starovoitov, Daniel Borkmann, Network Development,
Linux API
In-Reply-To: <CAG48ez0+1k90oK2qrwbg0HAWF=eSocZee=Mi75E_7UY0u7TGJg@mail.gmail.com>
On Fri, Oct 05, 2018 at 04:27:58PM +0200, Jann Horn wrote:
>
> Can you please describe exactly why something that is not a kernel
> unit test needs deterministic BPF hash map behavior?
my use case for deterministic hashing is performance analysis.
Both while developing and tuning bpf program and while optimizing
kernel side implementation.
Local dos is a valid concern, so requiring root for this flag makes sense.
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: emit audit messages upon successful prog load and unload
From: Alexei Starovoitov @ 2018-10-05 20:26 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Jiri Olsa, Jesper Dangaard Brouer, Daniel Borkmann, ast, netdev,
Jiri Olsa
In-Reply-To: <20181005194249.GF20250@kernel.org>
On Fri, Oct 05, 2018 at 04:42:49PM -0300, Arnaldo Carvalho de Melo wrote:
>
> Is there a way for us to synthesize those prog load/unload for
> preexisting loaded bpf objects?
see 'bpftool prog show'.
get_next_id + get_fd_by_id solve it race free.
^ permalink raw reply
* Re: [PATCH iproute2-next] libnetlink: Use NLMSG_LENGTH to set nlmsg_len
From: David Ahern @ 2018-10-05 20:09 UTC (permalink / raw)
To: David Ahern, netdev; +Cc: stephen
In-Reply-To: <20181004213737.27846-1-dsahern@kernel.org>
On 10/4/18 3:37 PM, David Ahern wrote:
> From: David Ahern <dsahern@gmail.com>
>
> Some of the inner headers are not 4-byte aligned, so use
> NLMSG_LENGTH instead of sizeof(req) to set nlmsg_len.
>
this patch is wrong; headers are supposed to be 4-bytes aligned.
^ 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