* Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()
From: Linus Torvalds @ 2018-03-18 21:33 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Kees Cook, Al Viro, Florian Weimer, Andrew Morton, Josh Poimboeuf,
Randy Dunlap, Miguel Ojeda, Ingo Molnar, David Laight, Ian Abbott,
linux-input, linux-btrfs, Network Development,
Linux Kernel Mailing List, Kernel Hardening
In-Reply-To: <42b4342b-aefc-a16a-0d43-9f9c0d63ba7a@rasmusvillemoes.dk>
On Sun, Mar 18, 2018 at 2:13 PM, Rasmus Villemoes
<linux@rasmusvillemoes.dk> wrote:
> On 2018-03-17 19:52, Linus Torvalds wrote:
>>
>> Ok, so it really looks like that same "__builtin_constant_p() doesn't
>> return a constant".
>>
>> Which is really odd, but there you have it.
>
> Not really. We do rely on builtin_constant_p not being folded too
> quickly to a 0/1 answer, so that gcc still generates good code even if
> the argument is only known to be constant at a late(r) optimization
> stage (through inlining and all).
Hmm. That makes sense. It just doesn't work for our case when we
really want to choose the expression based on side effects or not.
> So unlike types_compatible_p, which
> can obviously be answered early during parsing, builtin_constant_p is
> most of the time a yes/no/maybe/it's complicated thing.
The silly thing is, the thing we *really* want to know _is_ actually
easily accessible during the early parsing, exactly like
__builtin_compatible_p(): it's not really that we care about the
expressions being constant, as much as the "can this have side
effects" question.
We only really use __builtin_constant_p() as a (bad) approximation of
that in this case, since it's the best we can do.
So the real use would be to say "can we use the simple direct macro
that just happens to also fold into a nice integer constant
expression" for __builtin_choose_expr().
I tried to find something like that, but it really doesn't exist, even
though I would actually have expected it to be a somewhat common
concern for macro writers: write a macro that works in any arbitrary
environment.
I guess array sizes are really the only true limiting environment
(static initializers is another one).
How annoying. Odd that newer gcc's seem to do so much better (ie gcc-5
seems to be fine). So _something_ must have changed.
Linus
^ permalink raw reply
* Re: [PATCH net] net: fec: Fix unbalanced PM runtime calls
From: Florian Fainelli @ 2018-03-18 21:42 UTC (permalink / raw)
To: David Miller; +Cc: netdev, andrew, l.stach, fugang.duan, linux-kernel
In-Reply-To: <20180318.163501.2001276876693998811.davem@davemloft.net>
On 03/18/2018 01:35 PM, David Miller wrote:
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Sun, 18 Mar 2018 12:49:51 -0700
>
>> When unbinding/removing the driver, we will run into the following warnings:
>>
>> [ 259.655198] fec 400d1000.ethernet: 400d1000.ethernet supply phy not found, using dummy regulator
>> [ 259.665065] fec 400d1000.ethernet: Unbalanced pm_runtime_enable!
>> [ 259.672770] fec 400d1000.ethernet (unnamed net_device) (uninitialized): Invalid MAC address: 00:00:00:00:00:00
>> [ 259.683062] fec 400d1000.ethernet (unnamed net_device) (uninitialized): Using random MAC address: f2:3e:93:b7:29:c1
>> [ 259.696239] libphy: fec_enet_mii_bus: probed
>>
>> Avoid these warnings by balancing the runtime PM calls during fec_drv_remove().
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>
> Applied, thank you.
>
> Queue this up for -stable?
I would be inclined to say yes, it was not exactly easy to track down a
set of commits, since this was changed quite a bit.
--
Florian
^ permalink raw reply
* Re: [PATCH v2 14/21] mtd: Remove depends on HAS_DMA in case of platform dependency
From: Boris Brezillon @ 2018-03-18 22:04 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Ulf Hansson, Wolfram Sang, linux-iio, linux-fpga,
linux-remoteproc, alsa-devel, Bjorn Andersson, Eric Anholt,
netdev, linux-mtd, linux-i2c, linux1394-devel, Christoph Hellwig,
Marek Szyprowski, Stefan Wahren, Boris Brezillon,
James E . J . Bottomley, Herbert Xu, linux-scsi,
Richard Weinberger, Joerg Roedel, Jassi Brar, Marek Vasut,
linux-serial, Matias Bjorling
In-Reply-To: <1521208314-4783-15-git-send-email-geert@linux-m68k.org>
Hi Geert,
On Fri, 16 Mar 2018 14:51:47 +0100
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
> In most cases this other symbol is an architecture or platform specific
> symbol, or PCI.
>
> Generic symbols and drivers without platform dependencies keep their
> dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
> cannot work anyway.
>
> This simplifies the dependencies, and allows to improve compile-testing.
>
Don't know which release you're targeting but it's likely to conflict
with the change I have in my nand/next branch. Is this a problem if I
take this patch through the mtd tree after [1] has reached Linus' tree?
Regards,
Boris
[1]https://lkml.org/lkml/2018/3/16/435
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Reviewed-by: Mark Brown <broonie@kernel.org>
> Acked-by: Robin Murphy <robin.murphy@arm.com>
> ---
> v2:
> - Add Reviewed-by, Acked-by,
> - Drop RFC state,
> - Drop new dependency of MTD_NAND_MARVELL on HAS_DMA,
> - Split per subsystem.
> ---
> drivers/mtd/nand/Kconfig | 8 ++------
> drivers/mtd/spi-nor/Kconfig | 2 +-
> 2 files changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index 736ac887303c88ba..55a2f8a2fa90cd87 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -46,7 +46,7 @@ config MTD_NAND_DENALI
> config MTD_NAND_DENALI_PCI
> tristate "Support Denali NAND controller on Intel Moorestown"
> select MTD_NAND_DENALI
> - depends on HAS_DMA && PCI
> + depends on PCI
> help
> Enable the driver for NAND flash on Intel Moorestown, using the
> Denali NAND controller core.
> @@ -184,7 +184,6 @@ config MTD_NAND_S3C2410_CLKSTOP
> config MTD_NAND_TANGO
> tristate "NAND Flash support for Tango chips"
> depends on ARCH_TANGO || COMPILE_TEST
> - depends on HAS_DMA
> help
> Enables the NAND Flash controller on Tango chips.
>
> @@ -328,7 +327,7 @@ config MTD_NAND_MARVELL
> tristate "NAND controller support on Marvell boards"
> depends on PXA3xx || ARCH_MMP || PLAT_ORION || ARCH_MVEBU || \
> COMPILE_TEST
> - depends on HAS_IOMEM && HAS_DMA
> + depends on HAS_IOMEM
> help
> This enables the NAND flash controller driver for Marvell boards,
> including:
> @@ -490,7 +489,6 @@ config MTD_NAND_SH_FLCTL
> tristate "Support for NAND on Renesas SuperH FLCTL"
> depends on SUPERH || COMPILE_TEST
> depends on HAS_IOMEM
> - depends on HAS_DMA
> help
> Several Renesas SuperH CPU has FLCTL. This option enables support
> for NAND Flash using FLCTL.
> @@ -558,7 +556,6 @@ config MTD_NAND_SUNXI
> config MTD_NAND_HISI504
> tristate "Support for NAND controller on Hisilicon SoC Hip04"
> depends on ARCH_HISI || COMPILE_TEST
> - depends on HAS_DMA
> help
> Enables support for NAND controller on Hisilicon SoC Hip04.
>
> @@ -572,7 +569,6 @@ config MTD_NAND_QCOM
> config MTD_NAND_MTK
> tristate "Support for NAND controller on MTK SoCs"
> depends on ARCH_MEDIATEK || COMPILE_TEST
> - depends on HAS_DMA
> help
> Enables support for NAND controller on MTK SoCs.
> This controller is found on mt27xx, mt81xx, mt65xx SoCs.
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
> index 89da88e591215db1..c493b8230a38c059 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -71,7 +71,7 @@ config SPI_FSL_QUADSPI
> config SPI_HISI_SFC
> tristate "Hisilicon SPI-NOR Flash Controller(SFC)"
> depends on ARCH_HISI || COMPILE_TEST
> - depends on HAS_IOMEM && HAS_DMA
> + depends on HAS_IOMEM
> help
> This enables support for hisilicon SPI-NOR flash controller.
>
--
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 16/21] remoteproc: Remove depends on HAS_DMA in case of platform dependency
From: Bjorn Andersson @ 2018-03-18 22:36 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Ulf Hansson, Wolfram Sang, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-fpga-u79uwXL29TY76Z2rM5mHXA,
linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Eric Anholt,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux1394-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Christoph Hellwig, Stefan Wahren, Boris Brezillon,
James E . J . Bottomley, Herbert Xu,
linux-scsi-u79uwXL29TY76Z2rM5mHXA, Richard Weinberger, Jassi Brar,
Marek Vasut, linux-serial-u79uwXL29TY76Z2rM5mHXA, Matias Bjorling,
David Woodhouse, linux-media-u79uwXL29TY76Z2rM5mHXA,
Ohad Ben-Cohen <
In-Reply-To: <1521208314-4783-17-git-send-email-geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
On Fri 16 Mar 06:51 PDT 2018, Geert Uytterhoeven wrote:
> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
> In most cases this other symbol is an architecture or platform specific
> symbol, or PCI.
>
> Generic symbols and drivers without platform dependencies keep their
> dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
> cannot work anyway.
>
> This simplifies the dependencies, and allows to improve compile-testing.
>
> Signed-off-by: Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
> Reviewed-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Acked-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
Acked-by: Bjorn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Regards,
Bjorn
> ---
> v2:
> - Add Reviewed-by, Acked-by,
> - Drop RFC state,
> - Split per subsystem.
> ---
> drivers/remoteproc/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index b609e1d3654ba65f..b60d8132113de0f7 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -23,7 +23,6 @@ config IMX_REMOTEPROC
>
> config OMAP_REMOTEPROC
> tristate "OMAP remoteproc support"
> - depends on HAS_DMA
> depends on ARCH_OMAP4 || SOC_OMAP5
> depends on OMAP_IOMMU
> select MAILBOX
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH net-next 2/5] cxgb4: Add support to initialise/read SRQ entries
From: Stefano Brivio @ 2018-03-18 22:37 UTC (permalink / raw)
To: Raju Rangoju
Cc: netdev, davem, nirranjan, indranil, venkatesh, swise, bharat,
Ganesh Goudar
In-Reply-To: <20180317072229.21211-3-rajur@chelsio.com>
On Sat, 17 Mar 2018 12:52:26 +0530
Raju Rangoju <rajur@chelsio.com> wrote:
> +struct srq_data *t4_init_srq(int srq_size)
> +{
> + struct srq_data *s;
> +
> + s = kzalloc(sizeof(*s), GFP_KERNEL | __GFP_NOWARN);
> + if (!s)
> + s = vzalloc(sizeof(*s));
> + if (!s)
> + return NULL;
I guess you could use kvzalloc() here.
> [...]
>
> +++ b/drivers/net/ethernet/chelsio/cxgb4/srq.h
>
> [...]
>
> +enum {
> + SRQ_WAIT_TO = (HZ * 5),
> +};
Why not #define? Am I missing something?
--
Stefano
^ permalink raw reply
* Re: [PATCH v11 crypto 06/12] crypto: chtls - structure and macro for Inline TLS
From: Sabrina Dubroca @ 2018-03-18 22:53 UTC (permalink / raw)
To: Atul Gupta
Cc: davejwatson, davem, herbert, sbrivio, linux-crypto, netdev,
ganeshgr
In-Reply-To: <1521214661-28928-6-git-send-email-atul.gupta@chelsio.com>
2018-03-16, 21:07:35 +0530, Atul Gupta wrote:
[...]
> +#define SOCK_INLINE (31)
[...]
> +static inline int csk_flag(const struct sock *sk, enum csk_flags flag)
> +{
> + struct chtls_sock *csk = rcu_dereference_sk_user_data(sk);
> +
> + if (!sock_flag(sk, SOCK_INLINE))
> + return 0;
> + return test_bit(flag, &csk->flags);
> +}
Should drivers really start defining their own socket flags?
> +static inline void set_queue(struct sk_buff *skb,
> + unsigned int queue, const struct sock *sk)
> +{
> + skb->queue_mapping = queue;
> +}
That's skb_set_queue_mapping(), no need to define your own.
--
Sabrina
^ permalink raw reply
* Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()
From: Rasmus Villemoes @ 2018-03-18 22:59 UTC (permalink / raw)
To: Linus Torvalds, Rasmus Villemoes
Cc: Kees Cook, Al Viro, Florian Weimer, Andrew Morton, Josh Poimboeuf,
Randy Dunlap, Miguel Ojeda, Ingo Molnar, David Laight, Ian Abbott,
linux-input, linux-btrfs, Network Development,
Linux Kernel Mailing List, Kernel Hardening
In-Reply-To: <CA+55aFwFoTapX2niPiaET5kg7K85qxhav1_PoDDxY0o_VRA5Ag@mail.gmail.com>
On 2018-03-18 22:33, Linus Torvalds wrote:
> On Sun, Mar 18, 2018 at 2:13 PM, Rasmus Villemoes
> <linux@rasmusvillemoes.dk> wrote:
>> On 2018-03-17 19:52, Linus Torvalds wrote:
>>>
>>> Ok, so it really looks like that same "__builtin_constant_p() doesn't
>>> return a constant".
>>>
>>> Which is really odd, but there you have it.
>>
>> Not really. We do rely on builtin_constant_p not being folded too
>> quickly to a 0/1 answer, so that gcc still generates good code even if
>> the argument is only known to be constant at a late(r) optimization
>> stage (through inlining and all).
>
> Hmm. That makes sense. It just doesn't work for our case when we
> really want to choose the expression based on side effects or not.
>
>> So unlike types_compatible_p, which
>> can obviously be answered early during parsing, builtin_constant_p is
>> most of the time a yes/no/maybe/it's complicated thing.
>
> The silly thing is, the thing we *really* want to know _is_ actually
> easily accessible during the early parsing, exactly like
> __builtin_compatible_p(): it's not really that we care about the
> expressions being constant, as much as the "can this have side
> effects" question.
OK, I missed where this was made about side effects of x and y, but I
suppose the idea was to use
no_side_effects(x) && no_side_effects(y) ? trivial_max(x, y) :
old_max(x, y)
or the same thing spelled with b_c_e? Yes, I think that would work, if
we indeed had that way of checking an expression.
> We only really use __builtin_constant_p() as a (bad) approximation of
> that in this case, since it's the best we can do.
I don't think you should parenthesize bad, rather capitalize it. ({x++;
0;}) is constant in the eyes of __builtin_constant_p, but not
side-effect free. Sure, that's very contrived, but I can easily imagine
some max(f(foo), -1) call where f is sometimes an external function, but
for other .configs it's a static inline that always returns 0, but still
has some non-trivial side-effect before that. And this would all depend
on which optimizations gcc applies before it decides to evaluate
builtin_constant_p, so could be some fun debugging. Good thing that that
didn't work out...
> So the real use would be to say "can we use the simple direct macro
> that just happens to also fold into a nice integer constant
> expression" for __builtin_choose_expr().
>
> I tried to find something like that, but it really doesn't exist, even
> though I would actually have expected it to be a somewhat common
> concern for macro writers: write a macro that works in any arbitrary
> environment.
Yeah, I think the closest is a five year old suggestion
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57612) to add a
__builtin_assert_no_side_effects, that could be used in macros that for
some reason cannot be implemented without evaluating some argument
multiple times. It would be more useful to have the predicate version,
which one could always turn into a build bug version. But we have
neither, unfortunately.
Rasmus
^ permalink raw reply
* [PATCH v2] net: ethernet: arc: Fix a potential memory leak if an optional regulator is deferred
From: Christophe JAILLET @ 2018-03-18 22:59 UTC (permalink / raw)
To: heiko, branislav, davem
Cc: netdev, linux-arm-kernel, linux-rockchip, linux-kernel,
kernel-janitors, Christophe JAILLET
If the optional regulator is deferred, we must release some resources.
They will be re-allocated when the probe function will be called again.
Fixes: 6eacf31139bf ("ethernet: arc: Add support for Rockchip SoC layer device tree bindings")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
v2: v1 did not compile because of an erroneous variable name. s/ret/err/
---
drivers/net/ethernet/arc/emac_rockchip.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/arc/emac_rockchip.c b/drivers/net/ethernet/arc/emac_rockchip.c
index 16f9bee992fe..8ee9dfd0e363 100644
--- a/drivers/net/ethernet/arc/emac_rockchip.c
+++ b/drivers/net/ethernet/arc/emac_rockchip.c
@@ -169,8 +169,10 @@ static int emac_rockchip_probe(struct platform_device *pdev)
/* Optional regulator for PHY */
priv->regulator = devm_regulator_get_optional(dev, "phy");
if (IS_ERR(priv->regulator)) {
- if (PTR_ERR(priv->regulator) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
+ if (PTR_ERR(priv->regulator) == -EPROBE_DEFER) {
+ err = -EPROBE_DEFER;
+ goto out_clk_disable;
+ }
dev_err(dev, "no regulator found\n");
priv->regulator = NULL;
}
--
2.14.1
^ permalink raw reply related
* Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()
From: Linus Torvalds @ 2018-03-18 23:36 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Kees Cook, Al Viro, Florian Weimer, Andrew Morton, Josh Poimboeuf,
Randy Dunlap, Miguel Ojeda, Ingo Molnar, David Laight, Ian Abbott,
linux-input, linux-btrfs, Network Development,
Linux Kernel Mailing List, Kernel Hardening
In-Reply-To: <38b6da49-1138-017e-7307-f39ff067d6d2@rasmusvillemoes.dk>
On Sun, Mar 18, 2018 at 3:59 PM, Rasmus Villemoes
<linux@rasmusvillemoes.dk> wrote:
>
> OK, I missed where this was made about side effects of x and y
We never made it explicit, since all we really cared about in the end
is the constantness.
But yes:
> but I suppose the idea was to use
>
> no_side_effects(x) && no_side_effects(y) ? trivial_max(x, y) :
> old_max(x, y)
Exactly. Except with __builtin_choose_expr(), because we need the end
result to be seen as a integer constant expression, so that we can
then use it as an array size. So it needs that early parse-time
resolution.
>> We only really use __builtin_constant_p() as a (bad) approximation of
>> that in this case, since it's the best we can do.
>
> I don't think you should parenthesize bad, rather capitalize it. ({x++;
> 0;}) is constant in the eyes of __builtin_constant_p, but not
> side-effect free.
Hmm. Yeah, but probably don't much care for the kernel.
For example, we do things like this:
#define __swab64(x) \
(__builtin_constant_p((__u64)(x)) ? \
___constant_swab64(x) : \
__fswab64(x))
where that "___constant_swab64()" very much uses the same argument
over and over.
And we do that for related reasons - we really want to do the constant
folding at build time for some cases, and this was the only sane way
to do it. Eg code like
return (addr & htonl(0xff000000)) == htonl(0x7f000000);
wants to do the right thing, and long ago gcc didn't have builtins for
byte swapping, so we had to just do nasty horribly macros that DTRT
for constants.
But since the kernel is standalone, we don't need to really worry
about the *generic* case, we just need to worry about our own macros,
and if somebody does that example you show I guess we'll just have to
shun them ;)
Of course, our own macros are often macros from hell, exactly because
they often contain a lot of type-checking and/or type-(size)-based
polymorphism. But then we actually *want* gcc to simplify things, and
avoid side effects, just have potentially very complex expressions.
But we basically never have that kind of intentionally evil macros, so
we are willing to live with a bad substitute.
But yes, it would be better to have some more control over things, and
actually have a way to say "if X is a constant integer expression, do
transformation Y, otherwise call function y()".
Actually sparse started out with the idea in the background that it
could become not just a checker, but a "transformation tool". Partly
because of long gone historical issues (ie gcc people used to be very
anti-plugin due to licensing issues).
Of course, a more integrated and powerful preprocessor language is
almost always what we *really* wanted, but traditionally "powerful
preprocessor" has always meant "completely incomprehensible and badly
integrated preprocessor".
"cpp" may be a horrid language, but it's there and it's fast (when
integrated with the front-end, like everybody does now)
But sadly, cpp is really bad for the above kind of "if argument is
constant" kind of tricks. I suspect we'd use it a lot otherwise.
>> So the real use would be to say "can we use the simple direct macro
>> that just happens to also fold into a nice integer constant
>> expression" for __builtin_choose_expr().
>>
>> I tried to find something like that, but it really doesn't exist, even
>> though I would actually have expected it to be a somewhat common
>> concern for macro writers: write a macro that works in any arbitrary
>> environment.
>
> Yeah, I think the closest is a five year old suggestion
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57612) to add a
> __builtin_assert_no_side_effects, that could be used in macros that for
> some reason cannot be implemented without evaluating some argument
> multiple times. It would be more useful to have the predicate version,
> which one could always turn into a build bug version. But we have
> neither, unfortunately.
Yeah, and since we're in the situation that *new* gcc versions work
for us anyway, and we only have issues with older gcc's (that sadly
people still use), even if there was a new cool feature we couldn't
use it.
Oh well. Thanks for the background.
Linus
^ permalink raw reply
* [PATCH net 0/7] fix idr leak in actions
From: Davide Caratti @ 2018-03-19 0:06 UTC (permalink / raw)
To: Cong Wang, Jiri Pirko, Jamal Hadi Salim, David S. Miller; +Cc: netdev
This series fixes situations where a temporary failure to install a TC
action results in the permanent impossibility to reuse the configured
'index'.
Thanks to Cong Wang for the initial review.
Davide Caratti (7):
net/sched: fix idr leak on the error path of tcf_bpf_init()
net/sched: fix idr leak in the error path of tcf_simp_init()
net/sched: fix idr leak in the error path of tcf_act_police_init()
net/sched: fix idr leak in the error path of tcp_pedit_init()
net/sched: fix idr leak in the error path of __tcf_ipt_init()
net/sched: fix idr leak in the error path of tcf_vlan_init()
net/sched: fix idr leak in the error path of tcf_skbmod_init()
net/sched/act_bpf.c | 2 +-
net/sched/act_ipt.c | 9 ++++++---
net/sched/act_pedit.c | 2 +-
net/sched/act_police.c | 2 +-
net/sched/act_simple.c | 2 +-
net/sched/act_skbmod.c | 2 +-
net/sched/act_vlan.c | 2 +-
7 files changed, 12 insertions(+), 9 deletions(-)
--
2.14.3
^ permalink raw reply
* [PATCH net 1/7] net/sched: fix idr leak on the error path of tcf_bpf_init()
From: Davide Caratti @ 2018-03-19 0:06 UTC (permalink / raw)
To: Cong Wang, Jiri Pirko, Jamal Hadi Salim, David S. Miller; +Cc: netdev
In-Reply-To: <cover.1521417146.git.dcaratti@redhat.com>
when the following command sequence is entered
# tc action add action bpf bytecode '4,40 0 0 12,31 0 1 2048,6 0 0 262144,6 0 0 0' index 100
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
# tc action add action bpf bytecode '4,40 0 0 12,21 0 1 2048,6 0 0 262144,6 0 0 0' index 100
RTNETLINK answers: No space left on device
We have an error talking to the kernel
act_bpf correctly refuses to install the first TC rule, because 31 is not
a valid instruction. However, it refuses to install the second TC rule,
even if the BPF code is correct. Furthermore, it's no more possible to
install any other rule having the same value of 'index' until act_bpf
module is unloaded/inserted again. After the idr has been reserved, call
tcf_idr_release() instead of tcf_idr_cleanup(), to fix this issue.
Fixes: 65a206c01e8e ("net/sched: Change act_api and act_xxx modules to use IDR")
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
net/sched/act_bpf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/act_bpf.c b/net/sched/act_bpf.c
index b3f2c15affa7..9d2cabf1dc7e 100644
--- a/net/sched/act_bpf.c
+++ b/net/sched/act_bpf.c
@@ -352,7 +352,7 @@ static int tcf_bpf_init(struct net *net, struct nlattr *nla,
return res;
out:
if (res == ACT_P_CREATED)
- tcf_idr_cleanup(*act, est);
+ tcf_idr_release(*act, bind);
return ret;
}
--
2.14.3
^ permalink raw reply related
* [PATCH net 2/7] net/sched: fix idr leak in the error path of tcf_simp_init()
From: Davide Caratti @ 2018-03-19 0:06 UTC (permalink / raw)
To: Cong Wang, Jiri Pirko, Jamal Hadi Salim, David S. Miller; +Cc: netdev
In-Reply-To: <cover.1521417146.git.dcaratti@redhat.com>
if the kernel fails to duplicate 'sdata', creation of a new action fails
with -ENOMEM. However, subsequent attempts to install the same action
using the same value of 'index' systematically fail with -ENOSPC, and
that value of 'index' will no more be usable by act_simple, until rmmod /
insmod of act_simple.ko is done:
# tc actions add action simple sdata hello index 100
# tc actions list action simple
action order 0: Simple <hello>
index 100 ref 1 bind 0
# tc actions flush action simple
# tc actions add action simple sdata hello index 100
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
# tc actions flush action simple
# tc actions add action simple sdata hello index 100
RTNETLINK answers: No space left on device
We have an error talking to the kernel
# tc actions add action simple sdata hello index 100
RTNETLINK answers: No space left on device
We have an error talking to the kernel
...
Fix this in the error path of tcf_simp_init(), calling tcf_idr_release()
in place of tcf_idr_cleanup().
Fixes: 65a206c01e8e ("net/sched: Change act_api and act_xxx modules to use IDR")
Suggested-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
net/sched/act_simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/act_simple.c b/net/sched/act_simple.c
index 425eac11f6da..b1f38063ada0 100644
--- a/net/sched/act_simple.c
+++ b/net/sched/act_simple.c
@@ -121,7 +121,7 @@ static int tcf_simp_init(struct net *net, struct nlattr *nla,
d = to_defact(*a);
ret = alloc_defdata(d, defdata);
if (ret < 0) {
- tcf_idr_cleanup(*a, est);
+ tcf_idr_release(*a, bind);
return ret;
}
d->tcf_action = parm->action;
--
2.14.3
^ permalink raw reply related
* [PATCH net 3/7] net/sched: fix idr leak in the error path of tcf_act_police_init()
From: Davide Caratti @ 2018-03-19 0:06 UTC (permalink / raw)
To: Cong Wang, Jiri Pirko, Jamal Hadi Salim, David S. Miller; +Cc: netdev
In-Reply-To: <cover.1521417146.git.dcaratti@redhat.com>
tcf_act_police_init() can fail after the idr has been successfully
reserved (e.g., qdisc_get_rtab() may return NULL). When this happens,
subsequent attempts to configure a police rule using the same idr value
systematiclly fail with -ENOSPC:
# tc action add action police rate 1000 burst 1000 drop index 100
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
# tc action add action police rate 1000 burst 1000 drop index 100
RTNETLINK answers: No space left on device
We have an error talking to the kernel
# tc action add action police rate 1000 burst 1000 drop index 100
RTNETLINK answers: No space left on device
...
Fix this in the error path of tcf_act_police_init(), calling
tcf_idr_release() in place of tcf_idr_cleanup().
Fixes: 65a206c01e8e ("net/sched: Change act_api and act_xxx modules to use IDR")
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
net/sched/act_police.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/act_police.c b/net/sched/act_police.c
index 95d3c9097b25..faebf82b99f1 100644
--- a/net/sched/act_police.c
+++ b/net/sched/act_police.c
@@ -194,7 +194,7 @@ static int tcf_act_police_init(struct net *net, struct nlattr *nla,
qdisc_put_rtab(P_tab);
qdisc_put_rtab(R_tab);
if (ret == ACT_P_CREATED)
- tcf_idr_cleanup(*a, est);
+ tcf_idr_release(*a, bind);
return err;
}
--
2.14.3
^ permalink raw reply related
* [PATCH net 4/7] net/sched: fix idr leak in the error path of tcp_pedit_init()
From: Davide Caratti @ 2018-03-19 0:06 UTC (permalink / raw)
To: Cong Wang, Jiri Pirko, Jamal Hadi Salim, David S. Miller; +Cc: netdev
In-Reply-To: <cover.1521417146.git.dcaratti@redhat.com>
tcf_pedit_init() can fail to allocate 'keys' after the idr has been
successfully reserved. When this happens, subsequent attempts to configure
a pedit rule using the same idr value systematically fail with -ENOSPC:
# tc action add action pedit munge ip ttl set 63 index 100
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
# tc action add action pedit munge ip ttl set 63 index 100
RTNETLINK answers: No space left on device
We have an error talking to the kernel
# tc action add action pedit munge ip ttl set 63 index 100
RTNETLINK answers: No space left on device
We have an error talking to the kernel
...
Fix this in the error path of tcf_act_pedit_init(), calling
tcf_idr_release() in place of tcf_idr_cleanup().
Fixes: 65a206c01e8e ("net/sched: Change act_api and act_xxx modules to use IDR")
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
net/sched/act_pedit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/act_pedit.c b/net/sched/act_pedit.c
index 349beaffb29e..fef08835f26d 100644
--- a/net/sched/act_pedit.c
+++ b/net/sched/act_pedit.c
@@ -176,7 +176,7 @@ static int tcf_pedit_init(struct net *net, struct nlattr *nla,
p = to_pedit(*a);
keys = kmalloc(ksize, GFP_KERNEL);
if (keys == NULL) {
- tcf_idr_cleanup(*a, est);
+ tcf_idr_release(*a, bind);
kfree(keys_ex);
return -ENOMEM;
}
--
2.14.3
^ permalink raw reply related
* [PATCH net 5/7] net/sched: fix idr leak in the error path of __tcf_ipt_init()
From: Davide Caratti @ 2018-03-19 0:06 UTC (permalink / raw)
To: Cong Wang, Jiri Pirko, Jamal Hadi Salim, David S. Miller; +Cc: netdev
In-Reply-To: <cover.1521417146.git.dcaratti@redhat.com>
__tcf_ipt_init() can fail after the idr has been successfully reserved.
When this happens, subsequent attempts to configure xt/ipt rules using
the same idr value systematically fail with -ENOSPC:
# tc action add action xt -j LOG --log-prefix test1 index 100
tablename: mangle hook: NF_IP_POST_ROUTING
target: LOG level warning prefix "test1" index 100
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
Command "(null)" is unknown, try "tc actions help".
# tc action add action xt -j LOG --log-prefix test1 index 100
tablename: mangle hook: NF_IP_POST_ROUTING
target: LOG level warning prefix "test1" index 100
RTNETLINK answers: No space left on device
We have an error talking to the kernel
Command "(null)" is unknown, try "tc actions help".
# tc action add action xt -j LOG --log-prefix test1 index 100
tablename: mangle hook: NF_IP_POST_ROUTING
target: LOG level warning prefix "test1" index 100
RTNETLINK answers: No space left on device
We have an error talking to the kernel
...
Fix this in the error path of __tcf_ipt_init(), calling tcf_idr_release()
in place of tcf_idr_cleanup(). Since tcf_ipt_release() can now be called
when tcfi_t is NULL, we also need to protect calls to ipt_destroy_target()
to avoid NULL pointer dereference.
Fixes: 65a206c01e8e ("net/sched: Change act_api and act_xxx modules to use IDR")
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
net/sched/act_ipt.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/sched/act_ipt.c b/net/sched/act_ipt.c
index 06e380ae0928..71b618144803 100644
--- a/net/sched/act_ipt.c
+++ b/net/sched/act_ipt.c
@@ -80,9 +80,12 @@ static void ipt_destroy_target(struct xt_entry_target *t)
static void tcf_ipt_release(struct tc_action *a)
{
struct tcf_ipt *ipt = to_ipt(a);
- ipt_destroy_target(ipt->tcfi_t);
+
+ if (ipt->tfci_t) {
+ ipt_destroy_target(ipt->tcfi_t);
+ kfree(ipt->tcfi_t);
+ }
kfree(ipt->tcfi_tname);
- kfree(ipt->tcfi_t);
}
static const struct nla_policy ipt_policy[TCA_IPT_MAX + 1] = {
@@ -187,7 +190,7 @@ static int __tcf_ipt_init(struct net *net, unsigned int id, struct nlattr *nla,
kfree(tname);
err1:
if (ret == ACT_P_CREATED)
- tcf_idr_cleanup(*a, est);
+ tcf_idr_release(*a, bind);
return err;
}
--
2.14.3
^ permalink raw reply related
* [PATCH net 6/7] net/sched: fix idr leak in the error path of tcf_vlan_init()
From: Davide Caratti @ 2018-03-19 0:06 UTC (permalink / raw)
To: Cong Wang, Jiri Pirko, Jamal Hadi Salim, David S. Miller; +Cc: netdev
In-Reply-To: <cover.1521417146.git.dcaratti@redhat.com>
tcf_vlan_init() can fail after the idr has been successfully reserved.
When this happens, every subsequent attempt to configure vlan rules using
the same idr value will systematically fail with -ENOSPC, unless the first
attempt was done using the 'replace' keyword.
# tc action add action vlan pop index 100
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
# tc action add action vlan pop index 100
RTNETLINK answers: No space left on device
We have an error talking to the kernel
# tc action add action vlan pop index 100
RTNETLINK answers: No space left on device
We have an error talking to the kernel
...
Fix this in tcf_vlan_init(), ensuring that tcf_idr_release() is called on
the error path when the idr has been reserved, but not yet inserted. Also,
don't test 'ovr' in the error path, to avoid a 'replace' failure implicitly
become a 'delete' that leaks refcount in act_vlan module:
# rmmod act_vlan; modprobe act_vlan
# tc action add action vlan push id 5 index 100
# tc action replace action vlan push id 7 index 100
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
# tc action list action vlan
#
# rmmod act_vlan
# rmmod: ERROR: Module act_vlan is in use
Fixes: 4c5b9d9642c8 ("act_vlan: VLAN action rewrite to use RCU lock/unlock and update")
Fixes: 65a206c01e8e ("net/sched: Change act_api and act_xxx modules to use IDR")
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
net/sched/act_vlan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/act_vlan.c b/net/sched/act_vlan.c
index c2914e9a4a6f..c49cb61adedf 100644
--- a/net/sched/act_vlan.c
+++ b/net/sched/act_vlan.c
@@ -195,7 +195,7 @@ static int tcf_vlan_init(struct net *net, struct nlattr *nla,
ASSERT_RTNL();
p = kzalloc(sizeof(*p), GFP_KERNEL);
if (!p) {
- if (ovr)
+ if (ret == ACT_P_CREATED)
tcf_idr_release(*a, bind);
return -ENOMEM;
}
--
2.14.3
^ permalink raw reply related
* [PATCH net 7/7] net/sched: fix idr leak in the error path of tcf_skbmod_init()
From: Davide Caratti @ 2018-03-19 0:06 UTC (permalink / raw)
To: Cong Wang, Jiri Pirko, Jamal Hadi Salim, David S. Miller; +Cc: netdev
In-Reply-To: <cover.1521417146.git.dcaratti@redhat.com>
tcf_skbmod_init() can fail after the idr has been successfully reserved.
When this happens, every subsequent attempt to configure skbmod rules
using the same idr value will systematically fail with -ENOSPC, unless
the first attempt was done using the 'replace' keyword:
# tc action add action skbmod swap mac index 100
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
# tc action add action skbmod swap mac index 100
RTNETLINK answers: No space left on device
We have an error talking to the kernel
# tc action add action skbmod swap mac index 100
RTNETLINK answers: No space left on device
We have an error talking to the kernel
...
Fix this in tcf_skbmod_init(), ensuring that tcf_idr_release() is called
on the error path when the idr has been reserved, but not yet inserted.
Also, don't test 'ovr' in the error path, to avoid a 'replace' failure
implicitly become a 'delete' that leaks refcount in act_skbmod module:
# rmmod act_skbmod; modprobe act_skbmod
# tc action add action skbmod swap mac index 100
# tc action add action skbmod swap mac continue index 100
RTNETLINK answers: File exists
We have an error talking to the kernel
# tc action replace action skbmod swap mac continue index 100
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
# tc action list action skbmod
#
# rmmod act_skbmod
rmmod: ERROR: Module act_skbmod is in use
Fixes: 65a206c01e8e ("net/sched: Change act_api and act_xxx modules to use IDR")
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
net/sched/act_skbmod.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/act_skbmod.c b/net/sched/act_skbmod.c
index d09565d6433e..7b0700f52b50 100644
--- a/net/sched/act_skbmod.c
+++ b/net/sched/act_skbmod.c
@@ -152,7 +152,7 @@ static int tcf_skbmod_init(struct net *net, struct nlattr *nla,
ASSERT_RTNL();
p = kzalloc(sizeof(struct tcf_skbmod_params), GFP_KERNEL);
if (unlikely(!p)) {
- if (ovr)
+ if (ret == ACT_P_CREATED)
tcf_idr_release(*a, bind);
return -ENOMEM;
}
--
2.14.3
^ permalink raw reply related
* Re: [PATCH net-next 0/4] net: dsa: Plug in PHYLINK support
From: Florian Fainelli @ 2018-03-19 0:11 UTC (permalink / raw)
To: netdev
Cc: privat, andrew, vivien.didelot, davem, rmk+kernel, sean.wang,
Woojung.Huh, john, cphealy
In-Reply-To: <20180318185246.19311-1-f.fainelli@gmail.com>
On 03/18/2018 11:52 AM, Florian Fainelli wrote:
> Hi all,
>
> This patch series adds PHYLINK support to DSA which is necessary to support more
> complex PHY and pluggable modules setups.
>
> Patch series can be found here:
>
> https://github.com/ffainelli/linux/commits/dsa-phylink
>
> This was tested on:
>
> - dsa-loop
> - bcm_sf2
> - mv88e6xxx
> - b53
>
> With a variety of test cases:
> - internal & external MDIO PHYs
> - MoCA with link notification through interrupt/MMIO register
> - built-in PHYs
> - ifconfig up/down for several cycles works
> - bind/unbind of the drivers
>
> And everything should still work as expected. Please be aware of the following:
>
> - switch drivers (like bcm_sf2) which may have user-facing network ports using
> fixed links would need to implement phylink_mac_ops to remain functional.
> PHYLINK does not create a phy_device for fixed links, therefore our
> call to adjust_link() from phylink_mac_link_{up,down} would not be calling
> into the driver. This *should not* affect CPU/DSA ports which are configured
> through adjust_link() but have no network devices
>
> - support for SFP/SFF is now possible, but switch drivers will still need some
> modifications to properly support those, including, but not limited to using
> the correct binding information. This will be submitted on top of this series
>
> Russell, we could theoretically eliminate patch 3 and resolve this within DSA
> entirely by keeping a per-port phy_interface_t (we did that before), this is
> not a big change if we have to, let me know if you feel like this is cleaner. I
> was initially considering passing a phylink_link_state reference to
> mac_link_{up,down} but only a couple of fields are valid during link_down and
> ended up with passing the phy_interface_t value we need instead. This is
> necessary for switch drivers which have different types of port interfaces (see
> bcm_sf2 documentation in tree).
I think I will proceed differently for v2:
- introduce DSA phylink_mac_ops in dsa_switch_ops, such that drivers can
define those as preliminary commits, those won't be used by
net/dsa/slave.c just yet though
- have all relevant drivers implement phylink_mac_ops such that the
pluming is there and functional
- switch net/dsa/slave.c to using PHYLINK
That way, we should avoid any breakage in between and have an "atomic"
switch between PHYLIB and PHYLINK.
>
> Thank you!
>
> Florian Fainelli (4):
> net: dsa: Eliminate dsa_slave_get_link()
> net: phy: phylink: Provide PHY interface to mac_link_{up,down}
> net: dsa: Plug in PHYLINK support
> net: dsa: bcm_sf2: Implement phylink_mac_ops
>
> drivers/net/dsa/bcm_sf2.c | 190 +++++++++++++--------
> drivers/net/ethernet/marvell/mvneta.c | 4 +-
> drivers/net/phy/phylink.c | 6 +-
> include/linux/phylink.h | 10 +-
> include/net/dsa.h | 27 ++-
> net/dsa/Kconfig | 2 +-
> net/dsa/dsa_priv.h | 9 -
> net/dsa/slave.c | 304 ++++++++++++++++++++--------------
> 8 files changed, 340 insertions(+), 212 deletions(-)
>
--
Florian
^ permalink raw reply
* Re: [PATCH net] net: fec: Fix unbalanced PM runtime calls
From: David Miller @ 2018-03-19 0:12 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, l.stach, fugang.duan, linux-kernel
In-Reply-To: <f1ba3f3e-adef-c7f0-d9b2-47bbdade91f5@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Sun, 18 Mar 2018 14:42:22 -0700
> On 03/18/2018 01:35 PM, David Miller wrote:
>> Queue this up for -stable?
>
> I would be inclined to say yes, it was not exactly easy to track down a
> set of commits, since this was changed quite a bit.
Ok, queued up.
^ permalink raw reply
* [PATCH net-next] tc-testing: add selftests for 'bpf' action
From: Davide Caratti @ 2018-03-19 0:19 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: Brenda J . Butler, Roman Mashak
Test d959: Add cBPF action with valid bytecode
Test f84a: Add cBPF action with invalid bytecode
Test e939: Add eBPF action with valid object-file
Test d819: Replace cBPF bytecode and action control
Test 6ae3: Delete cBPF action
Test 3e0d: List cBPF actions
Test 55ce: Flush BPF actions
Test ccc3: Add cBPF action with duplicate index
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
.../selftests/tc-testing/tc-tests/actions/bpf.json | 215 +++++++++++++++++++++
1 file changed, 215 insertions(+)
create mode 100644 tools/testing/selftests/tc-testing/tc-tests/actions/bpf.json
diff --git a/tools/testing/selftests/tc-testing/tc-tests/actions/bpf.json b/tools/testing/selftests/tc-testing/tc-tests/actions/bpf.json
new file mode 100644
index 000000000000..0295a63dd0c8
--- /dev/null
+++ b/tools/testing/selftests/tc-testing/tc-tests/actions/bpf.json
@@ -0,0 +1,215 @@
+[
+ {
+ "id": "d959",
+ "name": "Add cBPF action with valid bytecode",
+ "category": [
+ "actions",
+ "bpf"
+ ],
+ "setup": [
+ [
+ "$TC action flush action bpf",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC action add action bpf bytecode '4,40 0 0 12,21 0 1 2048,6 0 0 262144,6 0 0 0' index 100",
+ "expExitCode": "0",
+ "verifyCmd": "$TC action get action bpf index 100",
+ "matchPattern": "action order [0-9]*: bpf bytecode '4,40 0 0 12,21 0 1 2048,6 0 0 262144,6 0 0 0' default-action pipe.*index 100 ref",
+ "matchCount": "1",
+ "teardown": [
+ "$TC action flush action bpf"
+ ]
+ },
+ {
+ "id": "f84a",
+ "name": "Add cBPF action with invalid bytecode",
+ "category": [
+ "actions",
+ "bpf"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action bpf",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC action add action bpf bytecode '4,40 0 0 12,31 0 1 2048,6 0 0 262144,6 0 0 0' index 100",
+ "expExitCode": "255",
+ "verifyCmd": "$TC action get action bpf index 100",
+ "matchPattern": "action order [0-9]*: bpf bytecode '4,40 0 0 12,31 0 1 2048,6 0 0 262144,6 0 0 0' default-action pipe.*index 100 ref",
+ "matchCount": "0",
+ "teardown": [
+ "$TC actions flush action bpf"
+ ]
+ },
+ {
+ "id": "e939",
+ "name": "Add eBPF action with valid object-file",
+ "category": [
+ "actions",
+ "bpf"
+ ],
+ "setup": [
+ "printf '#include <linux/bpf.h>\nchar l[] __attribute__((section(\"license\"),used))=\"GPL\"; __attribute__((section(\"action\"),used)) int m(struct __sk_buff *s) { return 2; }' | clang -O2 -x c -c - -target bpf -o _b.o",
+ [
+ "$TC action flush action bpf",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC action add action bpf object-file _b.o index 667",
+ "expExitCode": "0",
+ "verifyCmd": "$TC action get action bpf index 667",
+ "matchPattern": "action order [0-9]*: bpf _b.o:\\[action\\] id [0-9]* tag 3b185187f1855c4c default-action pipe.*index 667 ref",
+ "matchCount": "1",
+ "teardown": [
+ "$TC action flush action bpf",
+ "rm -f _b.o"
+ ]
+ },
+ {
+ "id": "d819",
+ "name": "Replace cBPF bytecode and action control",
+ "category": [
+ "actions",
+ "bpf"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action bpf",
+ 0,
+ 1,
+ 255
+ ],
+ [
+ "$TC action add action bpf bytecode '4,40 0 0 12,21 0 1 2048,6 0 0 262144,6 0 0 0' index 555",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC action replace action bpf bytecode '4,40 0 0 12,21 0 1 2054,6 0 0 262144,6 0 0 0' drop index 555",
+ "expExitCode": "0",
+ "verifyCmd": "$TC action get action bpf index 555",
+ "matchPattern": "action order [0-9]*: bpf bytecode '4,40 0 0 12,21 0 1 2054,6 0 0 262144,6 0 0 0' default-action drop.*index 555 ref",
+ "matchCount": "1",
+ "teardown": [
+ "$TC action flush action bpf"
+ ]
+ },
+ {
+ "id": "6ae3",
+ "name": "Delete cBPF action ",
+ "category": [
+ "actions",
+ "bpf"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action bpf",
+ 0,
+ 1,
+ 255
+ ],
+ [
+ "$TC action add action bpf bytecode '4,40 0 0 12,21 0 1 2048,6 0 0 262144,6 0 0 0' index 444",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC action delete action bpf index 444",
+ "expExitCode": "0",
+ "verifyCmd": "$TC action get action bpf index 444",
+ "matchPattern": "action order [0-9]*: bpf bytecode '4,40 0 0 12,21 0 1 2048,6 0 0 262144,6 0 0 0' default-action pipe.*index 444 ref",
+ "matchCount": "0",
+ "teardown": [
+ "$TC action flush action bpf"
+ ]
+ },
+ {
+ "id": "3e0d",
+ "name": "List cBPF actions",
+ "category": [
+ "actions",
+ "bpf"
+ ],
+ "setup": [
+ [
+ "$TC action flush action bpf",
+ 0,
+ 1,
+ 255
+ ],
+ "$TC action add action bpf bytecode '4,40 0 0 12,21 0 1 2048,6 0 0 262144,6 0 0 0' ok index 101",
+ "$TC action add action bpf bytecode '4,40 0 0 12,21 0 1 2054,6 0 0 262144,6 0 0 0' drop index 102",
+ "$TC action add action bpf bytecode '4,40 0 0 12,21 0 1 33024,6 0 0 262144,6 0 0 0' continue index 103"
+ ],
+ "cmdUnderTest": "$TC action list action bpf",
+ "expExitCode": "0",
+ "verifyCmd": "$TC action list action bpf",
+ "matchPattern": "action order [0-9]*: bpf bytecode",
+ "matchCount": "3",
+ "teardown": [
+ "$TC actions flush action bpf"
+ ]
+ },
+ {
+ "id": "55ce",
+ "name": "Flush BPF actions",
+ "category": [
+ "actions",
+ "bpf"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action bpf",
+ 0,
+ 1,
+ 255
+ ],
+ "$TC action add action bpf bytecode '4,40 0 0 12,21 0 1 2048,6 0 0 262144,6 0 0 0' ok index 101",
+ "$TC action add action bpf bytecode '4,40 0 0 12,21 0 1 2054,6 0 0 262144,6 0 0 0' drop index 102",
+ "$TC action add action bpf bytecode '4,40 0 0 12,21 0 1 33024,6 0 0 262144,6 0 0 0' continue index 103"
+ ],
+ "cmdUnderTest": "$TC action flush action bpf",
+ "expExitCode": "0",
+ "verifyCmd": "$TC action list action bpf",
+ "matchPattern": "action order [0-9]*: bpf bytecode",
+ "matchCount": "0",
+ "teardown": [
+ "$TC actions flush action bpf"
+ ]
+ },
+ {
+ "id": "ccc3",
+ "name": "Add cBPF action with duplicate index",
+ "category": [
+ "actions",
+ "bpf"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action bpf",
+ 0,
+ 1,
+ 255
+ ],
+ "$TC action add action bpf bytecode '4,40 0 0 12,21 0 1 2048,6 0 0 262144,6 0 0 0' index 333"
+ ],
+ "cmdUnderTest": "$TC action add action bpf bytecode '4,40 0 0 12,21 0 1 2054,6 0 0 262144,6 0 0 0' index 333",
+ "expExitCode": "255",
+ "verifyCmd": "$TC action get action bpf index 333",
+ "matchPattern": "action order [0-9]*: bpf bytecode '4,40 0 0 12,21 0 1 2048,6 0 0 262144,6 0 0 0' default-action pipe.*index 333",
+ "matchCount": "1",
+ "teardown": [
+ "$TC action flush action bpf"
+ ]
+ }
+]
--
2.14.3
^ permalink raw reply related
* linux-next: manual merge of the net-next tree with the syscalls tree
From: Stephen Rothwell @ 2018-03-19 0:25 UTC (permalink / raw)
To: David Miller, Networking, Dominik Brodowski
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Kirill Tkhai
[-- Attachment #1: Type: text/plain, Size: 2640 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
include/linux/socket.h
between commits:
06947f40e3e9 ("net: socket: add __sys_recvfrom() helper; remove in-kernel call to syscall")
bd4053a762c6 ("net: socket: move check for forbid_cmsg_compat to __sys_...msg()")
from the syscalls tree and commit:
d8d211a2a0c3 ("net: Make extern and export get_net_ns()")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/linux/socket.h
index e2b6bd4fe977,1ce1f768a58c..000000000000
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@@ -356,30 -352,7 +356,31 @@@ extern long __sys_sendmsg(int fd, struc
extern int __sys_recvmmsg(int fd, struct mmsghdr __user *mmsg, unsigned int vlen,
unsigned int flags, struct timespec *timeout);
extern int __sys_sendmmsg(int fd, struct mmsghdr __user *mmsg,
- unsigned int vlen, unsigned int flags);
+ unsigned int vlen, unsigned int flags,
+ bool forbid_cmsg_compat);
+
+/* helpers which do the actual work for syscalls */
+extern int __sys_recvfrom(int fd, void __user *ubuf, size_t size,
+ unsigned int flags, struct sockaddr __user *addr,
+ int __user *addr_len);
+extern int __sys_sendto(int fd, void __user *buff, size_t len,
+ unsigned int flags, struct sockaddr __user *addr,
+ int addr_len);
+extern int __sys_accept4(int fd, struct sockaddr __user *upeer_sockaddr,
+ int __user *upeer_addrlen, int flags);
+extern int __sys_socket(int family, int type, int protocol);
+extern int __sys_bind(int fd, struct sockaddr __user *umyaddr, int addrlen);
+extern int __sys_connect(int fd, struct sockaddr __user *uservaddr,
+ int addrlen);
+extern int __sys_listen(int fd, int backlog);
+extern int __sys_getsockname(int fd, struct sockaddr __user *usockaddr,
+ int __user *usockaddr_len);
+extern int __sys_getpeername(int fd, struct sockaddr __user *usockaddr,
+ int __user *usockaddr_len);
+extern int __sys_socketpair(int family, int type, int protocol,
+ int __user *usockvec);
+extern int __sys_shutdown(int fd, int how);
+
+ extern struct ns_common *get_net_ns(struct ns_common *ns);
#endif /* _LINUX_SOCKET_H */
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 01/21] ASoC: Remove depends on HAS_DMA in case of platform dependency
From: Mark Brown @ 2018-03-19 0:54 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Ulf Hansson, Wolfram Sang, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-fpga-u79uwXL29TY76Z2rM5mHXA,
linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Bjorn Andersson, Eric Anholt,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux1394-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Christoph Hellwig, Stefan Wahren, Boris Brezillon,
James E . J . Bottomley, Herbert Xu,
linux-scsi-u79uwXL29TY76Z2rM5mHXA, Richard Weinberger, Jassi Brar,
Marek Vasut, linux-serial-u79uwXL29TY76Z2rM5mHXA, Matias Bjorling,
David Woodhouse, linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1521208314-4783-2-git-send-email-geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 437 bytes --]
On Fri, Mar 16, 2018 at 02:51:34PM +0100, Geert Uytterhoeven wrote:
> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
> In most cases this other symbol is an architecture or platform specific
> symbol, or PCI.
Acked-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Thanks again for doing this work, it's really good to see!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH v2 19/21] spi: Remove depends on HAS_DMA in case of platform dependency
From: Mark Brown @ 2018-03-19 0:54 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Ulf Hansson, Wolfram Sang, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-fpga-u79uwXL29TY76Z2rM5mHXA,
linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Bjorn Andersson, Eric Anholt,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux1394-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Christoph Hellwig, Stefan Wahren, Boris Brezillon,
James E . J . Bottomley, Herbert Xu,
linux-scsi-u79uwXL29TY76Z2rM5mHXA, Richard Weinberger, Jassi Brar,
Marek Vasut, linux-serial-u79uwXL29TY76Z2rM5mHXA, Matias Bjorling,
David Woodhouse, linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1521208314-4783-20-git-send-email-geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 377 bytes --]
On Fri, Mar 16, 2018 at 02:51:52PM +0100, Geert Uytterhoeven wrote:
> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
> In most cases this other symbol is an architecture or platform specific
> symbol, or PCI.
Acked-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [PATCH net-next v2 0/2] brcmfmac: add new dt entries for SG SDIO settings
From: Alexey Roslyakov @ 2018-03-19 1:40 UTC (permalink / raw)
To: andrew, kvalo, robh+dt, mark.rutland, arend.vanspriel, franky.lin,
hante.meuleman, chi-hsien.lin, wright.feng, netdev
Cc: linux-wireless, devicetree, linux-kernel, brcm80211-dev-list.pdl,
brcm80211-dev-list
Changes in v2: don't check of_property_read_* return values since it
doesn't change the value if property not found.
Suggested by Andrew Lunn.
^ permalink raw reply
* [PATCH net-next v2 1/2] brcmfmac: add new dt entries for SG SDIO settings
From: Alexey Roslyakov @ 2018-03-19 1:40 UTC (permalink / raw)
To: andrew, kvalo, robh+dt, mark.rutland, arend.vanspriel, franky.lin,
hante.meuleman, chi-hsien.lin, wright.feng, netdev
Cc: linux-wireless, devicetree, linux-kernel, brcm80211-dev-list.pdl,
brcm80211-dev-list, Alexey Roslyakov
In-Reply-To: <20180319014032.9394-1-alexey.roslyakov@gmail.com>
There are 3 fields in SDIO settings (quirks) to workaround some of
the SG SDIO host particularities, i.e higher align requirements for
SG items.
All coding is done the long time ago, but there is no way to change the
driver behavior without patching the kernel.
Add missing devicetree entries.
Signed-off-by: Alexey Roslyakov <alexey.roslyakov@gmail.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
index aee6e5937c41..14135752b659 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
@@ -30,14 +30,20 @@ void brcmf_of_probe(struct device *dev, enum brcmf_bus_type bus_type,
struct device_node *np = dev->of_node;
int irq;
u32 irqf;
- u32 val;
if (!np || bus_type != BRCMF_BUSTYPE_SDIO ||
!of_device_is_compatible(np, "brcm,bcm4329-fmac"))
return;
- if (of_property_read_u32(np, "brcm,drive-strength", &val) == 0)
- sdio->drive_strength = val;
+ of_property_read_u32(np, "brcm,drive-strength", &sdio->drive_strength);
+
+ sdio->broken_sg_support =
+ of_property_read_bool(np, "brcm,broken-sg-support");
+
+ of_property_read_u16(np, "brcm,sd-head-align", &sdio->sd_head_align);
+
+ of_property_read_u16(np, "brcm,sd-sgentry-align",
+ &sdio->sd_sgentry_align);
/* make sure there are interrupts defined in the node */
if (!of_find_property(np, "interrupts", NULL))
--
2.16.1
^ 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