- 10 Jun, 2022 35 commits
-
-
Miquel Raynal authored
We should never start a transmission after the queue has been stopped. But because it might work we don't kill the function here but rather warn loudly the user that something is wrong. Set a flag when the queue should remain stopped. Reset this flag when the queue actually gets restarded. Just check this value to know if a transmission is legitimate, warn if it is not. Turn the flags variable into an unsigned long to allow the use of atomic helpers on it. Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Acked-by:
Alexander Aring <aahringo@redhat.com> Link: https://lore.kernel.org/r/20220519150516.443078-11-miquel.raynal@bootlin.comSigned-off-by:
Stefan Schmidt <stefan@datenfreihafen.org>
-
Miquel Raynal authored
This is the slow path, we need to wait for each command to be processed before continuing so let's introduce an helper which does the transmission and blocks until it gets notified of its asynchronous completion. This helper is going to be used when introducing scan support. Signed-off-by:
-
Miquel Raynal authored
Right now we are able to stop a queue but we have no indication if a transmission is ongoing or not. Thanks to recent additions, we can track the number of ongoing transmissions so we know if the last transmission is over. Adding on top of it an internal wait queue also allows to be woken up asynchronously when this happens. If, beforehands, we marked the queue to be held and stopped it, we end up flushing and stopping the tx queue. Thanks to this feature, we will soon be able to introduce a synchronous transmit API. Signed-off-by:
-
Miquel Raynal authored
Sometimes calling the stop queue helper is not enough because it does not hold any lock. In order to be safe and avoid racy situations when trying to (soon) sync the Tx queue, for instance before sending an MLME frame, let's now introduce an helper which actually hold the necessary locks when doing so. Suggested-by:
Alexander Aring <alex.aring@gmail.com> Signed-off-by:
-
Miquel Raynal authored
Let's rename the current Tx path to show that this is the "hot" Tx path. We will soon introduce a slower Tx path for MLME commands. Signed-off-by:
-
Miquel Raynal authored
Create a hold_txs atomic variable and increment/decrement it when relevant, ie. when we want to hold the queue or release it: currently all the "stopped" situations are suitable, but very soon we will more extensively use this feature for MLME purposes. Upon release, the atomic counter is decremented and checked. If it is back to 0, then the netif queue gets woken up. This makes the whole process fully transparent, provided that all the users of ieee802154_wake/stop_queue() now call ieee802154_hold/release_queue() instead. In no situation individual drivers should call any of these helpers manually in order to avoid messing with the counters. There are other functions more suited for this purpose which have been introduced, such as the _xmit_complete() and _xmit_error() helpers which will handle all that for them. One advantage is that, as no more drivers call the stop/wake helpers directly, we can safely stop exporting them and only declare the hold/release ones in a header only accessible to the core. Signed-off-by:
-
Miquel Raynal authored
In order to create a synchronous API for MLME command purposes, we need to be able to track the end of the ongoing transmissions. Let's introduce an atomic variable which is incremented when a transmission starts and decremented when relevant so that we know at any moment whether there is an ongoing transmission. The counter gets decremented in the following situations: - The operation is asynchronous and there was a failure during the offloading process. - The operation is synchronous and the synchronous operation failed. - The operation finished, either successfully or not. Signed-off-by:
-
Miquel Raynal authored
Before adding more logic in the error path, let's move the wake queue call there, rename the default label and create an additional one. There is no functional change. Signed-off-by:
-
Miquel Raynal authored
This entry is dedicated to synchronous transmissions done by drivers without async hook. Make this clearer that this is not a work that any driver can use by at least prefixing it with "sync_". While at it, let's enhance the comment explaining why we choose one or the other. Signed-off-by:
-
Miquel Raynal authored
There are currently two driver hooks: one is synchronous, the other is not. We cannot rely on driver implementations to provide a synchronous API (which is related to the bus medium more than a wish to have a synchronized implementation) so we are going to introduce a sync API above any kind of driver transmit function. In order to clarify what this worker is for (synchronous driver implementation), let's rename it so that people don't get bothered by the fact that their driver does not make use of the "xmit worker" which is a too generic name. Signed-off-by:
-
Jakub Kicinski authored
Merge tag 'ieee802154-for-net-next-2022-06-09' of git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan-next Stefan Schmidt says: ==================== pull-request: ieee802154-next 2022-06-09 This is a separate pull request for 6lowpan changes. We agreed with the bluetooth maintainers to switch the trees these changing are going into from bluetooth to ieee802154. Jukka Rissanen stepped down as a co-maintainer of 6lowpan (Thanks for the work!). Alexander is staying as maintainer. Alexander reworked the nhc_id lookup in 6lowpan to be way simpler. Moved the data structure from rb to an array, which is all we need in this case. * tag 'ieee802154-for-net-next-2022-06-09' of git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan-next: MAINTAINERS: Remove Jukka Rissanen as 6lowpan maintainer net: 6lowpan: constify lowpan_nhc structures net: 6lowpan: use array for find nhc id net: 6lowpan: remove const from scalars ==================== Link: https://lore.kernel.org/r/20220609202956.1512156-1-stefan@datenfreihafen.orgSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Jonathan Toppins says: ==================== bonding: netlink errors and cleanup The first patch attempts to set helpful error messages when configuring bonds via netlink. The second patch removes redundant init code for RLB mode which is already done in bond_open. ==================== Link: https://lore.kernel.org/r/cover.1654711315.git.jtoppins@redhat.comSigned-off-by:
-
Jonathan Toppins authored
Setting RLB_NULL_INDEX is not needed as this is done in bond_alb_initialize which is called by bond_open. Also reduce the number of rtnl_unlock calls by just using the standard goto cleanup path. Signed-off-by:
Jonathan Toppins <jtoppins@redhat.com> Acked-by:
Jay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by:
-
Jonathan Toppins authored
Add support for reporting errors via extack in both bond_newlink and bond_changelink. Instead of having to look in the kernel log for why an option was not correct just report the error to the user via the extack variable. What is currently reported today: ip link add bond0 type bond ip link set bond0 up ip link set bond0 type bond mode 4 RTNETLINK answers: Device or resource busy After this change: ip link add bond0 type bond ip link set bond0 up ip link set bond0 type bond mode 4 Error: unable to set option because the bond is up. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueJakub Kicinski authored
Tony Nguyen says: ==================== 100GbE Intel Wired LAN Driver Updates 2022-06-08 Michal prevents setting of VF VLAN capabilities in switchdev mode and removes, not needed, specific switchdev VLAN operations. Karol converts u16 variables to unsigned int for GNSS calculations. Christophe Jaillet corrects the parameter order for a couple of devm_kcalloc() calls. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: ice: Use correct order for the parameters of devm_kcalloc() ice: remove u16 arithmetic in ice_gnss ice: remove VLAN representor specific ops ice: don't set VF VLAN caps in switchdev ==================== Link: https://lore.kernel.org/r/20220608160757.2395729-1-anthony.l.nguyen@intel.comSigned-off-by:
-
Jakub Kicinski authored
Eric Dumazet says: ==================== net: few debug refinements Adopt DEBUG_NET_WARN_ON_ONCE() or WARN_ON_ONCE() in some places where it makes sense. Add checks in napi_consume_skb() and __napi_alloc_skb() Make sure napi_get_frags() does not use page fragments for skb->head. ==================== Link: https://lore.kernel.org/r/20220608160438.1342569-1-eric.dumazet@gmail.comSigned-off-by:
-
Eric Dumazet authored
This is a follow up of commit 3226b158 ("net: avoid 32 x truesize under-estimation for tiny skbs") When/if we increase MAX_SKB_FRAGS, we better make sure the old bug will not come back. Adding a check in napi_get_frags() would be costly, even if using DEBUG_NET_WARN_ON_ONCE(). Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Eric Dumazet authored
Commit 6454eca8 ("net: Use lockdep_assert_in_softirq() in napi_consume_skb()") added a check in napi_consume_skb() which is a bit weak. napi_consume_skb() and __napi_alloc_skb() should only be used from BH context, not from hard irq or nmi context, otherwise we could have races. Signed-off-by:
-
Eric Dumazet authored
Remove this check from fast path unless CONFIG_DEBUG_NET=y Signed-off-by:
-
Eric Dumazet authored
Replace four WARN_ON() that have not triggered recently with DEBUG_NET_WARN_ON_ONCE(). Signed-off-by:
-
Eric Dumazet authored
sk_stream_kill_queues() has three checks which have been useful to detect kernel bugs in the past. However they are potentially a problem because they could flood the syslog. Signed-off-by:
-
Eric Dumazet authored
inet_sock_destruct() has four warnings which have been useful to point to kernel bugs in the past. However they are potentially a problem because they could flood the syslog. Signed-off-by:
-
Eric Dumazet authored
One check in dev_loopback_xmit() has not caught issues in the past. Keep it for CONFIG_DEBUG_NET=y builds only. Signed-off-by:
-
Eric Dumazet authored
Check against skb dst in socket backlog has never triggered in past years. Keep the check omly for CONFIG_DEBUG_NET=y builds. Signed-off-by:
-
Jakub Kicinski authored
Eric Dumazet says: ==================== net: adopt u64_stats_t type While KCSAN has not raised any reports yet, we should address the potential load/store tearing problem happening with per cpu stats. This series is not exhaustive, but hopefully a step in the right direction. ==================== Link: https://lore.kernel.org/r/20220608154640.1235958-1-eric.dumazet@gmail.comSigned-off-by:
-
Eric Dumazet authored
As explained in commit 316580b6 ("u64_stats: provide u64_stats_t type") we should use u64_stats_t and related accessors to avoid load/store tearing. Signed-off-by:
-
Eric Dumazet authored
As explained in commit 316580b6 ("u64_stats: provide u64_stats_t type") we should use u64_stats_t and related accessors to avoid load/store tearing. Signed-off-by:
-
Eric Dumazet authored
As explained in commit 316580b6 ("u64_stats: provide u64_stats_t type") we should use u64_stats_t and related accessors to avoid load/store tearing. Signed-off-by:
-
Eric Dumazet authored
As explained in commit 316580b6 ("u64_stats: provide u64_stats_t type") we should use u64_stats_t and related accessors to avoid load/store tearing. Signed-off-by:
-
Eric Dumazet authored
We have a convenient helper, let's use it. This will make the following patch easier to review and smaller. Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
-
Eric Dumazet authored
We have a convenient helper, let's use it. Signed-off-by:
-
Eric Dumazet authored
We have a convenient helper, let's use it. Signed-off-by:
-
Eric Dumazet authored
As explained in commit 316580b6 ("u64_stats: provide u64_stats_t type") we should use u64_stats_t and related accessors to avoid load/store tearing. Add READ_ONCE() when reading rx_errs & tx_drps. Signed-off-by:
-
Eric Dumazet authored
As explained in commit 316580b6 ("u64_stats: provide u64_stats_t type") we should use u64_stats_t and related accessors to avoid load/store tearing. Add READ_ONCE() when reading rx_errors & tx_dropped. Signed-off-by:
-
Jakub Kicinski authored
Netdev reference helpers have a dev_ prefix for historic reasons. Renaming the old helpers would be too much churn but we can rename the tracking ones which are relatively recent and should be the default for new code. Rename: dev_hold_track() -> netdev_hold() dev_put_track() -> netdev_put() dev_replace_track() -> netdev_ref_replace() Link: https://lore.kernel.org/r/20220608043955.919359-1-kuba@kernel.orgSigned-off-by:
-
- 09 Jun, 2022 5 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski authored
No conflicts. Signed-off-by: -
Jukka Rissanen authored
I no longer work on this so better update the file. Signed-off-by:
Jukka Rissanen <jukka.rissanen@linux.intel.com> Acked-by:
Marcel Holtmann <marcel@holtmann.org> Link: https://lore.kernel.org/r/20220527075625.9693-1-jukka.rissanen@linux.intel.comSigned-off-by:
-
Alexander Aring authored
This patch constify the lowpan_nhc declarations. Since we drop the rb node datastructure there is no need for runtime manipulation of this structure. Signed-off-by:
-
Alexander Aring authored
This patch will remove the complete overengineered and overthinking rb data structure for looking up the nhc by nhcid. Instead we using the existing nhc next header array and iterate over it. It works now for 1 byte values only. However there are only 1 byte nhc id values currently supported and IANA also does not specify large than 1 byte values yet. If there are 2 byte values for nhc ids specified we can revisit this data structure and add support for it. Signed-off-by:
-
Alexander Aring authored
The keyword const makes no sense for scalar types inside the lowpan_nhc structure. Most compilers will ignore it so we remove the keyword from the scalar types. Signed-off-by:
-
