* Re: [RFC] Add BPF_SYNCHRONIZE bpf(2) command
From: Joel Fernandes @ 2018-07-30 22:26 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Daniel Colascione, Lorenzo Colitti, Chenbo Feng,
Mathieu Desnoyers, Joel Fernandes, Alexei Starovoitov, lkml,
Tim Murray, Daniel Borkmann, netdev
In-Reply-To: <CAADnVQL=yTRvNLun2_oiwDvUvpvTV9=pOLyNhu=_cQ2sX04p5w@mail.gmail.com>
On Sun, Jul 29, 2018 at 06:57:06PM +0300, Alexei Starovoitov wrote:
> On Fri, Jul 27, 2018 at 10:17 PM, Daniel Colascione <dancol@google.com> wrote:
> > On Sat, Jul 14, 2018 at 11:18 AM, Joel Fernandes <joel@joelfernandes.org>
> > wrote:
> >>
> >> By the way just curious I was briefly going through kernel/bpf/arraymap.c.
> >> How are you protecting against load-store tearing of values of array map
> >> updates/lookups?
> >>
> >> For example, if userspace reads an array map at a particular index, while
> >> another CPU is updating it, then userspace can read partial values /
> >> half-updated values right? Since rcu_read_lock is in use, I was hoping to
> >> find something like rcu_assign_pointer there to protect readers against
> >> concurrent updates. Thanks for any clarification.
> >
> >
> > I'm also curious about the answer to this question.
>
> i'm not sure I understand the question.
> bpf_map_type_array is a C-like array.
> There is no locking of elements.
> If single program executing on two cpus
> and accesses the same value it will collide.
> Same goes for user space vs prog parallel access.
> bpf long_memcpy is an attempt to provide minimal
> level of automicity when values are aligned and
> size==long.
Thanks for the answer. I think you answered the question.
Regards,
- Joel
^ permalink raw reply
* YOU ARE ADVISED TO STOP CONTACTING THEM!!!
From: Mrs. CYNDY BANKS @ 2018-07-27 15:47 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 4236 bytes --]
^ permalink raw reply
* Re: [PATCH] net: remove bogus RCU annotations on socket.wq
From: Eric Dumazet @ 2018-07-30 22:23 UTC (permalink / raw)
To: Christoph Hellwig, Eric Dumazet, Paul E. McKenney, netdev; +Cc: linux-kernel
In-Reply-To: <20180730074507.17037-2-hch@lst.de>
On 07/30/2018 12:45 AM, Christoph Hellwig wrote:
> We never use RCU protection for it, just a lot of cargo-cult
> rcu_deference_protects calls.
>
> Note that we do keep the kfree_rcu call for it, as the references through
> struct sock are RCU protected and thus might require a grace period before
> freeing.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Thanks.
^ permalink raw reply
* [PATCH v4 net-next] net: ethernet: ti: cpsw: replace unnecessarily macroses on functions
From: Ivan Khoronzhuk @ 2018-07-30 22:05 UTC (permalink / raw)
To: grygorii.strashko, davem
Cc: linux-omap, netdev, linux-kernel, joe, andrew, Ivan Khoronzhuk
Replace ugly macroses on functions.
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
Based on net-next/master
v4..v3:
- use directly code instead of cpsw_src_port_detect()
v3..v2:
- comment corrections
v2..v1:
- removed inline for cpsw_src_port_detect()
drivers/net/ethernet/ti/cpsw.c | 58 +++++++++++++++-------------------
1 file changed, 26 insertions(+), 32 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 1b54c26c2bec..f051ce35a440 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -565,40 +565,28 @@ static const struct cpsw_stats cpsw_gstrings_ch_stats[] = {
(func)(slave++, ##arg); \
} while (0)
-#define cpsw_dual_emac_src_port_detect(cpsw, status, ndev, skb) \
- do { \
- if (!cpsw->data.dual_emac) \
- break; \
- if (CPDMA_RX_SOURCE_PORT(status) == 1) { \
- ndev = cpsw->slaves[0].ndev; \
- skb->dev = ndev; \
- } else if (CPDMA_RX_SOURCE_PORT(status) == 2) { \
- ndev = cpsw->slaves[1].ndev; \
- skb->dev = ndev; \
- } \
- } while (0)
-#define cpsw_add_mcast(cpsw, priv, addr) \
- do { \
- if (cpsw->data.dual_emac) { \
- struct cpsw_slave *slave = cpsw->slaves + \
- priv->emac_port; \
- int slave_port = cpsw_get_slave_port( \
- slave->slave_num); \
- cpsw_ale_add_mcast(cpsw->ale, addr, \
- 1 << slave_port | ALE_PORT_HOST, \
- ALE_VLAN, slave->port_vlan, 0); \
- } else { \
- cpsw_ale_add_mcast(cpsw->ale, addr, \
- ALE_ALL_PORTS, \
- 0, 0, 0); \
- } \
- } while (0)
-
static inline int cpsw_get_slave_port(u32 slave_num)
{
return slave_num + 1;
}
+static void cpsw_add_mcast(struct cpsw_priv *priv, u8 *addr)
+{
+ struct cpsw_common *cpsw = priv->cpsw;
+
+ if (cpsw->data.dual_emac) {
+ struct cpsw_slave *slave = cpsw->slaves + priv->emac_port;
+ int slave_port = cpsw_get_slave_port(slave->slave_num);
+
+ cpsw_ale_add_mcast(cpsw->ale, addr,
+ 1 << slave_port | ALE_PORT_HOST,
+ ALE_VLAN, slave->port_vlan, 0);
+ return;
+ }
+
+ cpsw_ale_add_mcast(cpsw->ale, addr, ALE_ALL_PORTS, 0, 0, 0);
+}
+
static void cpsw_set_promiscious(struct net_device *ndev, bool enable)
{
struct cpsw_common *cpsw = ndev_to_cpsw(ndev);
@@ -706,7 +694,7 @@ static void cpsw_ndo_set_rx_mode(struct net_device *ndev)
/* program multicast address list into ALE register */
netdev_for_each_mc_addr(ha, ndev) {
- cpsw_add_mcast(cpsw, priv, (u8 *)ha->addr);
+ cpsw_add_mcast(priv, ha->addr);
}
}
}
@@ -798,10 +786,16 @@ static void cpsw_rx_handler(void *token, int len, int status)
struct sk_buff *skb = token;
struct sk_buff *new_skb;
struct net_device *ndev = skb->dev;
- int ret = 0;
+ int ret = 0, port;
struct cpsw_common *cpsw = ndev_to_cpsw(ndev);
- cpsw_dual_emac_src_port_detect(cpsw, status, ndev, skb);
+ if (cpsw->data.dual_emac) {
+ port = CPDMA_RX_SOURCE_PORT(status);
+ if (port) {
+ ndev = cpsw->slaves[--port].ndev;
+ skb->dev = ndev;
+ }
+ }
if (unlikely(status < 0) || unlikely(!netif_running(ndev))) {
/* In dual emac mode check for all interfaces */
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v8 0/7] netdev: intel: Eliminate duplicate barriers on weakly-ordered archs
From: Alexander Duyck @ 2018-07-30 20:06 UTC (permalink / raw)
To: Sinan Kaya; +Cc: Netdev
In-Reply-To: <906d48a5-6eaf-a152-1936-05670b0a6ae8@kernel.org>
On Mon, Jul 30, 2018 at 12:20 PM, Sinan Kaya <okaya@kernel.org> wrote:
> +netdev,
>
> On 7/30/2018 9:45 AM, Alexander Duyck wrote:
>>
>> I haven't had a chance to work on this much myself. My understanding
>> is that igb has had the barriers updated, but I don't think any of the
>> other drivers have been worked over yet.
>
>
> Unfortunately, I have recently changed jobs and I no longer have the
> hardware to test my changes. I thought that you wanted to handle this
> yourself.
>
> I haven't seen any follow ups. I wanted to double check.
As I said so far igb has been the only one updated, and that was done
by a third party:
73017f4e051c8 igb: Use dma_wmb() instead of wmb() before doorbell writes
> I worked with several architecture leads on 4.17. All architectures
> support the updated barrier semantics now. It is time to clean up the
> network drivers.
Thanks for that update. As I said for now igb has the barriers
updated. The idea being that igb is the test vehicle for this so if we
go a kernel version or so without triggering any issues then we can
follow up with the other drivers.
The other thing we have to keep in mind is that unlike many other NICs
we have to also deal with emulations of our devices (e1000 and e1000e)
that may rely on certain barriers being used to enforce things like
SMP synchronization between CPUs, so we have to be careful as we roll
this out.
Thanks.
- Alex
^ permalink raw reply
* Re: [PATCH 07/10] dt-bindings: phy: add DT binding for Microsemi Ocelot SerDes muxing
From: Florian Fainelli @ 2018-07-30 21:39 UTC (permalink / raw)
To: Quentin Schulz, alexandre.belloni, ralf, paul.burton, jhogan,
robh+dt, mark.rutland, davem
Cc: kishon, andrew, linux-mips, devicetree, linux-kernel, netdev,
allan.nielsen, thomas.petazzoni
In-Reply-To: <cd75c96640cc7fe306ee355acb1db85adb5b796f.1532954208.git-series.quentin.schulz@bootlin.com>
On 07/30/2018 05:43 AM, Quentin Schulz wrote:
> Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
> ---
> Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt | 42 +++++++-
> 1 file changed, 42 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt b/Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt
> new file mode 100644
> index 0000000..25b102d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt
> @@ -0,0 +1,42 @@
> +Microsemi Ocelot SerDes muxing driver
> +-------------------------------------
> +
> +On Microsemi Ocelot, there is a handful of registers in HSIO address
> +space for setting up the SerDes to switch port muxing.
> +
> +A SerDes X can be "muxed" to work with switch port Y or Z for example.
> +One specific SerDes can also be used as a PCIe interface.
> +
> +Hence, a SerDes represents an interface, be it an Ethernet or a PCIe one.
> +
> +There are two kinds of SerDes: SERDES1G supports 10/100Mbps in
> +half/full-duplex and 1000Mbps in full-duplex mode while SERDES6G supports
> +10/100Mbps in half/full-duplex and 1000/2500Mbps in full-duplex mode.
> +
> +Also, SERDES6G number (aka "macro") 0 is the only interface supporting
> +QSGMII.
> +
> +Required properties:
> +
> +- compatible: should be "mscc,vsc7514-serdes"
> +- #phy-cells : from the generic phy bindings, must be 3. The first number
> + defines the kind of Serdes (1 for SERDES1G_X, 6 for
> + SERDES6G_X), the second defines the macros in the specified
> + kind of Serdes (X for SERDES1G_X or SERDES6G_X) and the
> + last one defines the input port to use for a given SerDes
> + macro,
It would probably be more natural to reverse some of this and have the
1st cell be the input port, while the 2nd and 3rd cell are the serdes
kind and the serdes macro type. Same comment as Andrew, can you please
define the 2nd and 3rd cells possible values in a header file that you
can include from both the DTS and the driver making use of that?
--
Florian
^ permalink raw reply
* Re: [PATCH net-next] virtio_net: force_napi_tx module param.
From: Stephen Hemminger @ 2018-07-30 19:51 UTC (permalink / raw)
To: David Miller; +Cc: caleb.raitto, mst, jasowang, netdev, caraitto
In-Reply-To: <20180729.090027.1373538625446665385.davem@davemloft.net>
On Sun, 29 Jul 2018 09:00:27 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Caleb Raitto <caleb.raitto@gmail.com>
> Date: Mon, 23 Jul 2018 16:11:19 -0700
>
> > From: Caleb Raitto <caraitto@google.com>
> >
> > The driver disables tx napi if it's not certain that completions will
> > be processed affine with tx service.
> >
> > Its heuristic doesn't account for some scenarios where it is, such as
> > when the queue pair count matches the core but not hyperthread count.
> >
> > Allow userspace to override the heuristic. This is an alternative
> > solution to that in the linked patch. That added more logic in the
> > kernel for these cases, but the agreement was that this was better left
> > to user control.
> >
> > Do not expand the existing napi_tx variable to a ternary value,
> > because doing so can break user applications that expect
> > boolean ('Y'/'N') instead of integer output. Add a new param instead.
> >
> > Link: https://patchwork.ozlabs.org/patch/725249/
> > Acked-by: Willem de Bruijn <willemb@google.com>
> > Acked-by: Jon Olson <jonolson@google.com>
> > Signed-off-by: Caleb Raitto <caraitto@google.com>
>
> So I looked into the history surrounding these issues.
>
> First of all, it's always ends up turning out crummy when drivers start
> to set affinities themselves. The worst possible case is to do it
> _conditionally_, and that is exactly what virtio_net is doing.
>
> From the user's perspective, this provides a really bad experience.
>
> So if I have a 32-queue device and there are 32 cpus, you'll do all
> the affinity settings, stopping Irqbalanced from doing anything
> right?
>
> So if I add one more cpu, you'll say "oops, no idea what to do in
> this situation" and not touch the affinities at all?
>
> That makes no sense at all.
>
> If the driver is going to set affinities at all, OWN that decision
> and set it all the time to something reasonable.
>
> Or accept that you shouldn't be touching this stuff in the first place
> and leave the affinities alone.
>
> Right now we're kinda in a situation where the driver has been setting
> affinities in the ncpus==nqueues cases for some time, so we can't stop
> doing it.
>
> Which means we have to set them in all cases to make the user
> experience sane again.
>
> I looked at the linked to patch again:
>
> https://patchwork.ozlabs.org/patch/725249/
>
> And I think the strategy should be made more generic, to get rid of
> the hyperthreading assumptions. I also agree that the "assign
> to first N cpus" logic doesn't make much sense either.
>
> Just distribute across the available cpus evenly, and be done with it.
> If you have 64 cpus and 32 queues, this assigns queues to every other
> cpu.
>
> Then we don't need this weird new module parameter.
I wonder if it would be possible to give irqbalanced hints
with irq_set_affinity_hint instead of doing direct affinity setting?
^ permalink raw reply
* Re: [PATCH] netlink: Don't shift with UB on nlk->ngroups
From: Dmitry Safonov @ 2018-07-30 19:50 UTC (permalink / raw)
To: David Miller
Cc: linux-kernel, rong.a.chen, 0x7f454c46, herbert, steffen.klassert,
netdev
In-Reply-To: <20180730.124330.538236571439983894.davem@davemloft.net>
On Mon, 2018-07-30 at 12:43 -0700, David Miller wrote:
> From: Dmitry Safonov <dima@arista.com>
> Date: Mon, 30 Jul 2018 18:32:36 +0100
>
> > On i386 nlk->ngroups might be 32 or 0. Which leads to UB, resulting
> in
> > hang during boot.
> > Check for 0 ngroups and use (unsigned long long) as a type to
> shift.
> >
> > Fixes: commit 7acf9d4237c46894e0fa0492dd96314a41742e84 ("netlink:
> Do not
> > subscribe to non-existent groups").
>
> Please, in the future, format your Fixes: tag correctly. No need
> to say the work "commit", please do not chop up the line no matter
> how long it is, and please provide 12 digits of SHA1_ID value, rather
> than the whole thing.
Oh, yeah, I have this in .gitconfig:
[core]
abbrev = 12
But I was formatting this not on my laptop and have managed to mislook.
Sorry about "commit" and the breakage.
> > Reported-by: kernel test robot <rong.a.chen@intel.com>
> > Signed-off-by: Dmitry Safonov <dima@arista.com>
>
> Applied, thank you.
Thank you.
^ permalink raw reply
* Re: [PATCH v3] perf build: Build error in libbpf with EXTRA_CFLAGS="-Wp,-D_FORTIFY_SOURCE=2 -O2"
From: Jakub Kicinski @ 2018-07-30 19:35 UTC (permalink / raw)
To: Thomas Richter
Cc: daniel, ast, netdev, linux-kernel, heiko.carstens, brueckner,
schwidefsky
In-Reply-To: <20180730085323.75738-1-tmricht@linux.ibm.com>
On Mon, 30 Jul 2018 10:53:23 +0200, Thomas Richter wrote:
> commit 531b014e7a2f ("tools: bpf: make use of reallocarray")
> causes a compiler error when building the perf tool in the linux-next
> tree. Compile file tools/lib/bpf/libbpf.c on a FEDORA 28
> installation with gcc compiler
> version: gcc (GCC) 8.0.1 20180324 (Red Hat 8.0.1-0.20)
> shows this error message:
>
> [root@p23lp27] # make V=1 EXTRA_CFLAGS="-Wp,-D_FORTIFY_SOURCE=2 -O2"
> [...]
> make -f /home6/tmricht/linux-next/tools/build/Makefile.build
> dir=./util/scripting-engines obj=libperf
> libbpf.c: In function ‘bpf_object__elf_collect’:
> libbpf.c:811:15: error: ignoring return value of ‘strerror_r’,
> declared with attribute warn_unused_result [-Werror=unused-result]
> strerror_r(-err, errmsg, sizeof(errmsg));
> ^
> cc1: all warnings being treated as errors
> mv: cannot stat './.libbpf.o.tmp': No such file or directory
> /home6/tmricht/linux-next/tools/build/Makefile.build:96: recipe for target 'libbpf.o' failed
>
> Replace all occurrences of strerror() by calls to strerror_r().
> To keep the compiler quiet also use the return value from strerror_r()
> otherwise a 'variable set but not use' warning which is treated as error
> terminates the compile.
>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
> Suggested-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Suggested-by: Daniel Borkmann <daniel@iogearbox.net>
> Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com>
> Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Conversion looks correct, thank you!
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
^ permalink raw reply
* Re: pull-request: can 2018-07-30,Re: pull-request: can 2018-07-30
From: David Miller @ 2018-07-30 19:33 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can, kernel
In-Reply-To: <d629f545-e2d6-c2dd-91f5-45a3dde73831@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Mon, 30 Jul 2018 21:06:27 +0200
> Oops, it's definitely too hot in the office at the moment. here it it:
That works, pulled, thanks :)
^ permalink raw reply
* Re: [PATCH net-next v5 1/4] net/sched: user-space can't set unknown tcfa_action values
From: Jamal Hadi Salim @ 2018-07-30 19:31 UTC (permalink / raw)
To: Paolo Abeni, netdev
Cc: Cong Wang, Jiri Pirko, Daniel Borkmann, Marcelo Ricardo Leitner,
Eyal Birger, David S. Miller
In-Reply-To: <b5721ac431ce9d621ea9e4a0c04de8d26dc9f558.camel@redhat.com>
On 30/07/18 12:41 PM, Paolo Abeni wrote:
> On Mon, 2018-07-30 at 10:03 -0400, Jamal Hadi Salim wrote:
>> On 30/07/18 08:30 AM, Paolo Abeni wrote:
>>> }
>>>
>>> + if (!tcf_action_valid(a->tcfa_action)) {
>>> + NL_SET_ERR_MSG(extack, "invalid action value, using TC_ACT_UNSPEC instead");
>>> + a->tcfa_action = TC_ACT_UNSPEC;
>>> + }
>>> +
>>> return a;
>>>
>>
>>
>> I think it would make a lot more sense to just reject the entry than
>> changing it underneath the user to a default value. Least element of
>> suprise.
>
> I fear that would break existing (bad) users ?!? This way, such users
> are notified they are doing something uncorrect, but still continue to
> work.
By "bad users" I think you mean someone setting a policy expecting
one behavior but getting a different one? If yes, that policy was
already wrong/buggy. As an example, if i configured:
match xxx action foo action goo action bar action gah
where action goo has a bad opcode
If you "fix it" with TC_ACT_UNSPEC then basically the above
policy is now equivalent to:
match xxx action foo action goo
Infact if there was a lower prio rule in the chain
then lookup will continue there and produce even stranger
results.
cheers,
jamal
>
> The patch can be changed to reject bad actions, if there is agreement,
> but it would not look as the safest way to me.
^ permalink raw reply
* Re: [PATCH v8 0/7] netdev: intel: Eliminate duplicate barriers on weakly-ordered archs
From: Sinan Kaya @ 2018-07-30 19:20 UTC (permalink / raw)
To: Alexander Duyck, netdev
In-Reply-To: <CAKgT0UcbSfgg3mpv0Qr2-w8iHhbQMsyM3LcrM4YwAv8yTiq+Vw@mail.gmail.com>
+netdev,
On 7/30/2018 9:45 AM, Alexander Duyck wrote:
> I haven't had a chance to work on this much myself. My understanding
> is that igb has had the barriers updated, but I don't think any of the
> other drivers have been worked over yet.
Unfortunately, I have recently changed jobs and I no longer have the
hardware to test my changes. I thought that you wanted to handle this
yourself.
I haven't seen any follow ups. I wanted to double check.
I worked with several architecture leads on 4.17. All architectures
support the updated barrier semantics now. It is time to clean up the
network drivers.
92d7223a7423 alpha: io: reorder barriers to guarantee writeX() and
iowriteX() ordering #2
a1cc7034e33d MIPS: io: Add barrier after register read in readX()
f6b7aeee8f16 MIPS: io: Prevent compiler reordering writeX()
a71e7c44ffb7 io: change writeX_relaxed() to remove barriers
8875c5543761 io: change readX_relaxed() to remove barriers
cd0e00c10672 alpha: io: reorder barriers to guarantee writeX() and
iowriteX() ordering
87fe2d543f81 io: change inX() to have their own IO barrier overrides
a7851aa54c0c io: change outX() to have their own IO barrier overrides
755bd04aaf4b io: define stronger ordering for the default writeX()
implementation
032d59e1cde9 io: define stronger ordering for the default readX()
implementation
64e2c6738b4d io: define several IO & PIO barrier types for the
asm-generic version
^ permalink raw reply
* Re: pull-request: can 2018-07-30
From: Marc Kleine-Budde @ 2018-07-30 19:06 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-can, kernel
In-Reply-To: <20180730.091628.2180063281807636490.davem@davemloft.net>
[-- Attachment #1.1: Type: text/plain, Size: 1604 bytes --]
On 07/30/2018 06:16 PM, David Miller wrote:
> From: Marc Kleine-Budde <mkl@pengutronix.de>
> Date: Mon, 30 Jul 2018 11:08:21 +0200
>
>> Hello David,
>>
>> this is a pull request of one patch for net/master.
>>
>> The patch by Anton Vasilyev and the Linux Driver Verification project
>> fixes a memory leak in the ems_usb driver's disconnect function.
>
> Where is the GIT URL you want me to pull from? :)
Oops, it's definitely too hot in the office at the moment. here it it:
---
The following changes since commit 25432eba9cd8f2ef5afef55be811b010a004b5fa:
openvswitch: meter: Fix setting meter id for new entries (2018-07-29 13:20:54 -0700)
are available in the Git repository at:
ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git tags/linux-can-fixes-for-4.18-20180730
for you to fetch changes up to 72c05f32f4a5055c9c8fe889bb6903ec959c0aad:
can: ems_usb: Fix memory leak on ems_usb_disconnect() (2018-07-30 11:04:27 +0200)
----------------------------------------------------------------
linux-can-fixes-for-4.18-20180730
----------------------------------------------------------------
Anton Vasilyev (1):
can: ems_usb: Fix memory leak on ems_usb_disconnect()
drivers/net/can/usb/ems_usb.c | 1 +
1 file changed, 1 insertion(+)
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RFC PATCH ghak90 (was ghak32) V3 01/10] audit: add container id
From: Richard Guy Briggs @ 2018-07-30 18:47 UTC (permalink / raw)
To: Paul Moore
Cc: cgroups, containers, linux-api, linux-audit, linux-fsdevel,
linux-kernel, netdev, ebiederm, luto, jlayton, carlos, dhowells,
viro, simo, Eric Paris, serge
In-Reply-To: <CAHC9VhQ3KwG-YmpJsOa9k=YqQmaQTaJXeB=eM9Fm80hujbngBg@mail.gmail.com>
On 2018-07-24 17:54, Paul Moore wrote:
> On Tue, Jul 24, 2018 at 3:09 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> > On 2018-07-20 18:13, Paul Moore wrote:
> > > On Wed, Jun 6, 2018 at 1:00 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> > > > Implement the proc fs write to set the audit container identifier of a
> > > > process, emitting an AUDIT_CONTAINER_ID record to document the event.
> > > >
> > > > This is a write from the container orchestrator task to a proc entry of
> > > > the form /proc/PID/audit_containerid where PID is the process ID of the
> > > > newly created task that is to become the first task in a container, or
> > > > an additional task added to a container.
> > > >
> > > > The write expects up to a u64 value (unset: 18446744073709551615).
> > > >
> > > > The writer must have capability CAP_AUDIT_CONTROL.
> > > >
> > > > This will produce a record such as this:
> > > > type=CONTAINER_ID msg=audit(2018-06-06 12:39:29.636:26949) : op=set opid=2209 old-contid=18446744073709551615 contid=123456 pid=628 auid=root uid=root tty=ttyS0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 comm=bash exe=/usr/bin/bash res=yes
> > > >
> > > > The "op" field indicates an initial set. The "pid" to "ses" fields are
> > > > the orchestrator while the "opid" field is the object's PID, the process
> > > > being "contained". Old and new audit container identifier values are
> > > > given in the "contid" fields, while res indicates its success.
> > > >
> > > > It is not permitted to unset or re-set the audit container identifier.
> > > > A child inherits its parent's audit container identifier, but then can
> > > > be set only once after.
> > > >
> > > > See: https://github.com/linux-audit/audit-kernel/issues/90
> > > > See: https://github.com/linux-audit/audit-userspace/issues/51
> > > > See: https://github.com/linux-audit/audit-testsuite/issues/64
> > > > See: https://github.com/linux-audit/audit-kernel/wiki/RFE-Audit-Container-ID
> > > >
> > > > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > > > ---
> > > > fs/proc/base.c | 37 ++++++++++++++++++++++++
> > > > include/linux/audit.h | 25 ++++++++++++++++
> > > > include/uapi/linux/audit.h | 2 ++
> > > > kernel/auditsc.c | 71 ++++++++++++++++++++++++++++++++++++++++++++++
> > > > 4 files changed, 135 insertions(+)
>
> ...
>
> > > > @@ -2112,6 +2116,73 @@ int audit_set_loginuid(kuid_t loginuid)
> > > > }
> > > >
> > > > /**
> > > > + * audit_set_contid - set current task's audit_context contid
> > > > + * @contid: contid value
> > > > + *
> > > > + * Returns 0 on success, -EPERM on permission failure.
> > > > + *
> > > > + * Called (set) from fs/proc/base.c::proc_contid_write().
> > > > + */
> > > > +int audit_set_contid(struct task_struct *task, u64 contid)
> > > > +{
> > > > + u64 oldcontid;
> > > > + int rc = 0;
> > > > + struct audit_buffer *ab;
> > > > + uid_t uid;
> > > > + struct tty_struct *tty;
> > > > + char comm[sizeof(current->comm)];
> > > > +
> > > > + /* Can't set if audit disabled */
> > > > + if (!task->audit)
> > > > + return -ENOPROTOOPT;
> > > > + oldcontid = audit_get_contid(task);
> > > > + /* Don't allow the audit containerid to be unset */
> > > > + if (!cid_valid(contid))
> > > > + rc = -EINVAL;
> > > > + /* if we don't have caps, reject */
> > > > + else if (!capable(CAP_AUDIT_CONTROL))
> > > > + rc = -EPERM;
> > > > + /* if task has children or is not single-threaded, deny */
> > > > + else if (!list_empty(&task->children))
> > > > + rc = -EBUSY;
> > >
> > > Is this safe without holding tasklist_lock? I worry we might be
> > > vulnerable to a race with fork().
> > >
> > > > + else if (!(thread_group_leader(task) && thread_group_empty(task)))
> > > > + rc = -EALREADY;
> > >
> > > Similar concern here as well, although related to threads.
> >
> > I think you are correct here and tasklist_lock should cover both. Do we
> > also want rcu_read_lock() immediately preceeding it?
>
> You'll need to take a closer look and determine the locking scheme. I
> simply took a quick look while reviewing this patch to see what of the
> existing locks, if any, would be most applicable here; tasklist_lock
> seemed like a good starting point.
>
> It looks like tasklist_lock is defined as a rwlock_t so I'm not sure
> it would make sense to use it with a RCU protected structure
> (typically it's RCU+spinlock), but maybe that is the case with a
> task_struct, you'll need to check.
All I need is a read rather than write tasklist_lock since I'm not
changing any inter-task relationships, which makes it possible to nest
it inside or outside the task_lock(). I don't think I need the RCU
lock.
> > > > + /* it is already set, and not inherited from the parent, reject */
> > > > + else if (cid_valid(oldcontid) && !task->audit->inherited)
> > > > + rc = -EEXIST;
> > >
> > > Maybe I'm missing something, but why do we care about preventing
> > > reassigning the audit container ID in this case? The task is single
> > > threaded and has no descendants at this point so it should be safe,
> > > yes? So long as the task changing the audit container ID has
> > > capable(CAP_AUDIT_CONTOL) it shouldn't matter, right?
> >
> > Because we hammered out this idea 6 months ago in the design phase and I
> > thought we all firmly agreed that the audit container identifier could
> > only be set once. Has any significant discussion happenned since then
> > to change that wisdom? I just wonder why this is coming up now.
>
> Implementation, and time, can change how one looks at an earlier
> design. I believe this is why most well reasoned specifications have
> a reference design.
>
> Remind me why the design had the restriction of write once for the
> audit container ID? At this point given the CAP_AUDIT_CONTROL and the
> single-thread, no-children restrictions I'm not sure what harm there
> is in allowing the value to be written multiple times (so long as the
> changes are audited of course).
Looking back through the conversations, I think you may be right that we
no longer need it, but it is easy to re-add if we find it necessary.
> > > Related, I'm questioning if we would ever care if the audit container
> > > ID was inherited or not?
> >
> > We do since that is the only way we can tell if the value has been set
> > once already or inherited unless we check if the parent's audit
> > container identifier is identical (which tells us it was inherited).
>
> Tied to the above question. If we don't care about multiple changes,
> given the other constraints, we probably don't need the inherited
> flag.
Agreed.
> paul moore
- RGB
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2018-07-30 20:14 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
Several small'ish fixes, I don't think any of this requires
another -rc but I'll leave that up to you:
1) Don't leak uninitialzed bytes to userspace in xfrm_user, from Eric
Dumazet.
2) Route leak in xfrm_lookup_route(), from Tommi Rantala.
3) Premature poll() returns in AF_XDP, from Björn Töpel.
4) devlink leak in netdevsim, from Jakub Kicinski.
5) Don't BUG_ON in fib_compute_spec_dst, the condition can
legitimately happen. From Lorenzo Bianconi.
6) Fix some spectre v1 gadgets in generic socket code, from
Jeremy Cline.
7) Don't allow user to bind to out of range multicast groups,
from Dmitry Safonov with a follow-up by Dmitry Safonov.
8) Fix metrics leak in fib6_drop_pcpu_from(), from Sabrina Dubroca.
Please pull, thanks a lot!
The following changes since commit 9981b4fb8684883dcc0daf088891ff32260b9794:
Merge tag 'mips_fixes_4.18_4' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux (2018-07-24 18:11:15 -0700)
are available in the Git repository at:
gitolite@ra.kernel.org:/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to 61f4b23769f0cc72ae62c9a81cf08f0397d40da8:
netlink: Don't shift with UB on nlk->ngroups (2018-07-30 12:42:22 -0700)
----------------------------------------------------------------
Anton Vasilyev (2):
net: mdio-mux: bcm-iproc: fix wrong getter and setter pair
can: ems_usb: Fix memory leak on ems_usb_disconnect()
Arjun Vynipadath (1):
cxgb4: Added missing break in ndo_udp_tunnel_{add/del}
Avinash Repaka (1):
RDS: RDMA: Fix the NULL-ptr deref in rds_ib_get_mr
Björn Töpel (1):
xsk: fix poll/POLLIN premature returns
Daniel Borkmann (2):
Merge branch 'bpf-annotate-kv-pair'
bpf: fix bpf_skb_load_bytes_relative pkt length check
David S. Miller (4):
Merge branch 'master' of git://git.kernel.org/.../klassert/ipsec
Merge git://git.kernel.org/.../bpf/bpf
Merge branch 'net-socket-Fix-potential-spectre-v1-gadgets'
Merge tag 'linux-can-fixes-for-4.18-20180730' of ssh://gitolite.kernel.org/.../mkl/linux-can
Dmitry Safonov (2):
netlink: Do not subscribe to non-existent groups
netlink: Don't shift with UB on nlk->ngroups
Eric Dumazet (1):
xfrm_user: prevent leaking 2 bytes of kernel memory
Eugeniy Paltsev (1):
NET: stmmac: align DMA stuff to largest cache line length
Eyal Birger (1):
vti6: fix PMTU caching and reporting on xmit
Florian Westphal (1):
xfrm: free skb if nlsk pointer is NULL
Gal Pressman (1):
net: ena: Fix use of uninitialized DMA address bits field
Govindarajulu Varadarajan (1):
enic: handle mtu change for vf properly
Jakub Kicinski (1):
netdevsim: don't leak devlink resources
Jeremy Cline (2):
net: socket: fix potential spectre v1 gadget in socketcall
net: socket: Fix potential spectre v1 gadget in sock_is_registered
John Hurley (1):
nfp: flower: fix port metadata conversion bug
Justin Pettit (1):
openvswitch: meter: Fix setting meter id for new entries
Lawrence Brakmo (1):
tcp: ack immediately when a cwr packet arrives
Lorenzo Bianconi (1):
ipv4: remove BUG_ON() from fib_compute_spec_dst
Martin KaFai Lau (5):
bpf: btf: Ensure the member->offset is in the right order
bpf: btf: Sync uapi btf.h to tools
bpf: Replace [u]int32_t and [u]int64_t in libbpf
bpf: Introduce BPF_ANNOTATE_KV_PAIR
bpf: btf: Use exact btf value_size match in map_check_btf()
Neal Cardwell (1):
tcp_bbr: fix bw probing to raise in-flight data for very small BDPs
Sabrina Dubroca (1):
net/ipv6: fix metrics leak
Stefan Wahren (1):
net: lan78xx: fix rx handling before first packet is send
Taehee Yoo (2):
xdp: add NULL pointer check in __xdp_return()
bpf: use GFP_ATOMIC instead of GFP_KERNEL in bpf_parse_prog()
Tariq Toukan (1):
net: rollback orig value on failure of dev_qdisc_change_tx_queue_len
Thomas Richter (1):
perf build: Build error in libbpf missing initialization
Tommi Rantala (1):
xfrm: fix missing dst_release() after policy blocking lbcast and multicast
Toshiaki Makita (1):
virtio_net: Fix incosistent received bytes counter
Wang YanQing (1):
bpf, x32: Fix regression caused by commit 24dea04767e6
Wei Yongjun (1):
net: igmp: make function __ip_mc_inc_group() static
Xiao Liang (1):
xen-netfront: wait xenbus state change when load module manually
Zhen Lei (1):
esp6: fix memleak on error path in esp6_input
dann frazier (1):
hinic: Link the logical network device to the pci device in sysfs
tangpengpeng (1):
net: fix amd-xgbe flow-control issue
arch/x86/net/bpf_jit_comp32.c | 8 +++---
drivers/net/can/usb/ems_usb.c | 1 +
drivers/net/ethernet/amazon/ena/ena_com.c | 1 +
drivers/net/ethernet/amd/xgbe/xgbe-mdio.c | 4 +--
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 2 ++
drivers/net/ethernet/cisco/enic/enic_main.c | 78 ++++++++++++++++++--------------------------------
drivers/net/ethernet/huawei/hinic/hinic_main.c | 1 +
drivers/net/ethernet/netronome/nfp/flower/main.c | 4 ++-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
drivers/net/netdevsim/devlink.c | 1 +
drivers/net/phy/mdio-mux-bcm-iproc.c | 2 +-
drivers/net/usb/lan78xx.c | 2 ++
drivers/net/virtio_net.c | 41 ++++++++++++++------------
drivers/net/xen-netfront.c | 6 ++++
kernel/bpf/arraymap.c | 2 +-
kernel/bpf/btf.c | 14 ++++++++-
net/core/dev.c | 17 ++++++-----
net/core/filter.c | 12 ++++----
net/core/lwt_bpf.c | 2 +-
net/core/xdp.c | 3 +-
net/ipv4/fib_frontend.c | 4 +--
net/ipv4/igmp.c | 3 +-
net/ipv4/tcp_bbr.c | 4 +++
net/ipv4/tcp_input.c | 9 +++++-
net/ipv6/esp6.c | 4 ++-
net/ipv6/ip6_fib.c | 18 +++++++++---
net/ipv6/ip6_vti.c | 11 +++----
net/netlink/af_netlink.c | 5 ++++
net/openvswitch/meter.c | 10 +++----
net/rds/ib_frmr.c | 5 ++++
net/rds/ib_mr.h | 3 +-
net/rds/ib_rdma.c | 21 ++++++++------
net/rds/rdma.c | 13 +++++----
net/rds/rds.h | 5 +++-
net/rds/send.c | 12 ++++----
net/socket.c | 5 +++-
net/xdp/xsk_queue.h | 2 +-
net/xfrm/xfrm_policy.c | 3 ++
net/xfrm/xfrm_user.c | 18 +++++++-----
tools/include/uapi/linux/btf.h | 2 +-
tools/lib/bpf/btf.c | 39 ++++++++++++-------------
tools/lib/bpf/btf.h | 10 ++++---
tools/lib/bpf/libbpf.c | 87 +++++++++++++++++++++++++++++--------------------------
tools/lib/bpf/libbpf.h | 4 +--
tools/testing/selftests/bpf/bpf_helpers.h | 9 ++++++
tools/testing/selftests/bpf/test_btf.c | 114 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
tools/testing/selftests/bpf/test_btf_haskv.c | 7 ++---
47 files changed, 412 insertions(+), 218 deletions(-)
^ permalink raw reply
* Re: [patch net-next] net: sched: don't dump chains only held by actions
From: Cong Wang @ 2018-07-30 18:19 UTC (permalink / raw)
To: Jiri Pirko
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
Jakub Kicinski, mlxsw
In-Reply-To: <20180729075146.GA2260@nanopsycho.orion>
On Sun, Jul 29, 2018 at 12:54 AM Jiri Pirko <jiri@resnulli.us> wrote:
>
> Sat, Jul 28, 2018 at 07:39:36PM CEST, xiyou.wangcong@gmail.com wrote:
> >On Sat, Jul 28, 2018 at 10:20 AM Cong Wang <xiyou.wangcong@gmail.com> wrote:
> >>
> >> On Fri, Jul 27, 2018 at 12:47 AM Jiri Pirko <jiri@resnulli.us> wrote:
> >> >
> >> > From: Jiri Pirko <jiri@mellanox.com>
> >> >
> >> > In case a chain is empty and not explicitly created by a user,
> >> > such chain should not exist. The only exception is if there is
> >> > an action "goto chain" pointing to it. In that case, don't show the
> >> > chain in the dump. Track the chain references held by actions and
> >> > use them to find out if a chain should or should not be shown
> >> > in chain dump.
> >> >
> >> > Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> >>
> >> Looks reasonable to me.
> >>
> >> Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
> >
> >Hold on...
> >
> >If you increase the refcnt for a zombie chain on NEWCHAIN path,
> >then it would become a non-zombie, this makes sense. However,
> >if the action_refcnt gets increased again when another action uses it,
> >it become a zombie again because refcnt==action_refcnt??
>
> No. action always increases both refcnt and action_refcnt
Hmm, then the name zombie is confusing, with your definition all
chains implicitly created by actions are zombies, unless touched
by user explicitly. Please find a better name.
Also, tcf_chain_get_by_act() could send out RTM_NEWCHAIN too,
which is confusing too as it is still a "zombie".
^ permalink raw reply
* Re: [PATCH] netlink: Don't shift with UB on nlk->ngroups
From: David Miller @ 2018-07-30 19:43 UTC (permalink / raw)
To: dima
Cc: linux-kernel, rong.a.chen, 0x7f454c46, herbert, steffen.klassert,
netdev
In-Reply-To: <20180730173236.20968-1-dima@arista.com>
From: Dmitry Safonov <dima@arista.com>
Date: Mon, 30 Jul 2018 18:32:36 +0100
> On i386 nlk->ngroups might be 32 or 0. Which leads to UB, resulting in
> hang during boot.
> Check for 0 ngroups and use (unsigned long long) as a type to shift.
>
> Fixes: commit 7acf9d4237c46894e0fa0492dd96314a41742e84 ("netlink: Do not
> subscribe to non-existent groups").
Please, in the future, format your Fixes: tag correctly. No need
to say the work "commit", please do not chop up the line no matter
how long it is, and please provide 12 digits of SHA1_ID value, rather
than the whole thing.
> Reported-by: kernel test robot <rong.a.chen@intel.com>
> Signed-off-by: Dmitry Safonov <dima@arista.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH 00/18] xfrm: Add compat layer
From: Florian Westphal @ 2018-07-30 19:43 UTC (permalink / raw)
To: Dmitry Safonov
Cc: David Miller, nharold, fw, steffen.klassert, linux-kernel,
herbert, 0x7f454c46, netdev, luto, ard.biesheuvel, hpa, mingo,
john.stultz, kirill.shutemov, oleg, sboyd, rostedt, tglx, x86,
linux-efi, akpm, gregkh, mchehab+samsung, shuah, linux-kselftest,
eparis, kadlec, pablo, paul, coreteam, linux-audit,
netfilter-devel, fan.du
In-Reply-To: <1532972360.2679.32.camel@arista.com>
Dmitry Safonov <dima@arista.com> wrote:
> On Sat, 2018-07-28 at 14:18 -0700, David Miller wrote:
> > From: Dmitry Safonov <dima@arista.com>
> > Date: Sat, 28 Jul 2018 17:26:55 +0100
> >
> > > Well, I think, I'll rework my patches set according to critics and
> > > separate compat xfrm layer. I've already a selftest to check that
> > 32/64
> > > bit xfrm works - so the most time-taking part is done.
> >
> > The way you've done the compat structures using __packed is only
> > going
> > to work on x86, just FYI.
>
> Thanks for pointing, so I'll probably cover it under something like
> HAS_COMPAT_XFRM.
> (if there isn't any better idea).
You can do that, I suspect you can use
CONFIG_COMPAT_FOR_U64_ALIGNMENT
as AFAICR the only reason for the compat problem is different alignment
requirements of 64bit integer types in the structs, not e.g. due to
"long" size differences.
Instead of __packed, you can use the "compat" data types, e.g.
compat_u64 instead of u64:
struct compat_xfrm_lifetime_cur {
compat_u64 bytes, packets, add_time, use_time;
}; /* same size on i386, but only 4 byte alignment required even on x86_64*/
You might be able to reuse
https://git.breakpoint.cc/cgit/fw/net-next.git/commit/?h=xfrm_config_compat_07&id=f64430e6d9e297f3990f485a4832e273751b9869
in your patch set.
I can try to submit the first few patches (which are not related to
compat, they just add const qualifiers) for inclusion later this week.
^ permalink raw reply
* Re: [RFC PATCH net-next v2 10/17] ethtool: implement GET_SETTINGS message
From: Michal Kubecek @ 2018-07-30 19:42 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, linux-kernel, Jiri Pirko, David Miller, Florian Fainelli,
Roopa Prabhu, Jakub Kicinski, John W. Linville
In-Reply-To: <20180730190941.GL2983@lunn.ch>
On Mon, Jul 30, 2018 at 09:09:41PM +0200, Andrew Lunn wrote:
> > +Response contents:
> > +
> > + ETHA_SETTINGS_LINK (u32) link state
>
> > + [ETHA_SETTINGS_LINK] = { .type = NLA_FLAG },
>
> Is this correct?
NLA_FLAG is wrong, we need three states: on/off/unknown for "get"
replies and on/off/keep for "set" requests.
> The link is either up or down. So a u32 seems a bit big.
I tend to use u32 everywhere with some obvious exceptions. The reason is
that netlink attributes are padded to 32 bits so that no matter if you
use u8, u16 or u32, the attribute still ends up taking 8 bytes. But yes,
this looks like an obvious exception where u8 wouldn't mean any risk of
running out of values one day.
Michal Kubecek
^ permalink raw reply
* Re: [PATCH v4 net-next] hv_netvsc: Add per-cpu ethtool stats for netvsc
From: David Miller @ 2018-07-30 19:34 UTC (permalink / raw)
To: yidren, yidren
Cc: kys, haiyangz, sthemmin, devel, netdev, linux-kernel, madhans
In-Reply-To: <20180730170945.20517-1-yidren@linuxonhyperv.com>
From: Yidong Ren <yidren@linuxonhyperv.com>
Date: Mon, 30 Jul 2018 17:09:45 +0000
> From: Yidong Ren <yidren@microsoft.com>
>
> This patch implements following ethtool stats fields for netvsc:
> cpu<n>_tx/rx_packets/bytes
> cpu<n>_vf_tx/rx_packets/bytes
>
> Corresponding per-cpu counters already exist in current code. Exposing
> these counters will help troubleshooting performance issues.
>
> for_each_present_cpu() was used instead of for_each_possible_cpu().
> for_each_possible_cpu() would create very long and useless output.
> It is still being used for internal buffer, but not for ethtool
> output.
>
> There could be an overflow if cpu was added between ethtool
> call netvsc_get_sset_count() and netvsc_get_ethtool_stats() and
> netvsc_get_strings(). (still safe if cpu was removed)
> ethtool makes these three function calls separately.
> As long as we use ethtool, I can't see any clean solution.
>
> Currently and in foreseeable short term, Hyper-V doesn't support
> cpu hot-plug. Plus, ethtool is for admin use. Unlikely the admin
> would perform such combo operations.
>
> Signed-off-by: Yidong Ren <yidren@microsoft.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] ath6kl: remove redundant variables netlen, orig_buf, orig_len, dropped and stats
From: Kalle Valo @ 2018-07-30 17:57 UTC (permalink / raw)
To: Colin King
Cc: David S . Miller, linux-wireless, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20180709131720.6668-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> Variables netlen, orig_buf, orig_len, dropped and stats are assigned values
> but are never used hence they are redundant and can be removed.
>
> Cleans up clang warnings:
> warning: variable 'netlen' set but not used [-Wunused-but-set-variable]
> warning: variable 'orig_buf' set but not used [-Wunused-but-set-variable]
> warning: variable 'orig_len' set but not used [-Wunused-but-set-variable]
> warning: variable 'dropped' set but not used [-Wunused-but-set-variable]
> warning: variable 'stats' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
619c9700a8fe ath6kl: remove redundant variables netlen, orig_buf, orig_len, dropped and stats
--
https://patchwork.kernel.org/patch/10514565/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: remove redundant pointers 'dev' and 'noa'
From: Kalle Valo @ 2018-07-30 17:54 UTC (permalink / raw)
To: Colin King
Cc: David S . Miller, ath10k, linux-wireless, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20180709123446.14796-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> Pointers dev and noa are being assigned but are never used hence they
> are redundant and can be removed.
>
> Cleans up clang warnings:
> warning: variable 'dev' set but not used [-Wunused-but-set-variable]
> warning: variable 'noa' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
e6712aa1244f ath10k: remove redundant pointers 'dev' and 'noa'
--
https://patchwork.kernel.org/patch/10514521/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ipvs: don't show negative times in ip_vs_conn
From: Matteo Croce @ 2018-07-30 17:49 UTC (permalink / raw)
To: eric.dumazet
Cc: Wensong Zhang, Simon Horman, Julian Anastasov, lvs-devel, netdev,
Jozsef Kadlecsik, Pablo Neira Ayuso, Florian Westphal,
netfilter-devel
In-Reply-To: <ff823fec-0c37-80f9-9bcf-515357c5209a@gmail.com>
On Fri, Jul 20, 2018 at 4:19 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
> On 07/20/2018 08:19 AM, Matteo Croce wrote:
> > Since commit 500462a9de65 ("timers: Switch to a non-cascading wheel"),
> > timers duration can last even 12.5% more than the scheduled interval.
> >
> > 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..c78c48a6d53f 100644
> > --- a/net/netfilter/ipvs/ip_vs_conn.c
> > +++ b/net/netfilter/ipvs/ip_vs_conn.c
> > @@ -1066,6 +1066,12 @@ static void ip_vs_conn_seq_stop(struct seq_file *seq, void *v)
> > rcu_read_unlock();
> > }
> >
> > +static unsigned int time_left(unsigned long time)
> > +{
> > + return time_is_after_jiffies(time) ?
> > + jiffies_to_msecs(time - jiffies) / 1000 : 0;
> > +}
>
>
> I would suggest adding jiffies_delta_to_msecs(), because we will need elsewhere,
> like in inet_sk_diag_fill()
>
>
> diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h
> index a27cf66523279c1a5d4aaa0d0087f1e9d48d170f..fa928242567db30769839ac8738be5dc58e372ab 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);
>
Hi Eric,
What about a function which returns directly the delta from a
timestamp, and 0 if elapsed?
So we can rely on time_is_after_jiffies() for overflows, it should be
less error prone.
static unsigned int jiffies_delta_to_msecs(unsigned long time)
{
return time_is_after_jiffies(time) ?
jiffies_to_msecs(time - jiffies) / 1000 : 0;
}
^ permalink raw reply
* [net-next PATCH] mlx5: handle DMA mapping error case for XDP redirect
From: Jesper Dangaard Brouer @ 2018-07-30 17:49 UTC (permalink / raw)
To: Saeed Mahameed, Tariq Toukan; +Cc: netdev, eugenia, Jesper Dangaard Brouer
In-Reply-To: <20180730182025.602089a9@redhat.com>
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>
---
drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c b/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
index bab8cd44d1c5..1881468dbcfa 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
@@ -283,6 +283,7 @@ int mlx5e_xdp_xmit(struct net_device *dev, int n, struct xdp_frame **frames,
xdpi.dma_addr = dma_map_single(sq->pdev, xdpf->data, xdpf->len,
DMA_TO_DEVICE);
if (unlikely(dma_mapping_error(sq->pdev, xdpi.dma_addr))) {
+ xdp_return_frame_rx_napi(xdpf);
drops++;
continue;
}
@@ -290,6 +291,8 @@ int mlx5e_xdp_xmit(struct net_device *dev, int n, struct xdp_frame **frames,
xdpi.xdpf = xdpf;
if (unlikely(!mlx5e_xmit_xdp_frame(sq, &xdpi))) {
+ dma_unmap_single(sq->pdev, xdpi.dma_addr,
+ xdpf->len, DMA_TO_DEVICE);
xdp_return_frame_rx_napi(xdpf);
drops++;
}
^ permalink raw reply related
* Re: [PATCH 00/18] xfrm: Add compat layer
From: Dmitry Safonov @ 2018-07-30 17:39 UTC (permalink / raw)
To: David Miller
Cc: nharold, fw, steffen.klassert, linux-kernel, herbert, 0x7f454c46,
netdev, luto, ard.biesheuvel, hpa, mingo, john.stultz,
kirill.shutemov, oleg, sboyd, rostedt, tglx, x86, linux-efi, akpm,
gregkh, mchehab+samsung, shuah, linux-kselftest, eparis, kadlec,
pablo, paul, coreteam, linux-audit, netfilter-devel, fan.du
In-Reply-To: <20180728.141812.1026007723536955024.davem@davemloft.net>
On Sat, 2018-07-28 at 14:18 -0700, David Miller wrote:
> From: Dmitry Safonov <dima@arista.com>
> Date: Sat, 28 Jul 2018 17:26:55 +0100
>
> > Well, I think, I'll rework my patches set according to critics and
> > separate compat xfrm layer. I've already a selftest to check that
> 32/64
> > bit xfrm works - so the most time-taking part is done.
>
> The way you've done the compat structures using __packed is only
> going
> to work on x86, just FYI.
Thanks for pointing, so I'll probably cover it under something like
HAS_COMPAT_XFRM.
(if there isn't any better idea).
> The "32-bit alignment for 64-bit objects" thing x86 has is very much
> not universal amongst ABIs having 32-bit and 64-bit variants.
--
Thanks,
Dmitry
^ 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