* [PATCH V2 net-next 0/2] be2net: patch-set
From: Suresh Reddy @ 2018-07-31 15:39 UTC (permalink / raw)
To: netdev
In-Reply-To: <Suresh.Reddy@broadcom.com>
v1->v2 : Modified the subject line and commit log.
Please consider applying these two patches to net-next.
Suresh Reddy (2):
be2net: gather debug info and reset adapter (only for Lancer) on a
tx-timeout
be2net: Update the driver version to 12.0.0.0
drivers/net/ethernet/emulex/benet/be.h | 2 +-
drivers/net/ethernet/emulex/benet/be_main.c | 80 ++++++++++++++++++++++++++++-
2 files changed, 80 insertions(+), 2 deletions(-)
--
2.10.1
^ permalink raw reply
* [PATCH V2 net-next 2/2] be2net: Update the driver version to 12.0.0.0
From: Suresh Reddy @ 2018-07-31 15:39 UTC (permalink / raw)
To: netdev
In-Reply-To: <20180731153943.19522-1-suresh.reddy@broadcom.com>
Signed-off-by: Suresh Reddy <suresh.reddy@broadcom.com>
---
drivers/net/ethernet/emulex/benet/be.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/emulex/benet/be.h b/drivers/net/ethernet/emulex/benet/be.h
index 7005949..d80fe03 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -37,7 +37,7 @@
#include "be_hw.h"
#include "be_roce.h"
-#define DRV_VER "11.4.0.0"
+#define DRV_VER "12.0.0.0"
#define DRV_NAME "be2net"
#define BE_NAME "Emulex BladeEngine2"
#define BE3_NAME "Emulex BladeEngine3"
--
2.10.1
^ permalink raw reply related
* [PATCH V2 net-next 1/2] be2net: gather debug info and reset adapter (only for Lancer) on a tx-timeout
From: Suresh Reddy @ 2018-07-31 15:39 UTC (permalink / raw)
To: netdev
In-Reply-To: <20180731153943.19522-1-suresh.reddy@broadcom.com>
This patch handles a TX-timeout as follows:
1) This patch gathers and prints the following info that can
help in diagnosing the cause of a TX-timeout.
a) TX queue and completion queue entries.
b) SKB and TCP/UDP header details.
2) For Lancer NICs (TX-timeout recovery is not supported for
BE3/Skyhawk-R NICs), it recovers from the TX timeout as follows:
a) On a TX-timeout, driver sets the PHYSDEV_CONTROL_FW_RESET_MASK
bit in the PHYSDEV_CONTROL register. Lancer firmware goes into
an error state and indicates this back to the driver via a bit
in a doorbell register.
b) Driver detects this and calls be_err_recover(). DMA is disabled,
all pending TX skbs are unmapped and freed (be_close()). All rings
are destroyed (be_clear()).
c) The driver waits for the FW to re-initialize and re-creates all
rings along with other data structs (be_resume())
Signed-off-by: Suresh Reddy <suresh.reddy@broadcom.com>
---
drivers/net/ethernet/emulex/benet/be_main.c | 80 ++++++++++++++++++++++++++++-
1 file changed, 79 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 05e4c0b..580cdec 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -1412,6 +1412,83 @@ static netdev_tx_t be_xmit(struct sk_buff *skb, struct net_device *netdev)
return NETDEV_TX_OK;
}
+static void be_tx_timeout(struct net_device *netdev)
+{
+ struct be_adapter *adapter = netdev_priv(netdev);
+ struct device *dev = &adapter->pdev->dev;
+ struct be_tx_obj *txo;
+ struct sk_buff *skb;
+ struct tcphdr *tcphdr;
+ struct udphdr *udphdr;
+ u32 *entry;
+ int status;
+ int i, j;
+
+ for_all_tx_queues(adapter, txo, i) {
+ dev_info(dev, "TXQ Dump: %d H: %d T: %d used: %d, qid: 0x%x\n",
+ i, txo->q.head, txo->q.tail,
+ atomic_read(&txo->q.used), txo->q.id);
+
+ entry = txo->q.dma_mem.va;
+ for (j = 0; j < TX_Q_LEN * 4; j += 4) {
+ if (entry[j] != 0 || entry[j + 1] != 0 ||
+ entry[j + 2] != 0 || entry[j + 3] != 0) {
+ dev_info(dev, "Entry %d 0x%x 0x%x 0x%x 0x%x\n",
+ j, entry[j], entry[j + 1],
+ entry[j + 2], entry[j + 3]);
+ }
+ }
+
+ entry = txo->cq.dma_mem.va;
+ dev_info(dev, "TXCQ Dump: %d H: %d T: %d used: %d\n",
+ i, txo->cq.head, txo->cq.tail,
+ atomic_read(&txo->cq.used));
+ for (j = 0; j < TX_CQ_LEN * 4; j += 4) {
+ if (entry[j] != 0 || entry[j + 1] != 0 ||
+ entry[j + 2] != 0 || entry[j + 3] != 0) {
+ dev_info(dev, "Entry %d 0x%x 0x%x 0x%x 0x%x\n",
+ j, entry[j], entry[j + 1],
+ entry[j + 2], entry[j + 3]);
+ }
+ }
+
+ for (j = 0; j < TX_Q_LEN; j++) {
+ if (txo->sent_skb_list[j]) {
+ skb = txo->sent_skb_list[j];
+ if (ip_hdr(skb)->protocol == IPPROTO_TCP) {
+ tcphdr = tcp_hdr(skb);
+ dev_info(dev, "TCP source port %d\n",
+ ntohs(tcphdr->source));
+ dev_info(dev, "TCP dest port %d\n",
+ ntohs(tcphdr->dest));
+ dev_info(dev, "TCP seqence num %d\n",
+ ntohs(tcphdr->seq));
+ dev_info(dev, "TCP ack_seq %d\n",
+ ntohs(tcphdr->ack_seq));
+ } else if (ip_hdr(skb)->protocol ==
+ IPPROTO_UDP) {
+ udphdr = udp_hdr(skb);
+ dev_info(dev, "UDP source port %d\n",
+ ntohs(udphdr->source));
+ dev_info(dev, "UDP dest port %d\n",
+ ntohs(udphdr->dest));
+ }
+ dev_info(dev, "skb[%d] %p len %d proto 0x%x\n",
+ j, skb, skb->len, skb->protocol);
+ }
+ }
+ }
+
+ if (lancer_chip(adapter)) {
+ dev_info(dev, "Initiating reset due to tx timeout\n");
+ dev_info(dev, "Resetting adapter\n");
+ status = lancer_physdev_ctrl(adapter,
+ PHYSDEV_CONTROL_FW_RESET_MASK);
+ if (status)
+ dev_err(dev, "Reset failed .. Reboot server\n");
+ }
+}
+
static inline bool be_in_all_promisc(struct be_adapter *adapter)
{
return (adapter->if_flags & BE_IF_FLAGS_ALL_PROMISCUOUS) ==
@@ -3274,7 +3351,7 @@ void be_detect_error(struct be_adapter *adapter)
/* Do not log error messages if its a FW reset */
if (sliport_err1 == SLIPORT_ERROR_FW_RESET1 &&
sliport_err2 == SLIPORT_ERROR_FW_RESET2) {
- dev_info(dev, "Firmware update in progress\n");
+ dev_info(dev, "Reset is in progress\n");
} else {
dev_err(dev, "Error detected in the card\n");
dev_err(dev, "ERR: sliport status 0x%x\n",
@@ -5218,6 +5295,7 @@ static const struct net_device_ops be_netdev_ops = {
.ndo_get_vf_config = be_get_vf_config,
.ndo_set_vf_link_state = be_set_vf_link_state,
.ndo_set_vf_spoofchk = be_set_vf_spoofchk,
+ .ndo_tx_timeout = be_tx_timeout,
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = be_netpoll,
#endif
--
2.10.1
^ permalink raw reply related
* Re: [PATCH v4 bpf-next 08/14] bpf: introduce the bpf_get_local_storage() helper function
From: Roman Gushchin @ 2018-07-31 17:24 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, linux-kernel, kernel-team, Alexei Starovoitov
In-Reply-To: <f07d5417-4a55-c92f-800c-4950f4dc8aee@iogearbox.net>
On Tue, Jul 31, 2018 at 12:34:06PM +0200, Daniel Borkmann wrote:
> Hi Roman,
>
> On 07/27/2018 11:52 PM, Roman Gushchin wrote:
> > The bpf_get_local_storage() helper function is used
> > to get a pointer to the bpf local storage from a bpf program.
> >
> > It takes a pointer to a storage map and flags as arguments.
> > Right now it accepts only cgroup storage maps, and flags
> > argument has to be 0. Further it can be extended to support
> > other types of local storage: e.g. thread local storage etc.
> >
> > Signed-off-by: Roman Gushchin <guro@fb.com>
> > Cc: Alexei Starovoitov <ast@kernel.org>
> > Cc: Daniel Borkmann <daniel@iogearbox.net>
> > Acked-by: Martin KaFai Lau <kafai@fb.com>
> > ---
> > include/linux/bpf.h | 2 ++
> > include/uapi/linux/bpf.h | 13 ++++++++++++-
> > kernel/bpf/cgroup.c | 2 ++
> > kernel/bpf/core.c | 1 +
> > kernel/bpf/helpers.c | 20 ++++++++++++++++++++
> > kernel/bpf/verifier.c | 18 ++++++++++++++++++
> > net/core/filter.c | 23 ++++++++++++++++++++++-
> > 7 files changed, 77 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > index ca4ac2a39def..cd8790d2c6ed 100644
> > --- a/include/linux/bpf.h
> > +++ b/include/linux/bpf.h
> > @@ -788,6 +788,8 @@ extern const struct bpf_func_proto bpf_sock_map_update_proto;
> > extern const struct bpf_func_proto bpf_sock_hash_update_proto;
> > extern const struct bpf_func_proto bpf_get_current_cgroup_id_proto;
> >
> > +extern const struct bpf_func_proto bpf_get_local_storage_proto;
> > +
> > /* Shared helpers among cBPF and eBPF. */
> > void bpf_user_rnd_init_once(void);
> > u64 bpf_user_rnd_u32(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5);
> > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > index a0aa53148763..495180f229ee 100644
> > --- a/include/uapi/linux/bpf.h
> > +++ b/include/uapi/linux/bpf.h
> > @@ -2081,6 +2081,16 @@ union bpf_attr {
> > * Return
> > * A 64-bit integer containing the current cgroup id based
> > * on the cgroup within which the current task is running.
> > + *
> > + * void* get_local_storage(void *map, u64 flags)
> > + * Description
> > + * Get the pointer to the local storage area.
> > + * The type and the size of the local storage is defined
> > + * by the *map* argument.
> > + * The *flags* meaning is specific for each map type,
> > + * and has to be 0 for cgroup local storage.
> > + * Return
> > + * Pointer to the local storage area.
> > */
>
> I think it would be crucial to clarify what underlying assumption the
> program writer can make with regards to concurrent access to this storage.
>
> E.g. in this context, can _only_ BPF_XADD be used for counters as otherwise
> any other type of access may race in parallel, or are we protected by the
> socket lock and can safely override all data in this buffer via normal stores
> (e.g. for socket related progs)? What about other types?
>
> Right now nothing is mentioned here, but I think it must be clarified to
> avoid any surprises. E.g. in normal htab case program can at least use the
> map update there for atomic value updates, but those are disallowed from
> the cgroup local storage, hence my question. Btw, no need to resend, I can
> also update the paragraph there.
Fair enough.
Mid- to long-term we want to add a per-cpu version of the cgroup local storage,
and, possible, some locking API. But right now XADD is what should be used.
I think something like this should work here:
--
Depending on the bpf program type, a local storage area can be shared between
multiple instances of the bpf program, running simultaneously.
A user should care about the synchronization by himself. For example,
by using BPF_STX_XADD instruction to alter the shared data.
--
Please, feel free to change/add to the text above.
Also, it might be good to change the example to use STX_XADD:
index 0597943ce34b..dc83fb2d3f27 100644
--- a/tools/testing/selftests/bpf/test_cgroup_storage.c
+++ b/tools/testing/selftests/bpf/test_cgroup_storage.c
@@ -18,9 +18,9 @@ int main(int argc, char **argv)
BPF_MOV64_IMM(BPF_REG_2, 0), /* flags, not used */
BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
BPF_FUNC_get_local_storage),
+ BPF_MOV64_IMM(BPF_REG_1, 1),
+ BPF_STX_XADD(BPF_DW, BPF_REG_0, BPF_REG_1, 0),
BPF_LDX_MEM(BPF_W, BPF_REG_1, BPF_REG_0, 0),
- BPF_ALU64_IMM(BPF_ADD, BPF_REG_1, 1),
- BPF_STX_MEM(BPF_DW, BPF_REG_0, BPF_REG_1, 0),
BPF_ALU64_IMM(BPF_AND, BPF_REG_1, 0x1),
BPF_MOV64_REG(BPF_REG_0, BPF_REG_1),
BPF_EXIT_INSN(),
Thank you!
Roman
^ permalink raw reply related
* Re: [PATCH net] inet: frag: enforce memory limits earlier
From: Florian Westphal @ 2018-07-31 15:52 UTC (permalink / raw)
To: Jann Horn
Cc: Florian Westphal, Eric Dumazet, David S. Miller,
Network Development, eric.dumazet, posk, pabeni
In-Reply-To: <CAG48ez3+4P6MVSeTSY1XGyc-77Kk83PvpAT3p5tn0Ajk9Pj9Qg@mail.gmail.com>
Jann Horn <jannh@google.com> wrote:
> On Tue, Jul 31, 2018 at 7:54 AM Florian Westphal <fw@strlen.de> wrote:
> >
> > Eric Dumazet <edumazet@google.com> wrote:
> > > We currently check current frags memory usage only when
> > > a new frag queue is created. This allows attackers to first
> > > consume the memory budget (default : 4 MB) creating thousands
> > > of frag queues, then sending tiny skbs to exceed high_thresh
> > > limit by 2 to 3 order of magnitude.
> > >
> > > Note that before commit 648700f76b03 ("inet: frags: use rhashtables
> > > for reassembly units"), work queue could be starved under DOS,
> > > getting no cpu cycles.
> > > After commit 648700f76b03, only the per frag queue timer can eventually
> > > remove an incomplete frag queue and its skbs.
> >
> > I'm not sure this is a good idea.
> >
> > This can now prevent "good" queue from completing just because attacker
> > is sending garbage.
>
> There is only a limited amount of memory available to store fragments.
> If you receive lots of fragments that don't form complete packets,
> you'll have to drop some packets. I don't see why it matters whether
> incoming garbage only prevents the creation of new queues or also the
> completion of existing queues.
Agreed. Objection withdrawn.
Acked-by: Florian Westphal <fw@strlen.de>
^ permalink raw reply
* RE: [Intel-wired-lan] Issue with driver i40e stat strings count mismatch
From: Wyborny, Carolyn @ 2018-07-31 15:53 UTC (permalink / raw)
To: Jesper Dangaard Brouer, Stefan Assmann, Keller, Jacob E
Cc: netdev@vger.kernel.org, intel-wired-lan, Topel, Bjorn,
Keller, Jacob E
In-Reply-To: <20180731162835.628ebb62@redhat.com>
> -----Original Message-----
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On
> Behalf Of Jesper Dangaard Brouer
> Sent: Tuesday, July 31, 2018 7:29 AM
> To: Stefan Assmann <sassmann@kpanic.de>; Keller, Jacob E
> <jacob.e.keller@intel.com>
> Cc: netdev@vger.kernel.org; intel-wired-lan <intel-wired-
> lan@lists.osuosl.org>; brouer@redhat.com; Topel, Bjorn
> <bjorn.topel@intel.com>
> Subject: Re: [Intel-wired-lan] Issue with driver i40e stat strings count
> mismatch
>
>
> On Tue, 31 Jul 2018 09:05:40 +0200 Stefan Assmann
> <sassmann@kpanic.de> wrote:
>
> > From: Stefan Assmann <sassmann@kpanic.de>
> > To: Jesper Dangaard Brouer <brouer@redhat.com>, Jeff Kirsher
> <jeffrey.t.kirsher@intel.com>
> > Cc: Björn Töpel <bjorn.topel@intel.com>,
> "alexander.h.duyck@intel.com" <alexander.h.duyck@intel.com>, intel-
> wired-lan <intel-wired-lan@lists.osuosl.org>, "netdev@vger.kernel.org"
> <netdev@vger.kernel.org>
> > Subject: Re: Issue with driver i40e stat strings count mismatch
> > Date: Tue, 31 Jul 2018 09:05:40 +0200
> > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
> > Thunderbird/52.9.1
> > Message-ID: <64be8e6a-c285-2864-fd91-356eba645acd@kpanic.de>
> >
> > On 10.07.2018 13:17, Jesper Dangaard Brouer wrote:
> > > Hi Intel-fokes,
> > >
> > > Your i40e driver have issues with it's ethtool stats. A warning
> > > triggers at drivers/net/ethernet/intel/i40e/i40e_ethtool.c line 1907
> > > (see splash below) in func i40e_get_stat_strings().
> >
> > Hi Jesper,
> >
> > I ran into the same issue. Here's my proposed fix.
>
> Thanks for following up Stefan :-)
>
> I'm hoping some Intel people will look at evaluating this fix? ...
>
Thanks, we have a patch in process for this fix and other related ones from Jake Keller. We'll expedite it.
Carolyn
Carolyn Wyborny
Linux Development
Networking Division
Intel Corporation
^ permalink raw reply
* Re: pull-request: wireless-drivers 2018-07-31
From: David Miller @ 2018-07-31 17:34 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87bmanadg0.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Tue, 31 Jul 2018 13:48:15 +0300
> two small patches I still would like to get to the net tree for v4.18.
> Please let me know if you have any problems.
Pulled, thanks Kalle.
^ permalink raw reply
* Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)
From: Christopher Lameter @ 2018-07-31 17:36 UTC (permalink / raw)
To: Andrey Ryabinin
Cc: Theodore Ts'o, Jan Kara, linux-ext4, Greg Kroah-Hartman,
Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
David S. Miller, netfilter-devel, coreteam, netdev, Gerrit Renker,
dccp, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, David Airlie,
intel-gfx, dri-devel, Eric Dumazet, Alexey Kuznetsov,
Hideaki YOSHIFUJI <yosh
In-Reply-To: <e3b48104-3efb-1896-0d46-792419f49a75@virtuozzo.com>
On Tue, 31 Jul 2018, Andrey Ryabinin wrote:
> Guys, it seems that we have a lot of code using SLAB_TYPESAFE_BY_RCU cache without constructor.
> I think it's nearly impossible to use that combination without having bugs.
> It's either you don't really need the SLAB_TYPESAFE_BY_RCU, or you need to have a constructor in kmem_cache.
>
> Could you guys, please, verify your code if it's really need SLAB_TYPSAFE or constructor?
>
> E.g. the netlink code look extremely suspicious:
>
> /*
> * Do not use kmem_cache_zalloc(), as this cache uses
> * SLAB_TYPESAFE_BY_RCU.
> */
> ct = kmem_cache_alloc(nf_conntrack_cachep, gfp);
> if (ct == NULL)
> goto out;
>
> spin_lock_init(&ct->lock);
>
> If nf_conntrack_cachep objects really used in rcu typesafe manner, than 'ct' returned by kmem_cache_alloc might still be
> in use by another cpu. So we just reinitialize spin_lock used by someone else?
ct may still be read by another cpu in a RCU section but the object was
freed elsewhere so no other processor may modify the object.
The lock must have been released before freeing the slab object and thus
the initialization of the spinlock is unnecessary if it was
initialized in ctor.
If there is refcounting going on then why use SLAB_TYPESAFE_BY_RCU?
^ permalink raw reply
* Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)
From: Eric Dumazet @ 2018-07-31 17:41 UTC (permalink / raw)
To: Christoph Lameter
Cc: Andrey Ryabinin, Theodore Ts'o, jack, linux-ext4,
Greg Kroah-Hartman, Pablo Neira Ayuso, Jozsef Kadlecsik,
Florian Westphal, David Miller, netfilter-devel, coreteam, netdev,
Gerrit Renker, dccp, jani.nikula, joonas.lahtinen, rodrigo.vivi,
airlied, intel-gfx, dri-devel, Alexey Kuznetsov,
Hideaki YOSHIFUJI, Ursula Braun
In-Reply-To: <01000164f169bc6b-c73a8353-d7d9-47ec-a782-90aadcb86bfb-000000@email.amazonses.com>
On Tue, Jul 31, 2018 at 10:36 AM Christopher Lameter <cl@linux.com> wrote:
>
> If there is refcounting going on then why use SLAB_TYPESAFE_BY_RCU?
To allow fast reuse of objects, without going through call_rcu() and
reducing cache efficiency.
I believe this is mentioned in Documentation/RCU/rculist_nulls.txt
^ permalink raw reply
* [PATCH net v2 0/2] fix glitch in IPVS /proc handlers
From: Matteo Croce @ 2018-07-31 16:03 UTC (permalink / raw)
To: Wensong Zhang, Simon Horman, Julian Anastasov, lvs-devel, netdev,
Jozsef Kadlecsik
Cc: Pablo Neira Ayuso, Florian Westphal, netfilter-devel,
Eric Dumazet
Fix a bug which shows negative values in IPVS /proc handlers.
Also add an helper function to calculate a time delta
Matteo Croce (2):
jiffies: add utility function to calculate delta in ms
ipvs: don't show negative times in ip_vs_conn
include/linux/jiffies.h | 5 +++++
net/netfilter/ipvs/ip_vs_conn.c | 22 ++++++++++++++--------
2 files changed, 19 insertions(+), 8 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH net v2 1/2] jiffies: add utility function to calculate delta in ms
From: Matteo Croce @ 2018-07-31 16:03 UTC (permalink / raw)
To: Wensong Zhang, Simon Horman, Julian Anastasov, lvs-devel, netdev,
Jozsef Kadlecsik
Cc: Pablo Neira Ayuso, Florian Westphal, netfilter-devel,
Eric Dumazet
In-Reply-To: <20180731160333.12215-1-mcroce@redhat.com>
add jiffies_delta_to_msecs() helper func to calculate the delta between
two times and eventually 0 if negative.
Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Matteo Croce <mcroce@redhat.com>
---
include/linux/jiffies.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h
index a27cf6652327..fa928242567d 100644
--- a/include/linux/jiffies.h
+++ b/include/linux/jiffies.h
@@ -447,6 +447,11 @@ static inline clock_t jiffies_delta_to_clock_t(long delta)
return jiffies_to_clock_t(max(0L, delta));
}
+static inline unsigned int jiffies_delta_to_msecs(long delta)
+{
+ return jiffies_to_msecs(max(0L, delta));
+}
+
extern unsigned long clock_t_to_jiffies(unsigned long x);
extern u64 jiffies_64_to_clock_t(u64 x);
extern u64 nsec_to_clock_t(u64 x);
--
2.17.1
^ permalink raw reply related
* [PATCH net v2 2/2] ipvs: don't show negative times in ip_vs_conn
From: Matteo Croce @ 2018-07-31 16:03 UTC (permalink / raw)
To: Wensong Zhang, Simon Horman, Julian Anastasov, lvs-devel, netdev,
Jozsef Kadlecsik
Cc: Pablo Neira Ayuso, Florian Westphal, netfilter-devel,
Eric Dumazet
In-Reply-To: <20180731160333.12215-1-mcroce@redhat.com>
Since commit 500462a9de65 ("timers: Switch to a non-cascading wheel"),
timers duration can last even 12.5% more than the scheduled interval.
IPVS has two handlers, /proc/net/ip_vs_conn and /proc/net/ip_vs_conn_sync,
which shows the remaining time before that a connection expires.
The default expire time for a connection is 60 seconds, and the
expiration timer can fire even 4 seconds later than the scheduled time.
The expiration time is calculated subtracting jiffies to the scheduled
expiration time, and it's shown as a huge number when the timer fires late,
since both values are unsigned.
This can confuse script and tools which relies on it, like ipvsadm:
root@mcroce-redhat:~# while ipvsadm -lc |grep SYN_RECV; do sleep 1 ; done
TCP 00:05 SYN_RECV [fc00:1::1]:55732 [fc00:1::2]:8000 [fc00:2000::1]:8000
TCP 00:04 SYN_RECV [fc00:1::1]:55732 [fc00:1::2]:8000 [fc00:2000::1]:8000
TCP 00:03 SYN_RECV [fc00:1::1]:55732 [fc00:1::2]:8000 [fc00:2000::1]:8000
TCP 00:02 SYN_RECV [fc00:1::1]:55732 [fc00:1::2]:8000 [fc00:2000::1]:8000
TCP 00:01 SYN_RECV [fc00:1::1]:55732 [fc00:1::2]:8000 [fc00:2000::1]:8000
TCP 00:00 SYN_RECV [fc00:1::1]:55732 [fc00:1::2]:8000 [fc00:2000::1]:8000
TCP 68719476:44 SYN_RECV [fc00:1::1]:55732 [fc00:1::2]:8000 [fc00:2000::1]:8000
TCP 68719476:43 SYN_RECV [fc00:1::1]:55732 [fc00:1::2]:8000 [fc00:2000::1]:8000
TCP 68719476:42 SYN_RECV [fc00:1::1]:55732 [fc00:1::2]:8000 [fc00:2000::1]:8000
TCP 68719476:41 SYN_RECV [fc00:1::1]:55732 [fc00:1::2]:8000 [fc00:2000::1]:8000
TCP 68719476:40 SYN_RECV [fc00:1::1]:55732 [fc00:1::2]:8000 [fc00:2000::1]:8000
TCP 68719476:39 SYN_RECV [fc00:1::1]:55732 [fc00:1::2]:8000 [fc00:2000::1]:8000
Signed-off-by: Matteo Croce <mcroce@redhat.com>
---
net/netfilter/ipvs/ip_vs_conn.c | 22 ++++++++++++++--------
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
index 99e0aa350dc5..615286dcf4c0 100644
--- a/net/netfilter/ipvs/ip_vs_conn.c
+++ b/net/netfilter/ipvs/ip_vs_conn.c
@@ -1102,24 +1102,28 @@ static int ip_vs_conn_seq_show(struct seq_file *seq, void *v)
#ifdef CONFIG_IP_VS_IPV6
if (cp->af == AF_INET6)
seq_printf(seq, "%-3s %pI6 %04X %pI6 %04X "
- "%s %04X %-11s %7lu%s\n",
+ "%s %04X %-11s %7u%s\n",
ip_vs_proto_name(cp->protocol),
&cp->caddr.in6, ntohs(cp->cport),
&cp->vaddr.in6, ntohs(cp->vport),
dbuf, ntohs(cp->dport),
ip_vs_state_name(cp->protocol, cp->state),
- (cp->timer.expires-jiffies)/HZ, pe_data);
+ jiffies_delta_to_msecs(cp->timer.expires -
+ jiffies) / 1000,
+ pe_data);
else
#endif
seq_printf(seq,
"%-3s %08X %04X %08X %04X"
- " %s %04X %-11s %7lu%s\n",
+ " %s %04X %-11s %7u%s\n",
ip_vs_proto_name(cp->protocol),
ntohl(cp->caddr.ip), ntohs(cp->cport),
ntohl(cp->vaddr.ip), ntohs(cp->vport),
dbuf, ntohs(cp->dport),
ip_vs_state_name(cp->protocol, cp->state),
- (cp->timer.expires-jiffies)/HZ, pe_data);
+ jiffies_delta_to_msecs(cp->timer.expires -
+ jiffies) / 1000,
+ pe_data);
}
return 0;
}
@@ -1164,26 +1168,28 @@ static int ip_vs_conn_sync_seq_show(struct seq_file *seq, void *v)
#ifdef CONFIG_IP_VS_IPV6
if (cp->af == AF_INET6)
seq_printf(seq, "%-3s %pI6 %04X %pI6 %04X "
- "%s %04X %-11s %-6s %7lu\n",
+ "%s %04X %-11s %-6s %7u\n",
ip_vs_proto_name(cp->protocol),
&cp->caddr.in6, ntohs(cp->cport),
&cp->vaddr.in6, ntohs(cp->vport),
dbuf, ntohs(cp->dport),
ip_vs_state_name(cp->protocol, cp->state),
ip_vs_origin_name(cp->flags),
- (cp->timer.expires-jiffies)/HZ);
+ jiffies_delta_to_msecs(cp->timer.expires -
+ jiffies) / 1000);
else
#endif
seq_printf(seq,
"%-3s %08X %04X %08X %04X "
- "%s %04X %-11s %-6s %7lu\n",
+ "%s %04X %-11s %-6s %7u\n",
ip_vs_proto_name(cp->protocol),
ntohl(cp->caddr.ip), ntohs(cp->cport),
ntohl(cp->vaddr.ip), ntohs(cp->vport),
dbuf, ntohs(cp->dport),
ip_vs_state_name(cp->protocol, cp->state),
ip_vs_origin_name(cp->flags),
- (cp->timer.expires-jiffies)/HZ);
+ jiffies_delta_to_msecs(cp->timer.expires -
+ jiffies) / 1000);
}
return 0;
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net v2 1/2] jiffies: add utility function to calculate delta in ms
From: Eric Dumazet @ 2018-07-31 16:07 UTC (permalink / raw)
To: Matteo Croce, Wensong Zhang, Simon Horman, Julian Anastasov,
lvs-devel, netdev, Jozsef Kadlecsik
Cc: Pablo Neira Ayuso, Florian Westphal, netfilter-devel
In-Reply-To: <20180731160333.12215-2-mcroce@redhat.com>
On 07/31/2018 09:03 AM, Matteo Croce wrote:
> add jiffies_delta_to_msecs() helper func to calculate the delta between
> two times and eventually 0 if negative.
>
> Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Matteo Croce <mcroce@redhat.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Thanks.
^ permalink raw reply
* Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)
From: Linus Torvalds @ 2018-07-31 17:49 UTC (permalink / raw)
To: Christoph Lameter
Cc: Dave Airlie, DRI, linux-mm, Eric Dumazet, Network Development,
gerrit, dccp, coreteam, Jozsef Kadlecsik, Andrey Ryabinin,
linux-ext4, Alexey Kuznetsov, Pablo Neira Ayuso, linux-s390,
Andrey Konovalov, intel-gfx, Ursula Braun, Rodrigo Vivi,
Dmitry Vyukov, Theodore Ts'o, Hideaki YOSHIFUJI,
Greg Kroah-Hartman, Florian Westphal,
Linux Kernel Mailing List <linu
In-Reply-To: <01000164f169bc6b-c73a8353-d7d9-47ec-a782-90aadcb86bfb-000000@email.amazonses.com>
On Tue, Jul 31, 2018 at 10:36 AM Christopher Lameter <cl@linux.com> wrote:
>
> If there is refcounting going on then why use SLAB_TYPESAFE_BY_RCU?
.. because the object can be accessed (by RCU) after the refcount has
gone down to zero, and the thing has been released.
That's the whole and only point of SLAB_TYPESAFE_BY_RCU.
That flag basically says:
"I may end up accessing this object *after* it has been free'd,
because there may be RCU lookups in flight"
This has nothing to do with constructors. It's ok if the object gets
reused as an object of the same type and does *not* get
re-initialized, because we're perfectly fine seeing old stale data.
What it guarantees is that the slab isn't shared with any other kind
of object, _and_ that the underlying pages are free'd after an RCU
quiescent period (so the pages aren't shared with another kind of
object either during an RCU walk).
And it doesn't necessarily have to have a constructor, because the
thing that a RCU walk will care about is
(a) guaranteed to be an object that *has* been on some RCU list (so
it's not a "new" object)
(b) the RCU walk needs to have logic to verify that it's still the
*same* object and hasn't been re-used as something else.
So the re-use might initialize the fields lazily, not necessarily using a ctor.
And the point of using SLAB_TYPESAFE_BY_RCU is that using the more
traditional RCU freeing - where you free each object one by one with
an RCU delay - can be prohibitively slow and have a huge memory
overhead (because of big chunks of memory that are queued for
freeing).
In contrast, a SLAB_TYPESAFE_BY_RCU memory gets free'd and re-used
immediately, but because it gets reused as the same kind of object,
the RCU walker can "know" what parts have meaning for re-use, in a way
it couidn't if the re-use was random.
That said, it *is* subtle, and people should be careful.
Linus
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v2 6/7] net: phy: Add support to configure clock in Broadcom iProc mdio mux
From: Florian Fainelli @ 2018-07-31 17:57 UTC (permalink / raw)
To: Arun Parameswaran, David S. Miller, Andrew Lunn, Rob Herring,
Mark Rutland, Ray Jui, Scott Branden, Catalin Marinas,
Will Deacon
Cc: netdev, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list
In-Reply-To: <1532726613-6483-7-git-send-email-arun.parameswaran@broadcom.com>
On 07/27/2018 02:23 PM, Arun Parameswaran wrote:
> Add support to configure the internal rate adjust register based on the
> core clock supplied through device tree in the Broadcom iProc mdio mux.
>
> The operating frequency of the mdio mux block is 11MHz. This is derrived
> by dividing the clock to the mdio mux with the rate adjust register.
>
> In some SoC's the default values of the rate adjust register do not yield
> 11MHz. These SoC's are required to specify the clock via the device tree
> for proper operation.
>
> Signed-off-by: Arun Parameswaran <arun.parameswaran@broadcom.com>
> ---
[snip]
> static int iproc_mdio_wait_for_idle(void __iomem *base, bool result)
> @@ -198,10 +219,22 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
> return PTR_ERR(md->base);
> }
>
> + md->core_clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(md->core_clk)) {
> + md->core_clk = NULL;
You need to specifically check for -EPROBE_DEFER here and propagate that
to the caller, other errors could be ignored like you do it here, same
comment as in patch 7, if you make md->core_clk NULL, then you can drop
testing for that pointer being valid.
--
Florian
^ permalink raw reply
* Re: [PATCH net v2 0/2] fix glitch in IPVS /proc handlers
From: Simon Horman @ 2018-07-31 16:28 UTC (permalink / raw)
To: Matteo Croce, Pablo Neira Ayuso
Cc: Wensong Zhang, Julian Anastasov, lvs-devel, netdev,
Jozsef Kadlecsik, Pablo Neira Ayuso, Florian Westphal,
netfilter-devel, Eric Dumazet
In-Reply-To: <20180731160333.12215-1-mcroce@redhat.com>
On Tue, Jul 31, 2018 at 06:03:31PM +0200, Matteo Croce wrote:
> Fix a bug which shows negative values in IPVS /proc handlers.
> Also add an helper function to calculate a time delta
>
> Matteo Croce (2):
> jiffies: add utility function to calculate delta in ms
> ipvs: don't show negative times in ip_vs_conn
Acked-by: Simon Horman <horms@verge.net.au>
Pablo, please consider taking these via the nf tree.
^ permalink raw reply
* Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)
From: Eric Dumazet @ 2018-07-31 18:16 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Christoph Lameter, Andrey Ryabinin, Theodore Ts'o, jack,
linux-ext4, Greg Kroah-Hartman, Pablo Neira Ayuso,
Jozsef Kadlecsik, Florian Westphal, David Miller, netfilter-devel,
coreteam, netdev, Gerrit Renker, dccp, jani.nikula,
joonas.lahtinen, rodrigo.vivi, airlied, intel-gfx, dri-devel,
Alexey Kuznetsov, Hideaki YOSHIFUJI
In-Reply-To: <CACT4Y+Y6dhNgisDM9hdP-M-Rnk66DxZWcX7v39ESGJR8RY3asQ@mail.gmail.com>
On Tue, Jul 31, 2018 at 10:51 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>
>
> Is it OK to overwrite ct->status? It seems that are some read and
> writes to it right after atomic_inc_not_zero.
If it is after a (successful) atomic_inc_not_zero(),
the object is guaranteed to be alive (not freed or about to be freed).
About readind/writing a specific field, all traditional locking rules apply.
For TCP socket, we would generally grab the socket lock before
reading/writing various fields.
ct->status seems to be manipulated with set_bit() and clear_bit()
which are SMP safe.
^ permalink raw reply
* Re: [net-next PATCH] mlx5: handle DMA mapping error case for XDP redirect
From: David Miller @ 2018-07-31 16:47 UTC (permalink / raw)
To: tariqt; +Cc: brouer, saeedm, netdev, eugenia
In-Reply-To: <112892c8-c915-6ae0-f76b-23285fb73efc@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Date: Tue, 31 Jul 2018 09:35:37 +0300
> On 30/07/2018 8:49 PM, Jesper Dangaard Brouer wrote:
>> Commit 58b99ee3e3eb ("net/mlx5e: Add support for XDP_REDIRECT in
>> device-out side")
>> forgot to return/free the xdp_frame in case the DMA mapping failed,
>> correct this.
>> Also DMA unmap the frame in case mlx5e_xmit_xdp_frame() fails.
>> Fixes: 58b99ee3e3eb ("net/mlx5e: Add support for XDP_REDIRECT in
>> device-out side")
>> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
...
> Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/3] xsk: improvements to RX queue check and replace
From: David Miller @ 2018-07-31 16:48 UTC (permalink / raw)
To: daniel; +Cc: jakub.kicinski, alexei.starovoitov, netdev, oss-drivers,
bjorn.topel
In-Reply-To: <60ce1aab-5a6f-8d9c-e3d0-cc79fb15953d@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Tue, 31 Jul 2018 09:50:12 +0200
> On 07/31/2018 05:43 AM, Jakub Kicinski wrote:
>> Hi!
>>
>> First 3 patches of my recent RFC. The first one make the check against
>> real_num_rx_queues slightly more reliable, while the latter two redefine
>> XDP_QUERY_XSK_UMEM slightly to disallow replacing UMEM in the driver at
>> the stack level.
>>
>> I'm not sure where this lays on the bpf vs net trees scale, but there
>> should be no conflicts with either tree.
>
> I'm fine either way, in any case, series looks good to me:
>
> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Series applied to net-next then :)
^ permalink raw reply
* Re: [PATCH net-next 1/3] qed: Add DCBX API - qed_dcbx_get_priority_tc()
From: David Miller @ 2018-07-31 16:58 UTC (permalink / raw)
To: denis.bolotin; +Cc: netdev, ariel.elior
In-Reply-To: <20180731072608.2976-2-denis.bolotin@cavium.com>
From: Denis Bolotin <denis.bolotin@cavium.com>
Date: Tue, 31 Jul 2018 10:26:06 +0300
> +int qed_dcbx_get_priority_tc(struct qed_hwfn *p_hwfn, u8 pri, u8 *p_tc)
> +{
> + struct qed_dcbx_get *dcbx_info;
> + int rc;
> +
> + if (pri >= QED_MAX_PFC_PRIORITIES) {
> + DP_ERR(p_hwfn, "Invalid priority %d\n", pri);
> + return -EINVAL;
> + }
> +
> + dcbx_info = kzalloc(sizeof(*dcbx_info), GFP_KERNEL);
> + if (!dcbx_info)
> + return -ENOMEM;
> +
> + rc = qed_dcbx_query_params(p_hwfn, dcbx_info,
> + QED_DCBX_OPERATIONAL_MIB);
All the layering to probe these values is kinda crazy.
You go through all of the layers of the qed DCB code, capture
all of the DCBX operational state (it's a lot, it's not
trivial, and there is a ton of code that runs to place it
into this qed_dcbx_get structure).
Then you pick out _1_ value and throw the rest of it away.
This is kind of rediculious. After the values have been
fetched, they sit in known qed driver data structures in
known locations.
There is therefore no reason to allocate memory for this
large structure.
Just provide an API in the DCBX code that 1) Makes sure the
info fetch has occurred and the software state is up to date
and 2) returns just the value you are looking for.
All of this indirection and extra work makes no sense at all.
^ permalink raw reply
* Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)
From: Linus Torvalds @ 2018-07-31 18:51 UTC (permalink / raw)
To: Christoph Lameter
Cc: Dave Airlie, DRI, linux-mm, Eric Dumazet, Network Development,
gerrit, dccp, coreteam, Jozsef Kadlecsik, Andrey Ryabinin,
linux-ext4, Alexey Kuznetsov, Pablo Neira Ayuso, linux-s390,
Andrey Konovalov, intel-gfx, Ursula Braun, Rodrigo Vivi,
Dmitry Vyukov, Theodore Ts'o, Hideaki YOSHIFUJI,
Greg Kroah-Hartman, Florian Westphal,
Linux Kernel Mailing List <linu
In-Reply-To: <CA+55aFzHR1+YbDee6Cduo6YXHO9LKmLN1wP=MVzbP41nxUb5=g@mail.gmail.com>
On Tue, Jul 31, 2018 at 10:49 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> So the re-use might initialize the fields lazily, not necessarily using a ctor.
In particular, the pattern that nf_conntrack uses looks like it is safe.
If you have a well-defined refcount, and use "atomic_inc_not_zero()"
to guard the speculative RCU access section, and use
"atomic_dec_and_test()" in the freeing section, then you should be
safe wrt new allocations.
If you have a completely new allocation that has "random stale
content", you know that it cannot be on the RCU list, so there is no
speculative access that can ever see that random content.
So the only case you need to worry about is a re-use allocation, and
you know that the refcount will start out as zero even if you don't
have a constructor.
So you can think of the refcount itself as always having a zero
constructor, *BUT* you need to be careful with ordering.
In particular, whoever does the allocation needs to then set the
refcount to a non-zero value *after* it has initialized all the other
fields. And in particular, it needs to make sure that it uses the
proper memory ordering to do so.
And in this case, we have
static struct nf_conn *
__nf_conntrack_alloc(struct net *net,
{
...
atomic_set(&ct->ct_general.use, 0);
which is a no-op for the re-use case (whether racing or not, since any
"inc_not_zero" users won't touch it), but initializes it to zero for
the "completely new object" case.
And then, the thing that actually exposes it to the speculative walkers does:
int
nf_conntrack_hash_check_insert(struct nf_conn *ct)
{
...
smp_wmb();
/* The caller holds a reference to this object */
atomic_set(&ct->ct_general.use, 2);
which means that it stays as zero until everything is actually set up,
and then the optimistic walker can use the other fields (including
spinlocks etc) to verify that it's actually the right thing. The
smp_wmb() means that the previous initialization really will be
visible before the object is visible.
Side note: on some architectures it might help to make that "smp_wmb
-> atomic_set()" sequence be am "smp_store_release()" instead. Doesn't
matter on x86, but might matter on arm64.
NOTE! One thing to be very worried about is that re-initializing
whatever RCU lists means that now the RCU walker may be walking on the
wrong list so the walker may do the right thing for this particular
entry, but it may miss walking *other* entries. So then you can get
spurious lookup failures, because the RCU walker never walked all the
way to the end of the right list. That ends up being a much more
subtle bug.
But the nf_conntrack case seems to get that right too, see the restart
in ____nf_conntrack_find().
So I don't see anything wrong in nf_conntrack.
But yes, using SLAB_TYPESAFE_BY_RCU is very very subtle. But most of
the subtleties have nothing to do with having a constructor, they are
about those "make sure memory ordering wrt refcount is right" and
"restart speculative RCU walk" issues that actually happen regardless
of having a constructor or not.
Linus
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH v2] bpf: verifier: MOV64 don't mark dst reg unbounded
From: Arthur Fabre @ 2018-07-31 17:17 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Y Song, Edward Cree, netdev
Cc: Arthur Fabre
When check_alu_op() handles a BPF_MOV64 between two registers,
it calls check_reg_arg(DST_OP) on the dst register, marking it as unbounded.
If the src and dst register are the same, this marks the src as
unbounded, which can lead to unexpected errors for further checks that
rely on bounds info. For example:
BPF_MOV64_IMM(BPF_REG_2, 0),
BPF_MOV64_REG(BPF_REG_2, BPF_REG_2),
BPF_ALU64_REG(BPF_ADD, BPF_REG_1, BPF_REG_2),
BPF_MOV64_IMM(BPF_REG_0, 0),
BPF_EXIT_INSN(),
results in:
"math between ctx pointer and register with unbounded min value is not
allowed"
check_alu_op() now uses check_reg_arg(DST_OP_NO_MARK), and MOVs
that need to mark the dst register (MOVIMM, MOV32) do so.
Added a test case for MOV64 dst == src, and dst != src.
Signed-off-by: Arthur Fabre <afabre@cloudflare.com>
---
v2: Add mov64 tests, always use DST_OP_NO_MARK
kernel/bpf/verifier.c | 6 +++--
tools/testing/selftests/bpf/test_verifier.c | 26 +++++++++++++++++++++
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 63aaac52a265..ec63b56be4af 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -3238,8 +3238,8 @@ static int check_alu_op(struct bpf_verifier_env *env, struct bpf_insn *insn)
}
}
- /* check dest operand */
- err = check_reg_arg(env, insn->dst_reg, DST_OP);
+ /* check dest operand, mark as required later */
+ err = check_reg_arg(env, insn->dst_reg, DST_OP_NO_MARK);
if (err)
return err;
@@ -3265,6 +3265,8 @@ static int check_alu_op(struct bpf_verifier_env *env, struct bpf_insn *insn)
/* case: R = imm
* remember the value we stored into this reg
*/
+ /* clear any state __mark_reg_known doesn't set */
+ mark_reg_unknown(env, regs, insn->dst_reg);
regs[insn->dst_reg].type = SCALAR_VALUE;
if (BPF_CLASS(insn->code) == BPF_ALU64) {
__mark_reg_known(regs + insn->dst_reg,
diff --git a/tools/testing/selftests/bpf/test_verifier.c b/tools/testing/selftests/bpf/test_verifier.c
index 41106d9d5cc7..79f10e95e7df 100644
--- a/tools/testing/selftests/bpf/test_verifier.c
+++ b/tools/testing/selftests/bpf/test_verifier.c
@@ -12372,6 +12372,32 @@ static struct bpf_test tests[] = {
.result = REJECT,
.errstr = "variable ctx access var_off=(0x0; 0x4)",
},
+ {
+ "mov64 src == dst",
+ .insns = {
+ BPF_MOV64_IMM(BPF_REG_2, 0),
+ BPF_MOV64_REG(BPF_REG_2, BPF_REG_2),
+ // Check bounds are OK
+ BPF_ALU64_REG(BPF_ADD, BPF_REG_1, BPF_REG_2),
+ BPF_MOV64_IMM(BPF_REG_0, 0),
+ BPF_EXIT_INSN(),
+ },
+ .prog_type = BPF_PROG_TYPE_SCHED_CLS,
+ .result = ACCEPT,
+ },
+ {
+ "mov64 src != dst",
+ .insns = {
+ BPF_MOV64_IMM(BPF_REG_3, 0),
+ BPF_MOV64_REG(BPF_REG_2, BPF_REG_3),
+ // Check bounds are OK
+ BPF_ALU64_REG(BPF_ADD, BPF_REG_1, BPF_REG_2),
+ BPF_MOV64_IMM(BPF_REG_0, 0),
+ BPF_EXIT_INSN(),
+ },
+ .prog_type = BPF_PROG_TYPE_SCHED_CLS,
+ .result = ACCEPT,
+ },
};
static int probe_filter_length(const struct bpf_insn *fp)
--
2.18.0
^ permalink raw reply related
* [patch net] net: dsa: mv88e6xxx: Fix SERDES support on 88E6141/6341
From: Andrew Lunn @ 2018-07-31 17:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev, marek.behun, Andrew Lunn
Version 1 of the patch adding SERDES support to the 88E6141/6341
correctly added the ops to the 88E6141/6341. However, by the time
version 3 was committed, the ops had moved to the 88E6085/6175. Put
them back where they belong.
Fixes: 5bafeb6e7e87 ("net: dsa: mv88e6xxx: 88E6141/6341 SERDES support")
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/mv88e6xxx/chip.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 9ef07a06aceb..bb28c701381a 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2617,7 +2617,6 @@ static const struct mv88e6xxx_ops mv88e6085_ops = {
.rmu_disable = mv88e6085_g1_rmu_disable,
.vtu_getnext = mv88e6352_g1_vtu_getnext,
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
- .serdes_power = mv88e6341_serdes_power,
};
static const struct mv88e6xxx_ops mv88e6095_ops = {
@@ -2783,6 +2782,7 @@ static const struct mv88e6xxx_ops mv88e6141_ops = {
.reset = mv88e6352_g1_reset,
.vtu_getnext = mv88e6352_g1_vtu_getnext,
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
+ .serdes_power = mv88e6341_serdes_power,
.gpio_ops = &mv88e6352_gpio_ops,
};
@@ -2960,7 +2960,6 @@ static const struct mv88e6xxx_ops mv88e6175_ops = {
.reset = mv88e6352_g1_reset,
.vtu_getnext = mv88e6352_g1_vtu_getnext,
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
- .serdes_power = mv88e6341_serdes_power,
};
static const struct mv88e6xxx_ops mv88e6176_ops = {
@@ -3336,6 +3335,7 @@ static const struct mv88e6xxx_ops mv88e6341_ops = {
.reset = mv88e6352_g1_reset,
.vtu_getnext = mv88e6352_g1_vtu_getnext,
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
+ .serdes_power = mv88e6341_serdes_power,
.gpio_ops = &mv88e6352_gpio_ops,
.avb_ops = &mv88e6390_avb_ops,
};
--
2.18.0
^ permalink raw reply related
* [PATCH v1 0/3] WireGuard: Secure Network Tunnel
From: Jason A. Donenfeld @ 2018-07-31 19:10 UTC (permalink / raw)
To: linux-kernel, netdev, davem; +Cc: Jason A. Donenfeld
This patchset is available on git.kernel.org in this branch:
* https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/linux.git/log/?h=jd/wireguard
The two primary patches in it may be viewed using these temporary tags:
* https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/linux.git/commit/?h=zinc
* https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/linux.git/commit/?h=wireguard
WireGuard is a secure network tunnel written especially for Linux, which
has faced around three years of serious development, deployment, and
scrutiny. It delivers excellent performance and is extremely easy to
use and configure. It has been designed with the primary goal of being
both easy to audit by virtue of being small and highly secure from a
cryptography and systems security perspective. WireGuard is used by some
massive companies pushing enormous amounts of traffic, and likely
already today you've consumed bytes that at some point transited through
a WireGuard tunnel. Even as an out-of-tree module, WireGuard has been
integrated into various userspace tools, Linux distributions, mobile
phones, and data centers. There are ports in several languages to
several operating systems, and even commercial hardware and services
sold integrating WireGuard. It is time, therefore, for WireGuard to be
properly integrated into Linux.
Ample information, including documentation, installation instructions,
and project details, is available at:
* https://www.wireguard.com/
* https://www.wireguard.com/papers/wireguard.pdf
As it is currently an out-of-tree module, it lives in its own git repo
and has its own mailing list, and every commit for the module is tested
against every stable kernel since 3.10 on a variety of architectures
using an extensive test suite:
* https://git.zx2c4.com/WireGuard
https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/WireGuard.git/
* https://lists.zx2c4.com/mailman/listinfo/wireguard
* https://www.wireguard.com/build-status/
The project has been broadly discussed at conferences, and was presented
to the Netdev developers in Seoul last November, where a paper was
released detailing some interesting aspects of the project. Dave asked
me after the talk if I would consider sending in a v1 "sooner rather
than later", hence this patchset. A decision is still waiting from the
LPC network track committee, but an update on these topics may be
presented in Vancouver in a few months. Presentations:
* https://www.wireguard.com/presentations/
* https://www.wireguard.com/papers/wireguard-netdev22.pdf
The cryptography in the protocol itself has been formally verified by
several independent academic teams with positive results, and I know of
two additional efforts on their way to further corroborate those
findings. The version 1 protocol is "complete", and so the purpose of
this review is to assess the implementation of the protocol. However, it
still may be of interest to know that the thing you're reviewing uses a
protocol with various nice security properties:
* https://www.wireguard.com/formal-verification/
This patchset is divided into three parts. The first is a boring commit
to random.c, which Ted approved a while back but asked me to submit it
together with WireGuard and have it enter the kernel through the net
tree. The second is a small collection of cryptographic primitives. The
third is WireGuard itself, presented as a unintrusive and self-contained
virtual network driver.
The primary pathology of this patchset is the very long lines; I have
3840 horizontal pixels on my laptop, and I enjoy using all of them.
However, if this is a problem for parent tree maintainers, I'll dutifully
wrap at 80 chars per the norm. Beyond that, the focus of WireGuard has been
on keeping things fairly simple, so I hope that this will be an enjoyable
review.
Enjoy,
Jason
--
2.18.0
^ permalink raw reply
* [PATCH v1 1/3] random: Make crng state queryable
From: Jason A. Donenfeld @ 2018-07-31 19:11 UTC (permalink / raw)
To: linux-kernel, netdev, davem; +Cc: Jason A. Donenfeld, Theodore Ts'o
In-Reply-To: <20180731191102.2434-1-Jason@zx2c4.com>
It is very useful to be able to know whether or not get_random_bytes_wait
/ wait_for_random_bytes is going to block or not, or whether plain
get_random_bytes is going to return good randomness or bad randomness.
The particular use case is for mitigating certain attacks in WireGuard.
A handshake packet arrives and is queued up. Elsewhere a worker thread
takes items from the queue and processes them. In replying to these
items, it needs to use some random data, and it has to be good random
data. If we simply block until we can have good randomness, then it's
possible for an attacker to fill the queue up with packets waiting to be
processed. Upon realizing the queue is full, WireGuard will detect that
it's under a denial of service attack, and behave accordingly. A better
approach is just to drop incoming handshake packets if the crng is not
yet initialized.
This patch, therefore, makes that information directly accessible.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
---
drivers/char/random.c | 15 +++++++++++++++
include/linux/random.h | 1 +
2 files changed, 16 insertions(+)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index cd888d4ee605..4efd16f6e0e1 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1658,6 +1658,21 @@ int wait_for_random_bytes(void)
}
EXPORT_SYMBOL(wait_for_random_bytes);
+/*
+ * Returns whether or not the urandom pool has been seeded and thus guaranteed
+ * to supply cryptographically secure random numbers. This applies to: the
+ * /dev/urandom device, the get_random_bytes function, and the get_random_{u32,
+ * ,u64,int,long} family of functions.
+ *
+ * Returns: true if the urandom pool has been seeded.
+ * false if the urandom pool has not been seeded.
+ */
+bool rng_is_initialized(void)
+{
+ return crng_ready();
+}
+EXPORT_SYMBOL(rng_is_initialized);
+
/*
* Add a callback function that will be invoked when the nonblocking
* pool is initialised.
diff --git a/include/linux/random.h b/include/linux/random.h
index 2ddf13b4281e..c8208e0ff227 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -36,6 +36,7 @@ extern void add_interrupt_randomness(int irq, int irq_flags) __latent_entropy;
extern void get_random_bytes(void *buf, int nbytes);
extern int wait_for_random_bytes(void);
+extern bool rng_is_initialized(void);
extern int add_random_ready_callback(struct random_ready_callback *rdy);
extern void del_random_ready_callback(struct random_ready_callback *rdy);
extern void get_random_bytes_arch(void *buf, int nbytes);
--
2.18.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox