- 30 Mar, 2020 1 commit
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller authored
Minor comment conflict in mac80211. Signed-off-by:David S. Miller <davem@davemloft.net>
-
- 29 Mar, 2020 10 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
Merge vm fixes from Andrew Morton: "5 fixes" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: mm/sparse: fix kernel crash with pfn_section_valid check mm: fork: fix kernel_stack memcg stats for various stack implementations hugetlb_cgroup: fix illegal access to memory drivers/base/memory.c: indicate all memory blocks as removable mm/swapfile.c: move inode_lock out of claim_swapfile
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull timer fix from Thomas Gleixner: "A single fix for the Hyper-V clocksource driver to make sched clock actually return nanoseconds and not the virtual clock value which increments at 10e7 HZ (100ns)" * tag 'timers-urgent-2020-03-29' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: clocksource/drivers/hyper-v: Make sched clock return nanoseconds correctly
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull irq fix from Thomas Gleixner: "A single bugfix to prevent reference leaks in irq affinity notifiers" * tag 'irq-urgent-2020-03-29' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: genirq: Fix reference leaks on irq affinity notifiers
-
Aneesh Kumar K.V authored
Fix the crash like this: BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc000000000c3447c Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries CPU: 11 PID: 7519 Comm: lt-ndctl Not tainted 5.6.0-rc7-autotest #1 ... NIP [c000000000c3447c] vmemmap_populated+0x98/0xc0 LR [c000000000088354] vmemmap_free+0x144/0x320 Call Trace: section_deactivate+0x220/0x240 __remove_pages+0x118/0x170 arch_remove_memory+0x3c/0x150 memunmap_pages+0x1cc/0x2f0 devm_action_release+0x30/0x50 release_nodes+0x2f8/0x3e0 device_release_driver_internal+0x168/0x270 unbind_store+0x130/0x170 drv_attr_store+0x44/0x60 sysfs_kf_write+0x68/0x80 kernfs_fop_write+0x100/0x290 __vfs_write+0x3c/0x70 vfs_write+0xcc/0x240 ksys_write+0x7c/0x140 system_call+0x5c/0x68 The crash is due to NULL dereference at test_bit(idx, ms->usage->subsection_map); due to ms->usage = NULL in pfn_section_valid() With commit d41e2f3b ("mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case") section_mem_map is set to NULL after depopulate_section_mem(). This was done so that pfn_page() can work correctly with kernel config that disables SPARSEMEM_VMEMMAP. With that config pfn_to_page does __section_mem_map_addr(__sec) + __pfn; where static inline struct page *__section_mem_map_addr(struct mem_section *section) { unsigned long map = section->section_mem_map; map &= SECTION_MAP_MASK; return (struct page *)map; } Now with SPASEMEM_VMEMAP enabled, mem_section->usage->subsection_map is used to check the pfn validity (pfn_valid()). Since section_deactivate release mem_section->usage if a section is fully deactivated, pfn_valid() check after a subsection_deactivate cause a kernel crash. static inline int pfn_valid(unsigned long pfn) { ... return early_section(ms) || pfn_section_valid(ms, pfn); } where static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn) { int idx = subsection_map_index(pfn); return test_bit(idx, ms->usage->subsection_map); } Avoid this by clearing SECTION_HAS_MEM_MAP when mem_section->usage is freed. For architectures like ppc64 where large pages are used for vmmemap mapping (16MB), a specific vmemmap mapping can cover multiple sections. Hence before a vmemmap mapping page can be freed, the kernel needs to make sure there are no valid sections within that mapping. Clearing the section valid bit before depopulate_section_memap enables this. [aneesh.kumar@linux.ibm.com: add comment] Link: http://lkml.kernel.org/r/20200326133235.343616-1-aneesh.kumar@linux.ibm.comLink: http://lkml.kernel.org/r/20200325031914.107660-1-aneesh.kumar@linux.ibm.com Fixes: d41e2f3b ("mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case") Reported-by:Sachin Sant <sachinp@linux.vnet.ibm.com> Signed-off-by:
Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Tested-by:
Baoquan He <bhe@redhat.com> Reviewed-by:
Wei Yang <richard.weiyang@gmail.com> Acked-by:
Michal Hocko <mhocko@suse.com> Acked-by:
Pankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Dan Williams <dan.j.williams@intel.com> Cc: David Hildenbrand <david@redhat.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Mike Rapoport <rppt@linux.ibm.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Roman Gushchin authored
Depending on CONFIG_VMAP_STACK and the THREAD_SIZE / PAGE_SIZE ratio the space for task stacks can be allocated using __vmalloc_node_range(), alloc_pages_node() and kmem_cache_alloc_node(). In the first and the second cases page->mem_cgroup pointer is set, but in the third it's not: memcg membership of a slab page should be determined using the memcg_from_slab_page() function, which looks at page->slab_cache->memcg_params.memcg . In this case, using mod_memcg_page_state() (as in account_kernel_stack()) is incorrect: page->mem_cgroup pointer is NULL even for pages charged to a non-root memory cgroup. It can lead to kernel_stack per-memcg counters permanently showing 0 on some architectures (depending on the configuration). In order to fix it, let's introduce a mod_memcg_obj_state() helper, which takes a pointer to a kernel object as a first argument, uses mem_cgroup_from_obj() to get a RCU-protected memcg pointer and calls mod_memcg_state(). It allows to handle all possible configurations (CONFIG_VMAP_STACK and various THREAD_SIZE/PAGE_SIZE values) without spilling any memcg/kmem specifics into fork.c . Note: This is a special version of the patch created for stable backports. It contains code from the following two patches: - mm: memcg/slab: introduce mem_cgroup_from_obj() - mm: fork: fix kernel_stack memcg stats for various stack implementations [guro@fb.com: introduce mem_cgroup_from_obj()] Link: http://lkml.kernel.org/r/20200324004221.GA36662@carbon.dhcp.thefacebook.com Fixes: 4d96ba35 ("mm: memcg/slab: stop setting page->mem_cgroup pointer for slab pages") Signed-off-by:
Roman Gushchin <guro@fb.com> Signed-off-by:
Shakeel Butt <shakeelb@google.com> Acked-by:
Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@kernel.org> Cc: Bharata B Rao <bharata@linux.ibm.com> Cc: Shakeel Butt <shakeelb@google.com> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/20200303233550.251375-1-guro@fb.comSigned-off-by:
-
Mina Almasry authored
This appears to be a mistake in commit faced7e0 ("mm: hugetlb controller for cgroups v2"). Essentially that commit does a hugetlb_cgroup_from_counter assuming that page_counter_try_charge has initialized counter. But if that has failed then it seems will not initialize counter, so hugetlb_cgroup_from_counter(counter) ends up pointing to random memory, causing kasan to complain. The solution is to simply use 'h_cg', instead of hugetlb_cgroup_from_counter(counter), since that is a reference to the hugetlb_cgroup anyway. After this change kasan ceases to complain. Fixes: faced7e0 ("mm: hugetlb controller for cgroups v2") Reported-by: syzbot+cac0c4e204952cf449b1@syzkaller.appspotmail.com Signed-off-by:
Mina Almasry <almasrymina@google.com> Signed-off-by:
Giuseppe Scrivano <gscrivan@redhat.com> Acked-by:
Tejun Heo <tj@kernel.org> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: David Rientjes <rientjes@google.com> Link: http://lkml.kernel.org/r/20200313223920.124230-1-almasrymina@google.comSigned-off-by:
-
David Hildenbrand authored
We see multiple issues with the implementation/interface to compute whether a memory block can be offlined (exposed via /sys/devices/system/memory/memoryX/removable) and would like to simplify it (remove the implementation). 1. It runs basically lockless. While this might be good for performance, we see possible races with memory offlining that will require at least some sort of locking to fix. 2. Nowadays, more false positives are possible. No arch-specific checks are performed that validate if memory offlining will not be denied right away (and such check will require locking). For example, arm64 won't allow to offline any memory block that was added during boot - which will imply a very high error rate. Other archs have other constraints. 3. The interface is inherently racy. E.g., if a memory block is detected to be removable (and was not a false positive at that time), there is still no guarantee that offlining will actually succeed. So any caller already has to deal with false positives. 4. It is unclear which performance benefit this interface actually provides. The introducing commit 5c755e9f ("memory-hotplug: add sysfs removable attribute for hotplug memory remove") mentioned "A user-level agent must be able to identify which sections of memory are likely to be removable before attempting the potentially expensive operation." However, no actual performance comparison was included. Known users: - lsmem: Will group memory blocks based on the "removable" property. [1] - chmem: Indirect user. It has a RANGE mode where one can specify removable ranges identified via lsmem to be offlined. However, it also has a "SIZE" mode, which allows a sysadmin to skip the manual "identify removable blocks" step. [2] - powerpc-utils: Uses the "removable" attribute to skip some memory blocks right away when trying to find some to offline+remove. However, with ballooning enabled, it already skips this information completely (because it once resulted in many false negatives). Therefore, the implementation can deal with false positives properly already. [3] According to Nathan Fontenot, DLPAR on powerpc is nowadays no longer driven from userspace via the drmgr command (powerpc-utils). Nowadays it's managed in the kernel - including onlining/offlining of memory blocks - triggered by drmgr writing to /sys/kernel/dlpar. So the affected legacy userspace handling is only active on old kernels. Only very old versions of drmgr on a new kernel (unlikely) might execute slower - totally acceptable. With CONFIG_MEMORY_HOTREMOVE, always indicating "removable" should not break any user space tool. We implement a very bad heuristic now. Without CONFIG_MEMORY_HOTREMOVE we cannot offline anything, so report "not removable" as before. Original discussion can be found in [4] ("[PATCH RFC v1] mm: is_mem_section_removable() overhaul"). Other users of is_mem_section_removable() will be removed next, so that we can remove is_mem_section_removable() completely. [1] http://man7.org/linux/man-pages/man1/lsmem.1.html [2] http://man7.org/linux/man-pages/man8/chmem.8.html [3] https://github.com/ibm-power-utilities/powerpc-utils [4] https://lkml.kernel.org/r/20200117105759.27905-1-david@redhat.com Also, this patch probably fixes a crash reported by Steve. http://lkml.kernel.org/r/CAPcyv4jpdaNvJ67SkjyUJLBnBnXXQv686BiVW042g03FUmWLXw@mail.gmail.comReported-by:
"Scargall, Steve" <steve.scargall@intel.com> Suggested-by:
Michal Hocko <mhocko@kernel.org> Signed-off-by:
David Hildenbrand <david@redhat.com> Signed-off-by:
Nathan Fontenot <ndfont@gmail.com> Acked-by:
-
Naohiro Aota authored
claim_swapfile() currently keeps the inode locked when it is successful, or the file is already swapfile (with -EBUSY). And, on the other error cases, it does not lock the inode. This inconsistency of the lock state and return value is quite confusing and actually causing a bad unlock balance as below in the "bad_swap" section of __do_sys_swapon(). This commit fixes this issue by moving the inode_lock() and IS_SWAPFILE check out of claim_swapfile(). The inode is unlocked in "bad_swap_unlock_inode" section, so that the inode is ensured to be unlocked at "bad_swap". Thus, error handling codes after the locking now jumps to "bad_swap_unlock_inode" instead of "bad_swap". ===================================== WARNING: bad unlock balance detected! 5.5.0-rc7+ #176 Not tainted ------------------------------------- swapon/4294 is trying to release lock (&sb->s_type->i_mutex_key) at: __do_sys_swapon+0x94b/0x3550 but there are no more locks to release! other info that might help us debug this: no locks held by swapon/4294. stack backtrace: CPU: 5 PID: 4294 Comm: swapon Not tainted 5.5.0-rc7-BTRFS-ZNS+ #176 Hardware name: ASUS All Series/H87-PRO, BIOS 2102 07/29/2014 Call Trace: dump_stack+0xa1/0xea print_unlock_imbalance_bug.cold+0x114/0x123 lock_release+0x562/0xed0 up_write+0x2d/0x490 __do_sys_swapon+0x94b/0x3550 __x64_sys_swapon+0x54/0x80 do_syscall_64+0xa4/0x4b0 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f15da0a0dc7 Fixes: 1638045c ("mm: set S_SWAPFILE on blockdev swap devices") Signed-off-by:Naohiro Aota <naohiro.aota@wdc.com> Signed-off-by:
Qais Youef <qais.yousef@arm.com> Reviewed-by:
Darrick J. Wong <darrick.wong@oracle.com> Cc: Christoph Hellwig <hch@infradead.org> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/20200206090132.154869-1-naohiro.aota@wdc.comSigned-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netLinus Torvalds authored
Pull networking fixes from David Miller: 1) Fix memory leak in vti6, from Torsten Hilbrich. 2) Fix double free in xfrm_policy_timer, from YueHaibing. 3) NL80211_ATTR_CHANNEL_WIDTH attribute is put with wrong type, from Johannes Berg. 4) Wrong allocation failure check in qlcnic driver, from Xu Wang. 5) Get ks8851-ml IO operations right, for real this time, from Marek Vasut. * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (22 commits) r8169: fix PHY driver check on platforms w/o module softdeps net: ks8851-ml: Fix IO operations, again mlxsw: spectrum_mr: Fix list iteration in error path qlcnic: Fix bad kzalloc null test mac80211: set IEEE80211_TX_CTRL_PORT_CTRL_PROTO for nl80211 TX mac80211: mark station unauthorized before key removal mac80211: Check port authorization in the ieee80211_tx_dequeue() case cfg80211: Do not warn on same channel at the end of CSA mac80211: drop data frames without key on encrypted links ieee80211: fix HE SPR size calculation nl80211: fix NL80211_ATTR_CHANNEL_WIDTH attribute type xfrm: policy: Fix doulbe free in xfrm_policy_timer bpf: Explicitly memset some bpf info structures declared on the stack bpf: Explicitly memset the bpf_attr structure bpf: Sanitize the bpf_struct_ops tcp-cc name vti6: Fix memory leak of skb if input policy check fails esp: remove the skb from the chain when it's enqueued in cryptd_wq ipv6: xfrm6_tunnel.c: Use built-in RCU list checking xfrm: add the missing verify_sec_ctx_len check in xfrm_add_acquire xfrm: fix uctx len check in verify_sec_ctx_len ...
-
- 28 Mar, 2020 4 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxLinus Torvalds authored
Pull i2c fixes from Wolfram Sang: "Three more driver bugfixes, and two doc improvements fixing build warnings while we are here" * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: pca-platform: Use platform_irq_get_optional i2c: st: fix missing struct parameter description i2c: nvidia-gpu: Handle timeout correctly in gpu_i2c_check_status() i2c: fix a doc warning i2c: hix5hd2: add missed clk_disable_unprepare in remove
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds authored
Pull SCSI fixes from James Bottomley: "Two small fixes: one in drivers (qla2xxx), and one in the core (sd) to try to cope with USB enclosures that silently change reported parameters" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: sd: Fix optimal I/O size for devices that change reported values scsi: qla2xxx: Fix I/Os being passed down when FC device is being deleted
-
Chris Packham authored
The interrupt is not required so use platform_irq_get_optional() to avoid error messages like i2c-pca-platform 22080000.i2c: IRQ index 0 not found Signed-off-by:
Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
Alain Volmat authored
Fix a missing struct parameter description to allow warning free W=1 compilation. Signed-off-by:
Alain Volmat <avolmat@me.com> Reviewed-by:
Patrice Chotard <patrice.chotard@st.com> Signed-off-by:
-
- 27 Mar, 2020 25 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfDavid S. Miller authored
Daniel Borkmann says: ==================== pull-request: bpf 2020-03-27 The following pull-request contains BPF updates for your *net* tree. We've added 3 non-merge commits during the last 4 day(s) which contain a total of 4 files changed, 25 insertions(+), 20 deletions(-). The main changes are: 1) Explicitly memset the bpf_attr structure on bpf() syscall to avoid having to rely on compiler to do so. Issues have been noticed on some compilers with padding and other oddities where the request was then unexpectedly rejected, from Greg Kroah-Hartman. 2) Sanitize the bpf_struct_ops TCP congestion control name in order to avoid problematic characters such as whitespaces, from Martin KaFai Lau. ==================== Signed-off-by: -
David S. Miller authored
Vladimir Oltean says: ==================== Configure the MTU on DSA switches This series adds support for configuring the MTU on front-panel switch ports, while seamlessly adapting the CPU port and the DSA master to the largest value plus the tagger overhead. It also implements bridge MTU auto-normalization within the DSA core, as resulted after the feedback of the implementation of this feature inside the bridge driver in v2. Support was added for quite a number of switches, in the hope that this series would gain some traction: - sja1105 - felix - vsc73xx - b53 and rest of the platform V3 of this series was submitted here: https://patchwork.ozlabs.org/cover/1262394/ V2 of this series was submitted here: https://patchwork.ozlabs.org/cover/1261471/ V1 of this series was submitted here: https://patchwork.ozlabs.org/cover/1199868/ ==================== Signed-off-by:
-
Vladimir Oltean authored
Changing the MTU for this switch means altering the DEV_GMII:MAC_CFG_STATUS:MAC_MAXLEN_CFG field MAX_LEN, which in turn limits the size of frames that can be received. Special accounting needs to be done for the DSA CPU port (NPI port in hardware terms). The NPI port configuration needs to be held inside the private ocelot structure, since it is now accessed from multiple places. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Vladimir Oltean authored
Instead of hardcoding the MTU to the maximum value allowed by the hardware, obey the value known by the operating system. Signed-off-by:
-
Vladimir Oltean authored
On this switch, the frame length enforcements are performed by the ingress policers. There are 2 types of those: regular L2 (also called best-effort) and Virtual Link policers (an ARINC664/AFDX concept for defining L2 streams with certain QoS abilities). To avoid future confusion, I prefer to call the reset reason "Best-effort policers", even though the VL policers are not yet supported. We also need to change the setup of the initial static config, such that DSA calls to .change_mtu (which are expensive) become no-ops and don't reset the switch 5 times. A driver-level decision is to unconditionally allow single VLAN-tagged traffic on all ports. The CPU port must accept an additional VLAN header for the DSA tag, which is again a driver-level decision. The policers actually count bytes not only from the SDU, but also from the Ethernet header and FCS, so those need to be accounted for as well. Signed-off-by:
-
Murali Krishna Policharla authored
It looks like the Broadcom switches supported by the b53 driver don't support precise configuration of the MTU, but just a mumbo-jumbo boolean flag. Set that. Also configure BCM583XX devices to send and receive jumbo frames when ports are configured with 10/100 Mbps speed. Signed-off-by:
Murali Krishna Policharla <murali.policharla@broadcom.com> Signed-off-by:
-
Vladimir Oltean authored
Many switches don't have an explicit knob for configuring the MTU (maximum transmission unit per interface). Instead, they do the length-based packet admission checks on the ingress interface, for reasons that are easy to understand (why would you accept a packet in the queuing subsystem if you know you're going to drop it anyway). So it is actually the MRU that these switches permit configuring. In Linux there only exists the IFLA_MTU netlink attribute and the associated dev_set_mtu function. The comments like to play blind and say that it's changing the "maximum transfer unit", which is to say that there isn't any directionality in the meaning of the MTU word. So that is the interpretation that this patch is giving to things: MTU == MRU. When 2 interfaces having different MTUs are bridged, the bridge driver MTU auto-adjustment logic kicks in: what br_mtu_auto_adjust() does is it adjusts the MTU of the bridge net device itself (and not that of the slave net devices) to the minimum value of all slave interfaces, in order for forwarded packets to not exceed the MTU regardless of the interface they are received and send on. The idea behind this behavior, and why the slave MTUs are not adjusted, is that normal termination from Linux over the L2 forwarding domain should happen over the bridge net device, which _is_ properly limited by the minimum MTU. And termination over individual slave devices is possible even if those are bridged. But that is not "forwarding", so there's no reason to do normalization there, since only a single interface sees that packet. The problem with those switches that can only control the MRU is with the offloaded data path, where a packet received on an interface with MRU 9000 would still be forwarded to an interface with MRU 1500. And the br_mtu_auto_adjust() function does not really help, since the MTU configured on the bridge net device is ignored. In order to enforce the de-facto MTU == MRU rule for these switches, we need to do MTU normalization, which means: in order for no packet larger than the MTU configured on this port to be sent, then we need to limit the MRU on all ports that this packet could possibly come from. AKA since we are configuring the MRU via MTU, it means that all ports within a bridge forwarding domain should have the same MTU. And that is exactly what this patch is trying to do. >From an implementation perspective, we try to follow the intent of the user, otherwise there is a risk that we might livelock them (they try to change the MTU on an already-bridged interface, but we just keep changing it back in an attempt to keep the MTU normalized). So the MTU that the bridge is normalized to is either: - The most recently changed one: ip link set dev swp0 master br0 ip link set dev swp1 master br0 ip link set dev swp0 mtu 1400 This sequence will make swp1 inherit MTU 1400 from swp0. - The one of the most recently added interface to the bridge: ip link set dev swp0 master br0 ip link set dev swp1 mtu 1400 ip link set dev swp1 master br0 The above sequence will make swp0 inherit MTU 1400 as well. Suggested-by:
-
Vladimir Oltean authored
It is useful be able to configure port policers on a switch to accept frames of various sizes: - Increase the MTU for better throughput from the default of 1500 if it is known that there is no 10/100 Mbps device in the network. - Decrease the MTU to limit the latency of high-priority frames under congestion, or work around various network segments that add extra headers to packets which can't be fragmented. For DSA slave ports, this is mostly a pass-through callback, called through the regular ndo ops and at probe time (to ensure consistency across all supported switches). The CPU port is called with an MTU equal to the largest configured MTU of the slave ports. The assumption is that the user might want to sustain a bidirectional conversation with a partner over any switch port. The DSA master is configured the same as the CPU port, plus the tagger overhead. Since the MTU is by definition L2 payload (sans Ethernet header), it is up to each individual driver to figure out if it needs to do anything special for its frame tags on the CPU port (it shouldn't except in special cases). So the MTU does not contain the tagger overhead on the CPU port. However the MTU of the DSA master, minus the tagger overhead, is used as a proxy for the MTU of the CPU port, which does not have a net device. This is to avoid uselessly calling the .change_mtu function on the CPU port when nothing should change. So it is safe to assume that the DSA master and the CPU port MTUs are apart by exactly the tagger's overhead in bytes. Some changes were made around dsa_master_set_mtu(), function which was now removed, for 2 reasons: - dev_set_mtu() already calls dev_validate_mtu(), so it's redundant to do the same thing in DSA - __dev_set_mtu() returns 0 if ops->ndo_change_mtu is an absent method That is to say, there's no need for this function in DSA, we can safely call dev_set_mtu() directly, take the rtnl lock when necessary, and just propagate whatever errors get reported (since the user probably wants to be informed). Some inspiration (mainly in the MTU DSA notifier) was taken from a vaguely similar patch from Murali and Florian, who are credited as co-developers down below. Co-developed-by: -
Murali Krishna Policharla authored
Change DMA descriptor length to handle jumbo frames beyond 8192 bytes. Also update jumbo frame max size to include FCS, the DMA packet length received includes FCS. Signed-off-by:
Arun Parameswaran <arun.parameswaran@broadcom.com> Reviewed-by:
Ray Jui <ray.jui@broadcom.com> Signed-off-by:
-
Murali Krishna Policharla authored
The BCM7XX PHY family requires special configuration to pass jumbo frames. Do that during initial PHY setup. Signed-off-by:
Scott Branden <scott.branden@broadcom.com> Signed-off-by:
-
Heiner Kallweit authored
On Android/x86 the module loading infrastructure can't deal with softdeps. Therefore the check for presence of the Realtek PHY driver module fails. mdiobus_register() will try to load the PHY driver module, therefore move the check to after this call and explicitly check that a dedicated PHY driver is bound to the PHY device. Fixes: f3259377 ("r8169: check that Realtek PHY driver module is loaded") Reported-by:
Chih-Wei Huang <cwhuang@android-x86.org> Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
David S. Miller authored
Merge tag 'wireless-drivers-next-2020-03-27' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for v5.7 Third set of patches for v5.7. Nothing really special this time, business as usual. When pulling this to net-next there's again a conflict in: drivers/net/wireless/intel/iwlwifi/pcie/drv.c To solve this drop these three lines from the conflict (the first hunk from "HEAD") as the whole AX200 block was moved above in the same file: IWL_DEV_INFO(0x2723, 0x1653, iwl_ax200_cfg_cc, iwl_ax200_killer_1650w_name), IWL_DEV_INFO(0x2723, 0x1654, iwl_ax200_cfg_cc, iwl_ax200_killer_1650x_name), IWL_DEV_INFO(0x2723, IWL_CFG_ANY, iwl_ax200_cfg_cc, iwl_ax200_name), And keep all the __IWL_DEV_INFO() entries (the second hunk). In other words, take everything from wireless-drivers-next. When running 'git diff' after the resolution the output should be empty. Major changes: brcmfmac * add USB autosuspend support ath11k * handle RX fragments * enable PN offload * add support for HE BSS color iwlwifi * support new FW API version * support for EDCA measurements * new scan API features * enable new firmware debugging code ==================== Kalle gave me directions on how to resolve the iwlwifi conflict as follows: ==================== When pulling this to net-next there's again a conflict in: drivers/net/wireless/intel/iwlwifi/pcie/drv.c To solve this drop these three lines from the conflict (the first hunk from "HEAD") as the whole AX200 block was moved above in the same file: IWL_DEV_INFO(0x2723, 0x1653, iwl_ax200_cfg_cc, iwl_ax200_killer_1650w_name), IWL_DEV_INFO(0x2723, 0x1654, iwl_ax200_cfg_cc, iwl_ax200_killer_1650x_name), IWL_DEV_INFO(0x2723, IWL_CFG_ANY, iwl_ax200_cfg_cc, iwl_ax200_name), And keep all the __IWL_DEV_INFO() entries (the second hunk). In other words, take everything from wireless-drivers-next. When running 'git diff' after the resolution the output should be empty. ==================== Signed-off-by:
-
David S. Miller authored
Julian Wiedmann says: ==================== s390/qeth: updates 2020-03-27 please apply the following patch series for qeth to netdev's net-next tree. Spring clean edition: - remove one sysfs attribute that was never put in use, - make support for OSN and OSX devices optional, and - probe for removal of the obsolete OSN support. ==================== Signed-off-by: -
Julian Wiedmann authored
OSN devices currently spend an awful long time in qeth_l2_set_online() until various unsupported HW cmds time out. This has been broken for over two years, ever since commit d22ffb5a ("s390/qeth: fix IPA command submission race") triggered a FW bug in cmd processing. Prior to commit 782e4a79 ("s390/qeth: don't poll for cmd IO completion"), this wait for timeout would have even been spent busy-polling. The offending patch was picked up by stable and all relevant distros, and yet noone noticed. OSN setups only ever worked in combination with an out-of-tree blob, and the last machine that even offered HW with OSN support was released back in 2015. Rather than attempting to work-around this FW issue for no actual gain, add a deprecation warning so anyone who still wants to maintain this part of the code can speak up. Else rip it all out in 2021. Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by:
-
Julian Wiedmann authored
The last machine generation that supports OSN is z13, and OSX is only supported up to z14. Allow users and distros to decide whether they still need support for these device types. Signed-off-by:
-
Julian Wiedmann authored
Ever since commit 4a71df50 ("qeth: new qeth device driver") introduced this attribute, it can be read & written but has no actual effect. Signed-off-by:
-
David S. Miller authored
Vasundhara Volam says: ==================== bnxt_en: Updates to devlink info_get cb This series adds support for a generic macro to devlink info_get cb. Adds support for fw.mgmt.api and board.id info to bnxt_en driver info_get cb. Also, updates the devlink-info.rst and bnxt.rst documentation accordingly. This series adds a patch to fix few macro names that maps to bnxt_en firmware versions. v1->v2: Remove ECN dev param, base_mh_addr and serial number info support in this series. Rename drv.spec macro to fw.api. --- v2->v3: Remove hw.addr info as it is per netdev but not per device info. --- v3->v4: Rename "fw.api" to "fw.mgmt.api". Also, add a patch that modifies few macro names in info_get command, to match the devlink documentation. ==================== Signed-off-by: -
Vasundhara Volam authored
Fix macro names to report fw.mgmt and fw.ncsi versions to match the devlink documentation. Example display after fixes: $ devlink dev info pci/0000:af:00.0 pci/0000:af:00.0: driver bnxt_en serial_number B0-26-28-FF-FE-25-84-20 versions: fixed: board.id BCM957454A4540 asic.id C454 asic.rev 1 running: fw 216.1.154.0 fw.psid 0.0.0 fw.mgmt 216.1.146.0 fw.mgmt.api 1.10.1 fw.ncsi 864.0.44.0 fw.roce 216.1.16.0 Fixes: 9599e036 ("bnxt_en: Add support for devlink info command") Signed-off-by:Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Vasundhara Volam authored
Add part number info from the vital product data to info_get command via devlink tool. Update bnxt.rst documentation as well. Cc: Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Vasundhara Volam authored
Store the part number and serial number information from VPD in the bnxt structure. Follow up patch will add the support to display the information via devlink command. Signed-off-by:
-
Vasundhara Volam authored
This patch adds a new macro for serial number keyword. Acked-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Vasundhara Volam authored
Display the minimum version of firmware interface spec supported between driver and firmware. Also update bnxt.rst documentation file. Signed-off-by:
-
Vasundhara Volam authored
Add definition and documentation for the new generic info "fw.mgmt.api". This macro specifies the version of the software interfaces between driver and firmware. Cc: Jakub Kicinski <kuba@kernel.org> Cc: Jacob Keller <jacob.e.keller@intel.com> Cc: Jiri Pirko <jiri@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Various static checkers fixes Jakub told me he gets some warnings with W=1, so I decided to check with sparse, smatch and coccinelle as well. This patch set fixes all the issues found. None are actual bugs / regressions and therefore not targeted at net. Patches #1-#2 add missing kernel-doc comments. Patch #3 removes dead code. Patch #4 reworks the ACL code to avoid defining a static variable in a header file. Patch #5 removes unnecessary conversion to bool that coccinelle warns about. Patch #6 avoids false-positive uninitialized symbol errors emitted by smatch. ==================== Signed-off-by: -
Ido Schimmel authored
Suppress the following smatch errors. None of these are actually possible with current code paths. drivers/net/ethernet/mellanox/mlxsw//spectrum_router.c:1220 mlxsw_sp_ipip_entry_find_decap() error: uninitialized symbol 'saddrp'. drivers/net/ethernet/mellanox/mlxsw//spectrum_router.c:1220 mlxsw_sp_ipip_entry_find_decap() error: uninitialized symbol 'saddr_len'. drivers/net/ethernet/mellanox/mlxsw//spectrum_router.c:1221 mlxsw_sp_ipip_entry_find_decap() error: uninitialized symbol 'saddr_prefix_len'. drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:1390 mlxsw_sp_netdevice_ipip_ol_reg_event() error: uninitialized symbol 'ipipt'. drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:3255 mlxsw_sp_nexthop_group_update() error: uninitialized symbol 'err'. Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Reviewed-by:
-
