* Re: [PATCH v2 13/13] ARM: pxa: change SSP DMA channels allocation
From: Daniel Mack @ 2018-05-25 7:56 UTC (permalink / raw)
To: Robert Jarzmik, Haojian Zhuang, Ezequiel Garcia, Boris Brezillon,
David Woodhouse, Brian Norris, Marek Vasut, Richard Weinberger,
Liam Girdwood, Mark Brown, Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, linux-ide, dmaengine, linux-media,
linux-mmc, linux-mtd, netdev, alsa-devel
In-Reply-To: <20180524070703.11901-14-robert.jarzmik@free.fr>
On Thursday, May 24, 2018 09:07 AM, Robert Jarzmik wrote:
> Now the dma_slave_map is available for PXA architecture, switch the SSP
> device to it.
>
> This specifically means that :
> - for platform data based machines, the DMA requestor channels are
> extracted from the slave map, where pxa-ssp-dai.<N> is a 1-1 match to
> ssp.<N>, and the channels are either "rx" or "tx".
>
> - for device tree platforms, the dma node should be hooked into the
> pxa2xx-ac97 or pxa-ssp-dai node.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Acked-by: Daniel Mack <daniel@zonque.org>
We should, however, merge what's left of this management glue code into
the users of it, so the dma related properties can be put in the right
devicetree node.
I'll prepare a patch for that for 4.18. This is a good preparation for
this round though.
Thanks,
Daniel
> ---
> Since v1: Removed channel names from platform_data
> ---
> arch/arm/plat-pxa/ssp.c | 47 ----------------------------------------------
> include/linux/pxa2xx_ssp.h | 2 --
> sound/soc/pxa/pxa-ssp.c | 5 ++---
> 3 files changed, 2 insertions(+), 52 deletions(-)
>
> diff --git a/arch/arm/plat-pxa/ssp.c b/arch/arm/plat-pxa/ssp.c
> index ba13f793fbce..ed36dcab80f1 100644
> --- a/arch/arm/plat-pxa/ssp.c
> +++ b/arch/arm/plat-pxa/ssp.c
> @@ -127,53 +127,6 @@ static int pxa_ssp_probe(struct platform_device *pdev)
> if (IS_ERR(ssp->clk))
> return PTR_ERR(ssp->clk);
>
> - if (dev->of_node) {
> - struct of_phandle_args dma_spec;
> - struct device_node *np = dev->of_node;
> - int ret;
> -
> - /*
> - * FIXME: we should allocate the DMA channel from this
> - * context and pass the channel down to the ssp users.
> - * For now, we lookup the rx and tx indices manually
> - */
> -
> - /* rx */
> - ret = of_parse_phandle_with_args(np, "dmas", "#dma-cells",
> - 0, &dma_spec);
> -
> - if (ret) {
> - dev_err(dev, "Can't parse dmas property\n");
> - return -ENODEV;
> - }
> - ssp->drcmr_rx = dma_spec.args[0];
> - of_node_put(dma_spec.np);
> -
> - /* tx */
> - ret = of_parse_phandle_with_args(np, "dmas", "#dma-cells",
> - 1, &dma_spec);
> - if (ret) {
> - dev_err(dev, "Can't parse dmas property\n");
> - return -ENODEV;
> - }
> - ssp->drcmr_tx = dma_spec.args[0];
> - of_node_put(dma_spec.np);
> - } else {
> - res = platform_get_resource(pdev, IORESOURCE_DMA, 0);
> - if (res == NULL) {
> - dev_err(dev, "no SSP RX DRCMR defined\n");
> - return -ENODEV;
> - }
> - ssp->drcmr_rx = res->start;
> -
> - res = platform_get_resource(pdev, IORESOURCE_DMA, 1);
> - if (res == NULL) {
> - dev_err(dev, "no SSP TX DRCMR defined\n");
> - return -ENODEV;
> - }
> - ssp->drcmr_tx = res->start;
> - }
> -
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (res == NULL) {
> dev_err(dev, "no memory resource defined\n");
> diff --git a/include/linux/pxa2xx_ssp.h b/include/linux/pxa2xx_ssp.h
> index 8461b18e4608..03a7ca46735b 100644
> --- a/include/linux/pxa2xx_ssp.h
> +++ b/include/linux/pxa2xx_ssp.h
> @@ -212,8 +212,6 @@ struct ssp_device {
> int type;
> int use_count;
> int irq;
> - int drcmr_rx;
> - int drcmr_tx;
>
> struct device_node *of_node;
> };
> diff --git a/sound/soc/pxa/pxa-ssp.c b/sound/soc/pxa/pxa-ssp.c
> index 0291c7cb64eb..e09368d89bbc 100644
> --- a/sound/soc/pxa/pxa-ssp.c
> +++ b/sound/soc/pxa/pxa-ssp.c
> @@ -104,9 +104,8 @@ static int pxa_ssp_startup(struct snd_pcm_substream *substream,
> dma = kzalloc(sizeof(struct snd_dmaengine_dai_dma_data), GFP_KERNEL);
> if (!dma)
> return -ENOMEM;
> -
> - dma->filter_data = substream->stream == SNDRV_PCM_STREAM_PLAYBACK ?
> - &ssp->drcmr_tx : &ssp->drcmr_rx;
> + dma->chan_name = substream->stream == SNDRV_PCM_STREAM_PLAYBACK ?
> + "tx" : "rx";
>
> snd_soc_dai_set_dma_data(cpu_dai, substream, dma);
>
>
^ permalink raw reply
* Re: [PATCH 0/6] ravb/sh_eth: fix sleep in atomic by reusing shared ethtool handlers
From: Geert Uytterhoeven @ 2018-05-25 8:11 UTC (permalink / raw)
To: Vladimir Zapolskiy
Cc: David S. Miller, Sergei Shtylyov, netdev, Linux-Renesas
In-Reply-To: <1527160318-10958-1-git-send-email-vladimir_zapolskiy@mentor.com>
Hi Vladimir,
On Thu, May 24, 2018 at 1:11 PM, Vladimir Zapolskiy
<vladimir_zapolskiy@mentor.com> wrote:
> For ages trivial changes to RAVB and SuperH ethernet links by means of
> standard 'ethtool' trigger a 'sleeping function called from invalid
> context' bug, to visualize it on r8a7795 ULCB:
>
> % ethtool -r eth0
> BUG: sleeping function called from invalid context at kernel/locking/mutex.c:747
[...]
> Please note that sh_eth patches from the series were built-tested only.
Thanks you very much!
I've tested this on both R-Car M2-W (sh_eth) and R-Car H3 ES2.0 (ravb),
and the BUG disappeared.
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH bpf-next 0/5] fix test_sockmap
From: Prashant Bhole @ 2018-05-25 8:28 UTC (permalink / raw)
To: John Fastabend, Alexei Starovoitov, Daniel Borkmann
Cc: David S . Miller, Shuah Khan, netdev
In-Reply-To: <28161781-9e02-bce4-501d-81dbbc24e1e8@gmail.com>
On 5/24/2018 1:58 PM, John Fastabend wrote:
> On 05/23/2018 09:47 PM, Prashant Bhole wrote:
>>
>>
>> On 5/23/2018 6:44 PM, Prashant Bhole wrote:
>>>
>>>
>>> On 5/22/2018 2:08 AM, John Fastabend wrote:
>>>> On 05/20/2018 10:13 PM, Prashant Bhole wrote:
>>>>>
>>>>>
>>>>> On 5/19/2018 1:42 AM, John Fastabend wrote:
>>>>>> On 05/18/2018 12:17 AM, Prashant Bhole wrote:
>>>>>>> This series fixes bugs in test_sockmap code. They weren't caught
>>>>>>> previously because failure in RX/TX thread was not notified to the
>>>>>>> main thread.
>>>>>>>
>>>>>>> Also fixed data verification logic and slightly improved test output
>>>>>>> such that parameters values (cork, apply, start, end) of failed test
>>>>>>> can be easily seen.
>>>>>>>
>>>>>>
>>>>>> Great, this was on my list so thanks for taking care of it.
>>>>>>
>>>>>>> Note: Even after fixing above problems there are issues with tests
>>>>>>> which set cork parameter. Tests fail (RX thread timeout) when cork
>>>>>>> value is non-zero and overall data sent by TX thread isn't multiples
>>>>>>> of cork value.
>>>>>>
>>>>>>
>>>>>> This is expected. When 'cork' is set the sender should only xmit
>>>>>> the data when 'cork' bytes are available. If the user doesn't
>>>>>> provide the N bytes the data is cork'ed waiting for the bytes and
>>>>>> if the socket is closed the state is cleaned up. What these tests
>>>>>> are testing is the cleanup path when a user doesn't provide the
>>>>>> N bytes. In practice this is used to validate headers and prevent
>>>>>> users from sending partial headers. We want to keep these tests because
>>>>>> they verify a tear-down path in the code.
>>>>>
>>>>> Ok.
>>>>>
>>>>>>
>>>>>> After your changes do these get reported as failures? If so we
>>>>>> need to account for the above in the calculations.
>>>>>
>>>>> Yes, cork related test are reported as failures because of RX thread
>>>>> timeout.
>>>>>
>>>>> So with your above description, I think we need to differentiate cork
>>>>> tests with partial data and full data. In partial data test we can have
>>>>> something like "timeout_expected" flag. Any other way to fix it?
>>>>>
>>>>
>>>> Adding a flag seems reasonable to me. Lets do this for now. Also I
>>>> plan to add more negative tests so we can either use the same
>>>> flag or a new one for those cases as well.
>>>>
>>>
>>> John,
>>> I worked on this for some time and noticed that the RX-timeout of
>>> tests with cork parameter is dependent on various parameters. So we
>>> can not set a flag like the way 'drop_expected' flag is set before
>>> executing the test.
>>>
>>> So I decided to write a function which judges all parameters before
>>> each test and decides whether a test with cork parameter will
>>> timeout or not. Then the conditions in the function became
>>> complicated. For example some tests fail if opt->rate < 17 (with
>>> some other conditions). Here is 17 is related to FRAGS_PER_SKB.
>>> Consider following two examples.
>> I'm sorry. Correction: s/FRAGS_PER_SKB/MAX_SKB_FRAGS/
>>
>>>
>>> ./test_sockmap --cgroup /mnt/cgroup2 -r 16 -i 1 -l 30 -t sendpage
>>> --txmsg --txmsg_cork 1024 # RX timeout occurs
>>>
>>> ./test_sockmap --cgroup /mnt/cgroup2 -r 17 -i 1 -l 30 -t sendpage
>>> --txmsg --txmsg_cork 1024 # Success!
>>>
>
> Ah yes this hits the buffer limit and flushes the queue. The kernel
> side doesn't know how to merge those specific sendpage requests so
> it gives each request its own buffer and when the limit is reached
> we flush it.
>
>>> Do we need to keep such tests? if yes, then I will continue with
>>> adding such conditions in the function.
>>>
>
> Yes, these tests are needed because they are testing the edge cases.
> These are probably the most important tests because my normal usage
> will catch any issues in the "good" cases its these types of things
> that can go unnoticed (at least for a short while) if we don't have
> specific tests for them.
I tried but it is difficult to come up with a right set of conditions
which lead to test failure.
-Prashant
>
> Thanks for doing this.
> John
^ permalink raw reply
* Re: [PATCH bpf-next v7 6/6] selftests/bpf: test for seg6local End.BPF action
From: Daniel Borkmann @ 2018-05-25 8:30 UTC (permalink / raw)
To: Y Song, Mathieu Xhonneux; +Cc: netdev, dlebrun, Alexei Starovoitov
In-Reply-To: <CAH3MdRUTO_Cg57WqJu8qji-mxpvvL5hiBzU4Wp_rYetEXiQNMQ@mail.gmail.com>
On 05/25/2018 04:30 AM, Y Song wrote:
> When compiling latest bpf-next, I hit the following compilation error:
>
> clang -I. -I./include/uapi -I../../../include/uapi -idirafter
> /usr/local/include -idirafter
> /data/users/yhs/work/llvm/build/install/lib/clang/7.0.0/include
> -idirafter /usr/include -Wno-compare-distinct-pointer-types \
> -O2 -target bpf -emit-llvm -c test_lwt_seg6local.c -o - | \
> llc -march=bpf -mcpu=generic -filetype=obj -o
> /data/users/yhs/work/net-next/tools/testing/selftests/bpf/test_lwt_seg6local.o
> test_lwt_seg6local.c:4:10: fatal error: 'linux/seg6_local.h' file not found
> #include <linux/seg6_local.h>
> ^~~~~~~~~~~~~~~~~~~~
> 1 error generated.
> make: Leaving directory
> `/data/users/yhs/work/net-next/tools/testing/selftests/bpf'
>
> Should the seg6_local.h be copied to tools/ directory?
Yeah it should, Mathieu please fix!
^ permalink raw reply
* Re: [PATCH v2 08/13] ASoC: pxa: remove the dmaengine compat need
From: Daniel Mack @ 2018-05-25 8:35 UTC (permalink / raw)
To: Robert Jarzmik, Haojian Zhuang, Ezequiel Garcia, Boris Brezillon,
David Woodhouse, Brian Norris, Marek Vasut, Richard Weinberger,
Liam Girdwood, Mark Brown, Arnd Bergmann
Cc: alsa-devel, netdev, linux-mmc, linux-kernel, linux-ide, linux-mtd,
dmaengine, linux-arm-kernel, linux-media
In-Reply-To: <20180524070703.11901-9-robert.jarzmik@free.fr>
On Thursday, May 24, 2018 09:06 AM, Robert Jarzmik wrote:
> As the pxa architecture switched towards the dmaengine slave map, the
> old compatibility mechanism to acquire the dma requestor line number and
> priority are not needed anymore.
>
> This patch simplifies the dma resource acquisition, using the more
> generic function dma_request_slave_channel().
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Reviewed-by: Daniel Mack <daniel@zonque.org>
> ---
> sound/arm/pxa2xx-ac97.c | 14 ++------------
> sound/arm/pxa2xx-pcm-lib.c | 6 +++---
> sound/soc/pxa/pxa2xx-ac97.c | 32 +++++---------------------------
> sound/soc/pxa/pxa2xx-i2s.c | 6 ++----
> 4 files changed, 12 insertions(+), 46 deletions(-)
>
> diff --git a/sound/arm/pxa2xx-ac97.c b/sound/arm/pxa2xx-ac97.c
> index 4bc244c40f80..236a63cdaf9f 100644
> --- a/sound/arm/pxa2xx-ac97.c
> +++ b/sound/arm/pxa2xx-ac97.c
> @@ -63,28 +63,18 @@ static struct snd_ac97_bus_ops pxa2xx_ac97_ops = {
> .reset = pxa2xx_ac97_legacy_reset,
> };
>
> -static struct pxad_param pxa2xx_ac97_pcm_out_req = {
> - .prio = PXAD_PRIO_LOWEST,
> - .drcmr = 12,
> -};
> -
> static struct snd_dmaengine_dai_dma_data pxa2xx_ac97_pcm_out = {
> .addr = __PREG(PCDR),
> .addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
> + .chan_name = "pcm_pcm_stereo_out",
> .maxburst = 32,
> - .filter_data = &pxa2xx_ac97_pcm_out_req,
> -};
> -
> -static struct pxad_param pxa2xx_ac97_pcm_in_req = {
> - .prio = PXAD_PRIO_LOWEST,
> - .drcmr = 11,
> };
>
> static struct snd_dmaengine_dai_dma_data pxa2xx_ac97_pcm_in = {
> .addr = __PREG(PCDR),
> .addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
> + .chan_name = "pcm_pcm_stereo_in",
> .maxburst = 32,
> - .filter_data = &pxa2xx_ac97_pcm_in_req,
> };
>
> static struct snd_pcm *pxa2xx_ac97_pcm;
> diff --git a/sound/arm/pxa2xx-pcm-lib.c b/sound/arm/pxa2xx-pcm-lib.c
> index e8da3b8ee721..dcbe7ecc1835 100644
> --- a/sound/arm/pxa2xx-pcm-lib.c
> +++ b/sound/arm/pxa2xx-pcm-lib.c
> @@ -125,9 +125,9 @@ int __pxa2xx_pcm_open(struct snd_pcm_substream *substream)
> if (ret < 0)
> return ret;
>
> - return snd_dmaengine_pcm_open_request_chan(substream,
> - pxad_filter_fn,
> - dma_params->filter_data);
> + return snd_dmaengine_pcm_open(
> + substream, dma_request_slave_channel(rtd->cpu_dai->dev,
> + dma_params->chan_name));
> }
> EXPORT_SYMBOL(__pxa2xx_pcm_open);
>
> diff --git a/sound/soc/pxa/pxa2xx-ac97.c b/sound/soc/pxa/pxa2xx-ac97.c
> index 803818aabee9..1b41c0f2a8fb 100644
> --- a/sound/soc/pxa/pxa2xx-ac97.c
> +++ b/sound/soc/pxa/pxa2xx-ac97.c
> @@ -68,61 +68,39 @@ static struct snd_ac97_bus_ops pxa2xx_ac97_ops = {
> .reset = pxa2xx_ac97_cold_reset,
> };
>
> -static struct pxad_param pxa2xx_ac97_pcm_stereo_in_req = {
> - .prio = PXAD_PRIO_LOWEST,
> - .drcmr = 11,
> -};
> -
> static struct snd_dmaengine_dai_dma_data pxa2xx_ac97_pcm_stereo_in = {
> .addr = __PREG(PCDR),
> .addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
> + .chan_name = "pcm_pcm_stereo_in",
> .maxburst = 32,
> - .filter_data = &pxa2xx_ac97_pcm_stereo_in_req,
> -};
> -
> -static struct pxad_param pxa2xx_ac97_pcm_stereo_out_req = {
> - .prio = PXAD_PRIO_LOWEST,
> - .drcmr = 12,
> };
>
> static struct snd_dmaengine_dai_dma_data pxa2xx_ac97_pcm_stereo_out = {
> .addr = __PREG(PCDR),
> .addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
> + .chan_name = "pcm_pcm_stereo_out",
> .maxburst = 32,
> - .filter_data = &pxa2xx_ac97_pcm_stereo_out_req,
> };
>
> -static struct pxad_param pxa2xx_ac97_pcm_aux_mono_out_req = {
> - .prio = PXAD_PRIO_LOWEST,
> - .drcmr = 10,
> -};
> static struct snd_dmaengine_dai_dma_data pxa2xx_ac97_pcm_aux_mono_out = {
> .addr = __PREG(MODR),
> .addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES,
> + .chan_name = "pcm_aux_mono_out",
> .maxburst = 16,
> - .filter_data = &pxa2xx_ac97_pcm_aux_mono_out_req,
> };
>
> -static struct pxad_param pxa2xx_ac97_pcm_aux_mono_in_req = {
> - .prio = PXAD_PRIO_LOWEST,
> - .drcmr = 9,
> -};
> static struct snd_dmaengine_dai_dma_data pxa2xx_ac97_pcm_aux_mono_in = {
> .addr = __PREG(MODR),
> .addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES,
> + .chan_name = "pcm_aux_mono_in",
> .maxburst = 16,
> - .filter_data = &pxa2xx_ac97_pcm_aux_mono_in_req,
> };
>
> -static struct pxad_param pxa2xx_ac97_pcm_aux_mic_mono_req = {
> - .prio = PXAD_PRIO_LOWEST,
> - .drcmr = 8,
> -};
> static struct snd_dmaengine_dai_dma_data pxa2xx_ac97_pcm_mic_mono_in = {
> .addr = __PREG(MCDR),
> .addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES,
> + .chan_name = "pcm_aux_mic_mono",
> .maxburst = 16,
> - .filter_data = &pxa2xx_ac97_pcm_aux_mic_mono_req,
> };
>
> static int pxa2xx_ac97_hifi_startup(struct snd_pcm_substream *substream,
> diff --git a/sound/soc/pxa/pxa2xx-i2s.c b/sound/soc/pxa/pxa2xx-i2s.c
> index 3fb60baf6eab..e7184de0de04 100644
> --- a/sound/soc/pxa/pxa2xx-i2s.c
> +++ b/sound/soc/pxa/pxa2xx-i2s.c
> @@ -82,20 +82,18 @@ static struct pxa_i2s_port pxa_i2s;
> static struct clk *clk_i2s;
> static int clk_ena = 0;
>
> -static unsigned long pxa2xx_i2s_pcm_stereo_out_req = 3;
> static struct snd_dmaengine_dai_dma_data pxa2xx_i2s_pcm_stereo_out = {
> .addr = __PREG(SADR),
> .addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
> + .chan_name = "tx",
> .maxburst = 32,
> - .filter_data = &pxa2xx_i2s_pcm_stereo_out_req,
> };
>
> -static unsigned long pxa2xx_i2s_pcm_stereo_in_req = 2;
> static struct snd_dmaengine_dai_dma_data pxa2xx_i2s_pcm_stereo_in = {
> .addr = __PREG(SADR),
> .addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
> + .chan_name = "rx",
> .maxburst = 32,
> - .filter_data = &pxa2xx_i2s_pcm_stereo_in_req,
> };
>
> static int pxa2xx_i2s_startup(struct snd_pcm_substream *substream,
>
^ permalink raw reply
* Re: Hangs in r8152 connected to power management in kernels at least up v4.17-rc4
From: Jiri Slaby @ 2018-05-25 8:41 UTC (permalink / raw)
To: Hayes Wang, Oliver Neukum; +Cc: netdev@vger.kernel.org
In-Reply-To: <c1c775d4-60c1-e4ac-87e5-81e655b5beeb@suse.cz>
On 05/16/2018, 03:36 PM, Jiri Slaby wrote:
> So I assume it must be a problem of making usb->disconnect without prior
> ndo->close (or alike).
So according to my debug messages, I think this should workaround the
problem:
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3962,7 +3962,8 @@ static int rtl8152_close(struct net_device *netdev)
#ifdef CONFIG_PM_SLEEP
unregister_pm_notifier(&tp->pm_notifier);
#endif
- napi_disable(&tp->napi);
+ if (!test_bit(RTL8152_UNPLUG, &tp->flags))
+ napi_disable(&tp->napi);
clear_bit(WORK_ENABLE, &tp->flags);
usb_kill_urb(tp->intr_urb);
cancel_delayed_work_sync(&tp->schedule);
napi is deleted in usb->disconnect, then unregister_netdev is called
which invokes netdev->ndo_stop, i.e. rtl8152_close above. And
rtl8152_close tries to napi_disable, but that is already deleted.
The patch does not solve the race between disconnect and ndo_stop
AFAICS. It needs locking, IMO. I am not familiar enough with the code,
but it looks like ->disconnect can happen any time while ->stop is in
progress.
thanks,
--
js
suse labs
^ permalink raw reply
* Re: [PATCH net-next] selftests: net: Test headroom handling of ip6_gre devices
From: Petr Machata @ 2018-05-25 9:05 UTC (permalink / raw)
To: William Tu
Cc: Linux Kernel Network Developers, linux-kselftest, David Miller,
Shuah Khan
In-Reply-To: <CALDO+Sbf3DEKyXnQNjyJNF-E+rroZ7XcKCYjiPOSDnzfkjwQiQ@mail.gmail.com>
William Tu <u9012063@gmail.com> writes:
>> +cleanup()
>> +{
>> + ip link del dev swp1
>> + ip link del dev swp3
>> + ip link del dev vh3
> I think we also need to do:
> ip link del dev gt6
gt6 is removed in test_headroom, but for early-break sort of scenarios I
guess we do want to have it in cleanup() as well. With 2>/dev/null,
because most of the time it will have been cleaned up already. I'll send
a v2 like that.
>> +test_headroom()
>> +{
>> + ip link add name gt6 "$@"
>> + ip link set dev gt6 up
>> +
>> + sleep 1
>> +
>> + tc filter add dev swp1 ingress pref 1000 matchall skip_hw \
>> + action mirred egress mirror dev gt6
>> + ping -I h1 192.0.2.2 -c 1 -w 2 &> /dev/null
>
> I increase ping count from 1 to 1000
> and after a while the program hangs when I try to ctrl+c
> + cleanup
> + ip link del dev swp1
> dmesg shows:
> ....
> [ 1256.002453] unregister_netdevice: waiting for swp1 to become free.
> Usage count = 9
> [ 1266.082571] unregister_netdevice: waiting for swp1 to become free.
> Usage count = 9
> [ 1276.163011] unregister_netdevice: waiting for swp1 to become free.
> Usage count = 9
Interesting. Looks like another bug, the headroom issue would panic
after the first packet (and only after the first packet--increasing ping
count doesn't make it more likely to reproduce, rerunning the whole
script does).
Thanks,
Petr
^ permalink raw reply
* [PATCH bpf-next] selftests/bpf: missing headers test_lwt_seg6local
From: Mathieu Xhonneux @ 2018-05-25 11:20 UTC (permalink / raw)
To: netdev; +Cc: ys114321, daniel, alexei.starovoitov
Previous patch "selftests/bpf: test for seg6local End.BPF action" lacks
some UAPI headers in tools/.
clang -I. -I./include/uapi -I../../../include/uapi -idirafter
/usr/local/include -idirafter
/data/users/yhs/work/llvm/build/install/lib/clang/7.0.0/include
-idirafter /usr/include -Wno-compare-distinct-pointer-types \
-O2 -target bpf -emit-llvm -c test_lwt_seg6local.c -o - | \
llc -march=bpf -mcpu=generic -filetype=obj -o
[...]/net-next/tools/testing/selftests/bpf/test_lwt_seg6local.o
test_lwt_seg6local.c:4:10: fatal error: 'linux/seg6_local.h' file not found
^~~~~~~~~~~~~~~~~~~~
1 error generated.
make: Leaving directory
`/data/users/yhs/work/net-next/tools/testing/selftests/bpf'
Reported-by: Y Song <ys114321@gmail.com>
Signed-off-by: Mathieu Xhonneux <m.xhonneux@gmail.com>
---
.../selftests/bpf/include/uapi/linux/seg6.h | 55 +++++++++++++++
.../selftests/bpf/include/uapi/linux/seg6_local.h | 80 ++++++++++++++++++++++
2 files changed, 135 insertions(+)
create mode 100644 tools/testing/selftests/bpf/include/uapi/linux/seg6.h
create mode 100644 tools/testing/selftests/bpf/include/uapi/linux/seg6_local.h
diff --git a/tools/testing/selftests/bpf/include/uapi/linux/seg6.h b/tools/testing/selftests/bpf/include/uapi/linux/seg6.h
new file mode 100644
index 000000000000..286e8d6a8e98
--- /dev/null
+++ b/tools/testing/selftests/bpf/include/uapi/linux/seg6.h
@@ -0,0 +1,55 @@
+/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
+/*
+ * SR-IPv6 implementation
+ *
+ * Author:
+ * David Lebrun <david.lebrun@uclouvain.be>
+ *
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#ifndef _UAPI_LINUX_SEG6_H
+#define _UAPI_LINUX_SEG6_H
+
+#include <linux/types.h>
+#include <linux/in6.h> /* For struct in6_addr. */
+
+/*
+ * SRH
+ */
+struct ipv6_sr_hdr {
+ __u8 nexthdr;
+ __u8 hdrlen;
+ __u8 type;
+ __u8 segments_left;
+ __u8 first_segment; /* Represents the last_entry field of SRH */
+ __u8 flags;
+ __u16 tag;
+
+ struct in6_addr segments[0];
+};
+
+#define SR6_FLAG1_PROTECTED (1 << 6)
+#define SR6_FLAG1_OAM (1 << 5)
+#define SR6_FLAG1_ALERT (1 << 4)
+#define SR6_FLAG1_HMAC (1 << 3)
+
+#define SR6_TLV_INGRESS 1
+#define SR6_TLV_EGRESS 2
+#define SR6_TLV_OPAQUE 3
+#define SR6_TLV_PADDING 4
+#define SR6_TLV_HMAC 5
+
+#define sr_has_hmac(srh) ((srh)->flags & SR6_FLAG1_HMAC)
+
+struct sr6_tlv {
+ __u8 type;
+ __u8 len;
+ __u8 data[0];
+};
+
+#endif
diff --git a/tools/testing/selftests/bpf/include/uapi/linux/seg6_local.h b/tools/testing/selftests/bpf/include/uapi/linux/seg6_local.h
new file mode 100644
index 000000000000..edc138bdc56d
--- /dev/null
+++ b/tools/testing/selftests/bpf/include/uapi/linux/seg6_local.h
@@ -0,0 +1,80 @@
+/*
+ * SR-IPv6 implementation
+ *
+ * Author:
+ * David Lebrun <david.lebrun@uclouvain.be>
+ *
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#ifndef _UAPI_LINUX_SEG6_LOCAL_H
+#define _UAPI_LINUX_SEG6_LOCAL_H
+
+#include <linux/seg6.h>
+
+enum {
+ SEG6_LOCAL_UNSPEC,
+ SEG6_LOCAL_ACTION,
+ SEG6_LOCAL_SRH,
+ SEG6_LOCAL_TABLE,
+ SEG6_LOCAL_NH4,
+ SEG6_LOCAL_NH6,
+ SEG6_LOCAL_IIF,
+ SEG6_LOCAL_OIF,
+ SEG6_LOCAL_BPF,
+ __SEG6_LOCAL_MAX,
+};
+#define SEG6_LOCAL_MAX (__SEG6_LOCAL_MAX - 1)
+
+enum {
+ SEG6_LOCAL_ACTION_UNSPEC = 0,
+ /* node segment */
+ SEG6_LOCAL_ACTION_END = 1,
+ /* adjacency segment (IPv6 cross-connect) */
+ SEG6_LOCAL_ACTION_END_X = 2,
+ /* lookup of next seg NH in table */
+ SEG6_LOCAL_ACTION_END_T = 3,
+ /* decap and L2 cross-connect */
+ SEG6_LOCAL_ACTION_END_DX2 = 4,
+ /* decap and IPv6 cross-connect */
+ SEG6_LOCAL_ACTION_END_DX6 = 5,
+ /* decap and IPv4 cross-connect */
+ SEG6_LOCAL_ACTION_END_DX4 = 6,
+ /* decap and lookup of DA in v6 table */
+ SEG6_LOCAL_ACTION_END_DT6 = 7,
+ /* decap and lookup of DA in v4 table */
+ SEG6_LOCAL_ACTION_END_DT4 = 8,
+ /* binding segment with insertion */
+ SEG6_LOCAL_ACTION_END_B6 = 9,
+ /* binding segment with encapsulation */
+ SEG6_LOCAL_ACTION_END_B6_ENCAP = 10,
+ /* binding segment with MPLS encap */
+ SEG6_LOCAL_ACTION_END_BM = 11,
+ /* lookup last seg in table */
+ SEG6_LOCAL_ACTION_END_S = 12,
+ /* forward to SR-unaware VNF with static proxy */
+ SEG6_LOCAL_ACTION_END_AS = 13,
+ /* forward to SR-unaware VNF with masquerading */
+ SEG6_LOCAL_ACTION_END_AM = 14,
+ /* custom BPF action */
+ SEG6_LOCAL_ACTION_END_BPF = 15,
+
+ __SEG6_LOCAL_ACTION_MAX,
+};
+
+#define SEG6_LOCAL_ACTION_MAX (__SEG6_LOCAL_ACTION_MAX - 1)
+
+enum {
+ SEG6_LOCAL_BPF_PROG_UNSPEC,
+ SEG6_LOCAL_BPF_PROG,
+ SEG6_LOCAL_BPF_PROG_NAME,
+ __SEG6_LOCAL_BPF_PROG_MAX,
+};
+
+#define SEG6_LOCAL_BPF_PROG_MAX (__SEG6_LOCAL_BPF_PROG_MAX - 1)
+
+#endif
--
2.16.1
^ permalink raw reply related
* Re: [PATCH net] tun: Fix NULL pointer dereference in XDP redirect
From: Jason Wang @ 2018-05-25 9:59 UTC (permalink / raw)
To: Toshiaki Makita, David S. Miller; +Cc: netdev
In-Reply-To: <1527222729-2561-1-git-send-email-makita.toshiaki@lab.ntt.co.jp>
On 2018年05月25日 12:32, Toshiaki Makita wrote:
> Calling XDP redirection requires preempt/bh disabled. Especially softirq
> can call another XDP function and redirection functions, then percpu
> value ri->map can be overwritten to NULL.
>
> This is a generic XDP case called from tun.
>
> [ 3535.736058] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
> [ 3535.743974] PGD 0 P4D 0
> [ 3535.746530] Oops: 0000 [#1] SMP PTI
> [ 3535.750049] Modules linked in: vhost_net vhost tap tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter sunrpc vfat fat ext4 mbcache jbd2 intel_rapl skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm ipmi_ssif irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc ses aesni_intel crypto_simd cryptd enclosure hpwdt hpilo glue_helper ipmi_si pcspkr wmi mei_me ioatdma mei ipmi_devintf shpchp dca ipmi_msghandler lpc_ich acpi_power_meter sch_fq_codel ip_tables xfs libcrc32c sd_mod mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm smartpqi i40e crc32c_intel scsi_transport_sas tg3 i2c_core ptp pps_core
> [ 3535.813456] CPU: 5 PID: 1630 Comm: vhost-1614 Not tainted 4.17.0-rc4 #2
> [ 3535.820127] Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 11/14/2017
> [ 3535.828732] RIP: 0010:__xdp_map_lookup_elem+0x5/0x30
> [ 3535.833740] RSP: 0018:ffffb4bc47bf7c58 EFLAGS: 00010246
> [ 3535.839009] RAX: ffff9fdfcfea1c40 RBX: 0000000000000000 RCX: ffff9fdf27fe3100
> [ 3535.846205] RDX: ffff9fdfca769200 RSI: 0000000000000000 RDI: 0000000000000000
> [ 3535.853402] RBP: ffffb4bc491d9000 R08: 00000000000045ad R09: 0000000000000ec0
> [ 3535.860597] R10: 0000000000000001 R11: ffff9fdf26c3ce4e R12: ffff9fdf9e72c000
> [ 3535.867794] R13: 0000000000000000 R14: fffffffffffffff2 R15: ffff9fdfc82cdd00
> [ 3535.874990] FS: 0000000000000000(0000) GS:ffff9fdfcfe80000(0000) knlGS:0000000000000000
> [ 3535.883152] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 3535.888948] CR2: 0000000000000018 CR3: 0000000bde724004 CR4: 00000000007626e0
> [ 3535.896145] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 3535.903342] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 3535.910538] PKRU: 55555554
> [ 3535.913267] Call Trace:
> [ 3535.915736] xdp_do_generic_redirect+0x7a/0x310
> [ 3535.920310] do_xdp_generic.part.117+0x285/0x370
> [ 3535.924970] tun_get_user+0x5b9/0x1260 [tun]
> [ 3535.929279] tun_sendmsg+0x52/0x70 [tun]
> [ 3535.933237] handle_tx+0x2ad/0x5f0 [vhost_net]
> [ 3535.937721] vhost_worker+0xa5/0x100 [vhost]
> [ 3535.942030] kthread+0xf5/0x130
> [ 3535.945198] ? vhost_dev_ioctl+0x3b0/0x3b0 [vhost]
> [ 3535.950031] ? kthread_bind+0x10/0x10
> [ 3535.953727] ret_from_fork+0x35/0x40
> [ 3535.957334] Code: 0e 74 15 83 f8 10 75 05 e9 49 aa b3 ff f3 c3 0f 1f 80 00 00 00 00 f3 c3 e9 29 9d b3 ff 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 <8b> 47 18 83 f8 0e 74 0d 83 f8 10 75 05 e9 49 a9 b3 ff 31 c0 c3
> [ 3535.976387] RIP: __xdp_map_lookup_elem+0x5/0x30 RSP: ffffb4bc47bf7c58
> [ 3535.982883] CR2: 0000000000000018
> [ 3535.987096] ---[ end trace 383b299dd1430240 ]---
> [ 3536.131325] Kernel panic - not syncing: Fatal exception
> [ 3536.137484] Kernel Offset: 0x26a00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
> [ 3536.281406] ---[ end Kernel panic - not syncing: Fatal exception ]---
>
> And a kernel with generic case fixed still panics in tun driver XDP
> redirect, because it did not disable bh.
>
> [ 2055.128746] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
> [ 2055.136662] PGD 0 P4D 0
> [ 2055.139219] Oops: 0000 [#1] SMP PTI
> [ 2055.142736] Modules linked in: vhost_net vhost tap tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter sunrpc vfat fat ext4 mbcache jbd2 intel_rapl skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc ses aesni_intel ipmi_ssif crypto_simd enclosure cryptd hpwdt glue_helper ioatdma hpilo wmi dca pcspkr ipmi_si acpi_power_meter ipmi_devintf shpchp mei_me ipmi_msghandler mei lpc_ich sch_fq_codel ip_tables xfs libcrc32c sd_mod mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm i40e smartpqi tg3 scsi_transport_sas crc32c_intel i2c_core ptp pps_core
> [ 2055.206142] CPU: 6 PID: 1693 Comm: vhost-1683 Tainted: G W 4.17.0-rc5-fix-tun+ #1
> [ 2055.215011] Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 11/14/2017
> [ 2055.223617] RIP: 0010:__xdp_map_lookup_elem+0x5/0x30
> [ 2055.228624] RSP: 0018:ffff998b07607cc0 EFLAGS: 00010246
> [ 2055.233892] RAX: ffff8dbd8e235700 RBX: ffff8dbd8ff21c40 RCX: 0000000000000004
> [ 2055.241089] RDX: ffff998b097a9000 RSI: 0000000000000000 RDI: 0000000000000000
> [ 2055.248286] RBP: 0000000000000000 R08: 00000000000065a8 R09: 0000000000005d80
> [ 2055.255483] R10: 0000000000000040 R11: ffff8dbcf0100000 R12: ffff998b097a9000
> [ 2055.262681] R13: ffff8dbd8c98c000 R14: 0000000000000000 R15: ffff998b07607d78
> [ 2055.269879] FS: 0000000000000000(0000) GS:ffff8dbd8ff00000(0000) knlGS:0000000000000000
> [ 2055.278039] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 2055.283834] CR2: 0000000000000018 CR3: 0000000c0c8cc005 CR4: 00000000007626e0
> [ 2055.291030] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 2055.298227] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 2055.305424] PKRU: 55555554
> [ 2055.308153] Call Trace:
> [ 2055.310624] xdp_do_redirect+0x7b/0x380
> [ 2055.314499] tun_get_user+0x10fe/0x12a0 [tun]
> [ 2055.318895] tun_sendmsg+0x52/0x70 [tun]
> [ 2055.322852] handle_tx+0x2ad/0x5f0 [vhost_net]
> [ 2055.327337] vhost_worker+0xa5/0x100 [vhost]
> [ 2055.331646] kthread+0xf5/0x130
> [ 2055.334813] ? vhost_dev_ioctl+0x3b0/0x3b0 [vhost]
> [ 2055.339646] ? kthread_bind+0x10/0x10
> [ 2055.343343] ret_from_fork+0x35/0x40
> [ 2055.346950] Code: 0e 74 15 83 f8 10 75 05 e9 e9 aa b3 ff f3 c3 0f 1f 80 00 00 00 00 f3 c3 e9 c9 9d b3 ff 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 <8b> 47 18 83 f8 0e 74 0d 83 f8 10 75 05 e9 e9 a9 b3 ff 31 c0 c3
> [ 2055.366004] RIP: __xdp_map_lookup_elem+0x5/0x30 RSP: ffff998b07607cc0
> [ 2055.372500] CR2: 0000000000000018
> [ 2055.375856] ---[ end trace 2a2dcc5e9e174268 ]---
> [ 2055.523626] Kernel panic - not syncing: Fatal exception
> [ 2055.529796] Kernel Offset: 0x2e000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
> [ 2055.677539] ---[ end Kernel panic - not syncing: Fatal exception ]---
>
> Fixes: 761876c857cb ("tap: XDP support")
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> ---
> drivers/net/tun.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 45d8077..4fc7dbf 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -1650,6 +1650,7 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
> else
> *skb_xdp = 0;
>
> + local_bh_disable();
> preempt_disable();
> rcu_read_lock();
> xdp_prog = rcu_dereference(tun->xdp_prog);
> @@ -1676,6 +1677,7 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
> goto err_redirect;
> rcu_read_unlock();
> preempt_enable();
> + local_bh_enable();
> return NULL;
> case XDP_TX:
> get_page(alloc_frag->page);
> @@ -1685,6 +1687,7 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
> tun_xdp_flush(tun->dev);
> rcu_read_unlock();
> preempt_enable();
> + local_bh_enable();
> return NULL;
> case XDP_PASS:
> delta = orig_data - xdp.data;
> @@ -1704,6 +1707,7 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
> if (!skb) {
> rcu_read_unlock();
> preempt_enable();
> + local_bh_enable();
> return ERR_PTR(-ENOMEM);
> }
>
> @@ -1714,6 +1718,7 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
>
> rcu_read_unlock();
> preempt_enable();
> + local_bh_enable();
>
> return skb;
>
> @@ -1722,6 +1727,7 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
> err_xdp:
> rcu_read_unlock();
> preempt_enable();
> + local_bh_enable();
> this_cpu_inc(tun->pcpu_stats->rx_dropped);
> return NULL;
> }
> @@ -1917,16 +1923,22 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
> struct bpf_prog *xdp_prog;
> int ret;
>
> + local_bh_disable();
> + preempt_disable();
> rcu_read_lock();
> xdp_prog = rcu_dereference(tun->xdp_prog);
> if (xdp_prog) {
> ret = do_xdp_generic(xdp_prog, skb);
> if (ret != XDP_PASS) {
> rcu_read_unlock();
> + preempt_enable();
> + local_bh_enable();
> return total_len;
> }
> }
> rcu_read_unlock();
> + preempt_enable();
> + local_bh_enable();
> }
>
> rcu_read_lock();
Good catch, thanks.
But I think we can just replace preempt_disable()/enable() with
local_bh_disable()/local_bh_enable() ?
Thanks
^ permalink raw reply
* Re: [net-next] ath10k: Remove useless test before clk_disable_unprepare
From: Kalle Valo @ 2018-05-25 10:04 UTC (permalink / raw)
To: YueHaibing
Cc: kvalo-A+ZNKFmMK5xy9aJCnZT0Uw, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, YueHaibing
In-Reply-To: <20180516105454.30212-1-yuehaibing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
YueHaibing <yuehaibing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote:
> clk_disable_unprepare() already checks that the clock pointer is valid.
> No need to test it before calling it.
>
> Signed-off-by: YueHaibing <yuehaibing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Patch applied to ath-next branch of ath.git, thanks.
cf3c0ae6a32b ath10k: remove useless test before clk_disable_unprepare
--
https://patchwork.kernel.org/patch/10403597/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH net-next 0/7] net: bridge: Notify about bridge VLANs
From: Petr Machata @ 2018-05-25 10:09 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, devel, bridge, jiri, idosch, davem, razvan.stefanescu,
gregkh, stephen, andrew, vivien.didelot, nikolay
In-Reply-To: <61962919-cf93-cd7b-f248-9dfee5c9529d@gmail.com>
Florian Fainelli <f.fainelli@gmail.com> writes:
> You seem to have approached the bridge changes a little differently from
> this series:
>
> https://lists.linux-foundation.org/pipermail/bridge/2016-November/010112.html
It pretty much extends the patchset to also send the notifications for
the CPU port.
I missed this e-mail yesterday and now I see you already found out for
yourself how it behaves.
> Both have the same intent that by targeting the bridge device itself,
> you can propagate that through switchdev to the switch drivers, and in
> turn create configurations where for instance, you have:
>
> - CPU/management port present in specific VLANs that is a subset or
> superset of the VLANs configured on front-panel ports
> - CPU/management port tagged/untagged in specific VLANs which can be a
> different setting from the front-panel ports
>
> One problem we have in DSA at the moment is that we always add the CPU
> port to the VLANs configured to the front-panel port but we do this with
> the same attributes as the front panel ports! For instance, if you add
> Port 0 to VLAN1 untagged, the the CPU port also gets added to that
> VLAN1, also untagged. As long as there is just one VLAN untagged, this
> is not much of a problem. Now do this with another VLAN or another port,
> and the CPU can no longer differentiate the traffic from which VLAN it
> is coming from, no bueno.
Yep, with this patchset you should be able to use the CPU port
notifications to configure things exactly.
> bridge vlan add vid 2 dev port0 pvid untagged
> -> port0 (e.g: switch port 0) gets programmed
> -> CPU port gets programmed
> bridge vlan add vid 2 dev br0 self
> -> CPU port gets programmed
> bridge vlan add vid 2 dev port0
> -> port0 (switch port 0) gets programmed
>
> Are these use cases possible with your series? It seems to me like it is
> if we drop the netif_is_bridge_master() checks and resolve orig_dev as
> being a hint for the CPU/management port.
Yeah, that's how it behaves. If you accept the events where
netif_is_bridge_master(orig_dev), you can tell the CPU port-related
events from the rest by BRIDGE_VLAN_INFO_BRENTRY.
Thanks,
Petr
^ permalink raw reply
* [PATCH v2 net-next] tcp: use data length instead of skb->len in tcp_probe
From: Yafang Shao @ 2018-05-25 10:14 UTC (permalink / raw)
To: songliubraving; +Cc: davem, netdev, linux-kernel, Yafang Shao
skb->len is meaningless to user.
data length could be more helpful, with which we can easily filter out
the packet without payload.
Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
---
include/trace/events/tcp.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/trace/events/tcp.h b/include/trace/events/tcp.h
index c1a5284..703abb6 100644
--- a/include/trace/events/tcp.h
+++ b/include/trace/events/tcp.h
@@ -236,7 +236,7 @@
__field(__u16, sport)
__field(__u16, dport)
__field(__u32, mark)
- __field(__u16, length)
+ __field(__u16, data_len)
__field(__u32, snd_nxt)
__field(__u32, snd_una)
__field(__u32, snd_cwnd)
@@ -261,7 +261,7 @@
__entry->dport = ntohs(inet->inet_dport);
__entry->mark = skb->mark;
- __entry->length = skb->len;
+ __entry->data_len = skb->len - tcp_hdrlen(skb);
__entry->snd_nxt = tp->snd_nxt;
__entry->snd_una = tp->snd_una;
__entry->snd_cwnd = tp->snd_cwnd;
@@ -272,9 +272,9 @@
__entry->sock_cookie = sock_gen_cookie(sk);
),
- TP_printk("src=%pISpc dest=%pISpc mark=%#x length=%d snd_nxt=%#x snd_una=%#x snd_cwnd=%u ssthresh=%u snd_wnd=%u srtt=%u rcv_wnd=%u sock_cookie=%llx",
+ TP_printk("src=%pISpc dest=%pISpc mark=%#x data_len=%d snd_nxt=%#x snd_una=%#x snd_cwnd=%u ssthresh=%u snd_wnd=%u srtt=%u rcv_wnd=%u sock_cookie=%llx",
__entry->saddr, __entry->daddr, __entry->mark,
- __entry->length, __entry->snd_nxt, __entry->snd_una,
+ __entry->data_len, __entry->snd_nxt, __entry->snd_una,
__entry->snd_cwnd, __entry->ssthresh, __entry->snd_wnd,
__entry->srtt, __entry->rcv_wnd, __entry->sock_cookie)
);
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next] bpfilter: fix a build err
From: YueHaibing @ 2018-05-25 10:17 UTC (permalink / raw)
To: davem, ast; +Cc: netdev, linux-kernel, YueHaibing
gcc-7.3.0 report following err:
HOSTCC net/bpfilter/main.o
In file included from net/bpfilter/main.c:9:0:
./include/uapi/linux/bpf.h:12:10: fatal error: linux/bpf_common.h: No such file or directory
#include <linux/bpf_common.h>
remove it by adding a include path.
Fixes: d2ba09c17a06 ("net: add skeleton of bpfilter kernel module")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
net/bpfilter/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bpfilter/Makefile b/net/bpfilter/Makefile
index 2af752c..3f3cb87 100644
--- a/net/bpfilter/Makefile
+++ b/net/bpfilter/Makefile
@@ -5,7 +5,7 @@
hostprogs-y := bpfilter_umh
bpfilter_umh-objs := main.o
-HOSTCFLAGS += -I. -Itools/include/
+HOSTCFLAGS += -I. -Itools/include/ -Itools/include/uapi
ifeq ($(CONFIG_BPFILTER_UMH), y)
# builtin bpfilter_umh should be compiled with -static
# since rootfs isn't mounted at the time of __init
--
2.7.0
^ permalink raw reply related
* Re: [v3] wcn36xx: Add support for Factory Test Mode (FTM)
From: Kalle Valo @ 2018-05-25 10:18 UTC (permalink / raw)
To: Ramon Fried
Cc: linux-kernel, wcn36xx, linux-wireless, netdev, Eyal Ilsar,
Ramon Fried
In-Reply-To: <20180522190256.32136-1-ramon.fried@gmail.com>
Ramon Fried <ramon.fried@gmail.com> wrote:
> Introduce infrastructure for supporting Factory Test Mode (FTM) of the
> wireless LAN subsystem. In order for the user space to access the
> firmware in test mode the relevant netlink channel needs to be exposed
> from the kernel driver.
>
> The above is achieved as follows:
> 1) Register wcn36xx driver to testmode callback from netlink
> 2) Add testmode callback implementation to handle incoming FTM commands
> 3) Add FTM command packet structure
> 4) Add handling for GET_BUILD_RELEASE_NUMBER (msgid=0x32A2)
> 5) Add generic handling for all PTT_MSG packets
>
> Signed-off-by: Eyal Ilsar <eilsar@codeaurora.org>
> Signed-off-by: Ramon Fried <ramon.fried@linaro.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
87f825e6e246 wcn36xx: Add support for Factory Test Mode (FTM)
--
https://patchwork.kernel.org/patch/10419423/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 0/4] RFC CPSW switchdev mode
From: Ilias Apalodimas @ 2018-05-25 10:28 UTC (permalink / raw)
To: Andrew Lunn
Cc: Ivan Vecera, Jiri Pirko, netdev, grygorii.strashko,
ivan.khoronzhuk, nsekhar, francois.ozog, yogeshs, spatton
In-Reply-To: <20180525062902.GA11526@apalos>
On Fri, May 25, 2018 at 09:29:02AM +0300, Ilias Apalodimas wrote:
> On Thu, May 24, 2018 at 06:33:10PM +0200, Andrew Lunn wrote:
> > On Thu, May 24, 2018 at 07:02:54PM +0300, Ilias Apalodimas wrote:
> > > On Thu, May 24, 2018 at 05:25:59PM +0200, Andrew Lunn wrote:
> > > > O.K, back to the basic idea. Switch ports are just normal Linux
> > > > interfaces.
> > > >
> > > > How would you configure this with two e1000e put in a bridge? I want
> > > > multicast to be bridged between the two e1000e, but the host stack
> > > > should not see the packets.
> > > I am not sure i am following. I might be missing something. In your case you
> > > got two ethernet pci/pcie interfaces bridged through software. You can filter
> > > those if needed. In the case we are trying to cover, you got a hardware that
> > > offers that capability. Since not all switches are pcie based shouldn't we be
> > > able to allow this ?
> >
> > switchdev is about offloading what Linux can do to hardware to
> > accelerate it. The switch is a block of accelerator hardware, like a
> > GPU is for accelerating graphics. Linux can render OpenGL, but it is
> > better to hand it over to the GPU accelerator.
> >
> > Same applies here. The Linux bridge can bridge multicast. Using the
> > switchdev API, you can push that down to the accelerator, and let it
> > do it.
> >
> > So you need to think about, how do you make the Linux bridge not pass
> > multicast traffic to the host stack. Then how do you extend the
> > switchdev API so you can push this down to the accelerator.
> >
> > To really get switchdev, you often need to pivot your point of view a
> > bit. People often think, switchdev is about writing drivers for
> > switches. Its not, its about how you offload networking which Linux
> > can do down to a switch. And if the switch cannot accelerate it, you
> > leave Linux to do it.
> >
> > When you get in the details, i think you will find the switchdev API
> > actually already has what you need for this use case. What you need to
> > figure out is how you make the Linux bridge not pass multicast to the
> > host. Well, actually, not pass multicast it has not asked for. Then
> > accelerate it.
> >
> Understood, if we missed back anything on handling multicast for
> the cpu port we'll go back and fix it (i am assuming snooping is the answer
> here). Multicasting is only one part of the equation though. What about the
> need for vlans/FDBs on that port though?
>
I just noticed this: https://www.spinics.net/lists/netdev/msg504760.html
I tried doing the "bridge vlan add vid 2 dev br0 self" in my initial attempts
but didn't get a notification to program the CPU port(with the sef argument).
This obviously solves our vlan configuration issue. So it's only static FBDs
left.
Regards
Ilias
^ permalink raw reply
* [PATCH net] ipv6: sr: fix memory OOB access in seg6_do_srh_encap/inline
From: Mathieu Xhonneux @ 2018-05-25 12:29 UTC (permalink / raw)
To: netdev; +Cc: dlebrun
seg6_do_srh_encap and seg6_do_srh_inline can possibly do an
out-of-bounds access when adding the SRH to the packet. This no longer
happen when expanding the skb not only by the size of the SRH (+
outer IPv6 header), but also by skb->mac_len.
[ 53.793056] BUG: KASAN: use-after-free in seg6_do_srh_encap+0x284/0x620
[ 53.794564] Write of size 14 at addr ffff88011975ecfa by task ping/674
[ 53.796665] CPU: 0 PID: 674 Comm: ping Not tainted 4.17.0-rc3-ARCH+ #90
[ 53.796670] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.11.0-20171110_100015-anatol 04/01/2014
[ 53.796673] Call Trace:
[ 53.796679] <IRQ>
[ 53.796689] dump_stack+0x71/0xab
[ 53.796700] print_address_description+0x6a/0x270
[ 53.796707] kasan_report+0x258/0x380
[ 53.796715] ? seg6_do_srh_encap+0x284/0x620
[ 53.796722] memmove+0x34/0x50
[ 53.796730] seg6_do_srh_encap+0x284/0x620
[ 53.796741] ? seg6_do_srh+0x29b/0x360
[ 53.796747] seg6_do_srh+0x29b/0x360
[ 53.796756] seg6_input+0x2e/0x2e0
[ 53.796765] lwtunnel_input+0x93/0xd0
[ 53.796774] ipv6_rcv+0x690/0x920
[ 53.796783] ? ip6_input+0x170/0x170
[ 53.796791] ? eth_gro_receive+0x2d0/0x2d0
[ 53.796800] ? ip6_input+0x170/0x170
[ 53.796809] __netif_receive_skb_core+0xcc0/0x13f0
[ 53.796820] ? netdev_info+0x110/0x110
[ 53.796827] ? napi_complete_done+0xb6/0x170
[ 53.796834] ? e1000_clean+0x6da/0xf70
[ 53.796845] ? process_backlog+0x129/0x2a0
[ 53.796853] process_backlog+0x129/0x2a0
[ 53.796862] net_rx_action+0x211/0x5c0
[ 53.796870] ? napi_complete_done+0x170/0x170
[ 53.796887] ? run_rebalance_domains+0x11f/0x150
[ 53.796891] __do_softirq+0x10e/0x39e
[ 53.796894] do_softirq_own_stack+0x2a/0x40
[ 53.796895] </IRQ>
[ 53.796898] do_softirq.part.16+0x54/0x60
[ 53.796900] __local_bh_enable_ip+0x5b/0x60
[ 53.796903] ip6_finish_output2+0x416/0x9f0
[ 53.796906] ? ip6_dst_lookup_flow+0x110/0x110
[ 53.796909] ? ip6_sk_dst_lookup_flow+0x390/0x390
[ 53.796911] ? __rcu_read_unlock+0x66/0x80
[ 53.796913] ? ip6_mtu+0x44/0xf0
[ 53.796916] ? ip6_output+0xfc/0x220
[ 53.796918] ip6_output+0xfc/0x220
[ 53.796921] ? ip6_finish_output+0x2b0/0x2b0
[ 53.796923] ? memcpy+0x34/0x50
[ 53.796926] ip6_send_skb+0x43/0xc0
[ 53.796929] rawv6_sendmsg+0x1216/0x1530
[ 53.796932] ? __orc_find+0x6b/0xc0
[ 53.796934] ? rawv6_rcv_skb+0x160/0x160
[ 53.796937] ? __rcu_read_unlock+0x66/0x80
[ 53.796939] ? __rcu_read_unlock+0x66/0x80
[ 53.796942] ? is_bpf_text_address+0x1e/0x30
[ 53.796944] ? kernel_text_address+0xec/0x100
[ 53.796946] ? __kernel_text_address+0xe/0x30
[ 53.796948] ? unwind_get_return_address+0x2f/0x50
[ 53.796950] ? __save_stack_trace+0x92/0x100
[ 53.796954] ? save_stack+0x89/0xb0
[ 53.796956] ? kasan_kmalloc+0xa0/0xd0
[ 53.796958] ? kmem_cache_alloc+0xd2/0x1f0
[ 53.796961] ? prepare_creds+0x23/0x160
[ 53.796963] ? __x64_sys_capset+0x252/0x3e0
[ 53.796966] ? do_syscall_64+0x69/0x160
[ 53.796968] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 53.796971] ? __alloc_pages_nodemask+0x170/0x380
[ 53.796973] ? __alloc_pages_slowpath+0x12c0/0x12c0
[ 53.796977] ? tty_vhangup+0x20/0x20
[ 53.796979] ? policy_nodemask+0x1a/0x90
[ 53.796982] ? __mod_node_page_state+0x8d/0xa0
[ 53.796986] ? __check_object_size+0xe7/0x240
[ 53.796989] ? __sys_sendto+0x229/0x290
[ 53.796991] ? rawv6_rcv_skb+0x160/0x160
[ 53.796993] __sys_sendto+0x229/0x290
[ 53.796996] ? __ia32_sys_getpeername+0x50/0x50
[ 53.796999] ? commit_creds+0x2de/0x520
[ 53.797002] ? security_capset+0x57/0x70
[ 53.797004] ? __x64_sys_capset+0x29f/0x3e0
[ 53.797007] ? __x64_sys_rt_sigsuspend+0xe0/0xe0
[ 53.797011] ? __do_page_fault+0x664/0x770
[ 53.797014] __x64_sys_sendto+0x74/0x90
[ 53.797017] do_syscall_64+0x69/0x160
[ 53.797019] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 53.797022] RIP: 0033:0x7f43b7a6714a
[ 53.797023] RSP: 002b:00007ffd891bd368 EFLAGS: 00000246 ORIG_RAX:
000000000000002c
[ 53.797026] RAX: ffffffffffffffda RBX: 00000000006129c0 RCX: 00007f43b7a6714a
[ 53.797028] RDX: 0000000000000040 RSI: 00000000006129c0 RDI: 0000000000000004
[ 53.797029] RBP: 00007ffd891be640 R08: 0000000000610940 R09: 000000000000001c
[ 53.797030] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000040
[ 53.797032] R13: 000000000060e6a0 R14: 0000000000008004 R15: 000000000040b661
[ 53.797171] Allocated by task 642:
[ 53.797460] kasan_kmalloc+0xa0/0xd0
[ 53.797463] kmem_cache_alloc+0xd2/0x1f0
[ 53.797465] getname_flags+0x40/0x210
[ 53.797467] user_path_at_empty+0x1d/0x40
[ 53.797469] do_faccessat+0x12a/0x320
[ 53.797471] do_syscall_64+0x69/0x160
[ 53.797473] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 53.797607] Freed by task 642:
[ 53.797869] __kasan_slab_free+0x130/0x180
[ 53.797871] kmem_cache_free+0xa8/0x230
[ 53.797872] filename_lookup+0x15b/0x230
[ 53.797874] do_faccessat+0x12a/0x320
[ 53.797876] do_syscall_64+0x69/0x160
[ 53.797878] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 53.798014] The buggy address belongs to the object at ffff88011975e600
which belongs to the cache names_cache of size 4096
[ 53.799043] The buggy address is located 1786 bytes inside of
4096-byte region [ffff88011975e600, ffff88011975f600)
[ 53.800013] The buggy address belongs to the page:
[ 53.800414] page:ffffea000465d600 count:1 mapcount:0
mapping:0000000000000000 index:0x0 compound_mapcount: 0
[ 53.801259] flags: 0x17fff0000008100(slab|head)
[ 53.801640] raw: 017fff0000008100 0000000000000000 0000000000000000
0000000100070007
[ 53.803147] raw: dead000000000100 dead000000000200 ffff88011b185a40
0000000000000000
[ 53.803787] page dumped because: kasan: bad access detected
[ 53.804384] Memory state around the buggy address:
[ 53.804788] ffff88011975eb80: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[ 53.805384] ffff88011975ec00: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[ 53.805979] >ffff88011975ec80: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[ 53.806577] ^
[ 53.807165] ffff88011975ed00: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[ 53.807762] ffff88011975ed80: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[ 53.808356] ==================================================================
[ 53.808949] Disabling lock debugging due to kernel taint
Fixes: 6c8702c60b88 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")
Signed-off-by: David Lebrun <dlebrun@google.com>
Signed-off-by: Mathieu Xhonneux <m.xhonneux@gmail.com>
---
net/ipv6/seg6_iptunnel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/seg6_iptunnel.c b/net/ipv6/seg6_iptunnel.c
index 5fe139484919..bf4763fd68c2 100644
--- a/net/ipv6/seg6_iptunnel.c
+++ b/net/ipv6/seg6_iptunnel.c
@@ -103,7 +103,7 @@ int seg6_do_srh_encap(struct sk_buff *skb, struct ipv6_sr_hdr *osrh, int proto)
hdrlen = (osrh->hdrlen + 1) << 3;
tot_len = hdrlen + sizeof(*hdr);
- err = skb_cow_head(skb, tot_len);
+ err = skb_cow_head(skb, tot_len + skb->mac_len);
if (unlikely(err))
return err;
@@ -161,7 +161,7 @@ int seg6_do_srh_inline(struct sk_buff *skb, struct ipv6_sr_hdr *osrh)
hdrlen = (osrh->hdrlen + 1) << 3;
- err = skb_cow_head(skb, hdrlen);
+ err = skb_cow_head(skb, hdrlen + skb->mac_len);
if (unlikely(err))
return err;
--
2.16.1
^ permalink raw reply related
* Re: [PATCH 2/8] batman-adv: Disable CONFIG_BATMAN_ADV_DEBUGFS by default
From: Sergei Shtylyov @ 2018-05-25 10:33 UTC (permalink / raw)
To: Simon Wunderlich, davem; +Cc: netdev, b.a.t.m.a.n, Sven Eckelmann
In-Reply-To: <20180524120300.15829-3-sw@simonwunderlich.de>
Hello!
On 5/24/2018 3:02 PM, Simon Wunderlich wrote:
> From: Sven Eckelmann <sven@narfation.org>
>
> All tools which were known to the batman-adv development team are
> supporting the batman-adv netlink interface since a while. Also debugfs is
> not supported for batman-adv interfaces in any non-default netns. Thus
> disabling CONFIG_BATMAN_ADV_DEBUGFS by default should not cause problems on
> most systems. It is still possible to enable it in case it is still
> required in a specific setup.
>
> Signed-off-by: Sven Eckelmann <sven@narfation.org>
> Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
> ---
> net/batman-adv/Kconfig | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/batman-adv/Kconfig b/net/batman-adv/Kconfig
> index e4e2e02b7380..bee034a95208 100644
> --- a/net/batman-adv/Kconfig
> +++ b/net/batman-adv/Kconfig
> @@ -94,13 +94,13 @@ config BATMAN_ADV_DEBUGFS
> bool "batman-adv debugfs entries"
> depends on BATMAN_ADV
> depends on DEBUG_FS
> - default y
> + default n
N is the default default. :-) You don't need this line.
[...]
MBR, Sergei
^ permalink raw reply
* Re: [v8, bpf-next, 4/9] net/wireless/iwlwifi: fix iwlwifi_dev_ucode_error tracepoint
From: Kalle Valo @ 2018-05-25 10:48 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Johannes Berg, Alexei Starovoitov, davem, daniel, torvalds,
peterz, rostedt, mathieu.desnoyers, netdev, kernel-team,
linux-api, linux-wireless
In-Reply-To: <20180524232837.24jvdsdiohkpj7fs@ast-mbp>
Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:
> On Wed, May 23, 2018 at 01:03:08PM +0200, Johannes Berg wrote:
>> On Wed, 2018-03-28 at 12:05 -0700, Alexei Starovoitov wrote:
>> > fix iwlwifi_dev_ucode_error tracepoint to pass pointer to a table
>> > instead of all 17 arguments by value.
>> > dvm/main.c and mvm/utils.c have 'struct iwl_error_event_table'
>> > defined with very similar yet subtly different fields and offsets.
>> > tracepoint is still common and using definition of 'struct iwl_error_event_table'
>> > from dvm/commands.h while copying fields.
>> > Long term this tracepoint probably should be split into two.
>>
>> It would've been nice to CC the wireless list for wireless related
>> patches ...
>
> Ohh. I didn't realize that networking wireless doesn't fall under netdev.
> I thought wireless folks are silent because they are embarrassed
> by a function with 17 arguments.
Really, this is the level of discussion now? You don't even bother to CC
the driver maintainers and your first reaction is that they are just too
embarrassed to answer? Oh man...
But if you continue doing these kind of "drive-by cleanups" to a
subsystem you are not familiar with, at least don't assume anything and
instead use get_maintainer script to find the maintainers so that the
patches get reviewed and applied to the correct tree:
$ scripts/get_maintainer.pl --no-rolestats --no-git -f drivers/net/wireless/intel/iwlwifi/dvm/main.c
Johannes Berg <johannes.berg@intel.com>
Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Luca Coelho <luciano.coelho@intel.com>
Intel Linux Wireless <linuxwifi@intel.com>
Kalle Valo <kvalo@codeaurora.org>
"David S. Miller" <davem@davemloft.net>
Daniel Borkmann <daniel@iogearbox.net>
Alexei Starovoitov <ast@kernel.org>
Kees Cook <keescook@chromium.org>
linux-wireless@vger.kernel.org
netdev@vger.kernel.org
linux-kernel@vger.kernel.org
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/8] batman-adv: Disable CONFIG_BATMAN_ADV_DEBUGFS by default
From: Sven Eckelmann @ 2018-05-25 10:50 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Simon Wunderlich, davem, netdev, b.a.t.m.a.n
In-Reply-To: <fec8128d-0021-74db-b047-305fb1f70104@cogentembedded.com>
[-- Attachment #1: Type: text/plain, Size: 679 bytes --]
On Freitag, 25. Mai 2018 13:33:59 CEST Sergei Shtylyov wrote:
[...]
> > --- a/net/batman-adv/Kconfig
> > +++ b/net/batman-adv/Kconfig
> > @@ -94,13 +94,13 @@ config BATMAN_ADV_DEBUGFS
> > bool "batman-adv debugfs entries"
> > depends on BATMAN_ADV
> > depends on DEBUG_FS
> > - default y
> > + default n
>
> N is the default default. :-) You don't need this line.
Hm, looks like this would have to be changed in a lot of places (~782
according to `git grep 'default n$'|wc -l` in my slightly outdated linux-
next). Do you want to fix it everywhere? Might be good to get this integrated
in checkpatch.pl when this will become a new policy.
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 10/13] dmaengine: pxa: document pxad_param
From: Vinod @ 2018-05-25 10:59 UTC (permalink / raw)
To: Robert Jarzmik
Cc: Daniel Mack, Haojian Zhuang, Ezequiel Garcia, Boris Brezillon,
David Woodhouse, Brian Norris, Marek Vasut, Richard Weinberger,
Liam Girdwood, Mark Brown, Arnd Bergmann, linux-arm-kernel,
linux-kernel, linux-ide, dmaengine, linux-media, linux-mmc,
linux-mtd, netdev, alsa-devel
In-Reply-To: <20180524070703.11901-11-robert.jarzmik@free.fr>
On 24-05-18, 09:07, Robert Jarzmik wrote:
> Add some documentation for the pxad_param structure, and describe the
> contract behind the minimal required priority of a DMA channel.
Acked-by: Vinod Koul <vkoul@kernel.org>
--
~Vinod
^ permalink raw reply
* Re: [PATCH v2 11/13] dmaengine: pxa: make the filter function internal
From: Vinod @ 2018-05-25 10:59 UTC (permalink / raw)
To: Robert Jarzmik
Cc: Daniel Mack, Haojian Zhuang, Ezequiel Garcia, Boris Brezillon,
David Woodhouse, Brian Norris, Marek Vasut, Richard Weinberger,
Liam Girdwood, Mark Brown, Arnd Bergmann, linux-arm-kernel,
linux-kernel, linux-ide, dmaengine, linux-media, linux-mmc,
linux-mtd, netdev, alsa-devel
In-Reply-To: <20180524070703.11901-12-robert.jarzmik@free.fr>
On 24-05-18, 09:07, Robert Jarzmik wrote:
> As the pxa architecture and all its related drivers do not rely anymore
> on the filter function, thanks to the slave map conversion, make
> pxad_filter_fn() static, and remove it from the global namespace.
Acked-by: Vinod Koul <vkoul@kernel.org>
--
~Vinod
^ permalink raw reply
* Re: [PATCH 2/8] batman-adv: Disable CONFIG_BATMAN_ADV_DEBUGFS by default
From: Sergei Shtylyov @ 2018-05-25 11:13 UTC (permalink / raw)
To: Sven Eckelmann
Cc: Joe Perches, netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <2946906.LStWHluSmG@bentobox>
On 5/25/2018 1:50 PM, Sven Eckelmann wrote:
> [...]
>>> --- a/net/batman-adv/Kconfig
>>> +++ b/net/batman-adv/Kconfig
>>> @@ -94,13 +94,13 @@ config BATMAN_ADV_DEBUGFS
>>> bool "batman-adv debugfs entries"
>>> depends on BATMAN_ADV
>>> depends on DEBUG_FS
>>> - default y
>>> + default n
>>
>> N is the default default. :-) You don't need this line.
>
> Hm, looks like this would have to be changed in a lot of places (~782
> according to `git grep 'default n$'|wc -l` in my slightly outdated linux-
> next). Do you want to fix it everywhere?
No, but we can at least not add the new ones...
> Might be good to get this integrated
> in checkpatch.pl when this will become a new policy.
Adding Joe Perches. Joe, can you add a check for "default n"?
> Kind regards,
> Sven
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 2/8] batman-adv: Disable CONFIG_BATMAN_ADV_DEBUGFS by default
From: Sven Eckelmann @ 2018-05-25 11:15 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Joe Perches, netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <6fd70d33-11f7-33dd-3b11-e5031fe46466-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 728 bytes --]
On Freitag, 25. Mai 2018 14:13:40 CEST Sergei Shtylyov wrote:
> > [...]
> >>> --- a/net/batman-adv/Kconfig
> >>> +++ b/net/batman-adv/Kconfig
> >>> @@ -94,13 +94,13 @@ config BATMAN_ADV_DEBUGFS
> >>> bool "batman-adv debugfs entries"
> >>> depends on BATMAN_ADV
> >>> depends on DEBUG_FS
> >>> - default y
> >>> + default n
> >>
> >> N is the default default. :-) You don't need this line.
> >
> > Hm, looks like this would have to be changed in a lot of places (~782
> > according to `git grep 'default n$'|wc -l` in my slightly outdated linux-
> > next). Do you want to fix it everywhere?
>
> No, but we can at least not add the new ones...
But the patch was added to net-next yesterday.
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] ath6kl: mark expected switch fall-throughs
From: Sergei Shtylyov @ 2018-05-25 11:27 UTC (permalink / raw)
To: Gustavo A. R. Silva, Kalle Valo, David S. Miller
Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20180524231322.GA22704@embeddedor.com>
Hello!
On 5/25/2018 2:13 AM, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> ---
> drivers/net/wireless/ath/ath6kl/cfg80211.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c b/drivers/net/wireless/ath/ath6kl/cfg80211.c
> index 2ba8cf3..29e32cd 100644
> --- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
> +++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
> @@ -3898,17 +3898,17 @@ int ath6kl_cfg80211_init(struct ath6kl *ar)
> wiphy->max_scan_ie_len = 1000; /* FIX: what is correct limit? */
> switch (ar->hw.cap) {
> case WMI_11AN_CAP:
> - ht = true;
> + ht = true; /* fall through */
> case WMI_11A_CAP:
> band_5gig = true;
> break;
> case WMI_11GN_CAP:
> - ht = true;
> + ht = true; /* fall through */
> case WMI_11G_CAP:
> band_2gig = true;
> break;
> case WMI_11AGN_CAP:
> - ht = true;
> + ht = true; /* fall through */
> case WMI_11AG_CAP:
> band_2gig = true;
> band_5gig = true;
Hm, typically such comments are done on a line of their own, have never
seen this style...
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v2 net-next] sfc: stop the TX queue before pushing new buffers
From: Edward Cree @ 2018-05-25 11:57 UTC (permalink / raw)
To: Martin Habets, linux-net-drivers, davem; +Cc: netdev, jarod
In-Reply-To: <f2749cb0-f1ce-4572-04fe-f1c11fe09237@solarflare.com>
On 24/05/18 10:14, Martin Habets wrote:
> efx_enqueue_skb() can push new buffers for the xmit_more functionality.
> We must stops the TX queue before this or else the TX queue does not get
> restarted and we get a netdev watchdog.
>
> In the error handling we may now need to unwind more than 1 packet, and
> we may need to push the new buffers onto the partner queue.
>
> v2: In the error leg also push this queue if xmit_more is set
>
> Fixes: e9117e5099ea ("sfc: Firmware-Assisted TSO version 2")
> Reported-by: Jarod Wilson <jarod@redhat.com>
> Tested-by: Jarod Wilson <jarod@redhat.com>
> Signed-off-by: Martin Habets <mhabets@solarflare.com>
Acked-by: Edward Cree <ecree@solarflare.com>
^ 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