- 23 Jun, 2020 1 commit
-
-
Andrii Nakryiko authored
Switch existing Kconfig externs to be just one of few possible kinds of more generic externs. This refactoring is in preparation for ksymbol extern support, added in the follow up patch. There are no functional changes intended. Signed-off-by:
Andrii Nakryiko <andriin@fb.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Reviewed-by:
Hao Luo <haoluo@google.com> Link: https://lore.kernel.org/bpf/20200619231703.738941-2-andriin@fb.com
-
- 22 Jun, 2020 6 commits
-
-
Andrii Nakryiko authored
Add a bunch of getter for various aspects of BPF map. Some of these attribute (e.g., key_size, value_size, type, etc) are available right now in struct bpf_map_def, but this patch adds getter allowing to fetch them individually. bpf_map_def approach isn't very scalable, when ABI stability requirements are taken into account. It's much easier to extend libbpf and add support for new features, when each aspect of BPF map has separate getter/setter. Getters follow the common naming convention of not explicitly having "get" in its name: bpf_map__type() returns map type, bpf_map__key_size() returns key_size. Setters, though, explicitly have set in their name: bpf_map__set_type(), bpf_map__set_key_size(). This patch ensures we now have a getter and a setter for the following map attributes: - type; - max_entries; - map_flags; - numa_node; - key_size; - value_size; - ifindex. bpf_map__resize() enforces unnecessary restriction of max_entries > 0. It is unnecessary, because libbpf actually supports zero max_entries for some cases (e.g., for PERF_EVENT_ARRAY map) and treats it specially during map creation time. To allow setting max_entries=0, new bpf_map__set_max_entries() setter is added. bpf_map__resize()'s behavior is preserved for backwards compatibility reasons. Map ifindex getter is added as well. There is a setter already, but no corresponding getter. Fix this assymetry as well. bpf_map__set_ifindex() itself is converted from void function into error-returning one, similar to other setters. The only error returned right now is -EBUSY, if BPF map is already loaded and has corresponding FD. One lacking attribute with no ability to get/set or even specify it declaratively is numa_node. This patch fixes this gap and both adds programmatic getter/setter, as well as adds support for numa_node field in BTF-defined map. Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Toke Høiland-Jørgensen <toke@redhat.com> Link: https://lore.kernel.org/bpf/20200621062112.3006313-1-andriin@fb.com
-
Andrey Ignatov authored
Add selftests to test access to map pointers from bpf program for all map types except struct_ops (that one would need additional work). verifier test focuses mostly on scenarios that must be rejected. prog_tests test focuses on accessing multiple fields both scalar and a nested struct from bpf program and verifies that those fields have expected values. Signed-off-by:
Andrey Ignatov <rdna@fb.com> Signed-off-by:
John Fastabend <john.fastabend@gmail.com> Acked-by:
Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/139a6a17f8016491e39347849b951525335c6eb4.1592600985.git.rdna@fb.com
-
Andrey Ignatov authored
Set map_btf_name and map_btf_id for all map types so that map fields can be accessed by bpf programs. Signed-off-by:
-
Andrey Ignatov authored
There are multiple use-cases when it's convenient to have access to bpf map fields, both `struct bpf_map` and map type specific struct-s such as `struct bpf_array`, `struct bpf_htab`, etc. For example while working with sock arrays it can be necessary to calculate the key based on map->max_entries (some_hash % max_entries). Currently this is solved by communicating max_entries via "out-of-band" channel, e.g. via additional map with known key to get info about target map. That works, but is not very convenient and error-prone while working with many maps. In other cases necessary data is dynamic (i.e. unknown at loading time) and it's impossible to get it at all. For example while working with a hash table it can be convenient to know how much capacity is already used (bpf_htab.count.counter for BPF_F_NO_PREALLOC case). At the same time kernel knows this info and can provide it to bpf program. Fill this gap by adding support to access bpf map fields from bpf program for both `struct bpf_map` and map type specific fields. Support is implemented via btf_struct_access() so that a user can define their own `struct bpf_map` or map type specific struct in their program with only necessary fields and preserve_access_index attribute, cast a map to this struct and use a field. For example: struct bpf_map { __u32 max_entries; } __attribute__((preserve_access_index)); struct bpf_array { struct bpf_map map; __u32 elem_size; } __attribute__((preserve_access_index)); struct { __uint(type, BPF_MAP_TYPE_ARRAY); __uint(max_entries, 4); __type(key, __u32); __type(value, __u32); } m_array SEC(".maps"); SEC("cgroup_skb/egress") int cg_skb(void *ctx) { struct bpf_array *array = (struct bpf_array *)&m_array; struct bpf_map *map = (struct bpf_map *)&m_array; /* .. use map->max_entries or array->map.max_entries .. */ } Similarly to other btf_struct_access() use-cases (e.g. struct tcp_sock in net/ipv4/bpf_tcp_ca.c) the patch allows access to any fields of corresponding struct. Only reading from map fields is supported. For btf_struct_access() to work there should be a way to know btf id of a struct that corresponds to a map type. To get btf id there should be a way to get a stringified name of map-specific struct, such as "bpf_array", "bpf_htab", etc for a map type. Two new fields are added to `struct bpf_map_ops` to handle it: * .map_btf_name keeps a btf name of a struct returned by map_alloc(); * .map_btf_id is used to cache btf id of that struct. To make btf ids calculation cheaper they're calculated once while preparing btf_vmlinux and cached same way as it's done for btf_id field of `struct bpf_func_proto` While calculating btf ids, struct names are NOT checked for collision. Collisions will be checked as a part of the work to prepare btf ids used in verifier in compile time that should land soon. The only known collision for `struct bpf_htab` (kernel/bpf/hashtab.c vs net/core/sock_map.c) was fixed earlier. Both new fields .map_btf_name and .map_btf_id must be set for a map type for the feature to work. If neither is set for a map type, verifier will return ENOTSUPP on a try to access map_ptr of corresponding type. If just one of them set, it's verifier misconfiguration. Only `struct bpf_array` for BPF_MAP_TYPE_ARRAY and `struct bpf_htab` for BPF_MAP_TYPE_HASH are supported by this patch. Other map types will be supported separately. The feature is available only for CONFIG_DEBUG_INFO_BTF=y and gated by perfmon_capable() so that unpriv programs won't have access to bpf map fields. Signed-off-by: -
Andrey Ignatov authored
There are two different `struct bpf_htab` in bpf code in the following files: - kernel/bpf/hashtab.c - net/core/sock_map.c It makes it impossible to find proper btf_id by name = "bpf_htab" and kind = BTF_KIND_STRUCT what is needed to support access to map ptr so that bpf program can access `struct bpf_htab` fields. To make it possible one of the struct-s should be renamed, sock_map.c looks like a better candidate for rename since it's specialized version of hashtab. Rename it to bpf_shtab ("sh" stands for Sock Hash). Signed-off-by: -
Andrey Ignatov authored
btf_parse_vmlinux() implements manual search for struct bpf_ctx_convert since at the time of implementing btf_find_by_name_kind() was not available. Later btf_find_by_name_kind() was introduced in 27ae7997 ("bpf: Introduce BPF_PROG_TYPE_STRUCT_OPS"). It provides similar search functionality and can be leveraged in btf_parse_vmlinux(). Do it. Signed-off-by:
-
- 19 Jun, 2020 3 commits
-
-
Andrii Nakryiko authored
Relicense it to be compatible with the rest of bpftool files. Suggested-by:
Quentin Monnet <quentin@isovalent.com> Signed-off-by:
-
Yonghong Song authored
Added two test_verifier subtests for 32bit pointer/scalar arithmetic with BPF_SUB operator. They are passing verifier now. Signed-off-by:
Yonghong Song <yhs@fb.com> Signed-off-by:
-
Yonghong Song authored
When do experiments with llvm (disabling instcombine and simplifyCFG), I hit the following error with test_seg6_loop.o. ; R1=pkt(id=0,off=0,r=48,imm=0), R7=pkt(id=0,off=40,r=48,imm=0) w2 = w7 ; R2_w=inv(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff)) w2 -= w1 R2 32-bit pointer arithmetic prohibited The corresponding source code is: uint32_t srh_off // srh and skb->data are all packet pointers srh_off = (char *)srh - (char *)(long)skb->data; The verifier does not support 32-bit pointer/scalar arithmetic. Without my llvm change, the code looks like ; R3=pkt(id=0,off=40,r=48,imm=0), R8=pkt(id=0,off=0,r=48,imm=0) w3 -= w8 ; R3_w=inv(id=0) This is explicitly allowed in verifier if both registers are pointers and the opcode is BPF_SUB. To fix this problem, I changed the verifier to allow 32-bit pointer/scaler BPF_SUB operations. At the source level, the issue could be workarounded with inline asm or changing "uint32_t srh_off" to "uint64_t srh_off". But I feel that verifier change might be the right thing to do. Signed-off-by:
-
- 18 Jun, 2020 1 commit
-
-
Martin KaFai Lau authored
The cache_idx is currently picked by RR. There is chance that the same cache_idx will be picked by multiple sk_storage_maps while other cache_idx is still unused. e.g. It could happen when the sk_storage_map is recreated during the restart of the user space process. This patch tracks the usage count for each cache_idx. There is 16 of them now (defined in BPF_SK_STORAGE_CACHE_SIZE). It will try to pick the free cache_idx. If none was found, it would pick one with the minimal usage count. Signed-off-by:
-
- 17 Jun, 2020 6 commits
-
-
Andrii Nakryiko authored
Bump libbpf version to 0.1.0, as new development cycle starts. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netLinus Torvalds authored
Pull networking fixes from David Miller: 1) Don't get per-cpu pointer with preemption enabled in nft_set_pipapo, fix from Stefano Brivio. 2) Fix memory leak in ctnetlink, from Pablo Neira Ayuso. 3) Multiple definitions of MPTCP_PM_MAX_ADDR, from Geliang Tang. 4) Accidently disabling NAPI in non-error paths of macb_open(), from Charles Keepax. 5) Fix races between alx_stop and alx_remove, from Zekun Shen. 6) We forget to re-enable SRIOV during resume in bnxt_en driver, from Michael Chan. 7) Fix memory leak in ipv6_mc_destroy_dev(), from Wang Hai. 8) rxtx stats use wrong index in mvpp2 driver, from Sven Auhagen. 9) Fix memory leak in mptcp_subflow_create_socket error path, from Wei Yongjun. 10) We should not adjust the TCP window advertised when sending dup acks in non-SACK mode, because it won't be counted as a dup by the sender if the window size changes. From Eric Dumazet. 11) Destroy the right number of queues during remove in mvpp2 driver, from Sven Auhagen. 12) Various WOL and PM fixes to e1000 driver, from Chen Yu, Vaibhav Gupta, and Arnd Bergmann. * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (35 commits) e1000e: fix unused-function warning e1000: use generic power management e1000e: Do not wake up the system via WOL if device wakeup is disabled lan743x: add MODULE_DEVICE_TABLE for module loading alias mlxsw: spectrum: Adjust headroom buffers for 8x ports bareudp: Fixed configuration to avoid having garbage values mvpp2: remove module bugfix tcp: grow window for OOO packets only for SACK flows mptcp: fix memory leak in mptcp_subflow_create_socket() netfilter: flowtable: Make nf_flow_table_offload_add/del_cb inline net/sched: act_ct: Make tcf_ct_flow_table_restore_skb inline net: dsa: sja1105: fix PTP timestamping with large tc-taprio cycles mvpp2: ethtool rxtx stats fix MAINTAINERS: switch to my private email for Renesas Ethernet drivers rocker: fix incorrect error handling in dma_rings_init test_objagg: Fix potential memory leak in error handling net: ethernet: mtk-star-emac: simplify interrupt handling mld: fix memory leak in ipv6_mc_destroy_dev() bnxt_en: Return from timer if interface is not in open state. bnxt_en: Fix AER reset logic on 57500 chips. ... -
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fsLinus Torvalds authored
Pull AFS fixes from David Howells: "I've managed to get xfstests kind of working with afs. Here are a set of patches that fix most of the bugs found. There are a number of primary issues: - Incorrect handling of mtime and non-handling of ctime. It might be argued, that the latter isn't a bug since the AFS protocol doesn't support ctime, but I should probably still update it locally. - Shared-write mmap, truncate and writeback bugs. This includes not changing i_size under the callback lock, overwriting local i_size with the reply from the server after a partial writeback, not limiting the writeback from an mmapped page to EOF. - Checks for an abort code indicating that the primary vnode in an operation was deleted by a third-party are done in the wrong place. - Silly rename bugs. This includes an incomplete conversion to the new operation handling, duplicate nlink handling, nlink changing not being done inside the callback lock and insufficient handling of third-party conflicting directory changes. And some secondary ones: - The UAEOVERFLOW abort code should map to EOVERFLOW not EREMOTEIO. - Remove a couple of unused or incompletely used bits. - Remove a couple of redundant success checks. These seem to fix all the data-corruption bugs found by ./check -afs -g quick along with the obvious silly rename bugs and time bugs. There are still some test failures, but they seem to fall into two classes: firstly, the authentication/security model is different to the standard UNIX model and permission is arbitrated by the server and cached locally; and secondly, there are a number of features that AFS does not support (such as mknod). But in these cases, the tests themselves need to be adapted or skipped. Using the in-kernel afs client with xfstests also found a bug in the AuriStor AFS server that has been fixed for a future release" * tag 'afs-fixes-20200616' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs: afs: Fix silly rename afs: afs_vnode_commit_status() doesn't need to check the RPC error afs: Fix use of afs_check_for_remote_deletion() afs: Remove afs_operation::abort_code afs: Fix yfs_fs_fetch_status() to honour vnode selector afs: Remove yfs_fs_fetch_file_status() as it's not used afs: Fix the mapping of the UAEOVERFLOW abort code afs: Fix truncation issues and mmap writeback size afs: Concoct ctimes afs: Fix EOF corruption afs: afs_write_end() should change i_size under the right lock afs: Fix non-setting of mtime when writing into mmap -
Randy Dunlap authored
Remove SH-5 documentation index entries following the removal of SH-5 source code. Error: Cannot open file ../arch/sh/mm/tlb-sh5.c Error: Cannot open file ../arch/sh/mm/tlb-sh5.c Error: Cannot open file ../arch/sh/include/asm/tlb_64.h Error: Cannot open file ../arch/sh/include/asm/tlb_64.h Fixes: 3b69e8b4 ("Merge tag 'sh-for-5.8' of git://git.libc.org/linux-sh") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Cc: Rich Felker <dalias@libc.org> Cc: Christoph Hellwig <hch@infradead.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: ysato@users.sourceforge.jp Cc: linux-sh@vger.kernel.org Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
Merge tag 'flex-array-conversions-5.8-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux Pull flexible-array member conversions from Gustavo A. R. Silva: "Replace zero-length arrays with flexible-array members. Notice that all of these patches have been baking in linux-next for two development cycles now. There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. C99 introduced “flexible array members”, which lacks a numeric size for the array declaration entirely: struct something { size_t count; struct foo items[]; }; This is the way the kernel expects dynamically sized trailing elements to be declared. It allows the compiler to generate errors when the flexible array does not occur last in the structure, which helps to prevent some kind of undefined behavior[3] bugs from being inadvertently introduced to the codebase. It also allows the compiler to correctly analyze array sizes (via sizeof(), CONFIG_FORTIFY_SOURCE, and CONFIG_UBSAN_BOUNDS). For instance, there is no mechanism that warns us that the following application of the sizeof() operator to a zero-length array always results in zero: struct something { size_t count; struct foo items[0]; }; struct something *instance; instance = kmalloc(struct_size(instance, items, count), GFP_KERNEL); instance->count = count; size = sizeof(instance->items) * instance->count; memcpy(instance->items, source, size); At the last line of code above, size turns out to be zero, when one might have thought it represents the total size in bytes of the dynamic memory recently allocated for the trailing array items. Here are a couple examples of this issue[4][5]. Instead, flexible array members have incomplete type, and so the sizeof() operator may not be applied[6], so any misuse of such operators will be immediately noticed at build time. The cleanest and least error-prone way to implement this is through the use of a flexible array member: struct something { size_t count; struct foo items[]; }; struct something *instance; instance = kmalloc(struct_size(instance, items, count), GFP_KERNEL); instance->count = count; size = sizeof(instance->items[0]) * instance->count; memcpy(instance->items, source, size); instead" [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") [4] commit f2cd32a4 ("rndis_wlan: Remove logically dead code") [5] commit ab91c2a8 ("tpm: eventlog: Replace zero-length array with flexible-array member") [6] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html * tag 'flex-array-conversions-5.8-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux: (41 commits) w1: Replace zero-length array with flexible-array tracing/probe: Replace zero-length array with flexible-array soc: ti: Replace zero-length array with flexible-array tifm: Replace zero-length array with flexible-array dmaengine: tegra-apb: Replace zero-length array with flexible-array stm class: Replace zero-length array with flexible-array Squashfs: Replace zero-length array with flexible-array ASoC: SOF: Replace zero-length array with flexible-array ima: Replace zero-length array with flexible-array sctp: Replace zero-length array with flexible-array phy: samsung: Replace zero-length array with flexible-array RxRPC: Replace zero-length array with flexible-array rapidio: Replace zero-length array with flexible-array media: pwc: Replace zero-length array with flexible-array firmware: pcdp: Replace zero-length array with flexible-array oprofile: Replace zero-length array with flexible-array block: Replace zero-length array with flexible-array tools/testing/nvdimm: Replace zero-length array with flexible-array libata: Replace zero-length array with flexible-array kprobes: Replace zero-length array with flexible-array ...
-
Arvind Sankar authored
The purgatory Makefile removes -fstack-protector options if they were configured in, but does not currently add -fno-stack-protector. If gcc was configured with the --enable-default-ssp configure option, this results in the stack protector still being enabled for the purgatory (absent distro-specific specs files that might disable it again for freestanding compilations), if the main kernel is being compiled with stack protection enabled (if it's disabled for the main kernel, the top-level Makefile will add -fno-stack-protector). This will break the build since commit e4160b2e ("x86/purgatory: Fail the build if purgatory.ro has missing symbols") and prior to that would have caused runtime failure when trying to use kexec. Explicitly add -fno-stack-protector to avoid this, as done in other Makefiles that need to disable the stack protector. Reported-by:
Gabriel C <nix.or.die@googlemail.com> Signed-off-by:
Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by:
-
- 16 Jun, 2020 23 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queueDavid S. Miller authored
Jeff Kirsher says: ==================== Intel Wired LAN Driver Updates 2020-06-16 This series contains fixes to e1000 and e1000e. Chen fixes an e1000e issue where systems could be waken via WoL, even though the user has disabled the wakeup bit via sysfs. Vaibhav Gupta updates the e1000 driver to clean up the legacy Power Management hooks. Arnd Bergmann cleans up the inconsistent use CONFIG_PM_SLEEP preprocessor tags, which also resolves the compiler warnings about the possibility of unused structure. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Arnd Bergmann authored
The CONFIG_PM_SLEEP #ifdef checks in this file are inconsistent, leading to a warning about sometimes unused function: drivers/net/ethernet/intel/e1000e/netdev.c:137:13: error: unused function 'e1000e_check_me' [-Werror,-Wunused-function] Rather than adding more #ifdefs, just remove them completely and mark the PM functions as __maybe_unused to let the compiler work it out on it own. Fixes: e086ba2f ("e1000e: disable s0ix entry and exit flows for ME systems") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Vaibhav Gupta authored
With legacy PM hooks, it was the responsibility of a driver to manage PCI states and also the device's power state. The generic approach is to let PCI core handle the work. e1000_suspend() calls __e1000_shutdown() to perform intermediate tasks. __e1000_shutdown() modifies the value of "wake" (device should be wakeup enabled or not), responsible for controlling the flow of legacy PM. Since, PCI core has no idea about the value of "wake", new code for generic PM may produce unexpected results. Thus, use "device_set_wakeup_enable()" to wakeup-enable the device accordingly. Signed-off-by:
Vaibhav Gupta <vaibhavgupta40@gmail.com> Tested-by:
-
Chen Yu authored
Currently the system will be woken up via WOL(Wake On LAN) even if the device wakeup ability has been disabled via sysfs: cat /sys/devices/pci0000:00/0000:00:1f.6/power/wakeup disabled The system should not be woken up if the user has explicitly disabled the wake up ability for this device. This patch clears the WOL ability of this network device if the user has disabled the wake up ability in sysfs. Fixes: bc7f75fa ("[E1000E]: New pci-express e1000 driver") Reported-by:
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: <Stable@vger.kernel.org> Signed-off-by:
Chen Yu <yu.c.chen@intel.com> Tested-by:
-
Tim Harvey authored
Without a MODULE_DEVICE_TABLE the attributes are missing that create an alias for auto-loading the module in userspace via hotplug. Signed-off-by:
Tim Harvey <tharvey@gateworks.com> Signed-off-by:
-
David Howells authored
Fix AFS's silly rename by the following means: (1) Set the destination directory in afs_do_silly_rename() so as to avoid misbehaviour and indicate that the directory data version will increment by 1 so as to avoid warnings about unexpected changes in the DV. Also indicate that the ctime should be updated to avoid xfstest grumbling. (2) Note when the server indicates that a directory changed more than we expected (AFS_OPERATION_DIR_CONFLICT), indicating a conflict with a third party change, checking on successful completion of unlink and rename. The problem is that the FS.RemoveFile RPC op doesn't report the status of the unlinked file, though YFS.RemoveFile2 does. This can be mitigated by the assumption that if the directory DV cranked by exactly 1, we can be sure we removed one link from the file; further, ordinarily in AFS, files cannot be hardlinked across directories, so if we reduce nlink to 0, the file is deleted. However, if the directory DV jumps by more than 1, we cannot know if a third party intervened by adding or removing a link on the file we just removed a link from. The same also goes for any vnode that is at the destination of the FS.Rename RPC op. (3) Make afs_vnode_commit_status() apply the nlink drop inside the cb_lock section along with the other attribute updates if ->op_unlinked is set on the descriptor for the appropriate vnode. (4) Issue a follow up status fetch to the unlinked file in the event of a third party conflict that makes it impossible for us to know if we actually deleted the file or not. (5) Provide a flag, AFS_VNODE_SILLY_DELETED, to make afs_getattr() lie to the user about the nlink of a silly deleted file so that it appears as 0, not 1. Found with the generic/035 and generic/084 xfstests. Fixes: e49c7b2f ("afs: Build an abstraction around an "operation" concept") Reported-by:Marc Dionne <marc.dionne@auristor.com> Signed-off-by:
David Howells <dhowells@redhat.com>
-
Ido Schimmel authored
The port's headroom buffers are used to store packets while they traverse the device's pipeline and also to store packets that are egress mirrored. On Spectrum-3, ports with eight lanes use two headroom buffers between which the configured headroom size is split. In order to prevent packet loss, multiply the calculated headroom size by two for 8x ports. Fixes: da382875 ("mlxsw: spectrum: Extend to support Spectrum-3 ASIC") Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Reviewed-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Martin authored
Code to initialize the conf structure while gathering the configuration of the device was missing. Fixes: 571912c6 ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.") Signed-off-by:
Martin <martin.varghese@nokia.com> Signed-off-by:
-
Sven Auhagen authored
The remove function does not destroy all BM Pools when per cpu pool is active. When reloading the mvpp2 as a module the BM Pools are still active in hardware and due to the bug have twice the size now old + new. This eventually leads to a kernel crash. v2: * add Fixes tag Fixes: 7d04b0b1 ("mvpp2: percpu buffers") Signed-off-by:
Sven Auhagen <sven.auhagen@voleatech.de> Signed-off-by:
-
Eric Dumazet authored
Back in 2013, we made a change that broke fast retransmit for non SACK flows. Indeed, for these flows, a sender needs to receive three duplicate ACK before starting fast retransmit. Sending ACK with different receive window do not count. Even if enabling SACK is strongly recommended these days, there still are some cases where it has to be disabled. Not increasing the window seems better than having to rely on RTO. After the fix, following packetdrill test gives : // Initialize connection 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1) = 0 +0 < S 0:0(0) win 32792 <mss 1000,nop,wscale 7> +0 > S. 0:0(0) ack 1 <mss 1460,nop,wscale 8> +0 < . 1:1(0) ack 1 win 514 +0 accept(3, ..., ...) = 4 +0 < . 1:1001(1000) ack 1 win 514 // Quick ack +0 > . 1:1(0) ack 1001 win 264 +0 < . 2001:3001(1000) ack 1 win 514 // DUPACK : Normally we should not change the window +0 > . 1:1(0) ack 1001 win 264 +0 < . 3001:4001(1000) ack 1 win 514 // DUPACK : Normally we should not change the window +0 > . 1:1(0) ack 1001 win 264 +0 < . 4001:5001(1000) ack 1 win 514 // DUPACK : Normally we should not change the window +0 > . 1:1(0) ack 1001 win 264 +0 < . 1001:2001(1000) ack 1 win 514 // Hole is repaired. +0 > . 1:1(0) ack 5001 win 272 Fixes: 4e4f1fc2 ("tcp: properly increase rcv_ssthresh for ofo packets") Signed-off-by:Eric Dumazet <edumazet@google.com> Reported-by:
Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfdLinus Torvalds authored
Pull MFD fix from Lee Jones: "Fix NULL pointer dereference in mt6360 driver" * tag 'mfd-fixes-5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: mfd: mt6360: Fix register driver NULL pointer by adding driver name
-
David Howells authored
afs_vnode_commit_status() is only ever called if op->error is 0, so remove the op->error checks from the function. Fixes: e49c7b2f ("afs: Build an abstraction around an "operation" concept") Signed-off-by:
-
David Howells authored
afs_check_for_remote_deletion() checks to see if error ENOENT is returned by the server in response to an operation and, if so, marks the primary vnode as having been deleted as the FID is no longer valid. However, it's being called from the operation success functions, where no abort has happened - and if an inline abort is recorded, it's handled by afs_vnode_commit_status(). Fix this by actually calling the operation aborted method if provided and having that point to afs_check_for_remote_deletion(). Fixes: e49c7b2f ("afs: Build an abstraction around an "operation" concept") Signed-off-by:
-
David Howells authored
Remove afs_operation::abort_code as it's read but never set. Use ac.abort_code instead. Signed-off-by: -
David Howells authored
Fix yfs_fs_fetch_status() to honour the vnode selector in op->fetch_status.which as does afs_fs_fetch_status() that allows afs_do_lookup() to use this as an alternative to the InlineBulkStatus RPC call if not implemented by the server. This doesn't matter in the current code as YFS servers always implement InlineBulkStatus, but a subsequent will call it on YFS servers too in some circumstances. Fixes: e49c7b2f ("afs: Build an abstraction around an "operation" concept") Signed-off-by:
-
David Howells authored
Remove yfs_fs_fetch_file_status() as it's no longer used. Signed-off-by: -
Gene Chen authored
The driver name was accidentally removed when .probe() by was replaced by .probe_new() during an early patch review. [ 121.243012] EAX: c2a8bc64 EBX: 00000000 ECX: 00000000 EDX: 00000000 [ 121.243012] ESI: c2a8bc79 EDI: 00000000 EBP: e54bdea8 ESP: e54bdea0 [ 121.243012] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010286 [ 121.243012] CR0: 80050033 CR2: 00000000 CR3: 02ec3000 CR4: 000006b0 [ 121.243012] Call Trace: [ 121.243012] kset_find_obj+0x3d/0xc0 [ 121.243012] driver_find+0x16/0x40 [ 121.243012] driver_register+0x49/0x100 [ 121.243012] ? i2c_for_each_dev+0x39/0x50 [ 121.243012] ? __process_new_adapter+0x20/0x20 [ 121.243012] ? cht_wc_driver_init+0x11/0x11 [ 121.243012] i2c_register_driver+0x30/0x80 [ 121.243012] ? intel_lpss_pci_driver_init+0x16/0x16 [ 121.243012] mt6360_pmu_driver_init+0xf/0x11 [ 121.243012] do_one_initcall+0x33/0x1a0 [ 121.243012] ? parse_args+0x1eb/0x3d0 [ 121.243012] ? __might_sleep+0x31/0x90 [ 121.243012] ? kernel_init_freeable+0x10a/0x17f [ 121.243012] kernel_init_freeable+0x12c/0x17f [ 121.243012] ? rest_init+0x110/0x110 [ 121.243012] kernel_init+0xb/0x100 [ 121.243012] ? schedule_tail_wrapper+0x9/0xc [ 121.243012] ret_from_fork+0x19/0x24 [ 121.243012] Modules linked in: [ 121.243012] CR2: 0000000000000000 [ 121.243012] random: get_random_bytes called from init_oops_id+0x3a/0x40 with crng_init=0 [ 121.243012] ---[ end trace 38a803400f1a2bee ]--- [ 121.243012] EIP: strcmp+0x11/0x30 Fixes: 7edd3634 ("mfd: Add support for PMIC MT6360") Signed-off-by:
Gene Chen <gene_chen@richtek.com> Reviewed-by:
Matthias Brugger <matthias.bgg@kernel.org> [Lee: Taking the opportunity to fix the compatible string too 's/_/-/'] Signed-off-by:
Lee Jones <lee.jones@linaro.org>
-
Gustavo A. R. Silva authored
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://github.com/KSPP/linux/issues/21Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org>
-
Gustavo A. R. Silva authored
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://github.com/KSPP/linux/issues/21Signed-off-by:
-
Gustavo A. R. Silva authored
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://github.com/KSPP/linux/issues/21Signed-off-by:
-
Gustavo A. R. Silva authored
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://github.com/KSPP/linux/issues/21Signed-off-by:
-
Gustavo A. R. Silva authored
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://github.com/KSPP/linux/issues/21Signed-off-by:
-
Gustavo A. R. Silva authored
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://github.com/KSPP/linux/issues/21Signed-off-by:
-
