* Re: [PATCH net-next v7 1/3] vmcore: add API to collect hardware dump in second kernel
From: kbuild test robot @ 2018-05-01 20:44 UTC (permalink / raw)
To: Rahul Lakkireddy
Cc: kbuild-all, netdev, kexec, linux-fsdevel, linux-kernel, davem,
viro, ebiederm, stephen, akpm, torvalds, ganeshgr, nirranjan,
indranil, Rahul Lakkireddy
In-Reply-To: <b6065b53c5446d98ee55e09119f6821f979418d4.1525197408.git.rahul.lakkireddy@chelsio.com>
[-- Attachment #1: Type: text/plain, Size: 730 bytes --]
Hi Rahul,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Rahul-Lakkireddy/vmcore-add-API-to-collect-hardware-dump-in-second-kernel/20180502-023638
config: i386-tinyconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
>> ./usr/include/linux/vmcore.h:9: found __[us]{8,16,32,64} type without #include <linux/types.h>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 6293 bytes --]
^ permalink raw reply
* Re: [RFC net-next 4/5] net: phy: Add support for IEEE standard test modes
From: Florian Fainelli @ 2018-05-01 20:51 UTC (permalink / raw)
To: Woojung.Huh, netdev
Cc: andrew, rmk, linux-kernel, davem, cphealy, nikita.yoush,
vivien.didelot, Nisar.Sayed, UNGLinuxDriver
In-Reply-To: <9235D6609DB808459E95D78E17F2E43D40D55B0A@CHN-SV-EXMX02.mchp-main.com>
On 05/01/2018 01:07 PM, Woojung.Huh@microchip.com wrote:
> Hi Florian,
>
>> Not sure I completely understand your suggestion, do you mean that I
>> should break down the body of that function above such that there are
>> per-speed lower level functions? Something like the pseudo-code below:
>>
>> genphy_set_test() {
>> switch (mode) {
>> case PHY_STD_TEST_MODE_100BASET2_1:
>> ..
>> case PHY_STD_TEST_MODE_100BASET2_3:
>> return genphy_set_100baset2();
>>
>> case PHY_STD_TEST_MODE_1000BASET_1:
>> ..
>> case PHY_STD_TEST_MODE_1000BASET_4:
>> return genphy_set_1000baset();
>>
>> case PHY_STD_TEST_MODE_8021BWQCQ_1:
>> return genphy_set_100baset1();
>>
>> }
> Yes, I should write pseudo code. Sorry about confusion.
> User can override this function or expand to other modes.
Well, the way the code is structure is that if you call that function
with a test mode value that is not part of the standard set, it returns
-EOPNOTSUPP, so if your particular PHY driver wants to "overlay"
standard and non-standard modes, it can by using that hint.
This should work even if we have more standard test modes in the future
because the test modes are dynamically fetched by user-space using the
ETH_GSTRINGS ioctl().
Does that cover what you had in mind?
--
Florian
^ permalink raw reply
* [PATCH] net: stmmac: Avoid VLA usage
From: Kees Cook @ 2018-05-01 21:01 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue; +Cc: linux-kernel, netdev, Jose Abreu
In the quest to remove all stack VLAs from the kernel[1], this switches
the "status" stack buffer to use the existing small (8) upper bound on
how many queues can be checked for DMA, and adds a sanity-check just to
make sure it doesn't operate under pathological conditions.
[1] http://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com
Signed-off-by: Kees Cook <keescook@chromium.org>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index b65e2d144698..19bdc23fa314 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2045,7 +2045,11 @@ static void stmmac_dma_interrupt(struct stmmac_priv *priv)
tx_channel_count : rx_channel_count;
u32 chan;
bool poll_scheduled = false;
- int status[channels_to_check];
+ int status[max_t(u32, MTL_MAX_TX_QUEUES, MTL_MAX_RX_QUEUES)];
+
+ /* Make sure we never check beyond our status buffer. */
+ if (WARN_ON_ONCE(channels_to_check > ARRAY_SIZE(status)))
+ channels_to_check = ARRAY_SIZE(status);
/* Each DMA channel can be used for rx and tx simultaneously, yet
* napi_struct is embedded in struct stmmac_rx_queue rather than in a
--
2.7.4
--
Kees Cook
Pixel Security
^ permalink raw reply related
* Re: [PATCH bpf-nex] tools: bpftool: change time format for program 'loaded at:' information
From: Alexei Starovoitov @ 2018-05-01 21:25 UTC (permalink / raw)
To: Quentin Monnet; +Cc: ast, borkmann, netdev, oss-drivers
In-Reply-To: <1525205918-16779-1-git-send-email-quentin.monnet@netronome.com>
On Tue, May 01, 2018 at 09:18:38PM +0100, Quentin Monnet wrote:
> To make eBPF program load time easier to parse from "bpftool prog"
> output for machines, change the time format used by the program. The
> format now differs for plain and JSON version:
>
> - Plain version uses a string formatted according to ISO 8601.
> - JSON uses the number of seconds since the Epoch, wich is less friendly
> for humans but even easier to process.
>
> Example output:
>
> # ./bpftool prog
> 41298: xdp tag a04f5eef06a7f555 dev foo
> loaded_at 2018-04-18T17:19:47+0100 uid 0
> xlated 16B not jited memlock 4096B
>
> # ./bpftool prog -p
> [{
> "id": 41298,
> "type": "xdp",
> "tag": "a04f5eef06a7f555",
> "gpl_compatible": false,
> "dev": {
> "ifindex": 14,
> "ns_dev": 3,
> "ns_inode": 4026531993,
> "ifname": "foo"
> },
> "loaded_at": 1524068387,
> "uid": 0,
> "bytes_xlated": 16,
> "jited": false,
> "bytes_memlock": 4096
> }
> ]
>
> Previously, "Apr 18/17:19" would be used at both places.
>
> Suggested-by: Alexei Starovoitov <ast@kernel.org>
> Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
> Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Applied, Thanks!
^ permalink raw reply
* Re: [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc
From: Toke Høiland-Jørgensen @ 2018-05-01 21:54 UTC (permalink / raw)
To: Eric Dumazet, Eric Dumazet, Dave Taht, Cong Wang
Cc: Linux Kernel Network Developers, Cake List
In-Reply-To: <c43e3156-dce2-ced7-3a8f-47fe756202f9@gmail.com>
Eric Dumazet <eric.dumazet@gmail.com> writes:
> On 05/01/2018 12:31 PM, Toke Høiland-Jørgensen wrote:
>
>> Could you comment on specifically what you believe is broken in this,
>> please, so I can fix it in the same iteration?
>>
>
> Apart from the various pskb_may_pull() this helper should not change skb layout.
>
> Ideally, the skb should be const and you would use
> skb_header_pointer() to make clear you do not ever write this skb.
>
> This would make the reviewer job pretty easy, as no side effect can
> possibly happen.
Gotcha. Will fix; thanks :)
-Toke
^ permalink raw reply
* Re: [PATCH bpf] bpf: minor fix to selftest test_stacktrace_build_id()
From: Daniel Borkmann @ 2018-05-01 22:19 UTC (permalink / raw)
To: Song Liu, netdev; +Cc: kernel-team, Alexei Starovoitov
In-Reply-To: <20180501172024.781777-1-songliubraving@fb.com>
On 05/01/2018 07:20 PM, Song Liu wrote:
> 1. remove useless parameter list to ./urandom_read
> 2. add missing "\n" to the end of an error message
>
> Fixes: 81f77fd0deeb ("bpf: add selftest for stackmap with BPF_F_STACK_BUILD_ID")
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Signed-off-by: Song Liu <songliubraving@fb.com>
Applied to bpf tree, thanks Song!
^ permalink raw reply
* Re: [PATCH bpf-next 0/3] bpf: cleanups on managing subprog information
From: Alexei Starovoitov @ 2018-05-01 22:22 UTC (permalink / raw)
To: Jiong Wang; +Cc: borkmann, ecree, netdev, oss-drivers
In-Reply-To: <1525127296-3573-1-git-send-email-jiong.wang@netronome.com>
On Mon, Apr 30, 2018 at 06:28:13PM -0400, Jiong Wang wrote:
>
> There is no functional change by this patch set.
> No bpf selftest regression found after this patch set.
I was about to apply them, but there is a regression:
[ 27.773899] ==================================================================
[ 27.774802] BUG: KASAN: slab-out-of-bounds in do_jit+0x5499/0x6020
[ 27.775559] Read of size 4 at addr ffff8801197fe7f4 by task test_verifier/344
[ 27.776412]
[ 27.776607] CPU: 3 PID: 344 Comm: test_verifier Not tainted 4.17.0-rc2-00451-geb43cb64a84a #943
[ 27.777644] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-1.el7.centos 04/01/2014
[ 27.778894] Call Trace:
[ 27.779217] dump_stack+0x5b/0x8b
[ 27.779675] ? do_jit+0x5499/0x6020
[ 27.780148] print_address_description+0x73/0x290
[ 27.780716] ? do_jit+0x5499/0x6020
[ 27.781152] kasan_report+0x22b/0x350
[ 27.781602] do_jit+0x5499/0x6020
[ 27.782020] ? __mod_node_page_state+0xa2/0xd0
[ 27.782557] ? jit_fill_hole+0x20/0x20
[ 27.783019] ? ___slab_alloc+0x3e7/0x4d0
[ 27.783498] ? kasan_unpoison_shadow+0x30/0x40
[ 27.784042] ? kasan_kmalloc+0xa0/0xd0
[ 27.784497] ? __kmalloc+0x109/0x200
[ 27.784931] ? bpf_int_jit_compile+0x7ac/0xab0
[ 27.785475] bpf_int_jit_compile+0x2b6/0xab0
[ 27.786001] ? do_jit+0x6020/0x6020
[ 27.786428] ? kasan_kmalloc+0xa0/0xd0
[ 27.786885] bpf_check+0x2c05/0x4c40
[ 27.787346] ? fixup_bpf_calls+0x1140/0x1140
[ 27.787865] ? kasan_unpoison_shadow+0x30/0x40
[ 27.788406] ? kasan_kmalloc+0xa0/0xd0
[ 27.788865] ? memset+0x1f/0x40
[ 27.789255] ? bpf_obj_name_cpy+0x2d/0x200
[ 27.789750] bpf_prog_load+0xb07/0xeb0
simply running test_verifier with JIT and kasan on.
^ permalink raw reply
* Re: Silently dropped UDP packets on kernel 4.14
From: Florian Westphal @ 2018-05-01 22:24 UTC (permalink / raw)
To: Kristian Evensen; +Cc: Netfilter Development Mailing list, Network Development
In-Reply-To: <CAKfDRXj5oSD9-LKRbS_LYko+WEKwwunUq0L35G3t7Gi9Om74zw@mail.gmail.com>
Kristian Evensen <kristian.evensen@gmail.com> wrote:
> On Tue, May 1, 2018 at 8:50 PM, Kristian Evensen
> <kristian.evensen@gmail.com> wrote:
> > Does anyone have any idea of what could be wrong, where I should look
> > or other things I can try? I tried to space the requests out a bit in
> > time (I inserted a sleep 1 between them), and then the problem went
> > away.
>
> I should learn to always go through everything one last time before
> sending an email. First of all, I see that both requests are treated
> as new.
Normal when nfqueue is in use.
> Second, on my router, new requests are sent to user space for
> marking, which explains the large delay in processing. When removing
> the NFQUEUE-rule + handling and marking statically, my problem goes
> away and I get an answer for both packets.
Yes, because 2nd packet finds the conntrack entry created by the first
one.
> However, I do have one question. In my application, both packets are
> assigned the same mark. Shouldn't they then match the same conntrack
> entry, or am I missing something since that seems not to be the case?
The 2nd packet creates a new conntrack entry, because the conntrack
entry created by the first one is not inserted into global table yet.
This happens as last step, after packet has traversed all chains.
When nfqueue is used, this gets delayed, and 2nd packet will be dropped
as the insertion step finds that another packet created same flow
already.
I'm not sure what the best way to solve this is, we either need
to insert earlier in nfqueue case, or do conflict resolution in nfqueue
case (and perhaps also nat undo? not sure).
^ permalink raw reply
* Re: [PATCH net-next 0/2] bridge: FDB: Notify about removal of non-user-added entries
From: Petr Machata @ 2018-05-01 22:27 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, ivecera, davem, stephen, vivien.didelot, f.fainelli, jiri
In-Reply-To: <20180501175439.GB1265@lunn.ch>
Andrew Lunn <andrew@lunn.ch> writes:
> On Tue, May 01, 2018 at 07:04:19PM +0200, Petr Machata wrote:
>> Device drivers may generally need to keep in sync with bridge's FDB. In
>> particular, for its offload of tc mirror action where the mirrored-to
>> device is a gretap device, mlxsw needs to listen to a number of events.
>> SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE would be a natural notification to
>> listen to in order to keep up with FDB updates.
>>
>> However, for removal of FDB entries added due to device activity (as
>> opposed to explicit addition through "bridge fdb add" or similar), there
>> are no notifications.
>
> Could you explain this some more. Why is mlxsw special in that it
> needs this, but other drivers don't. The b53 driver supports tc
> mirror, for example.
mlxsw supports offload of tc mirror to a gretap netdevice to achieve
mirroring of traffic encapsulated in GRE. However, the device doesn't do
routing and switching on the encapsulated mirrored packets. You need to
configure exact parameters--L2 and L3 addresses, VLAN tagging if any,
etc., and a single front panel port to forward to.
To offload this, the driver sort of plays the game of networking stack.
Finds the underlay route, finds the neighbor to get the Ethernet address
(and possibly kick starts ARP resolution), and if the target netdevice
is a bridge, queries the FDB to find the one port to forward to (and
bails out if it needs to flood, we can't really offload that).
Now any time anything in that pipeline changes, the stuff after that
point needs to be redone, and the offloading decision (if and how) may
change.
So if an administrator decides to remove an FDB entry by hand, the
driver should notice this and reflect the intent by removing offloads
that depend on existence of that FDB entry. But since there's no event,
mlxsw doesn't notice this outright. It does notice later, because of an
unrelated event--e.g. from a neighbor, a FIB notification, whatever it
happens to be. That discrepancy is what I'm trying to fix.
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc
From: Cong Wang @ 2018-05-01 22:31 UTC (permalink / raw)
To: Eric Dumazet
Cc: Toke Høiland-Jørgensen, Dave Taht,
Linux Kernel Network Developers, Cake List
In-Reply-To: <4ec8da81-8671-f434-bada-27088b09ce7b@gmail.com>
On Tue, May 1, 2018 at 12:12 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> I guess that nobody really wants to really review Cake if
> it is a file with 2700 lines of code and hundreds of variables/tunables.
>
> Sure, we have big files in networking land, as a result of thousands of changes.
>
> If you split it, then maybe the work can be split among reviewers as a result.
>
+1
At *least* split it into CAKE without ack-filter and ack-filter implementation.
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: bridge: Notify about !added_by_user FDB entries
From: Petr Machata @ 2018-05-01 22:33 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: netdev, ivecera, davem, stephen, andrew, vivien.didelot,
f.fainelli, jiri, bridge@lists.linux-foundation.org
In-Reply-To: <df818113-33d4-d1ec-eb55-75e1aa59338d@cumulusnetworks.com>
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> writes:
> On 01/05/18 20:04, Petr Machata wrote:
>> Do not automatically bail out on sending notifications about activity on
>> non-user-added FDB entries. Instead, notify about this activity except
>> for cases where the activity itself originates in a notification, to
>> avoid sending duplicate notifications.
>>
>> Signed-off-by: Petr Machata <petrm@mellanox.com>
>> ---
>> net/bridge/br.c | 4 ++--
>> net/bridge/br_fdb.c | 40 +++++++++++++++++++++++++++-------------
>> net/bridge/br_private.h | 4 ++--
>> net/bridge/br_switchdev.c | 2 +-
>> 4 files changed, 32 insertions(+), 18 deletions(-)
>>
>
> Hi Petr,
> We already have 7 different fdb delete functions, I'm really not a fan of
> adding yet another one for such trivial change.
> Why don't you just add the new notify parameter to the already existing
> fdb_delete() ? (actually about the name see below)
> IMO it's confusing - if one wants a notification then use fdb_delete() or __fdb_delete(true)
> vs __fdb_delete(false) if a notification is not required. I think simply having the last
> parameter everywhere for fdb_delete() shows the intention clearer and avoids another
> fdb delete function.
All right--this is how I had it written actually, but then decided to do
this wrapping, because so many of the calls end up being true. I'll send
a v2 with just the extra argument.
> Another point, the notify parameter has a confusing name in this context because
> you're controlling the switchdev notifications not the rtnetlink ones. I'd suggest
> changing the name to something more descriptive like swdev_notify, otherwise you
> could get the funny end result of calling __fdb_notify() with notify == false which
> to me means don't notify. :-)
OK, swdev_notify it will be.
> Also please add the bridge maintainers to the CC list.
bridge@lists.linux-foundation.org? I saw it's a moderated list and for
some reason that made me think it's not meant for patch postings. I'll
add them the next time.
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH net-next v7 1/3] vmcore: add API to collect hardware dump in second kernel
From: Eric W. Biederman @ 2018-05-01 22:41 UTC (permalink / raw)
To: Rahul Lakkireddy
Cc: netdev, kexec, linux-fsdevel, linux-kernel, davem, viro, stephen,
akpm, torvalds, ganeshgr, nirranjan, indranil
In-Reply-To: <b6065b53c5446d98ee55e09119f6821f979418d4.1525197408.git.rahul.lakkireddy@chelsio.com>
Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> writes:
> The sequence of actions done by device drivers to append their device
> specific hardware/firmware logs to /proc/vmcore are as follows:
Except for the missing include that the kbuild test robot caught
I am not seeing a problems.
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
> 1. During probe (before hardware is initialized), device drivers
> register to the vmcore module (via vmcore_add_device_dump()), with
> callback function, along with buffer size and log name needed for
> firmware/hardware log collection.
>
> 2. vmcore module allocates the buffer with requested size. It adds
> an Elf note and invokes the device driver's registered callback
> function.
>
> 3. Device driver collects all hardware/firmware logs into the buffer
> and returns control back to vmcore module.
>
> Ensure that the device dump buffer size is always aligned to page size
> so that it can be mmaped.
>
> Also, rename alloc_elfnotes_buf() to vmcore_alloc_buf() to make it more
> generic and reserve NT_VMCOREDD note type to indicate vmcore device
> dump.
>
> Suggested-by: Eric Biederman <ebiederm@xmission.com>.
> Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
> ---
> v7:
> - Removed "CHELSIO" vendor identifier in Elf Note name. Instead,
> writing "LINUX".
> - Moved vmcoredd_header to new file include/uapi/linux/vmcore.h
> - Reworked vmcoredd_header to include Elf Note as part of the header
> itself.
> - Removed vmcoredd_get_note_size().
> - Renamed vmcoredd_write_note() to vmcoredd_write_header().
> - Replaced all "unsigned long" with "unsigned int" for device dump
> size since max size of Elf Word is u32.
>
> v6:
> - Reworked device dump elf note name to contain vendor identifier.
> - Added vmcoredd_header that precedes actual dump in the Elf Note.
> - Device dump's name is moved inside vmcoredd_header.
>
> v5:
> - Removed enabling CONFIG_PROC_VMCORE_DEVICE_DUMP by default and
> updated help message to indicate that the driver must be present
> in second kernel's initramfs to collect the underlying device
> snapshot.
>
> v4:
> - Made __vmcore_add_device_dump() static.
> - Moved compile check to define vmcore_add_device_dump() to
> crash_dump.h to fix compilation when vmcore.c is not compiled in.
> - Convert ---help--- to help in Kconfig as indicated by checkpatch.
> - Rebased to tip.
>
> v3:
> - Dropped sysfs crashdd module.
> - Added CONFIG_PROC_VMCORE_DEVICE_DUMP to allow configuring device
> dump support.
> - Moved logic related to adding dumps from crashdd to vmcore module.
> - Rename all crashdd* to vmcoredd*.
>
> v2:
> - Added ABI Documentation for crashdd.
> - Directly use octal permission instead of macro.
>
> Changes since rfc v2:
> - Moved exporting crashdd from procfs to sysfs. Suggested by
> Stephen Hemminger <stephen@networkplumber.org>
> - Moved code from fs/proc/crashdd.c to fs/crashdd/ directory.
> - Replaced all proc API with sysfs API and updated comments.
> - Calling driver callback before creating the binary file under
> crashdd sysfs.
> - Changed binary dump file permission from S_IRUSR to S_IRUGO.
> - Changed module name from CRASH_DRIVER_DUMP to CRASH_DEVICE_DUMP.
>
> rfc v2:
> - Collecting logs in 2nd kernel instead of during kernel panic.
> Suggested by Eric Biederman <ebiederm@xmission.com>.
> - Patch added in this series.
>
> fs/proc/Kconfig | 15 +++++
> fs/proc/vmcore.c | 140 +++++++++++++++++++++++++++++++++++++++++---
> include/linux/crash_dump.h | 18 ++++++
> include/linux/kcore.h | 6 ++
> include/uapi/linux/elf.h | 1 +
> include/uapi/linux/vmcore.h | 16 +++++
> 6 files changed, 187 insertions(+), 9 deletions(-)
> create mode 100644 include/uapi/linux/vmcore.h
>
> diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
> index 1ade1206bb89..0eaeb41453f5 100644
> --- a/fs/proc/Kconfig
> +++ b/fs/proc/Kconfig
> @@ -43,6 +43,21 @@ config PROC_VMCORE
> help
> Exports the dump image of crashed kernel in ELF format.
>
> +config PROC_VMCORE_DEVICE_DUMP
> + bool "Device Hardware/Firmware Log Collection"
> + depends on PROC_VMCORE
> + default n
> + help
> + After kernel panic, device drivers can collect the device
> + specific snapshot of their hardware or firmware before the
> + underlying devices are initialized in crash recovery kernel.
> + Note that the device driver must be present in the crash
> + recovery kernel's initramfs to collect its underlying device
> + snapshot.
> +
> + If you say Y here, the collected device dumps will be added
> + as ELF notes to /proc/vmcore.
> +
> config PROC_SYSCTL
> bool "Sysctl support (/proc/sys)" if EXPERT
> depends on PROC_FS
> diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
> index a45f0af22a60..60fce8dfe4e3 100644
> --- a/fs/proc/vmcore.c
> +++ b/fs/proc/vmcore.c
> @@ -20,6 +20,7 @@
> #include <linux/init.h>
> #include <linux/crash_dump.h>
> #include <linux/list.h>
> +#include <linux/mutex.h>
> #include <linux/vmalloc.h>
> #include <linux/pagemap.h>
> #include <linux/uaccess.h>
> @@ -44,6 +45,12 @@ static u64 vmcore_size;
>
> static struct proc_dir_entry *proc_vmcore;
>
> +#ifdef CONFIG_PROC_VMCORE_DEVICE_DUMP
> +/* Device Dump list and mutex to synchronize access to list */
> +static LIST_HEAD(vmcoredd_list);
> +static DEFINE_MUTEX(vmcoredd_mutex);
> +#endif /* CONFIG_PROC_VMCORE_DEVICE_DUMP */
> +
> /*
> * Returns > 0 for RAM pages, 0 for non-RAM pages, < 0 on error
> * The called function has to take care of module refcounting.
> @@ -302,10 +309,8 @@ static const struct vm_operations_struct vmcore_mmap_ops = {
> };
>
> /**
> - * alloc_elfnotes_buf - allocate buffer for ELF note segment in
> - * vmalloc memory
> - *
> - * @notes_sz: size of buffer
> + * vmcore_alloc_buf - allocate buffer in vmalloc memory
> + * @sizez: size of buffer
> *
> * If CONFIG_MMU is defined, use vmalloc_user() to allow users to mmap
> * the buffer to user-space by means of remap_vmalloc_range().
> @@ -313,12 +318,12 @@ static const struct vm_operations_struct vmcore_mmap_ops = {
> * If CONFIG_MMU is not defined, use vzalloc() since mmap_vmcore() is
> * disabled and there's no need to allow users to mmap the buffer.
> */
> -static inline char *alloc_elfnotes_buf(size_t notes_sz)
> +static inline char *vmcore_alloc_buf(size_t size)
> {
> #ifdef CONFIG_MMU
> - return vmalloc_user(notes_sz);
> + return vmalloc_user(size);
> #else
> - return vzalloc(notes_sz);
> + return vzalloc(size);
> #endif
> }
>
> @@ -665,7 +670,7 @@ static int __init merge_note_headers_elf64(char *elfptr, size_t *elfsz,
> return rc;
>
> *notes_sz = roundup(phdr_sz, PAGE_SIZE);
> - *notes_buf = alloc_elfnotes_buf(*notes_sz);
> + *notes_buf = vmcore_alloc_buf(*notes_sz);
> if (!*notes_buf)
> return -ENOMEM;
>
> @@ -851,7 +856,7 @@ static int __init merge_note_headers_elf32(char *elfptr, size_t *elfsz,
> return rc;
>
> *notes_sz = roundup(phdr_sz, PAGE_SIZE);
> - *notes_buf = alloc_elfnotes_buf(*notes_sz);
> + *notes_buf = vmcore_alloc_buf(*notes_sz);
> if (!*notes_buf)
> return -ENOMEM;
>
> @@ -1145,6 +1150,120 @@ static int __init parse_crash_elf_headers(void)
> return 0;
> }
>
> +#ifdef CONFIG_PROC_VMCORE_DEVICE_DUMP
> +/**
> + * vmcoredd_write_header - Write vmcore device dump header at the
> + * beginning of the dump's buffer.
> + * @buf: Output buffer where the note is written
> + * @data: Dump info
> + * @size: Size of the dump
> + *
> + * Fills beginning of the dump's buffer with vmcore device dump header.
> + */
> +static void vmcoredd_write_header(void *buf, struct vmcoredd_data *data,
> + u32 size)
> +{
> + struct vmcoredd_header *vdd_hdr = (struct vmcoredd_header *)buf;
> +
> + vdd_hdr->n_namesz = sizeof(vdd_hdr->name);
> + vdd_hdr->n_descsz = size + sizeof(vdd_hdr->dump_name);
> + vdd_hdr->n_type = NT_VMCOREDD;
> +
> + strncpy((char *)vdd_hdr->name, VMCOREDD_NOTE_NAME,
> + sizeof(vdd_hdr->name));
> + memcpy(vdd_hdr->dump_name, data->dump_name, sizeof(vdd_hdr->dump_name));
> +}
> +
> +/**
> + * vmcore_add_device_dump - Add a buffer containing device dump to vmcore
> + * @data: dump info.
> + *
> + * Allocate a buffer and invoke the calling driver's dump collect routine.
> + * Write Elf note at the beginning of the buffer to indicate vmcore device
> + * dump and add the dump to global list.
> + */
> +static int __vmcore_add_device_dump(struct vmcoredd_data *data)
> +{
> + struct vmcoredd_node *dump;
> + void *buf = NULL;
> + size_t data_size;
> + int ret;
> +
> + if (!data || !strlen(data->dump_name) ||
> + !data->vmcoredd_callback || !data->size)
> + return -EINVAL;
> +
> + dump = vzalloc(sizeof(*dump));
> + if (!dump) {
> + ret = -ENOMEM;
> + goto out_err;
> + }
> +
> + /* Keep size of the buffer page aligned so that it can be mmaped */
> + data_size = roundup(sizeof(struct vmcoredd_header) + data->size,
> + PAGE_SIZE);
> +
> + /* Allocate buffer for driver's to write their dumps */
> + buf = vmcore_alloc_buf(data_size);
> + if (!buf) {
> + ret = -ENOMEM;
> + goto out_err;
> + }
> +
> + vmcoredd_write_header(buf, data, data_size -
> + sizeof(struct vmcoredd_header));
> +
> + /* Invoke the driver's dump collection routing */
> + ret = data->vmcoredd_callback(data, buf +
> + sizeof(struct vmcoredd_header));
> + if (ret)
> + goto out_err;
> +
> + dump->buf = buf;
> + dump->size = data_size;
> +
> + /* Add the dump to driver sysfs list */
> + mutex_lock(&vmcoredd_mutex);
> + list_add_tail(&dump->list, &vmcoredd_list);
> + mutex_unlock(&vmcoredd_mutex);
> +
> + return 0;
> +
> +out_err:
> + if (buf)
> + vfree(buf);
> +
> + if (dump)
> + vfree(dump);
> +
> + return ret;
> +}
> +
> +int vmcore_add_device_dump(struct vmcoredd_data *data)
> +{
> + return __vmcore_add_device_dump(data);
> +}
> +EXPORT_SYMBOL(vmcore_add_device_dump);
> +#endif /* CONFIG_PROC_VMCORE_DEVICE_DUMP */
> +
> +/* Free all dumps in vmcore device dump list */
> +static void vmcore_free_device_dumps(void)
> +{
> +#ifdef CONFIG_PROC_VMCORE_DEVICE_DUMP
> + mutex_lock(&vmcoredd_mutex);
> + while (!list_empty(&vmcoredd_list)) {
> + struct vmcoredd_node *dump;
> +
> + dump = list_first_entry(&vmcoredd_list, struct vmcoredd_node,
> + list);
> + list_del(&dump->list);
> + vfree(dump->buf);
> + vfree(dump);
> + }
> + mutex_unlock(&vmcoredd_mutex);
> +#endif /* CONFIG_PROC_VMCORE_DEVICE_DUMP */
> +}
> +
> /* Init function for vmcore module. */
> static int __init vmcore_init(void)
> {
> @@ -1192,4 +1311,7 @@ void vmcore_cleanup(void)
> kfree(m);
> }
> free_elfcorebuf();
> +
> + /* clear vmcore device dump list */
> + vmcore_free_device_dumps();
> }
> diff --git a/include/linux/crash_dump.h b/include/linux/crash_dump.h
> index f7ac2aa93269..3e4ba9d753c8 100644
> --- a/include/linux/crash_dump.h
> +++ b/include/linux/crash_dump.h
> @@ -5,6 +5,7 @@
> #include <linux/kexec.h>
> #include <linux/proc_fs.h>
> #include <linux/elf.h>
> +#include <uapi/linux/vmcore.h>
>
> #include <asm/pgtable.h> /* for pgprot_t */
>
> @@ -93,4 +94,21 @@ static inline bool is_kdump_kernel(void) { return 0; }
> #endif /* CONFIG_CRASH_DUMP */
>
> extern unsigned long saved_max_pfn;
> +
> +/* Device Dump information to be filled by drivers */
> +struct vmcoredd_data {
> + char dump_name[VMCOREDD_MAX_NAME_BYTES]; /* Unique name of the dump */
> + unsigned int size; /* Size of the dump */
> + /* Driver's registered callback to be invoked to collect dump */
> + int (*vmcoredd_callback)(struct vmcoredd_data *data, void *buf);
> +};
> +
> +#ifdef CONFIG_PROC_VMCORE_DEVICE_DUMP
> +int vmcore_add_device_dump(struct vmcoredd_data *data);
> +#else
> +static inline int vmcore_add_device_dump(struct vmcoredd_data *data)
> +{
> + return -EOPNOTSUPP;
> +}
> +#endif /* CONFIG_PROC_VMCORE_DEVICE_DUMP */
> #endif /* LINUX_CRASHDUMP_H */
> diff --git a/include/linux/kcore.h b/include/linux/kcore.h
> index 80db19d3a505..8de55e4b5ee9 100644
> --- a/include/linux/kcore.h
> +++ b/include/linux/kcore.h
> @@ -28,6 +28,12 @@ struct vmcore {
> loff_t offset;
> };
>
> +struct vmcoredd_node {
> + struct list_head list; /* List of dumps */
> + void *buf; /* Buffer containing device's dump */
> + unsigned int size; /* Size of the buffer */
> +};
> +
> #ifdef CONFIG_PROC_KCORE
> extern void kclist_add(struct kcore_list *, void *, size_t, int type);
> #else
> diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
> index e2535d6dcec7..4e12c423b9fe 100644
> --- a/include/uapi/linux/elf.h
> +++ b/include/uapi/linux/elf.h
> @@ -421,6 +421,7 @@ typedef struct elf64_shdr {
> #define NT_ARM_SYSTEM_CALL 0x404 /* ARM system call number */
> #define NT_ARM_SVE 0x405 /* ARM Scalable Vector Extension registers */
> #define NT_ARC_V2 0x600 /* ARCv2 accumulator/extra registers */
> +#define NT_VMCOREDD 0x700 /* Vmcore Device Dump Note */
>
> /* Note header in a PT_NOTE section */
> typedef struct elf32_note {
> diff --git a/include/uapi/linux/vmcore.h b/include/uapi/linux/vmcore.h
> new file mode 100644
> index 000000000000..f9eab9a37370
> --- /dev/null
> +++ b/include/uapi/linux/vmcore.h
> @@ -0,0 +1,16 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _UAPI_VMCORE_H
> +#define _UAPI_VMCORE_H
> +
> +#define VMCOREDD_NOTE_NAME "LINUX"
> +#define VMCOREDD_MAX_NAME_BYTES 44
> +
> +struct vmcoredd_header {
> + __u32 n_namesz; /* Name size */
> + __u32 n_descsz; /* Content size */
> + __u32 n_type; /* NT_VMCOREDD */
> + __u8 name[8]; /* LINUX\0\0\0 */
> + __u8 dump_name[VMCOREDD_MAX_NAME_BYTES]; /* Device dump's name */
> +};
> +
> +#endif /* _UAPI_VMCORE_H */
^ permalink raw reply
* Re: RTL8723BE performance regression
From: João Paulo Rechi Vita @ 2018-05-01 22:41 UTC (permalink / raw)
To: Larry Finger
Cc: Steve deRosier, Yan-Hsuan Chuang, Ping-Ke Shih, Birming Chiu,
Shaofu, Steven Ting, Chaoming Li, Kalle Valo, linux-wireless,
Network Development, LKML, Daniel Drake,
João Paulo Rechi Vita, linux
In-Reply-To: <059b40f0-b8e2-b55f-92d5-a859ba4204a4@lwfinger.net>
On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
>>
>> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger <Larry.Finger@lwfinger.net>
>> wrote:
>>
>> (...)
>>
>>> As the antenna selection code changes affected your first bisection, do
>>> you
>>> have one of those HP laptops with only one antenna and the incorrect
>>> coding
>>> in the FUSE?
>>
>>
>> Yes, that is why I've been passing ant_sel=1 during my tests -- this
>> was needed to achieve a good performance in the past, before this
>> regression. I've also opened the laptop chassis and confirmed the
>> antenna cable is plugged to the connector labeled with "1" on the
>> card.
>>
>>> If so, please make sure that you still have the same signal
>>> strength for good and bad cases. I have tried to keep the driver and the
>>> btcoex code in sync, but there may be some combinations of antenna
>>> configuration and FUSE contents that cause the code to fail.
>>>
>>
>> What is the recommended way to monitor the signal strength?
>
>
> The btcoex code is developed for multiple platforms by a different group
> than the Linux driver. I think they made a change that caused ant_sel to
> switch from 1 to 2. At least numerous comments at
> github.com/lwfinger/rtlwifi_new claimed they needed to make that change.
>
> Mhy recommended method is to verify the wifi device name with "iw dev". Then
> using that device
>
> sudo iw dev <dev_name> scan | egrep "SSID|signal"
>
I have confirmed that the performance regression is indeed tied to
signal strength: on the good cases signal was between -16 and -8 dBm,
whereas in bad cases signal was always between -50 to - 40 dBm. I've
also switched to testing bandwidth in controlled LAN environment using
iperf3, as suggested by Steve deRosier, with the DUT being the only
machine connected to the 2.4 GHz radio and the machine running the
iperf3 server connected via ethernet.
Using those two tests (iperf3 and signal strength) I've dug deeper
into the culprit I had found previously, commit 7937f02d1953,
reverting it partially and testing the resulting driver, to isolate
which change was causing the problem. Besides "hooking up external
functions for newer ICs", as described by the commit message, that
commit also added code to decided whether ex_btc8723b1ant_*() or
ex_btc8723b2ant_*() functions should be used in halbtcoutsrc.c,
depending on the value of board_info.btdm_ant_num, whereas before that
commit ex_btc8723b2ant_*() were always used. Reverting to always using
ex_btc8723b2ant_*() functions fixes the regression on v4.15.
I've also tried to bisect between v4.15..v4.16 to find what else was
causing problems there, as the changes mentioned above on top of v4.16
did not solve the problem. The bisect pointed to "874e837d67d0
rtlwifi: fill FW version and subversion", only but reverting it plus
the changes mentioned above also didn't yield good results. That's
when I decided to get a bit creative: starting on v4.16 I first
applied the changes to have ex_btc8723b2ant_*() always being used, as
mentioned above, then reverted every commit between v4.15..v4.16
affecting drivers/net/wireless/realtek/rtlwifi/, and verified the
resulting kernel had a good performance. Then I started trimming down
the history and testing along the way, to reduce to the minimum set of
changes that had to be reverted in order to restore the good
performance. In addition to the ex_btc8723b2ant_*() changes and
reverting "874e837d67d0 rtlwifi: fill FW version and subversion", I've
also had to remove the following lines from
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c, which
were introduced by "40d9dd4f1c5d rtlwifi: btcoex: Remove global
variables from btcoex", in order to restore the upload performance and
signal strength.
/* set default antenna position to main port */
btcoexist->board_info.btdm_ant_pos = BTC_ANTENNA_AT_MAIN_PORT;
These are the results I've got on v4.16 (similarly on
wireless-drivers-next-for-davem-2018-03-29 or v4.15):
$ sudo iw dev wlp2s0 scan | grep -B3 JJ | grep signal
signal: -42.00 dBm
$ iperf3 -c 192.168.1.254
Connecting to host 192.168.1.254, port 5201
[ 4] local 192.168.1.253 port 39678 connected to 192.168.1.254 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 735 KBytes 6.02 Mbits/sec 1 1.41 KBytes
[ 4] 1.00-2.00 sec 274 KBytes 2.25 Mbits/sec 1 1.41 KBytes
[ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 1 28.3 KBytes
[ 4] 5.00-6.00 sec 423 KBytes 3.47 Mbits/sec 3 41.0 KBytes
[ 4] 6.00-7.00 sec 840 KBytes 6.88 Mbits/sec 0 58.0 KBytes
[ 4] 7.00-8.00 sec 830 KBytes 6.79 Mbits/sec 1 1.41 KBytes
[ 4] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 3.03 MBytes 2.54 Mbits/sec 7
sender
[ 4] 0.00-10.00 sec 2.88 MBytes 2.41 Mbits/sec
receiver
iperf Done.
And these are the results on v4.16 with all the changes mentioned on
the previous paragraph, and similar results were obtained when
applying the same changes on the current wireless-drivers-next master
branch (f56324baf329):
$ sudo iw dev wlp2s0 scan | grep -B3 JJ | grep signal
signal: -14.00 dBm
$ iperf3 -c 192.168.1.254
Connecting to host 192.168.1.254, port 5201
[ 4] local 192.168.1.253 port 59380 connected to 192.168.1.254 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 4.63 MBytes 38.8 Mbits/sec 0 194 KBytes
[ 4] 1.00-2.00 sec 4.58 MBytes 38.4 Mbits/sec 0 273 KBytes
[ 4] 2.00-3.00 sec 5.05 MBytes 42.3 Mbits/sec 0 332 KBytes
[ 4] 3.00-4.00 sec 4.98 MBytes 41.8 Mbits/sec 0 393 KBytes
[ 4] 4.00-5.00 sec 4.76 MBytes 39.9 Mbits/sec 0 434 KBytes
[ 4] 5.00-6.00 sec 4.85 MBytes 40.7 Mbits/sec 0 434 KBytes
[ 4] 6.00-7.00 sec 3.96 MBytes 33.2 Mbits/sec 0 464 KBytes
[ 4] 7.00-8.00 sec 4.74 MBytes 39.8 Mbits/sec 0 481 KBytes
[ 4] 8.00-9.00 sec 4.22 MBytes 35.4 Mbits/sec 0 508 KBytes
[ 4] 9.00-10.00 sec 4.09 MBytes 34.3 Mbits/sec 0 564 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 45.9 MBytes 38.5 Mbits/sec 0
sender
[ 4] 0.00-10.00 sec 45.0 MBytes 37.7 Mbits/sec
receiver
iperf Done.
I'll send an RFC patchset with the changes that I mentioned above.
Please advise whether those changes themselves should be merged, or if
you suggest a different approach.
^ permalink raw reply
* Re: Silently dropped UDP packets on kernel 4.14
From: Kristian Evensen @ 2018-05-01 22:42 UTC (permalink / raw)
To: Florian Westphal; +Cc: Netfilter Development Mailing list, Network Development
In-Reply-To: <20180501222406.fy5rph2t4dzndhu2@breakpoint.cc>
Hi,
Thanks for your quick and detailed reply!
On Wed, May 2, 2018 at 12:24 AM, Florian Westphal <fw@strlen.de> wrote:
> I'm not sure what the best way to solve this is, we either need
> to insert earlier in nfqueue case, or do conflict resolution in nfqueue
> case (and perhaps also nat undo? not sure).
My knowledge of the conntrack/nat subsystem is not that great, and I
don't know the implications of what I am about to suggest. However,
considering that the two packets represent the same flow, wouldn't it
be possible to apply the existing nat-mapping to the second packet,
and then let the second packet pass?
BR,
Kristian
^ permalink raw reply
* [RFC PATCH 1/3] rtlwifi: btcoex: Don't init antenna position to main port
From: João Paulo Rechi Vita @ 2018-05-01 22:46 UTC (permalink / raw)
To: Larry Finger
Cc: Steve deRosier, Yan-Hsuan Chuang, Ping-Ke Shih, Birming Chiu,
Shaofu, Steven Ting, Chaoming Li, Kalle Valo, linux-wireless,
Network Development, LKML, Daniel Drake,
João Paulo Rechi Vita, linux
In-Reply-To: <CA+A7VXUUsZHD2gr9TBcV6jZBOPGZv7_vK-wWZ0MvGgiCnAiUgQ@mail.gmail.com>
This partially reverts commit 40d9dd4f1c5dcd0d4a2a1f0efcd225c9c4b36d6f,
which does not only remove global variables from btcoex, as described on
its commit message, but also does a few other things -- in particular,
setting the default antenna position to BTC_ANTENNA_AT_MAIN_PORT.
This drastically affects the upload performance and signal strenght on
the HP 240 G4 laptop, as shown by the results bellow:
Without this change:
$ sudo iw dev wlp2s0 scan | grep -B3 JJ | grep signal
signal: -42.00 dBm
$ iperf3 -c 192.168.1.254
Connecting to host 192.168.1.254, port 5201
[ 4] local 192.168.1.253 port 39678 connected to 192.168.1.254 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 735 KBytes 6.02 Mbits/sec 1 1.41 KBytes
[ 4] 1.00-2.00 sec 274 KBytes 2.25 Mbits/sec 1 1.41 KBytes
[ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 1 28.3 KBytes
[ 4] 5.00-6.00 sec 423 KBytes 3.47 Mbits/sec 3 41.0 KBytes
[ 4] 6.00-7.00 sec 840 KBytes 6.88 Mbits/sec 0 58.0 KBytes
[ 4] 7.00-8.00 sec 830 KBytes 6.79 Mbits/sec 1 1.41 KBytes
[ 4] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 3.03 MBytes 2.54 Mbits/sec 7 sender
[ 4] 0.00-10.00 sec 2.88 MBytes 2.41 Mbits/sec receiver
iperf Done.
With this change:
$ sudo iw dev wlp2s0 scan | grep -B3 JJ | grep signal
signal: -14.00 dBm
$ iperf3 -c 192.168.1.254
Connecting to host 192.168.1.254, port 5201
[ 4] local 192.168.1.253 port 59380 connected to 192.168.1.254 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 4.63 MBytes 38.8 Mbits/sec 0 194 KBytes
[ 4] 1.00-2.00 sec 4.58 MBytes 38.4 Mbits/sec 0 273 KBytes
[ 4] 2.00-3.00 sec 5.05 MBytes 42.3 Mbits/sec 0 332 KBytes
[ 4] 3.00-4.00 sec 4.98 MBytes 41.8 Mbits/sec 0 393 KBytes
[ 4] 4.00-5.00 sec 4.76 MBytes 39.9 Mbits/sec 0 434 KBytes
[ 4] 5.00-6.00 sec 4.85 MBytes 40.7 Mbits/sec 0 434 KBytes
[ 4] 6.00-7.00 sec 3.96 MBytes 33.2 Mbits/sec 0 464 KBytes
[ 4] 7.00-8.00 sec 4.74 MBytes 39.8 Mbits/sec 0 481 KBytes
[ 4] 8.00-9.00 sec 4.22 MBytes 35.4 Mbits/sec 0 508 KBytes
[ 4] 9.00-10.00 sec 4.09 MBytes 34.3 Mbits/sec 0 564 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 45.9 MBytes 38.5 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 45.0 MBytes 37.7 Mbits/sec receiver
iperf Done.
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com>
---
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index b026e80940a4..86182b917c92 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -1388,9 +1388,6 @@ bool exhalbtc_bind_bt_coex_withadapter(void *adapter)
ant_num = rtl_get_hwpg_ant_num(rtlpriv);
exhalbtc_set_ant_num(rtlpriv, BT_COEX_ANT_TYPE_PG, ant_num);
- /* set default antenna position to main port */
- btcoexist->board_info.btdm_ant_pos = BTC_ANTENNA_AT_MAIN_PORT;
-
single_ant_path = rtl_get_hwpg_single_ant_path(rtlpriv);
exhalbtc_set_single_ant_path(btcoexist, single_ant_path);
--
2.17.0
^ permalink raw reply related
* [RFC PATCH 2/3] Revert "rtlwifi: fill FW version and subversion"
From: João Paulo Rechi Vita @ 2018-05-01 22:46 UTC (permalink / raw)
To: Larry Finger
Cc: Steve deRosier, Yan-Hsuan Chuang, Ping-Ke Shih, Birming Chiu,
Shaofu, Steven Ting, Chaoming Li, Kalle Valo, linux-wireless,
Network Development, LKML, Daniel Drake,
João Paulo Rechi Vita, linux
In-Reply-To: <20180501224613.32460-1-jprvita@endlessm.com>
This reverts commit 874e837d67d0db179c9771f38fd21df07c703e93.
This drastically affects the upload performance and signal strenght on
the HP 240 G4 laptop, as shown by the results bellow:
Without this change:
$ sudo iw dev wlp2s0 scan | grep -B3 JJ | grep signal
signal: -42.00 dBm
$ iperf3 -c 192.168.1.254
Connecting to host 192.168.1.254, port 5201
[ 4] local 192.168.1.253 port 39678 connected to 192.168.1.254 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 735 KBytes 6.02 Mbits/sec 1 1.41 KBytes
[ 4] 1.00-2.00 sec 274 KBytes 2.25 Mbits/sec 1 1.41 KBytes
[ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 1 28.3 KBytes
[ 4] 5.00-6.00 sec 423 KBytes 3.47 Mbits/sec 3 41.0 KBytes
[ 4] 6.00-7.00 sec 840 KBytes 6.88 Mbits/sec 0 58.0 KBytes
[ 4] 7.00-8.00 sec 830 KBytes 6.79 Mbits/sec 1 1.41 KBytes
[ 4] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 3.03 MBytes 2.54 Mbits/sec 7 sender
[ 4] 0.00-10.00 sec 2.88 MBytes 2.41 Mbits/sec receiver
iperf Done.
With this change:
$ sudo iw dev wlp2s0 scan | grep -B3 JJ | grep signal
signal: -14.00 dBm
$ iperf3 -c 192.168.1.254
Connecting to host 192.168.1.254, port 5201
[ 4] local 192.168.1.253 port 59380 connected to 192.168.1.254 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 4.63 MBytes 38.8 Mbits/sec 0 194 KBytes
[ 4] 1.00-2.00 sec 4.58 MBytes 38.4 Mbits/sec 0 273 KBytes
[ 4] 2.00-3.00 sec 5.05 MBytes 42.3 Mbits/sec 0 332 KBytes
[ 4] 3.00-4.00 sec 4.98 MBytes 41.8 Mbits/sec 0 393 KBytes
[ 4] 4.00-5.00 sec 4.76 MBytes 39.9 Mbits/sec 0 434 KBytes
[ 4] 5.00-6.00 sec 4.85 MBytes 40.7 Mbits/sec 0 434 KBytes
[ 4] 6.00-7.00 sec 3.96 MBytes 33.2 Mbits/sec 0 464 KBytes
[ 4] 7.00-8.00 sec 4.74 MBytes 39.8 Mbits/sec 0 481 KBytes
[ 4] 8.00-9.00 sec 4.22 MBytes 35.4 Mbits/sec 0 508 KBytes
[ 4] 9.00-10.00 sec 4.09 MBytes 34.3 Mbits/sec 0 564 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 45.9 MBytes 38.5 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 45.0 MBytes 37.7 Mbits/sec receiver
iperf Done.
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com>
---
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c | 2 --
drivers/net/wireless/realtek/rtlwifi/rtl8723com/fw_common.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c
index 63874512598b..a2eca669873b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c
@@ -141,8 +141,6 @@ int rtl88e_download_fw(struct ieee80211_hw *hw,
return 1;
pfwheader = (struct rtlwifi_firmware_header *)rtlhal->pfirmware;
- rtlhal->fw_version = le16_to_cpu(pfwheader->version);
- rtlhal->fw_subversion = pfwheader->subversion;
pfwdata = rtlhal->pfirmware;
fwsize = rtlhal->fwsize;
RT_TRACE(rtlpriv, COMP_FW, DBG_DMESG,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723com/fw_common.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723com/fw_common.c
index 521039c5d4ce..0d1ebc861720 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723com/fw_common.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723com/fw_common.c
@@ -200,8 +200,6 @@ int rtl8723_download_fw(struct ieee80211_hw *hw,
return 1;
pfwheader = (struct rtlwifi_firmware_header *)rtlhal->pfirmware;
- rtlhal->fw_version = le16_to_cpu(pfwheader->version);
- rtlhal->fw_subversion = pfwheader->subversion;
pfwdata = rtlhal->pfirmware;
fwsize = rtlhal->fwsize;
--
2.17.0
^ permalink raw reply related
* [RFC PATCH 3/3] rtlwifi: btcoex: Always use 2ant-functions for RTL8723BE
From: João Paulo Rechi Vita @ 2018-05-01 22:46 UTC (permalink / raw)
To: Larry Finger
Cc: Steve deRosier, Yan-Hsuan Chuang, Ping-Ke Shih, Birming Chiu,
Shaofu, Steven Ting, Chaoming Li, Kalle Valo, linux-wireless,
Network Development, LKML, Daniel Drake,
João Paulo Rechi Vita, linux
In-Reply-To: <20180501224613.32460-1-jprvita@endlessm.com>
This partially reverts commit 7937f02d1953952a6eaf626b175ea9db5541e699,
which not only hooked external functions for newer ICs, as described in
its commit message, but also changed the behavior for RTL8723BE
depending on the value of board_info.btdm_ant_num.
When board_info.btdm_ant_num == 1, 7937f02d19 changes the codepath to
use a whole different set of functions ex_btc8723b1ant_*, instead of the
ex_btc8723b2ant_* that were used before it.
This drastically affects the upload performance and signal strenght on
the HP 240 G4 laptop, as shown by the results bellow:
Without this change:
$ sudo iw dev wlp2s0 scan | grep -B3 JJ | grep signal
signal: -42.00 dBm
$ iperf3 -c 192.168.1.254
Connecting to host 192.168.1.254, port 5201
[ 4] local 192.168.1.253 port 39678 connected to 192.168.1.254 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 735 KBytes 6.02 Mbits/sec 1 1.41 KBytes
[ 4] 1.00-2.00 sec 274 KBytes 2.25 Mbits/sec 1 1.41 KBytes
[ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 1 28.3 KBytes
[ 4] 5.00-6.00 sec 423 KBytes 3.47 Mbits/sec 3 41.0 KBytes
[ 4] 6.00-7.00 sec 840 KBytes 6.88 Mbits/sec 0 58.0 KBytes
[ 4] 7.00-8.00 sec 830 KBytes 6.79 Mbits/sec 1 1.41 KBytes
[ 4] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 3.03 MBytes 2.54 Mbits/sec 7 sender
[ 4] 0.00-10.00 sec 2.88 MBytes 2.41 Mbits/sec receiver
iperf Done.
With this change:
$ sudo iw dev wlp2s0 scan | grep -B3 JJ | grep signal
signal: -14.00 dBm
$ iperf3 -c 192.168.1.254
Connecting to host 192.168.1.254, port 5201
[ 4] local 192.168.1.253 port 59380 connected to 192.168.1.254 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 4.63 MBytes 38.8 Mbits/sec 0 194 KBytes
[ 4] 1.00-2.00 sec 4.58 MBytes 38.4 Mbits/sec 0 273 KBytes
[ 4] 2.00-3.00 sec 5.05 MBytes 42.3 Mbits/sec 0 332 KBytes
[ 4] 3.00-4.00 sec 4.98 MBytes 41.8 Mbits/sec 0 393 KBytes
[ 4] 4.00-5.00 sec 4.76 MBytes 39.9 Mbits/sec 0 434 KBytes
[ 4] 5.00-6.00 sec 4.85 MBytes 40.7 Mbits/sec 0 434 KBytes
[ 4] 6.00-7.00 sec 3.96 MBytes 33.2 Mbits/sec 0 464 KBytes
[ 4] 7.00-8.00 sec 4.74 MBytes 39.8 Mbits/sec 0 481 KBytes
[ 4] 8.00-9.00 sec 4.22 MBytes 35.4 Mbits/sec 0 508 KBytes
[ 4] 9.00-10.00 sec 4.09 MBytes 34.3 Mbits/sec 0 564 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 45.9 MBytes 38.5 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 45.0 MBytes 37.7 Mbits/sec receiver
iperf Done.
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com>
---
.../realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 62 ++++---------------
1 file changed, 12 insertions(+), 50 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index 86182b917c92..a862b5efdf55 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -1452,10 +1452,7 @@ void exhalbtc_init_hw_config(struct btc_coexist *btcoexist, bool wifi_only)
else if (btcoexist->board_info.btdm_ant_num == 1)
ex_btc8821a1ant_init_hwconfig(btcoexist, wifi_only);
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 2)
- ex_btc8723b2ant_init_hwconfig(btcoexist);
- else if (btcoexist->board_info.btdm_ant_num == 1)
- ex_btc8723b1ant_init_hwconfig(btcoexist, wifi_only);
+ ex_btc8723b2ant_init_hwconfig(btcoexist);
} else if (IS_HARDWARE_TYPE_8723A(btcoexist->adapter)) {
/* 8723A has no this function */
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
@@ -1481,10 +1478,7 @@ void exhalbtc_init_coex_dm(struct btc_coexist *btcoexist)
else if (btcoexist->board_info.btdm_ant_num == 1)
ex_btc8821a1ant_init_coex_dm(btcoexist);
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 2)
- ex_btc8723b2ant_init_coex_dm(btcoexist);
- else if (btcoexist->board_info.btdm_ant_num == 1)
- ex_btc8723b1ant_init_coex_dm(btcoexist);
+ ex_btc8723b2ant_init_coex_dm(btcoexist);
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_init_coex_dm(btcoexist);
@@ -1516,10 +1510,7 @@ void exhalbtc_ips_notify(struct btc_coexist *btcoexist, u8 type)
else if (btcoexist->board_info.btdm_ant_num == 1)
ex_btc8821a1ant_ips_notify(btcoexist, ips_type);
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 2)
- ex_btc8723b2ant_ips_notify(btcoexist, ips_type);
- else if (btcoexist->board_info.btdm_ant_num == 1)
- ex_btc8723b1ant_ips_notify(btcoexist, ips_type);
+ ex_btc8723b2ant_ips_notify(btcoexist, ips_type);
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_ips_notify(btcoexist, ips_type);
@@ -1549,10 +1540,7 @@ void exhalbtc_lps_notify(struct btc_coexist *btcoexist, u8 type)
else if (btcoexist->board_info.btdm_ant_num == 1)
ex_btc8821a1ant_lps_notify(btcoexist, lps_type);
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 2)
- ex_btc8723b2ant_lps_notify(btcoexist, lps_type);
- else if (btcoexist->board_info.btdm_ant_num == 1)
- ex_btc8723b1ant_lps_notify(btcoexist, lps_type);
+ ex_btc8723b2ant_lps_notify(btcoexist, lps_type);
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_lps_notify(btcoexist, lps_type);
@@ -1582,10 +1570,7 @@ void exhalbtc_scan_notify(struct btc_coexist *btcoexist, u8 type)
else if (btcoexist->board_info.btdm_ant_num == 1)
ex_btc8821a1ant_scan_notify(btcoexist, scan_type);
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 2)
- ex_btc8723b2ant_scan_notify(btcoexist, scan_type);
- else if (btcoexist->board_info.btdm_ant_num == 1)
- ex_btc8723b1ant_scan_notify(btcoexist, scan_type);
+ ex_btc8723b2ant_scan_notify(btcoexist, scan_type);
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_scan_notify(btcoexist, scan_type);
@@ -1630,10 +1615,7 @@ void exhalbtc_connect_notify(struct btc_coexist *btcoexist, u8 action)
else if (btcoexist->board_info.btdm_ant_num == 1)
ex_btc8821a1ant_connect_notify(btcoexist, asso_type);
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 2)
- ex_btc8723b2ant_connect_notify(btcoexist, asso_type);
- else if (btcoexist->board_info.btdm_ant_num == 1)
- ex_btc8723b1ant_connect_notify(btcoexist, asso_type);
+ ex_btc8723b2ant_connect_notify(btcoexist, asso_type);
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_connect_notify(btcoexist, asso_type);
@@ -1666,10 +1648,7 @@ void exhalbtc_mediastatus_notify(struct btc_coexist *btcoexist,
else if (btcoexist->board_info.btdm_ant_num == 1)
ex_btc8821a1ant_media_status_notify(btcoexist, status);
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 2)
- ex_btc8723b2ant_media_status_notify(btcoexist, status);
- else if (btcoexist->board_info.btdm_ant_num == 1)
- ex_btc8723b1ant_media_status_notify(btcoexist, status);
+ ex_btc8723b2ant_media_status_notify(btcoexist, status);
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_media_status_notify(btcoexist, status);
@@ -1709,12 +1688,8 @@ void exhalbtc_special_packet_notify(struct btc_coexist *btcoexist, u8 pkt_type)
ex_btc8821a1ant_special_packet_notify(btcoexist,
packet_type);
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 2)
- ex_btc8723b2ant_special_packet_notify(btcoexist,
- packet_type);
- else if (btcoexist->board_info.btdm_ant_num == 1)
- ex_btc8723b1ant_special_packet_notify(btcoexist,
- packet_type);
+ ex_btc8723b2ant_special_packet_notify(btcoexist,
+ packet_type);
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_special_packet_notify(btcoexist,
@@ -1741,12 +1716,7 @@ void exhalbtc_bt_info_notify(struct btc_coexist *btcoexist,
ex_btc8821a1ant_bt_info_notify(btcoexist, tmp_buf,
length);
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 2)
- ex_btc8723b2ant_bt_info_notify(btcoexist, tmp_buf,
- length);
- else if (btcoexist->board_info.btdm_ant_num == 1)
- ex_btc8723b1ant_bt_info_notify(btcoexist, tmp_buf,
- length);
+ ex_btc8723b2ant_bt_info_notify(btcoexist, tmp_buf, length);
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_bt_info_notify(btcoexist, tmp_buf,
@@ -1763,8 +1733,6 @@ void exhalbtc_rf_status_notify(struct btc_coexist *btcoexist, u8 type)
if (IS_HARDWARE_TYPE_8821(btcoexist->adapter)) {
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 1)
- ex_btc8723b1ant_rf_status_notify(btcoexist, type);
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
}
}
@@ -1804,10 +1772,7 @@ void exhalbtc_halt_notify(struct btc_coexist *btcoexist)
else if (btcoexist->board_info.btdm_ant_num == 1)
ex_btc8821a1ant_halt_notify(btcoexist);
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 2)
- ex_btc8723b2ant_halt_notify(btcoexist);
- else if (btcoexist->board_info.btdm_ant_num == 1)
- ex_btc8723b1ant_halt_notify(btcoexist);
+ ex_btc8723b2ant_halt_notify(btcoexist);
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_halt_notify(btcoexist);
@@ -1880,10 +1845,7 @@ void exhalbtc_periodical(struct btc_coexist *btcoexist)
if (!halbtc_under_ips(btcoexist))
ex_btc8821a1ant_periodical(btcoexist);
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 2)
- ex_btc8723b2ant_periodical(btcoexist);
- else if (btcoexist->board_info.btdm_ant_num == 1)
- ex_btc8723b1ant_periodical(btcoexist);
+ ex_btc8723b2ant_periodical(btcoexist);
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_periodical(btcoexist);
--
2.17.0
^ permalink raw reply related
* [PATCH net] nfp: flower: set tunnel ttl value to net default
From: Jakub Kicinski @ 2018-05-01 22:49 UTC (permalink / raw)
To: davem; +Cc: netdev, oss-drivers, John Hurley
From: John Hurley <john.hurley@netronome.com>
Firmware requires that the ttl value for an encapsulating ipv4 tunnel
header be included as an action field. Prior to the support of Geneve
tunnel encap (when ttl set was removed completely), ttl value was
extracted from the tunnel key. However, tests have shown that this can
still produce a ttl of 0.
Fix the issue by setting the namespace default value for each new tunnel.
Follow up patch for net-next will do a full route lookup.
Fixes: 3ca3059dc3a9 ("nfp: flower: compile Geneve encap actions")
Fixes: b27d6a95a70d ("nfp: compile flower vxlan tunnel set actions")
Signed-off-by: John Hurley <john.hurley@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
drivers/net/ethernet/netronome/nfp/flower/action.c | 10 ++++++++--
drivers/net/ethernet/netronome/nfp/flower/cmsg.h | 5 ++++-
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/flower/action.c b/drivers/net/ethernet/netronome/nfp/flower/action.c
index b3567a596fc1..80df9a5d4217 100644
--- a/drivers/net/ethernet/netronome/nfp/flower/action.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/action.c
@@ -183,17 +183,21 @@ static int
nfp_fl_set_ipv4_udp_tun(struct nfp_fl_set_ipv4_udp_tun *set_tun,
const struct tc_action *action,
struct nfp_fl_pre_tunnel *pre_tun,
- enum nfp_flower_tun_type tun_type)
+ enum nfp_flower_tun_type tun_type,
+ struct net_device *netdev)
{
size_t act_size = sizeof(struct nfp_fl_set_ipv4_udp_tun);
struct ip_tunnel_info *ip_tun = tcf_tunnel_info(action);
u32 tmp_set_ip_tun_type_index = 0;
/* Currently support one pre-tunnel so index is always 0. */
int pretun_idx = 0;
+ struct net *net;
if (ip_tun->options_len)
return -EOPNOTSUPP;
+ net = dev_net(netdev);
+
set_tun->head.jump_id = NFP_FL_ACTION_OPCODE_SET_IPV4_TUNNEL;
set_tun->head.len_lw = act_size >> NFP_FL_LW_SIZ;
@@ -204,6 +208,7 @@ nfp_fl_set_ipv4_udp_tun(struct nfp_fl_set_ipv4_udp_tun *set_tun,
set_tun->tun_type_index = cpu_to_be32(tmp_set_ip_tun_type_index);
set_tun->tun_id = ip_tun->key.tun_id;
+ set_tun->ttl = net->ipv4.sysctl_ip_default_ttl;
/* Complete pre_tunnel action. */
pre_tun->ipv4_dst = ip_tun->key.u.ipv4.dst;
@@ -511,7 +516,8 @@ nfp_flower_loop_action(const struct tc_action *a,
*a_len += sizeof(struct nfp_fl_pre_tunnel);
set_tun = (void *)&nfp_fl->action_data[*a_len];
- err = nfp_fl_set_ipv4_udp_tun(set_tun, a, pre_tun, *tun_type);
+ err = nfp_fl_set_ipv4_udp_tun(set_tun, a, pre_tun, *tun_type,
+ netdev);
if (err)
return err;
*a_len += sizeof(struct nfp_fl_set_ipv4_udp_tun);
diff --git a/drivers/net/ethernet/netronome/nfp/flower/cmsg.h b/drivers/net/ethernet/netronome/nfp/flower/cmsg.h
index b6c0fd053a50..bee4367a2c38 100644
--- a/drivers/net/ethernet/netronome/nfp/flower/cmsg.h
+++ b/drivers/net/ethernet/netronome/nfp/flower/cmsg.h
@@ -190,7 +190,10 @@ struct nfp_fl_set_ipv4_udp_tun {
__be16 reserved;
__be64 tun_id __packed;
__be32 tun_type_index;
- __be32 extra[3];
+ __be16 reserved2;
+ u8 ttl;
+ u8 reserved3;
+ __be32 extra[2];
};
/* Metadata with L2 (1W/4B)
--
2.17.0
^ permalink raw reply related
* Re: [PATCH V4 net-next 1/2] tcp: send in-queue bytes in cmsg upon read
From: David Miller @ 2018-05-01 23:02 UTC (permalink / raw)
To: soheil.kdev; +Cc: netdev, ycheng, ncardwell, edumazet, willemb, soheil
In-Reply-To: <20180501193916.113642-1-soheil.kdev@gmail.com>
From: Soheil Hassas Yeganeh <soheil.kdev@gmail.com>
Date: Tue, 1 May 2018 15:39:15 -0400
> Add the TCP_INQ socket option to TCP. When this socket
> option is set, recvmsg() relays the number of bytes available
> on the socket for reading to the application via the
> TCP_CM_INQ control message.
Applied.
^ permalink raw reply
* Re: [PATCH V4 net-next 2/2] selftest: add test for TCP_INQ
From: David Miller @ 2018-05-01 23:02 UTC (permalink / raw)
To: soheil.kdev; +Cc: netdev, ycheng, ncardwell, edumazet, willemb, soheil
In-Reply-To: <20180501193916.113642-2-soheil.kdev@gmail.com>
From: Soheil Hassas Yeganeh <soheil.kdev@gmail.com>
Date: Tue, 1 May 2018 15:39:16 -0400
> From: Soheil Hassas Yeganeh <soheil@google.com>
>
> Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
> Reviewed-by: Eric Dumazet <edumazet@google.com>
> Reviewed-by: Neal Cardwell <ncardwell@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] net/tls: Don't recursively call push_record during tls_write_space callbacks
From: David Miller @ 2018-05-01 23:02 UTC (permalink / raw)
To: davejwatson; +Cc: andre, netdev, borisp, aviadye
In-Reply-To: <20180501200539.GA69207@davejwatson-mba.dhcp.thefacebook.com>
From: Dave Watson <davejwatson@fb.com>
Date: Tue, 1 May 2018 13:05:39 -0700
> It is reported that in some cases, write_space may be called in
> do_tcp_sendpages, such that we recursively invoke do_tcp_sendpages again:
>
> [ 660.468802] ? do_tcp_sendpages+0x8d/0x580
> [ 660.468826] ? tls_push_sg+0x74/0x130 [tls]
> [ 660.468852] ? tls_push_record+0x24a/0x390 [tls]
> [ 660.468880] ? tls_write_space+0x6a/0x80 [tls]
> ...
>
> tls_push_sg already does a loop over all sending sg's, so ignore
> any tls_write_space notifications until we are done sending.
> We then have to call the previous write_space to wake up
> poll() waiters after we are done with the send loop.
>
> Reported-by: Andre Tomt <andre@tomt.net>
> Signed-off-by: Dave Watson <davejwatson@fb.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] nfp: flower: set tunnel ttl value to net default
From: David Miller @ 2018-05-01 23:04 UTC (permalink / raw)
To: jakub.kicinski; +Cc: netdev, oss-drivers, john.hurley
In-Reply-To: <20180501224949.23240-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Tue, 1 May 2018 15:49:49 -0700
> From: John Hurley <john.hurley@netronome.com>
>
> Firmware requires that the ttl value for an encapsulating ipv4 tunnel
> header be included as an action field. Prior to the support of Geneve
> tunnel encap (when ttl set was removed completely), ttl value was
> extracted from the tunnel key. However, tests have shown that this can
> still produce a ttl of 0.
>
> Fix the issue by setting the namespace default value for each new tunnel.
> Follow up patch for net-next will do a full route lookup.
>
> Fixes: 3ca3059dc3a9 ("nfp: flower: compile Geneve encap actions")
> Fixes: b27d6a95a70d ("nfp: compile flower vxlan tunnel set actions")
> Signed-off-by: John Hurley <john.hurley@netronome.com>
> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH bpf-next] bpf/verifier: enable ctx + const + 0.
From: Alexei Starovoitov @ 2018-05-01 23:16 UTC (permalink / raw)
To: William Tu; +Cc: netdev, Yonghong Song, Yifeng Sun
In-Reply-To: <1525108505-21175-1-git-send-email-u9012063@gmail.com>
On Mon, Apr 30, 2018 at 10:15:05AM -0700, William Tu wrote:
> Existing verifier does not allow 'ctx + const + const'. However, due to
> compiler optimization, there is a case where BPF compilerit generates
> 'ctx + const + 0', as shown below:
>
> 599: (1d) if r2 == r4 goto pc+2
> R0=inv(id=0) R1=ctx(id=0,off=40,imm=0)
> R2=inv(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff))
> R3=inv(id=0,umax_value=65535,var_off=(0x0; 0xffff)) R4=inv0
> R6=ctx(id=0,off=0,imm=0) R7=inv2
> 600: (bf) r1 = r6 // r1 is ctx
> 601: (07) r1 += 36 // r1 has offset 36
> 602: (61) r4 = *(u32 *)(r1 +0) // r1 + 0
> dereference of modified ctx ptr R1 off=36+0, ctx+const is allowed,
> ctx+const+const is not
>
> The reason for BPF backend generating this code is due optimization
> likes this, explained from Yonghong:
> if (...)
> *(ctx + 60)
> else
> *(ctx + 56)
>
> The compiler translates it to
> if (...)
> ptr = ctx + 60
> else
> ptr = ctx + 56
> *(ptr + 0)
>
> So load ptr memory become an example of 'ctx + const + 0'. This patch
> enables support for this case.
>
> Fixes: f8ddadc4db6c7 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")
> Cc: Yonghong Song <yhs@fb.com>
> Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com>
> Signed-off-by: William Tu <u9012063@gmail.com>
> ---
> kernel/bpf/verifier.c | 2 +-
> tools/testing/selftests/bpf/test_verifier.c | 13 +++++++++++++
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 712d8655e916..c9a791b9cf2a 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -1638,7 +1638,7 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
> /* ctx accesses must be at a fixed offset, so that we can
> * determine what type of data were returned.
> */
> - if (reg->off) {
> + if (reg->off && off != reg->off) {
> verbose(env,
> "dereference of modified ctx ptr R%d off=%d+%d, ctx+const is allowed, ctx+const+const is not\n",
> regno, reg->off, off - reg->off);
> diff --git a/tools/testing/selftests/bpf/test_verifier.c b/tools/testing/selftests/bpf/test_verifier.c
> index 1acafe26498b..95ad5d5723ae 100644
> --- a/tools/testing/selftests/bpf/test_verifier.c
> +++ b/tools/testing/selftests/bpf/test_verifier.c
> @@ -8452,6 +8452,19 @@ static struct bpf_test tests[] = {
> .prog_type = BPF_PROG_TYPE_SCHED_CLS,
> },
> {
> + "arithmetic ops make PTR_TO_CTX + const + 0 valid",
> + .insns = {
> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_1,
> + offsetof(struct __sk_buff, data) -
> + offsetof(struct __sk_buff, mark)),
> + BPF_LDX_MEM(BPF_W, BPF_REG_0, BPF_REG_1, 0),
How rewritten code looks here?
The patch is allowing check_ctx_access() to proceed with sort-of
correct 'off' and remember ctx_field_size,
but in convert_ctx_accesses() it's using insn->off to do conversion.
Which is zero in this case, so it will convert
struct __sk_buff {
__u32 len; // offset 0
into access of 'struct sk_buff'->len
and then will add __sk_buff's &data - &mark delta to in-kernel len field.
Which will point to some random field further down in struct sk_buff.
Doesn't look correct at all.
How did you test this patch?
^ permalink raw reply
* Re: [PATCH net-next 0/2] sctp: unify sctp_make_op_error_fixed and sctp_make_op_error_space
From: Marcelo Ricardo Leitner @ 2018-05-01 23:28 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-sctp, vyasevich, nhorman, lucien.xin
In-Reply-To: <20180501.121353.1918662858023133319.davem@davemloft.net>
On Tue, May 01, 2018 at 12:13:53PM -0400, David Miller wrote:
> From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Date: Sun, 29 Apr 2018 12:56:30 -0300
>
> > These two variants are very close to each other and can be merged
> > to avoid code duplication. That's what this patchset does.
> >
> > First, we allow sctp_init_cause to return errors, which then allow us to
> > add sctp_make_op_error_limited that handles both situations.
>
> Series applied.
Thanks.
>
> But generally, there are a lot of smtp_init_cause() call sites with non-zero
> payload length that should start checking the return value now.
They are safe as is, because they follow the pattern:
- sctp_make_abort(...., somesize)
- sctp_init_cause(size)
where size is considered in somesize, so sctp_init_cause cannot fail
in there.
This new usage in sctp_make_op_error_limited is the only one where it
allocates a buffer without knowing how much data will actually be
pushed into it.
Marcelo
^ permalink raw reply
* Re: [PATCH net-next v7 1/3] vmcore: add API to collect hardware dump in second kernel
From: Stephen Hemminger @ 2018-05-01 23:28 UTC (permalink / raw)
To: Rahul Lakkireddy
Cc: netdev, kexec, linux-fsdevel, linux-kernel, davem, viro, ebiederm,
akpm, torvalds, ganeshgr, nirranjan, indranil
In-Reply-To: <b6065b53c5446d98ee55e09119f6821f979418d4.1525197408.git.rahul.lakkireddy@chelsio.com>
On Tue, 1 May 2018 23:57:45 +0530
Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> wrote:
> +
> +int vmcore_add_device_dump(struct vmcoredd_data *data)
> +{
> + return __vmcore_add_device_dump(data);
> +}
> +EXPORT_SYMBOL(vmcore_add_device_dump);
> +#endif /* CONFIG_PROC_VMCORE_DEVICE_DUMP
Why the stub wrapper function?
it does nothing.
^ 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