- 15 1月, 2020 16 次提交
-
-
由 Ido Schimmel 提交于
In commit a72afb68 ("mlxsw: Enforce firmware version for Spectrum-2") I added a required firmware version for Spectrum-2, but missed the fact that mlxsw_sp2_init() is used by both Spectrum-2 and Spectrum-3. This means that the same firmware version will be used for both, which is wrong. Fix this by creating a new init() callback for Spectrum-3. Fixes: a72afb68 ("mlxsw: Enforce firmware version for Spectrum-2") Signed-off-by: NIdo Schimmel <idosch@mellanox.com> Acked-by: NJiri Pirko <jiri@mellanox.com> Tested-by: NShalom Toledo <shalomt@mellanox.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
Merge tag 'mac80211-for-net-2020-01-15' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 Johannes Berg says: ==================== A few fixes: * -O3 enablement fallout, thanks to Arnd who ran this * fixes for a few leaks, thanks to Felix * channel 12 regulatory fix for custom regdomains * check for a crash reported by syzbot (NULL function is called on drivers that don't have it) * fix TKIP replay protection after setup with some APs (from Jouni) * restrict obtaining some mesh data to avoid WARN_ONs * fix deadlocks with auto-disconnect (socket owner) * fix radar detection events with multiple devices ==================== Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Felix Fietkau 提交于
The fragments attached to a skb can be part of a compound page. In that case, page_ref_inc will increment the refcount for the wrong page. Fix this by using get_page instead, which calls page_ref_inc on the compound head and also checks for overflow. Fixes: 2b67f944 ("cfg80211: reuse existing page fragments in A-MSDU rx") Cc: stable@vger.kernel.org Signed-off-by: NFelix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20200113182107.20461-1-nbd@nbd.nameSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Check if set_wiphy_params is assigned and return an error if not, some drivers (e.g. virt_wifi where syzbot reported it) don't have it. Reported-by: syzbot+e8a797964a4180eb57d5@syzkaller.appspotmail.com Reported-by: syzbot+34b582cf32c1db008f8e@syzkaller.appspotmail.com Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Link: https://lore.kernel.org/r/20200113125358.ac07f276efff.Ibd85ee1b12e47b9efb00a2adc5cd3fac50da791a@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Felix Fietkau 提交于
The per-tid statistics need to be released after the call to rdev_get_station Cc: stable@vger.kernel.org Fixes: 8689c051 ("cfg80211: dynamically allocate per-tid stats for station info") Signed-off-by: NFelix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20200108170630.33680-2-nbd@nbd.nameSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Felix Fietkau 提交于
The per-tid statistics need to be released after the call to rdev_get_station Cc: stable@vger.kernel.org Fixes: 5ab92e7f ("cfg80211: add support to probe unexercised mesh link") Signed-off-by: NFelix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20200108170630.33680-1-nbd@nbd.nameSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Markus Theil 提交于
Use methods which do not try to acquire the wdev lock themselves. Cc: stable@vger.kernel.org Fixes: 37b1c004 ("cfg80211: Support all iftypes in autodisconnect_wk") Signed-off-by: NMarkus Theil <markus.theil@tu-ilmenau.de> Link: https://lore.kernel.org/r/20200108115536.2262-1-markus.theil@tu-ilmenau.deSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Arnd Bergmann 提交于
After the introduction of CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3, the wext code produces a bogus warning: In function 'iw_handler_get_iwstats', inlined from 'ioctl_standard_call' at net/wireless/wext-core.c:1015:9, inlined from 'wireless_process_ioctl' at net/wireless/wext-core.c:935:10, inlined from 'wext_ioctl_dispatch.part.8' at net/wireless/wext-core.c:986:8, inlined from 'wext_handle_ioctl': net/wireless/wext-core.c:671:3: error: argument 1 null where non-null expected [-Werror=nonnull] memcpy(extra, stats, sizeof(struct iw_statistics)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from arch/x86/include/asm/string.h:5, net/wireless/wext-core.c: In function 'wext_handle_ioctl': arch/x86/include/asm/string_64.h:14:14: note: in a call to function 'memcpy' declared here The problem is that ioctl_standard_call() sometimes calls the handler with a NULL argument that would cause a problem for iw_handler_get_iwstats. However, iw_handler_get_iwstats never actually gets called that way. Marking that function as noinline avoids the warning and leads to slightly smaller object code as well. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20200107200741.3588770-1-arnd@arndb.deSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Jouni Malinen 提交于
TKIP replay protection was skipped for the very first frame received after a new key is configured. While this is potentially needed to avoid dropping a frame in some cases, this does leave a window for replay attacks with group-addressed frames at the station side. Any earlier frame sent by the AP using the same key would be accepted as a valid frame and the internal RSC would then be updated to the TSC from that frame. This would allow multiple previously transmitted group-addressed frames to be replayed until the next valid new group-addressed frame from the AP is received by the station. Fix this by limiting the no-replay-protection exception to apply only for the case where TSC=0, i.e., when this is for the very first frame protected using the new key, and the local RSC had not been set to a higher value when configuring the key (which may happen with GTK). Signed-off-by: NJouni Malinen <j@w1.fi> Link: https://lore.kernel.org/r/20200107153545.10934-1-j@w1.fiSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Orr Mazor 提交于
In case a radar event of CAC_FINISHED or RADAR_DETECTED happens during another phy is during CAC we might need to cancel that CAC. If we got a radar in a channel that another phy is now doing CAC on then the CAC should be canceled there. If, for example, 2 phys doing CAC on the same channels, or on comptable channels, once on of them will finish his CAC the other might need to cancel his CAC, since it is no longer relevant. To fix that the commit adds an callback and implement it in mac80211 to end CAC. This commit also adds a call to said callback if after a radar event we see the CAC is no longer relevant Signed-off-by: NOrr Mazor <Orr.Mazor@tandemg.com> Reviewed-by: NSergey Matyukevich <sergey.matyukevich.os@quantenna.com> Link: https://lore.kernel.org/r/20191222145449.15792-1-Orr.Mazor@tandemg.com [slightly reformat/reword commit message] Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Ganapathi Bhat 提交于
Commit e33e2241 ("Revert "cfg80211: Use 5MHz bandwidth by default when checking usable channels"") fixed a broken regulatory (leaving channel 12 open for AP where not permitted). Apply a similar fix to custom regulatory domain processing. Signed-off-by: NCathy Luo <xiaohua.luo@nxp.com> Signed-off-by: NGanapathi Bhat <ganapathi.bhat@nxp.com> Link: https://lore.kernel.org/r/1576836859-8945-1-git-send-email-ganapathi.bhat@nxp.com [reword commit message, fix coding style, add a comment] Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Lorenzo Bianconi 提交于
Page pool API will start syncing (if requested) starting from page->dma_addr + pool->p.offset. Fix dma sync length in mvneta_run_xdp since we do not need to account xdp headroom Fixes: 07e13edb ("net: mvneta: get rid of huge dma sync in mvneta_rx_refill") Signed-off-by: NLorenzo Bianconi <lorenzo@kernel.org> Acked-by: NJesper Dangaard Brouer <brouer@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Johan Hovold 提交于
Add missing endpoint sanity check to probe in order to prevent a NULL-pointer dereference (or slab out-of-bounds access) when retrieving the interrupt-endpoint bInterval on ndo_open() in case a device lacks the expected endpoints. Fixes: 40a82917 ("net/usb/r8152: enable interrupt transfer") Cc: hayeswang <hayeswang@realtek.com> Signed-off-by: NJohan Hovold <johan@kernel.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Sunil Muthuswamy 提交于
Currently, hv_sock restricts the port the guest socket can accept connections on. hv_sock divides the socket port namespace into two parts for server side (listening socket), 0-0x7FFFFFFF & 0x80000000-0xFFFFFFFF (there are no restrictions on client port namespace). The first part (0-0x7FFFFFFF) is reserved for sockets where connections can be accepted. The second part (0x80000000-0xFFFFFFFF) is reserved for allocating ports for the peer (host) socket, once a connection is accepted. This reservation of the port namespace is specific to hv_sock and not known by the generic vsock library (ex: af_vsock). This is problematic because auto-binds/ephemeral ports are handled by the generic vsock library and it has no knowledge of this port reservation and could allocate a port that is not compatible with hv_sock (and legitimately so). The issue hasn't surfaced so far because the auto-bind code of vsock (__vsock_bind_stream) prior to the change 'VSOCK: bind to random port for VMADDR_PORT_ANY' would start walking up from LAST_RESERVED_PORT (1023) and start assigning ports. That will take a large number of iterations to hit 0x7FFFFFFF. But, after the above change to randomize port selection, the issue has started coming up more frequently. There has really been no good reason to have this port reservation logic in hv_sock from the get go. Reserving a local port for peer ports is not how things are handled generally. Peer ports should reflect the peer port. This fixes the issue by lifting the port reservation, and also returns the right peer port. Since the code converts the GUID to the peer port (by using the first 4 bytes), there is a possibility of conflicts, but that seems like a reasonable risk to take, given this is limited to vsock and that only applies to all local sockets. Signed-off-by: NSunil Muthuswamy <sunilmut@microsoft.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Eric Dumazet 提交于
lan78xx_tx_bh() makes sure to not exceed MAX_SINGLE_PACKET_SIZE bytes in the aggregated packets it builds, but does nothing to prevent large GSO packets being submitted. Pierre-Francois reported various hangs when/if TSO is enabled. For localy generated packets, we can use netif_set_gso_max_size() to limit the size of TSO packets. Note that forwarded packets could still hit the issue, so a complete fix might require implementing .ndo_features_check for this driver, forcing a software segmentation if the size of the TSO packet exceeds MAX_SINGLE_PACKET_SIZE. Fixes: 55d7de9d ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Signed-off-by: NEric Dumazet <edumazet@google.com> Reported-by: NRENARD Pierre-Francois <pfrenard@gmail.com> Tested-by: NRENARD Pierre-Francois <pfrenard@gmail.com> Cc: Stefan Wahren <stefan.wahren@i2se.com> Cc: Woojung Huh <woojung.huh@microchip.com> Cc: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Vladis Dronov 提交于
There is a bug in ptp_clock_unregister(), where ptp_cleanup_pin_groups() first frees ptp->pin_{,dev_}attr, but then posix_clock_unregister() needs them to destroy a related sysfs device. These functions can not be just swapped, as posix_clock_unregister() frees ptp which is needed in the ptp_cleanup_pin_groups(). Fix this by calling ptp_cleanup_pin_groups() in ptp_clock_release(), right before ptp is freed. This makes this patch fix an UAF bug in a patch which fixes an UAF bug. Reported-by: NAntti Laakso <antti.laakso@intel.com> Fixes: a33121e5 ("ptp: fix the race between the release of ptp_clock and cdev") Link: https://lore.kernel.org/netdev/3d2bd09735dbdaf003585ca376b7c1e5b69a19bd.camel@intel.com/Signed-off-by: NVladis Dronov <vdronov@redhat.com> Acked-by: NRichard Cochran <richardcochran@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 14 1月, 2020 3 次提交
-
-
由 Johan Hovold 提交于
The driver was doing a synchronous uninterruptible bulk-transfer without using a timeout. This could lead to the driver hanging on probe due to a malfunctioning (or malicious) device until the device is physically disconnected. While sleeping in probe the driver prevents other devices connected to the same hub from being added to (or removed from) the bus. An arbitrary limit of five seconds should be more than enough. Fixes: dbafc289 ("NFC: pn533: don't send USB data off of the stack") Signed-off-by: NJohan Hovold <johan@kernel.org> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Kristian Evensen 提交于
RM500Q is a 5G module from Quectel, supporting both standalone and non-standalone modes. The normal Quectel quirks apply (DTR and dynamic interface numbers). Signed-off-by: NKristian Evensen <kristian.evensen@gmail.com> Acked-by: NBjørn Mork <bjorn@mork.no> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Milind Parab 提交于
This patch fix the issue with fixed link. With fixed-link device opening fails due to macb_phylink_connect not handling fixed-link mode, in which case no MAC-PHY connection is needed and phylink_connect return success (0), however in current driver attempt is made to search and connect to PHY even for fixed-link. Fixes: 7897b071 ("net: macb: convert to phylink") Signed-off-by: NMilind Parab <mparab@cadence.com> Reviewed-by: NClaudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 12 1月, 2020 3 次提交
-
-
由 Jakub Kicinski 提交于
My Netronome email address may become inactive soon. Signed-off-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jacob Keller 提交于
A couple of locations accidentally misspelled snapshot as shapshot. Signed-off-by: NJacob Keller <jacob.e.keller@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jacob Keller 提交于
The function to obtain a unique snapshot id was mistakenly typo'd as devlink_region_shapshot_id_get. Fix this typo by renaming the function and all of its users. Signed-off-by: NJacob Keller <jacob.e.keller@intel.com> Acked-by: NJiri Pirko <jiri@mellanox.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 11 1月, 2020 10 次提交
-
-
由 David S. Miller 提交于
Dan Murphy says: ==================== DP83822 and DP83TC811 Fixes Two fixes on net/phy/Kconfig for the TI ethernet PHYs. First fixed the typo in the Kconfig for the DP83TC811 where it incorretly stated that the support was for a DP83TC822 which does not exist. Second fix was to update the DP83822 Kconfig entry to indicate support for the DP83825 devices in the description and the prompt. ==================== Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dan Murphy 提交于
Update the Kconfig description to indicate support for the DP83825I device as well. Fixes: 32b12dc8fde1 ("net: phy: Add DP83825I to the DP83822 driver") Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDan Murphy <dmurphy@ti.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dan Murphy 提交于
Fix typo in the Kconfig for the DP83TC811 as it indicates support for the DP83TC822 which is incorrect. Fixes: 6d749428788b {"net: phy: DP83TC811: Introduce support for the DP83TC811 phy") Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDan Murphy <dmurphy@ti.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ido Schimmel 提交于
The commit cited below causes devlink to emit a warning if a type was not set on a devlink port for longer than 30 seconds to "prevent misbehavior of drivers". This proved to be problematic when unregistering the backing netdev. The flow is always: devlink_port_type_clear() // schedules the warning unregister_netdev() // blocking devlink_port_unregister() // cancels the warning The call to unregister_netdev() can block for long periods of time for various reasons: RTNL lock is contended, large amounts of configuration to unroll following dismantle of the netdev, etc. This results in devlink emitting a warning despite the driver behaving correctly. In emulated environments (of future hardware) which are usually very slow, the warning can also be emitted during port creation as more than 30 seconds can pass between the time the devlink port is registered and when its type is set. In addition, syzbot has hit this warning [1] 1974 times since 07/11/19 without being able to produce a reproducer. Probably because reproduction depends on the load or other bugs (e.g., RTNL not being released). To prevent bogus warnings, increase the timeout to 1 hour. [1] https://syzkaller.appspot.com/bug?id=e99b59e9c024a666c9f7450dc162a4b74d09d9cb Fixes: 136bf27f ("devlink: add warning in case driver does not set port type") Signed-off-by: NIdo Schimmel <idosch@mellanox.com> Reported-by: syzbot+b0a18ed7b08b735d2f41@syzkaller.appspotmail.com Reported-by: NAlex Veber <alexve@mellanox.com> Tested-by: NAlex Veber <alexve@mellanox.com> Acked-by: NJiri Pirko <jiri@mellanox.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David Ahern 提交于
Sven-Haegar reported looping on fib dumps when 255.255.255.255 route has been added to a table. The looping is caused by the key rolling over from FFFFFFFF to 0. When dumping a specific table only, we need a means to detect when the table dump is done. The key and count saved to cb args are both 0 only at the start of the table dump. If key is 0 and count > 0, then we are in the rollover case. Detect and return to avoid looping. This only affects dumps of a specific table; for dumps of all tables (the case prior to the change in the Fixes tag) inet_dump_fib moved the entry counter to the next table and reset the cb args used by fib_table_dump and fn_trie_dump_leaf, so the rollover ffffffff back to 0 did not cause looping with the dumps. Fixes: effe6792 ("net: Enable kernel side filtering of route dumps") Reported-by: NSven-Haegar Koch <haegar@sdinet.de> Signed-off-by: NDavid Ahern <dsahern@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
Jose Abreu says: ==================== net: stmmac: Filtering fixes Two single fixes for the L3 and L4 filtering in stmmac. 1) Updates the internal status of RSS when disabling it in order to keep internal driver status consistent. 2) Do not lets user add a filter if RSS is enabled because the filter will not work correctly as RSS bypasses this mechanism. ==================== Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jose Abreu 提交于
RSS, when enabled, will bypass the L3 and L4 filtering causing it not to work. Add a check before trying to setup the filters. Fixes: 425eabdd ("net: stmmac: Implement L3/L4 Filters using TC Flower") Signed-off-by: NJose Abreu <Jose.Abreu@synopsys.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jose Abreu 提交于
We are disabling RSS on HW but not updating the internal private status to the 'disabled' state. This is needed for next tc commit that will check if RSS is disabled before trying to apply filters. Fixes: 4647e021 ("net: stmmac: selftests: Add selftest for L3/L4 Filters") Signed-off-by: NJose Abreu <Jose.Abreu@synopsys.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jakub Kicinski 提交于
Mallesham reports the TLS with async accelerator was broken by commit d10523d0 ("net/tls: free the record on encryption error") because encryption can return -EINPROGRESS in such setups, which should not be treated as an error. The error is also present in the BPF path (likely copied from there). Reported-by: NMallesham Jatharakonda <mallesham.jatharakonda@oneconvergence.com> Fixes: d3b18ad3 ("tls: add bpf support to sk_msg handling") Fixes: d10523d0 ("net/tls: free the record on encryption error") Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: NSimon Horman <simon.horman@netronome.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jakub Kicinski 提交于
When device loses sync mid way through a record - kernel has to re-encrypt the part of the record which the device already decrypted to be able to decrypt and authenticate the record in its entirety. The re-encryption piggy backs on the decryption routine, but obviously because the partially decrypted record can't be authenticated crypto API returns an error which is then ignored by tls_device_reencrypt(). Commit 5c5ec668 ("net/tls: add TlsDecryptError stat") added a statistic to count decryption errors, this statistic can't be incremented when we see the expected re-encryption error. Move the inc to the caller. Reported-and-tested-by: NDavid Beckett <david.beckett@netronome.com> Fixes: 5c5ec668 ("net/tls: add TlsDecryptError stat") Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: NSimon Horman <simon.horman@netronome.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 10 1月, 2020 8 次提交
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue由 David S. Miller 提交于
Jeff Kirsher says: ==================== Intel Wired LAN Driver Updates 2020-01-09 This series contains fixes to e1000e, igb, ixgbe, ixgbevf, i40e and iavf drivers. Brett fixes the validation of the virtchnl queue select bitmaps by comparing the bitmaps against BIT(I40E_MAX_VF_QUEUES). Radoslaw removes the limitation of only 10 filter entries for a VF and allows use of all free RAR entries for the forwarding database, if needed. Cambda Zhu fixes the calculation of queue when restoring flow director filters after resetting the adapter for ixgbe. Manfred Rudigier fixes the SGMIISFP module discovery for 100FX/LX modules for igb. Stefan Assmann fixes iavf where during a VF reset event, MAC filters were not altered, which could lead to a stale filter when an administratively set MAC address is forced by the PF. Adam adds the missing code to set the PHY access flag on X722 devices, which supports accessing PHY registers with the admin queue command. Revert a previous commit for e1000e to use "delayed work" which was causing connections to reset unexpectedly and possible driver crashes. ==================== Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Martin Schiller 提交于
This patch fixes 2 issues in x25_connect(): 1. It makes absolutely no sense to reset the neighbour and the connection state after a (successful) nonblocking call of x25_connect. This prevents any connection from being established, since the response (call accept) cannot be processed. 2. Any further calls to x25_connect() while a call is pending should simply return, instead of creating new Call Request (on different logical channels). This patch should also fix the "KASAN: null-ptr-deref Write in x25_connect" and "BUG: unable to handle kernel NULL pointer dereference in x25_connect" bugs reported by syzbot. Signed-off-by: NMartin Schiller <ms@dev.tdt.de> Reported-by: syzbot+429c200ffc8772bfe070@syzkaller.appspotmail.com Reported-by: syzbot+eec0c87f31a7c3b66f7b@syzkaller.appspotmail.com Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Sergei Shtylyov 提交于
When adding the sh_eth_cpu_data::dual_port flag I forgot to add the flag checks to __sh_eth_get_regs(), causing the non-existing TSU registers to be dumped by 'ethtool' on the single port Ether controllers having TSU... Fixes: a94cf2a6 ("sh_eth: fix TSU init on SH7734/R8A7740") Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid由 Linus Torvalds 提交于
Pull HID fixes from Jiri Kosina: - fix for OOB in hiddev, from Dmitry Torokhov - _poll API fixes for hidraw, from Marcel Holtmann - functional fix for Steam driver, from Rodrigo Rivas Costa - a few new device IDs / device-specific quirks and other assorted smaller fixes * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: HID: steam: Fix input device disappearing HID: intel-ish-hid: ipc: Add Tiger Lake PCI device ID drivers/hid/hid-multitouch.c: fix a possible null pointer access. HID: wacom: Recognize new MobileStudio Pro PID HID: intel-ish-hid: ipc: add CMP device id HID: hiddev: fix mess in hiddev_open() HID: hid-input: clear unmapped usages HID: Add quirk for incorrect input length on Lenovo Y720 HID: asus: Ignore Asus vendor-page usage-code 0xff events HID: ite: Add USB id match for Acer SW5-012 keyboard dock HID: Add quirk for Xin-Mo Dual Controller HID: Fix slab-out-of-bounds read in hid_field_extract HID: multitouch: Add LG MELF0410 I2C touchscreen support HID: uhid: Fix returning EPOLLOUT from uhid_char_poll HID: hidraw: Fix returning EPOLLOUT from hidraw_poll
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net由 Linus Torvalds 提交于
Pull networking fixes from David Miller: 1) Missing netns pointer init in arp_tables, from Florian Westphal. 2) Fix normal tcp SACK being treated as D-SACK, from Pengcheng Yang. 3) Fix divide by zero in sch_cake, from Wen Yang. 4) Len passed to skb_put_padto() is wrong in qrtr code, from Carl Huang. 5) cmd->obj.chunk is leaked in sctp code error paths, from Xin Long. 6) cgroup bpf programs can be released out of order, fix from Roman Gushchin. 7) Make sure stmmac debugfs entry name is changed when device name changes, from Jiping Ma. 8) Fix memory leak in vlan_dev_set_egress_priority(), from Eric Dumazet. 9) SKB leak in lan78xx usb driver, also from Eric Dumazet. 10) Ridiculous TCA_FQ_QUANTUM values configured can cause loops in fq packet scheduler, reject them. From Eric Dumazet. * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (69 commits) tipc: fix wrong connect() return code tipc: fix link overflow issue at socket shutdown netfilter: ipset: avoid null deref when IPSET_ATTR_LINENO is present netfilter: conntrack: dccp, sctp: handle null timeout argument atm: eni: fix uninitialized variable warning macvlan: do not assume mac_header is set in macvlan_broadcast() net: sch_prio: When ungrafting, replace with FIFO mlxsw: spectrum_qdisc: Ignore grafting of invisible FIFO MAINTAINERS: Remove myself as co-maintainer for qcom-ethqos gtp: fix bad unlock balance in gtp_encap_enable_socket pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM tipc: remove meaningless assignment in Makefile tipc: do not add socket.o to tipc-y twice net: stmmac: dwmac-sun8i: Allow all RGMII modes net: stmmac: dwmac-sunxi: Allow all RGMII modes net: usb: lan78xx: fix possible skb leak net: stmmac: Fixed link does not need MDIO Bus vlan: vlan_changelink() should propagate errors vlan: fix memory leak in vlan_dev_set_egress_priority stmmac: debugfs entry name is not be changed when udev rename device name. ...
-
由 Jeff Kirsher 提交于
This reverts commit 59653e64. This is due to this commit causing driver crashes and connections to reset unexpectedly. Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com>
-
由 Adam Ludkiewicz 提交于
The X722 FW API version 1.9 adds support for accessing PHY registers with Admin Queue Command. This enables reading EEPROM data from (Q)SFP+ transceivers, what was previously possible only on X710 devices. Signed-off-by: NAdam Ludkiewicz <adam.ludkiewicz@intel.com> Tested-by: NAndrew Bowers <andrewx.bowers@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Stefan Assmann 提交于
Currently MAC filters are not altered during a VF reset event. This may lead to a stale filter when an administratively set MAC is forced by the PF. For an administratively set MAC the PF driver deletes the VFs filters, overwrites the VFs MAC address and triggers a VF reset. However the VF driver itself is not aware of the filter removal, which is what the VF reset is for. The VF reset queues all filters present in the VF driver to be re-added to the PF filter list (including the filter for the now stale VF MAC address) and triggers a VIRTCHNL_OP_GET_VF_RESOURCES event, which provides the new MAC address to the VF. When this happens i40e will complain and reject the stale MAC filter, at least in the untrusted VF case. i40e 0000:08:00.0: Setting MAC 3c:fa:fa:fa:fa:01 on VF 0 iavf 0000:08:02.0: Reset warning received from the PF iavf 0000:08:02.0: Scheduling reset task i40e 0000:08:00.0: Bring down and up the VF interface to make this change effective. i40e 0000:08:00.0: VF attempting to override administratively set MAC address, bring down and up the VF interface to resume normal operation i40e 0000:08:00.0: VF 0 failed opcode 10, retval: -1 iavf 0000:08:02.0: Failed to add MAC filter, error IAVF_ERR_NVM To avoid re-adding the stale MAC filter it needs to be removed from the VF driver's filter list before queuing the existing filters. Then during the VIRTCHNL_OP_GET_VF_RESOURCES event the correct filter needs to be added again, at which point the MAC address has been updated. As a bonus this change makes bringing the VF down and up again superfluous for the administratively set MAC case. Signed-off-by: NStefan Assmann <sassmann@kpanic.de> Tested-by: NAndrew Bowers <andrewx.bowers@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-