* Re: [PATCH v4 3/4] net: socket: simplify dev_ifconf handling
From: Jakub Kicinski @ 2020-11-24 20:52 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: netdev, Arnd Bergmann
In-Reply-To: <20201124151828.169152-4-arnd@kernel.org>
On Tue, 24 Nov 2020 16:18:27 +0100 Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The dev_ifconf() calling conventions make compat handling
> more complicated than necessary, simplify this by moving
> the in_compat_syscall() check into the function.
> The implementation can be simplified further, based on the
> knowledge that the dynamic registration is only ever used
> for IPv4.
Looks like this one breaks bisection (/breaks build which patch 4 then
fixes):
In file included from ../arch/x86/include/asm/sigframe.h:8,
from ../arch/x86/kernel/asm-offsets.c:17:
../include/linux/compat.h:348:29: error: field ‘ifru_settings’ has incomplete type
348 | struct compat_if_settings ifru_settings;
| ^~~~~~~~~~~~~
../include/linux/compat.h:352:8: error: redefinition of ‘struct compat_ifconf’
352 | struct compat_ifconf {
| ^~~~~~~~~~~~~
../include/linux/compat.h:108:8: note: originally defined here
108 | struct compat_ifconf {
| ^~~~~~~~~~~~~
make[2]: *** [arch/x86/kernel/asm-offsets.s] Error 1
make[1]: *** [prepare0] Error 2
make: *** [__sub-make] Error 2
^ permalink raw reply
* Re: VRF NS for lladdr sent on the wrong interface
From: Stephen Suryaputra @ 2020-11-24 20:57 UTC (permalink / raw)
To: David Ahern; +Cc: netdev
In-Reply-To: <6d0df155-ef2e-f3eb-46df-90d5083c0dc0@gmail.com>
On Tue, Nov 24, 2020 at 01:43:54PM -0700, David Ahern wrote:
> On 11/23/20 5:23 PM, Stephen Suryaputra wrote:
> > Hi,
> >
> > I'm running into a problem with lladdr pinging all-host mcast all nodes
> > addr. The ping intially works but after cycling the interface that
> > receives the ping, the echo request packet causes a neigh solicitation
> > being sent on a different interface.
> >
> > To repro, I included the attached namespace scripts. This is the
> > topology and an output of my test.
>
> Can you run your test script on 4.14-4.17 kernel? I am wondering if the
> changes in 4.19-next changed this behavior.
>
We found the issue on 4.14.200-based kernel.
^ permalink raw reply
* Re: [PATCH net-next v4 7/7] dpaa_eth: implement the A050385 erratum workaround for XDP
From: Maciej Fijalkowski @ 2020-11-24 20:50 UTC (permalink / raw)
To: Camelia Groza
Cc: kuba, brouer, saeed, davem, madalin.bucur, ioana.ciornei, netdev
In-Reply-To: <e53e361d320cb901b0d9b9b82e6c16a04fbe6f86.1606150838.git.camelia.groza@nxp.com>
On Mon, Nov 23, 2020 at 07:36:25PM +0200, Camelia Groza wrote:
> For XDP TX, even tough we start out with correctly aligned buffers, the
> XDP program might change the data's alignment. For REDIRECT, we have no
> control over the alignment either.
>
> Create a new workaround for xdp_frame structures to verify the erratum
> conditions and move the data to a fresh buffer if necessary. Create a new
> xdp_frame for managing the new buffer and free the old one using the XDP
> API.
>
> Due to alignment constraints, all frames have a 256 byte headroom that
> is offered fully to XDP under the erratum. If the XDP program uses all
> of it, the data needs to be move to make room for the xdpf backpointer.
Out of curiosity, wouldn't it be easier to decrease the headroom that is
given to xdp rather doing to full copy of a buffer in case you miss a few
bytes on headroom?
>
> Disable the metadata support since the information can be lost.
>
> Acked-by: Madalin Bucur <madalin.bucur@oss.nxp.com>
> Signed-off-by: Camelia Groza <camelia.groza@nxp.com>
> ---
> drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 82 +++++++++++++++++++++++++-
> 1 file changed, 79 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> index 149b549..d8fc19d 100644
> --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> @@ -2170,6 +2170,52 @@ static int dpaa_a050385_wa_skb(struct net_device *net_dev, struct sk_buff **s)
>
> return 0;
> }
> +
> +static int dpaa_a050385_wa_xdpf(struct dpaa_priv *priv,
> + struct xdp_frame **init_xdpf)
> +{
> + struct xdp_frame *new_xdpf, *xdpf = *init_xdpf;
> + void *new_buff;
> + struct page *p;
> +
> + /* Check the data alignment and make sure the headroom is large
> + * enough to store the xdpf backpointer. Use an aligned headroom
> + * value.
> + *
> + * Due to alignment constraints, we give XDP access to the full 256
> + * byte frame headroom. If the XDP program uses all of it, copy the
> + * data to a new buffer and make room for storing the backpointer.
> + */
> + if (PTR_IS_ALIGNED(xdpf->data, DPAA_A050385_ALIGN) &&
> + xdpf->headroom >= priv->tx_headroom) {
> + xdpf->headroom = priv->tx_headroom;
> + return 0;
> + }
> +
> + p = dev_alloc_pages(0);
> + if (unlikely(!p))
> + return -ENOMEM;
> +
> + /* Copy the data to the new buffer at a properly aligned offset */
> + new_buff = page_address(p);
> + memcpy(new_buff + priv->tx_headroom, xdpf->data, xdpf->len);
> +
> + /* Create an XDP frame around the new buffer in a similar fashion
> + * to xdp_convert_buff_to_frame.
> + */
> + new_xdpf = new_buff;
> + new_xdpf->data = new_buff + priv->tx_headroom;
> + new_xdpf->len = xdpf->len;
> + new_xdpf->headroom = priv->tx_headroom;
What if ptr was not aligned so you got here but tx_headroom was less than
xdpf->headroom? Shouldn't you choose the bigger one? Aren't you shrinking
the headroom for this case.
> + new_xdpf->frame_sz = DPAA_BP_RAW_SIZE;
> + new_xdpf->mem.type = MEM_TYPE_PAGE_ORDER0;
> +
> + /* Release the initial buffer */
> + xdp_return_frame_rx_napi(xdpf);
> +
> + *init_xdpf = new_xdpf;
> + return 0;
> +}
> #endif
>
> static netdev_tx_t
> @@ -2406,6 +2452,15 @@ static int dpaa_xdp_xmit_frame(struct net_device *net_dev,
> percpu_priv = this_cpu_ptr(priv->percpu_priv);
> percpu_stats = &percpu_priv->stats;
>
> +#ifdef CONFIG_DPAA_ERRATUM_A050385
> + if (unlikely(fman_has_errata_a050385())) {
> + if (dpaa_a050385_wa_xdpf(priv, &xdpf)) {
> + err = -ENOMEM;
> + goto out_error;
> + }
> + }
> +#endif
> +
> if (xdpf->headroom < DPAA_TX_PRIV_DATA_SIZE) {
> err = -EINVAL;
> goto out_error;
> @@ -2479,6 +2534,20 @@ static u32 dpaa_run_xdp(struct dpaa_priv *priv, struct qm_fd *fd, void *vaddr,
> xdp.frame_sz = DPAA_BP_RAW_SIZE - DPAA_TX_PRIV_DATA_SIZE;
> xdp.rxq = &dpaa_fq->xdp_rxq;
>
> + /* We reserve a fixed headroom of 256 bytes under the erratum and we
> + * offer it all to XDP programs to use. If no room is left for the
> + * xdpf backpointer on TX, we will need to copy the data.
> + * Disable metadata support since data realignments might be required
> + * and the information can be lost.
> + */
> +#ifdef CONFIG_DPAA_ERRATUM_A050385
> + if (unlikely(fman_has_errata_a050385())) {
> + xdp_set_data_meta_invalid(&xdp);
> + xdp.data_hard_start = vaddr;
> + xdp.frame_sz = DPAA_BP_RAW_SIZE;
> + }
> +#endif
> +
> xdp_act = bpf_prog_run_xdp(xdp_prog, &xdp);
>
> /* Update the length and the offset of the FD */
> @@ -2486,7 +2555,8 @@ static u32 dpaa_run_xdp(struct dpaa_priv *priv, struct qm_fd *fd, void *vaddr,
>
> switch (xdp_act) {
> case XDP_PASS:
> - *xdp_meta_len = xdp.data - xdp.data_meta;
> + *xdp_meta_len = xdp_data_meta_unsupported(&xdp) ? 0 :
> + xdp.data - xdp.data_meta;
You could consider surrounding this with ifdef and keep the old version in
the else branch so that old case is not hurt with that additional branch
that you're introducing with that ternary operator.
> break;
> case XDP_TX:
> /* We can access the full headroom when sending the frame
> @@ -3188,10 +3258,16 @@ static u16 dpaa_get_headroom(struct dpaa_buffer_layout *bl,
> */
> headroom = (u16)(bl[port].priv_data_size + DPAA_HWA_SIZE);
>
> - if (port == RX)
> + if (port == RX) {
> +#ifdef CONFIG_DPAA_ERRATUM_A050385
> + if (unlikely(fman_has_errata_a050385()))
> + headroom = XDP_PACKET_HEADROOM;
> +#endif
> +
> return ALIGN(headroom, DPAA_FD_RX_DATA_ALIGNMENT);
> - else
> + } else {
> return ALIGN(headroom, DPAA_FD_DATA_ALIGNMENT);
> + }
> }
>
> static int dpaa_eth_probe(struct platform_device *pdev)
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH net] enetc: Advance the taprio base time in the future
From: Vladimir Oltean @ 2020-11-24 21:00 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Po Liu, netdev@vger.kernel.org, Claudiu Manoil,
Vinicius Costa Gomes
In-Reply-To: <20201124095812.539b9d1e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
On Tue, Nov 24, 2020 at 09:58:12AM -0800, Jakub Kicinski wrote:
> > This is the right way for calculation. For the ENETC, hardware also
> > do the same calculation before send to Operation State Machine.
> > For some TSN IP, like Felix and DesignWare TSN in RT1170 and IMX8MP
> > require the basetime limite the range not less than the current time
> > 8 cycles, software may do calculation before setting to the
> > hardware.
> > Actually, I do suggest this calculation to sch_taprio.c, but I found
> > same calculation only for the TXTIME by taprio_get_start_time().
> > Which means:
> > If (currenttime < basetime)
> > Admin_basetime = basetime;
> > Else
> > Admin_basetime = basetime + (n+1)* cycletime;
> > N is the minimal value which make Admin_basetime is larger than the
> > currenttime.
> >
> > User space never to get the current time. Just set a value as offset
> > OR future time user want.
> > For example: set basetime = 1000000ns, means he want time align to
> > 1000000ns, and on the other device, also set the basetime =
> > 1000000ns, then the two devices are aligned cycle.
> > If user want all the devices start at 11.24.2020 11:00 then set
> > basetime = 1606273200.0 s.
> >
> > > - the sja1105 offload does it via future_base_time()
> > > - the ocelot/felix offload does it via vsc9959_new_base_time()
> > >
> > > As for the obvious question: doesn't the hardware just "do the right thing"
> > > if passed a time in the past? I've tested and it doesn't look like it. I cannot
> >
> > So hardware already do calculation same way.
>
> So the patch is unnecessary? Or correct? Not sure what you're saying..
He's not saying the patch is unnecessary. What the enetc driver
currently does for the case where the base_time is zero is bogus anyway.
What Po is saying is that calling future_base_time() should not be
needed. Instead, he is suggesting we could program directly the
admin_conf->base_time into the hardware, which will do the right thing
as long as the driver doesn't mangle it in various ways, such as replace
the base_time with the current time.
And what I said in the commit message is that I've been there before and
there were some still apparent issues with the schedule's phase. I had
some issues at the application layer as well. In the meantime I sorted
those out, and after re-applying the simple kernel change and giving the
system some thorough testing, it looks like Po is right.
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] Add support for DSFP transceiver type
From: Jakub Kicinski @ 2020-11-24 21:16 UTC (permalink / raw)
To: Andrew Lunn
Cc: Moshe Shemesh, David S. Miller, Adrian Pop, Michal Kubecek,
netdev, Vladyslav Tarasiuk, Moshe Shemesh
In-Reply-To: <20201124011459.GD2031446@lunn.ch>
On Tue, 24 Nov 2020 02:14:59 +0100 Andrew Lunn wrote:
> On Mon, Nov 23, 2020 at 11:19:56AM +0200, Moshe Shemesh wrote:
> > Add support for new cable module type DSFP (Dual Small Form-Factor Pluggable
> > transceiver). DSFP EEPROM memory layout is compatible with CMIS 4.0 spec. Add
> > CMIS 4.0 module type to UAPI and implement DSFP EEPROM dump in mlx5.
>
> So the patches themselves look O.K.
>
> But we are yet again kicking the can down the road and not fixing the
> underlying inflexibility of the API.
>
> Do we want to keep kicking the can, or is now the time to do the work
> on this API?
This is hardly rocket science. Let's do it right.
^ permalink raw reply
* Re: [PATCH net v2] devlink: Fix reload stats structure
From: Jakub Kicinski @ 2020-11-24 21:18 UTC (permalink / raw)
To: Moshe Shemesh; +Cc: David S. Miller, Jiri Pirko, netdev, linux-kernel
In-Reply-To: <1606109785-25197-1-git-send-email-moshe@mellanox.com>
On Mon, 23 Nov 2020 07:36:25 +0200 Moshe Shemesh wrote:
> Fix reload stats structure exposed to the user. Change stats structure
> hierarchy to have the reload action as a parent of the stat entry and
> then stat entry includes value per limit. This will also help to avoid
> string concatenation on iproute2 output.
>
> Reload stats structure before this fix:
> "stats": {
> "reload": {
> "driver_reinit": 2,
> "fw_activate": 1,
> "fw_activate_no_reset": 0
> }
> }
>
> After this fix:
> "stats": {
> "reload": {
> "driver_reinit": {
> "unspecified": 2
> },
> "fw_activate": {
> "unspecified": 1,
> "no_reset": 0
> }
> }
>
> Fixes: a254c264267e ("devlink: Add reload stats")
> Signed-off-by: Moshe Shemesh <moshe@mellanox.com>
> Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Applied.
^ permalink raw reply
* RE: Wifi hangs
From: Damary, Guy @ 2020-11-24 21:19 UTC (permalink / raw)
To: Coelho, Luciano, davem@davemloft.net, gonsolo@gmail.com,
Berg, Johannes, akpm@linux-foundation.org, kvalo@codeaurora.org,
hannes@cmpxchg.org, linux-kernel@vger.kernel.org,
Goodstein, Mordechay, kuba@kernel.org, linuxwifi,
linux-wireless@vger.kernel.org, Grumbach, Emmanuel,
netdev@vger.kernel.org, longman@redhat.com
In-Reply-To: <6b71718c405541d681f4d8b045a66a79ade0dd4f.camel@intel.com>
Hey Gonsolo,
It’s a pleasant to e-meet you.
My name is Guy and I’ll do my best to promote your issue.
We will probably need more information in order to make sure this issue is assigned to the relevant engineer at Intel,
To make sure your issue gets the proper attention and prioritized accordingly – I would kindly ask you to report it via Intel Customer Support service which can be found here: https://www.intel.com/content/www/us/en/support/contact-support.html?productId=59484,59485,83418#@11
Give me a ping once the request has been opened and I'll do my best to track it and make sure it will land in the right hands.
Thanks,
Guy.
-----Original Message-----
From: Coelho, Luciano <luciano.coelho@intel.com>
Sent: Thursday, November 19, 2020 23:01
To: Damary, Guy <guy.damary@intel.com>; davem@davemloft.net; gonsolo@gmail.com; Berg, Johannes <johannes.berg@intel.com>; akpm@linux-foundation.org; kvalo@codeaurora.org; hannes@cmpxchg.org; linux-kernel@vger.kernel.org; Goodstein, Mordechay <mordechay.goodstein@intel.com>; kuba@kernel.org; linuxwifi <linuxwifi@intel.com>; linux-wireless@vger.kernel.org; Grumbach, Emmanuel <emmanuel.grumbach@intel.com>; netdev@vger.kernel.org; longman@redhat.com
Subject: Re: Wifi hangs
Adding Guy Damary
Guy, can you help with this one? I believe there is a bugzilla issue for this already...
--
Cheers,
Luca.
On Thu, 2020-11-19 at 17:42 +0100, Gonsolo wrote:
> Hi!
>
> Sporadically my wifi hangs. Any idea why?
> This is on a 5.10.0-051000rc2-lowlatency kernel from
> https://kernel.ubuntu.com/~kernel-ppa/mainline.
> I have to stop and start the device to make it work again.
> From dmesg:
>
> [ +0,000101] ------------[ cut here ]------------ [ +0,000002] TX on
> unused queue 5 [ +0,000049] WARNING: CPU: 2 PID: 20577 at
> drivers/net/wireless/intel/iwlwifi/pcie/tx.c:1927
> iwl_trans_pcie_tx+0x676/0x7f0 [iwlwifi] [ +0,000003] Modules linked
> in: dvb_usb_af9035 uas usb_storage
> dvb_usb_v2 dvb_core rfcomm ccm snd_seq_dummy snd_hrtimer cmac
> algif_hash algif_skcipher af_alg bnep binfmt_misc nls_iso8859_1
> snd_hda_codec_hdmi intel_rapl_msr snd_hda_codec_realtek
> snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_hda_codec
> snd_hda_core snd_hwdep pn544_mei mei_phy pn544 cdc_mbim
> intel_rapl_common snd_pcm x86_pkg_temp_thermal intel_powerclamp
> coretemp hci snd_seq_midi cdc_wdm qcserial kvm_intel nfc
> snd_seq_midi_event usb_wwan mei_hdcp dell_laptop kvm ledtrig_audio
> cdc_ncm usbserial snd_rawmidi cdc_ether crct10dif_pclmul usbnet
> ghash_clmulni_intel mii dell_smm_hwmon iwlmvm mac80211 libarc4
> aesni_intel crypto_simd uvcvideo videobuf2_vmalloc iwlwifi cryptd
> glue_helper rapl intel_cstate snd_seq btusb btrtl btbcm
> videobuf2_memops i915 btintel bluetooth videobuf2_v4l2
> videobuf2_common snd_seq_device videodev dell_wmi snd_timer input_leds
> joydev dell_smbios mc dcdbas ecdh_generic ecc sparse_keymap cfg80211 [
> +0,000079] serio_raw at24 wmi_bmof dell_wmi_descriptor efi_pstore snd
> drm_kms_helper cec rc_core mei_me i2c_algo_bit fb_sys_fops syscopyarea
> sysfillrect mei soundcore sysimgblt dell_rbtn mac_hid sch_fq_codel
> parport_pc ppdev lp drm parport ip_tables x_tables
> autofs4 hid_logitech_hidpp hid_logitech_dj hid_generic usbhid hid
> sdhci_pci crc32_pclmul i2c_i801 psmouse cqhci i2c_smbus sdhci ahci
> libahci lpc_ich e1000e xhci_pci wmi xhci_pci_renesas video [last
> unloaded: dvb_usb_af9035]
> [ +0,000049] CPU: 2 PID: 20577 Comm: kworker/2:1 Not tainted
> 5.10.0-051000rc2-lowlatency #202011012330 [ +0,000001] Hardware name:
> Dell Inc. Latitude E7240/0R6F3F, BIOS A29
> 06/13/2019
> [ +0,000029] Workqueue: events cfg80211_rfkill_block_work [cfg80211]
> [ +0,000013] RIP: 0010:iwl_trans_pcie_tx+0x676/0x7f0 [iwlwifi] [
> +0,000005] Code: 3d 03 5e 03 00 00 b8 ea ff ff ff 0f 85 eb fc ff ff
> 44 89 fe 48 c7 c7 5d b5 d3 c0 89 45 d0 c6 05 e4 5d 03 00 01 e8 7b 5d
> 4b c4 <0f> 0b 8b 45 d0 e9 c8 fc ff ff 41 0f b6 86 80 00 00 00 83 e0 60
> 3c [ +0,000002] RSP: 0018:ffffaf8f00e1f680 EFLAGS: 00010282 [
> +0,000002] RAX: 0000000000000000 RBX: ffff9b8c8d0d0900 RCX:
> ffff9b8e96b18988 [ +0,000001] RDX: 00000000ffffffd8 RSI:
> 0000000000000027 RDI: ffff9b8e96b18980 [ +0,000001] RBP:
> ffffaf8f00e1f6e0 R08: 0000000000000000 R09: ffffaf8f00e1f470 [
> +0,000002] R10: ffffaf8f00e1f468 R11: ffffffff86353c28 R12:
> ffff9b8d823243e8 [ +0,000001] R13: 0000000000000037 R14:
> 0000000000000005 R15: 0000000000000005 [ +0,000002] FS:
> 0000000000000000(0000) GS:ffff9b8e96b00000(0000)
> knlGS:0000000000000000
> [ +0,000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [
> +0,000001] CR2: 00003a4e0b5b3080 CR3: 0000000105a0c002 CR4:
> 00000000001706e0 [ +0,000002] Call Trace:
> [ +0,000020] iwl_mvm_tx_mpdu+0x1e0/0x590 [iwlmvm] [ +0,000011]
> iwl_mvm_tx_skb_sta+0x153/0x1e0 [iwlmvm] [ +0,000008]
> iwl_mvm_tx_skb+0x1c/0x40 [iwlmvm] [ +0,000008]
> iwl_mvm_mac_itxq_xmit+0x7a/0xe0 [iwlmvm] [ +0,000010]
> iwl_mvm_mac_wake_tx_queue+0x29/0x80 [iwlmvm] [ +0,000029]
> drv_wake_tx_queue+0x51/0xe0 [mac80211] [ +0,000023]
> ieee80211_queue_skb+0x15b/0x220 [mac80211] [ +0,000035]
> ieee80211_tx+0xd6/0x140 [mac80211] [ +0,000025]
> ieee80211_xmit+0xb8/0xf0 [mac80211] [ +0,000024]
> __ieee80211_tx_skb_tid_band+0x6d/0x80 [mac80211] [ +0,000022]
> ieee80211_send_deauth_disassoc+0xff/0x130 [mac80211] [ +0,000024]
> ieee80211_set_disassoc+0x3ae/0x4b0 [mac80211] [ +0,000027]
> ieee80211_mgd_deauth+0x106/0x300 [mac80211] [ +0,000004] ?
> __update_blocked_fair+0xda/0x3f0 [ +0,000004] ?
> acpi_ut_delete_object_desc+0xa2/0xa6
> [ +0,000022] ieee80211_deauth+0x18/0x20 [mac80211] [ +0,000028]
> cfg80211_mlme_deauth+0xb2/0x1e0 [cfg80211] [ +0,000022]
> cfg80211_mlme_down+0x64/0x80 [cfg80211] [ +0,000021]
> cfg80211_disconnect+0x157/0x210 [cfg80211] [ +0,000021]
> __cfg80211_leave+0x133/0x1b0 [cfg80211] [ +0,000020]
> cfg80211_netdev_notifier_call+0x1bf/0x5c0 [cfg80211] [ +0,000009] ?
> iwl_mvm_nic_error+0x40/0x40 [iwlmvm] [ +0,000011] ?
> iwl_mvm_send_cmd_pdu+0x54/0x90 [iwlmvm] [ +0,000009] ?
> iwl_mvm_send_cmd+0x1f/0x50 [iwlmvm] [ +0,000008] ?
> iwl_mvm_mc_iface_iterator+0xb9/0xe0 [iwlmvm] [ +0,000023] ?
> __iterate_interfaces+0xa2/0x100 [mac80211] [ +0,000008] ?
> iwl_mvm_set_tim+0x50/0x50 [iwlmvm] [ +0,000009] ?
> iwl_mvm_set_tim+0x50/0x50 [iwlmvm] [ +0,000024] ?
> ieee80211_iterate_active_interfaces_atomic+0x38/0x50 [mac80211] [
> +0,000006] ? rtnl_is_locked+0x15/0x20 [ +0,000004] ?
> inetdev_event+0x34/0x400 [ +0,000006]
> raw_notifier_call_chain+0x49/0x60 [ +0,000003]
> call_netdevice_notifiers_info+0x50/0x90
> [ +0,000004] __dev_close_many+0x5e/0x110 [ +0,000002]
> dev_close_many+0x85/0x130 [ +0,000003] dev_close+0x5e/0x80 [
> +0,000021] cfg80211_shutdown_all_interfaces+0x77/0xd0 [cfg80211] [
> +0,000017] cfg80211_rfkill_block_work+0x1e/0x30 [cfg80211] [
> +0,000006] process_one_work+0x1e3/0x3b0 [ +0,000003]
> worker_thread+0x4d/0x350 [ +0,000003] ? rescuer_thread+0x390/0x390 [
> +0,000003] kthread+0x145/0x170 [ +0,000002] ?
> __kthread_bind_mask+0x70/0x70 [ +0,000004] ret_from_fork+0x22/0x30 [
> +0,000005] CPU: 2 PID: 20577 Comm: kworker/2:1 Not tainted
> 5.10.0-051000rc2-lowlatency #202011012330 [ +0,000002] Hardware name:
> Dell Inc. Latitude E7240/0R6F3F, BIOS A29
> 06/13/2019
> [ +0,000018] Workqueue: events cfg80211_rfkill_block_work [cfg80211]
> [ +0,000002] Call Trace:
> [ +0,000005] show_stack+0x52/0x58
> [ +0,000003] dump_stack+0x70/0x8b
> [ +0,000013] ? iwl_trans_pcie_tx+0x676/0x7f0 [iwlwifi] [ +0,000004]
> __warn.cold+0x24/0x77 [ +0,000011] ? iwl_trans_pcie_tx+0x676/0x7f0
> [iwlwifi] [ +0,000003] report_bug+0xa1/0xc0 [ +0,000006]
> handle_bug+0x3e/0xa0 [ +0,000002] exc_invalid_op+0x19/0x70 [
> +0,000004] asm_exc_invalid_op+0x12/0x20 [ +0,000011] RIP:
> 0010:iwl_trans_pcie_tx+0x676/0x7f0 [iwlwifi] [ +0,000003] Code: 3d 03
> 5e 03 00 00 b8 ea ff ff ff 0f 85 eb fc ff ff
> 44 89 fe 48 c7 c7 5d b5 d3 c0 89 45 d0 c6 05 e4 5d 03 00 01 e8 7b 5d
> 4b c4 <0f> 0b 8b 45 d0 e9 c8 fc ff ff 41 0f b6 86 80 00 00 00 83 e0 60
> 3c [ +0,000002] RSP: 0018:ffffaf8f00e1f680 EFLAGS: 00010282 [
> +0,000002] RAX: 0000000000000000 RBX: ffff9b8c8d0d0900 RCX:
> ffff9b8e96b18988 [ +0,000001] RDX: 00000000ffffffd8 RSI:
> 0000000000000027 RDI: ffff9b8e96b18980 [ +0,000002] RBP:
> ffffaf8f00e1f6e0 R08: 0000000000000000 R09: ffffaf8f00e1f470 [
> +0,000001] R10: ffffaf8f00e1f468 R11: ffffffff86353c28 R12:
> ffff9b8d823243e8 [ +0,000001] R13: 0000000000000037 R14:
> 0000000000000005 R15: 0000000000000005 [ +0,000013]
> iwl_mvm_tx_mpdu+0x1e0/0x590 [iwlmvm] [ +0,000012]
> iwl_mvm_tx_skb_sta+0x153/0x1e0 [iwlmvm] [ +0,000009]
> iwl_mvm_tx_skb+0x1c/0x40 [iwlmvm] [ +0,000009]
> iwl_mvm_mac_itxq_xmit+0x7a/0xe0 [iwlmvm] [ +0,000008]
> iwl_mvm_mac_wake_tx_queue+0x29/0x80 [iwlmvm] [ +0,000021]
> drv_wake_tx_queue+0x51/0xe0 [mac80211] [ +0,000021]
> ieee80211_queue_skb+0x15b/0x220 [mac80211] [ +0,000025]
> ieee80211_tx+0xd6/0x140 [mac80211] [ +0,000023]
> ieee80211_xmit+0xb8/0xf0 [mac80211] [ +0,000021]
> __ieee80211_tx_skb_tid_band+0x6d/0x80 [mac80211] [ +0,000025]
> ieee80211_send_deauth_disassoc+0xff/0x130 [mac80211] [ +0,000026]
> ieee80211_set_disassoc+0x3ae/0x4b0 [mac80211] [ +0,000023]
> ieee80211_mgd_deauth+0x106/0x300 [mac80211] [ +0,000004] ?
> __update_blocked_fair+0xda/0x3f0 [ +0,000003] ?
> acpi_ut_delete_object_desc+0xa2/0xa6
> [ +0,000024] ieee80211_deauth+0x18/0x20 [mac80211] [ +0,000022]
> cfg80211_mlme_deauth+0xb2/0x1e0 [cfg80211] [ +0,000021]
> cfg80211_mlme_down+0x64/0x80 [cfg80211] [ +0,000025]
> cfg80211_disconnect+0x157/0x210 [cfg80211] [ +0,000019]
> __cfg80211_leave+0x133/0x1b0 [cfg80211] [ +0,000017]
> cfg80211_netdev_notifier_call+0x1bf/0x5c0 [cfg80211] [ +0,000011] ?
> iwl_mvm_nic_error+0x40/0x40 [iwlmvm] [ +0,000009] ?
> iwl_mvm_send_cmd_pdu+0x54/0x90 [iwlmvm] [ +0,000009] ?
> iwl_mvm_send_cmd+0x1f/0x50 [iwlmvm] [ +0,000008] ?
> iwl_mvm_mc_iface_iterator+0xb9/0xe0 [iwlmvm] [ +0,000022] ?
> __iterate_interfaces+0xa2/0x100 [mac80211] [ +0,000008] ?
> iwl_mvm_set_tim+0x50/0x50 [iwlmvm] [ +0,000008] ?
> iwl_mvm_set_tim+0x50/0x50 [iwlmvm] [ +0,000024] ?
> ieee80211_iterate_active_interfaces_atomic+0x38/0x50 [mac80211] [
> +0,000004] ? rtnl_is_locked+0x15/0x20 [ +0,000003] ?
> inetdev_event+0x34/0x400 [ +0,000004]
> raw_notifier_call_chain+0x49/0x60 [ +0,000004]
> call_netdevice_notifiers_info+0x50/0x90
> [ +0,000004] __dev_close_many+0x5e/0x110 [ +0,000003]
> dev_close_many+0x85/0x130 [ +0,000003] dev_close+0x5e/0x80 [
> +0,000020] cfg80211_shutdown_all_interfaces+0x77/0xd0 [cfg80211] [
> +0,000018] cfg80211_rfkill_block_work+0x1e/0x30 [cfg80211] [
> +0,000004] process_one_work+0x1e3/0x3b0 [ +0,000004]
> worker_thread+0x4d/0x350 [ +0,000003] ? rescuer_thread+0x390/0x390 [
> +0,000002] kthread+0x145/0x170 [ +0,000003] ?
> __kthread_bind_mask+0x70/0x70 [ +0,000004] ret_from_fork+0x22/0x30 [
> +0,000012] ---[ end trace db8dbd78d4c68899 ]--- [ +0,100513]
> ------------[ cut here ]------------ [ +0,000003] Timeout waiting for
> hardware access (CSR_GP_CNTRL 0x000003d8) [ +0,000038] WARNING: CPU:
> 2 PID: 20577 at
> drivers/net/wireless/intel/iwlwifi/pcie/trans.c:2067
> iwl_trans_pcie_grab_nic_access+0x1bd/0x1f0 [iwlwifi] [ +0,000001]
> Modules linked in: dvb_usb_af9035 uas usb_storage
> dvb_usb_v2 dvb_core rfcomm ccm snd_seq_dummy snd_hrtimer cmac
> algif_hash algif_skcipher af_alg bnep binfmt_misc nls_iso8859_1
> snd_hda_codec_hdmi intel_rapl_msr snd_hda_codec_realtek
> snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_hda_codec
> snd_hda_core snd_hwdep pn544_mei mei_phy pn544 cdc_mbim
> intel_rapl_common snd_pcm x86_pkg_temp_thermal intel_powerclamp
> coretemp hci snd_seq_midi cdc_wdm qcserial kvm_intel nfc
> snd_seq_midi_event usb_wwan mei_hdcp dell_laptop kvm ledtrig_audio
> cdc_ncm usbserial snd_rawmidi cdc_ether crct10dif_pclmul usbnet
> ghash_clmulni_intel mii dell_smm_hwmon iwlmvm mac80211 libarc4
> aesni_intel crypto_simd uvcvideo videobuf2_vmalloc iwlwifi cryptd
> glue_helper rapl intel_cstate snd_seq btusb btrtl btbcm
> videobuf2_memops i915 btintel bluetooth videobuf2_v4l2
> videobuf2_common snd_seq_device videodev dell_wmi snd_timer input_leds
> joydev dell_smbios mc dcdbas ecdh_generic ecc sparse_keymap cfg80211 [
> +0,000043] serio_raw at24 wmi_bmof dell_wmi_descriptor efi_pstore snd
> drm_kms_helper cec rc_core mei_me i2c_algo_bit fb_sys_fops syscopyarea
> sysfillrect mei soundcore sysimgblt dell_rbtn mac_hid sch_fq_codel
> parport_pc ppdev lp drm parport ip_tables x_tables
> autofs4 hid_logitech_hidpp hid_logitech_dj hid_generic usbhid hid
> sdhci_pci crc32_pclmul i2c_i801 psmouse cqhci i2c_smbus sdhci ahci
> libahci lpc_ich e1000e xhci_pci wmi xhci_pci_renesas video [last
> unloaded: dvb_usb_af9035]
> [ +0,000027] CPU: 2 PID: 20577 Comm: kworker/2:1 Tainted: G W
> 5.10.0-051000rc2-lowlatency #202011012330 [ +0,000001]
> Hardware name: Dell Inc. Latitude E7240/0R6F3F, BIOS A29
> 06/13/2019
> [ +0,000026] Workqueue: events cfg80211_rfkill_block_work [cfg80211]
> [ +0,000009] RIP: 0010:iwl_trans_pcie_grab_nic_access+0x1bd/0x1f0
> [iwlwifi] [ +0,000001] Code: 85 c5 49 8d 57 08 bf 00 20 00 00 e8 0d
> bf 9a c3 e9
> 35 ff ff ff 89 c6 48 c7 c7 20 ea d3 c0 c6 05 93 25 03 00 01 e8 24 25
> 4b c4 <0f> 0b e9 f0 fe ff ff 49 8b 7c 24 38 48 c7 c1 88 ea d3 c0 31 d2
> 31
> [ +0,000001] RSP: 0018:ffffaf8f00e1fb80 EFLAGS: 00010082 [
> +0,000001] RAX: 0000000000000000 RBX: ffffaf8f00e1fbb8 RCX:
> ffff9b8e96b18988 [ +0,000001] RDX: 00000000ffffffd8 RSI:
> 0000000000000027 RDI: ffff9b8e96b18980 [ +0,000001] RBP:
> ffffaf8f00e1fba8 R08: 0000000000000000 R09: ffffaf8f00e1f970 [
> +0,000001] R10: ffffaf8f00e1f968 R11: ffffffff86353c28 R12:
> ffff9b8d895f8018 [ +0,000000] R13: 0000000000000000 R14:
> ffff9b8d895fa6f4 R15: 00000000000003d8 [ +0,000002] FS:
> 0000000000000000(0000) GS:ffff9b8e96b00000(0000)
> knlGS:0000000000000000
> [ +0,000000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [
> +0,000001] CR2: 00003a4e0b5b3080 CR3: 0000000103918004 CR4:
> 00000000001706e0 [ +0,000001] Call Trace:
> [ +0,000007] iwl_set_bits_prph+0x3a/0x90 [iwlwifi] [ +0,000008]
> iwl_fw_dbg_stop_restart_recording.part.0+0x234/0x260 [iwlwifi] [
> +0,000003] ? __cancel_work_timer+0x109/0x190 [ +0,000008]
> iwl_fw_dbg_stop_sync+0x46/0x50 [iwlwifi] [ +0,000009]
> __iwl_mvm_mac_stop+0x8c/0x170 [iwlmvm] [ +0,000004]
> iwl_mvm_mac_stop+0x77/0x90 [iwlmvm] [ +0,000022] drv_stop+0x32/0x110
> [mac80211] [ +0,000014] ieee80211_stop_device+0x46/0x50 [mac80211] [
> +0,000012] ieee80211_do_stop+0x551/0x860 [mac80211] [ +0,000003] ?
> _raw_spin_unlock_bh+0x1e/0x20 [ +0,000012] ieee80211_stop+0x1a/0x20
> [mac80211] [ +0,000002] __dev_close_many+0x9d/0x110 [ +0,000002]
> dev_close_many+0x85/0x130 [ +0,000002] dev_close+0x5e/0x80 [
> +0,000011] cfg80211_shutdown_all_interfaces+0x77/0xd0 [cfg80211] [
> +0,000010] cfg80211_rfkill_block_work+0x1e/0x30 [cfg80211] [
> +0,000002] process_one_work+0x1e3/0x3b0 [ +0,000002]
> worker_thread+0x4d/0x350 [ +0,000002] ? rescuer_thread+0x390/0x390 [
> +0,000002] kthread+0x145/0x170 [ +0,000001] ?
> __kthread_bind_mask+0x70/0x70 [ +0,000003] ret_from_fork+0x22/0x30
> [ +0,000002] CPU: 2 PID: 20577 Comm: kworker/2:1 Tainted: G W
> 5.10.0-051000rc2-lowlatency #202011012330 [ +0,000001]
> Hardware name: Dell Inc. Latitude E7240/0R6F3F, BIOS A29
> 06/13/2019
> [ +0,000010] Workqueue: events cfg80211_rfkill_block_work [cfg80211]
> [ +0,000001] Call Trace:
> [ +0,000002] show_stack+0x52/0x58
> [ +0,000002] dump_stack+0x70/0x8b
> [ +0,000007] ? iwl_trans_pcie_grab_nic_access+0x1bd/0x1f0 [iwlwifi]
> [ +0,000002] __warn.cold+0x24/0x77 [ +0,000007] ?
> iwl_trans_pcie_grab_nic_access+0x1bd/0x1f0 [iwlwifi] [ +0,000002]
> report_bug+0xa1/0xc0 [ +0,000015] handle_bug+0x3e/0xa0 [ +0,000001]
> exc_invalid_op+0x19/0x70 [ +0,000002] asm_exc_invalid_op+0x12/0x20 [
> +0,000007] RIP: 0010:iwl_trans_pcie_grab_nic_access+0x1bd/0x1f0
> [iwlwifi] [ +0,000001] Code: 85 c5 49 8d 57 08 bf 00 20 00 00 e8 0d
> bf 9a c3 e9
> 35 ff ff ff 89 c6 48 c7 c7 20 ea d3 c0 c6 05 93 25 03 00 01 e8 24 25
> 4b c4 <0f> 0b e9 f0 fe ff ff 49 8b 7c 24 38 48 c7 c1 88 ea d3 c0 31 d2
> 31
> [ +0,000001] RSP: 0018:ffffaf8f00e1fb80 EFLAGS: 00010082 [
> +0,000002] RAX: 0000000000000000 RBX: ffffaf8f00e1fbb8 RCX:
> ffff9b8e96b18988 [ +0,000000] RDX: 00000000ffffffd8 RSI:
> 0000000000000027 RDI: ffff9b8e96b18980 [ +0,000001] RBP:
> ffffaf8f00e1fba8 R08: 0000000000000000 R09: ffffaf8f00e1f970 [
> +0,000001] R10: ffffaf8f00e1f968 R11: ffffffff86353c28 R12:
> ffff9b8d895f8018 [ +0,000001] R13: 0000000000000000 R14:
> ffff9b8d895fa6f4 R15: 00000000000003d8 [ +0,000007]
> iwl_set_bits_prph+0x3a/0x90 [iwlwifi] [ +0,000008]
> iwl_fw_dbg_stop_restart_recording.part.0+0x234/0x260 [iwlwifi] [
> +0,000002] ? __cancel_work_timer+0x109/0x190 [ +0,000016]
> iwl_fw_dbg_stop_sync+0x46/0x50 [iwlwifi] [ +0,000006]
> __iwl_mvm_mac_stop+0x8c/0x170 [iwlmvm] [ +0,000004]
> iwl_mvm_mac_stop+0x77/0x90 [iwlmvm] [ +0,000012] drv_stop+0x32/0x110
> [mac80211] [ +0,000015] ieee80211_stop_device+0x46/0x50 [mac80211] [
> +0,000012] ieee80211_do_stop+0x551/0x860 [mac80211] [ +0,000002] ?
> _raw_spin_unlock_bh+0x1e/0x20 [ +0,000013] ieee80211_stop+0x1a/0x20
> [mac80211] [ +0,000002] __dev_close_many+0x9d/0x110 [ +0,000001]
> dev_close_many+0x85/0x130 [ +0,000002] dev_close+0x5e/0x80 [
> +0,000011] cfg80211_shutdown_all_interfaces+0x77/0xd0 [cfg80211] [
> +0,000010] cfg80211_rfkill_block_work+0x1e/0x30 [cfg80211] [
> +0,000002] process_one_work+0x1e3/0x3b0 [ +0,000002]
> worker_thread+0x4d/0x350 [ +0,000002] ? rescuer_thread+0x390/0x390 [
> +0,000001] kthread+0x145/0x170 [ +0,000002] ?
> __kthread_bind_mask+0x70/0x70 [ +0,000001] ret_from_fork+0x22/0x30 [
> +0,000002] ---[ end trace db8dbd78d4c6889a ]--- [ +0,000003] iwlwifi
> 0000:02:00.0: iwlwifi transaction failed, dumping registers [
> +0,000003] iwlwifi 0000:02:00.0: iwlwifi device config registers:
> [ +0,000241] iwlwifi 0000:02:00.0: 00000000: 08b18086 00100406
> 02800073 00000010 f7d00004 00000000 00000000 00000000 [ +0,000002]
> iwlwifi 0000:02:00.0: 00000020: 00000000 00000000
> 00000000 44708086 00000000 000000c8 00000000 0000010a [ +0,000002]
> iwlwifi 0000:02:00.0: 00000040: 00020010 10008ec0
> 00100c00 0006ec11 10110042 00000000 00000000 00000000 [ +0,000002]
> iwlwifi 0000:02:00.0: 00000060: 00000000 00080812
> 00000405 00000000 00010001 00000000 00000000 00000000 [ +0,000002]
> iwlwifi 0000:02:00.0: 00000080: 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000 [ +0,000001]
> iwlwifi 0000:02:00.0: 000000a0: 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000 [ +0,000002]
> iwlwifi 0000:02:00.0: 000000c0: 00000000 00000000
> c823d001 0d000000 00814005 fee00398 00000000 00000000 [ +0,000002]
> iwlwifi 0000:02:00.0: 000000e0: 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000 [ +0,000002]
> iwlwifi 0000:02:00.0: 00000100: 14010001 00000000
> 00000000 00462031 00000000 00002000 00000000 00000000 [ +0,000001]
> iwlwifi 0000:02:00.0: 00000120: 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000 [ +0,000002]
> iwlwifi 0000:02:00.0: 00000140: 14c10003 ff680263 4851b7ff 15410018
> 10031003 0001000b 0141cafe 00f01e1f [ +0,000002] iwlwifi
> 0000:02:00.0: iwlwifi device memory mapped registers:
> [ +0,000094] iwlwifi 0000:02:00.0: 00000000: 40000000 80000000
> 00000080 00000000 00000000 00000000 00000000 00000000 [ +0,000001]
> iwlwifi 0000:02:00.0: 00000020: 00000001 000003d8
> 00000144 00000000 80000000 803a0000 80008040 00080042 [ +0,000053]
> iwlwifi 0000:02:00.0: iwlwifi device AER capability structure:
> [ +0,000022] iwlwifi 0000:02:00.0: 00000000: 14010001 00000000
> 00000000 00462031 00000000 00002000 00000000 00000000 [ +0,000002]
> iwlwifi 0000:02:00.0: 00000020: 00000000 00000000 00000000 [
> +0,000001] iwlwifi 0000:02:00.0: iwlwifi parent port (0000:00:1c.3)
> config registers:
> [ +0,000094] iwlwifi 0000:00:1c.3: 00000000: 9c168086 00100407
> 060400e4 00810010 00000000 00000000 00020200 000000f0 [ +0,000002]
> iwlwifi 0000:00:1c.3: 00000020: f7d0f7d0 0001fff1
> 00000000 00000000 00000000 00000040 00000000 0012040a [ +0,000002]
> iwlwifi 0000:00:1c.3: 00000040: 01428010 00008000
> 00100000 04323c12 70110042 001cb200 01400000 00000000 [ +0,000002]
> iwlwifi 0000:00:1c.3: 00000060: 00000000 00000817
> 00000400 00000000 00010002 00000000 00000000 00000000 [ +0,000002]
> iwlwifi 0000:00:1c.3: 00000080: 00019005 fee00258
> 00000000 00000000 0000a00d 05ca1028 00000000 00000000 [ +0,000001]
> iwlwifi 0000:00:1c.3: 000000a0: c8030001 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000 [ +0,000002]
> iwlwifi 0000:00:1c.3: 000000c0: 00000000 00000000
> 00000000 00000000 01000000 00001842 8b118008 00000000 [ +0,000002]
> iwlwifi 0000:00:1c.3: 000000e0: 00400300 8c548c54
> 00000015 00000000 00000050 0c000040 08050fb1 00000004 [ +0,000001]
> iwlwifi 0000:00:1c.3: 00000100: 20000000 00000000
> 00000000 00060011 00000000 00002000 00000000 00000000 [ +0,000002]
> iwlwifi 0000:00:1c.3: 00000120: 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000 [ +0,000002]
> iwlwifi 0000:00:1c.3: 00000140: 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000 [ +0,000001]
> iwlwifi 0000:00:1c.3: 00000160: 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000 [ +0,000002]
> iwlwifi 0000:00:1c.3: 00000180: 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000 [ +0,000001]
> iwlwifi 0000:00:1c.3: 000001a0: 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000 [ +0,000002]
> iwlwifi 0000:00:1c.3: 000001c0: 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000 [ +0,000002]
> iwlwifi 0000:00:1c.3: 000001e0: 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000 [ +0,000001]
> iwlwifi 0000:00:1c.3: 00000200: 0001001e 0028281f 40a0281f [
> +2,028589] iwlwifi 0000:02:00.0: RF_KILL bit toggled to enable radio.
> [ +0,000004] iwlwifi 0000:02:00.0: reporting RF_KILL (radio enabled)
> [Nov19 17:24] wlp2s0: authenticate with 68:b6:fc:27:79:c8 [
> +0,002785] wlp2s0: send auth to 68:b6:fc:27:79:c8 (try 1/3) [
> +0,002128] wlp2s0: authenticated [ +0,000481] wlp2s0: associate with
> 68:b6:fc:27:79:c8 (try 1/3) [ +0,015219] wlp2s0: RX AssocResp from
> 68:b6:fc:27:79:c8 (capab=0xc11
> status=0 aid=7)
> [ +0,001892] wlp2s0: associated
> [ +0,227651] IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes
> ready
>
>
^ permalink raw reply
* Re: [PATCH 000/141] Fix fall-through warnings for Clang
From: Kees Cook @ 2020-11-24 21:25 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Jakub Kicinski, Gustavo A. R. Silva, LKML, alsa-devel,
amd-gfx list, bridge, ceph-devel, cluster-devel, coreteam, devel,
dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
linux1394-devel, linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
linux-atm-general, linux-block, linux-can, linux-cifs,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
linux-decnet-user, linux-ext4, linux-fbdev, linux-geode,
linux-gpio, linux-hams, linux-hwmon, linux-i3c, linux-ide,
linux-iio, linux-input, linux-integrity, linux-mediatek,
linux-media, linux-mmc, Linux Memory Management List, linux-mtd,
linux-nfs, linux-rdma, Linux-Renesas, linux-scsi, linux-sctp,
linux-security-module, linux-stm32, linux-usb, linux-watchdog,
linux-wireless, Network Development, netfilter-devel, nouveau,
op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
samba-technical, selinux, target-devel, tipc-discussion,
usb-storage, virtualization, wcn36xx,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), xen-devel,
linux-hardening, Nathan Chancellor, Miguel Ojeda, Joe Perches
In-Reply-To: <CAKwvOdntVfXj2WRR5n6Kw7BfG7FdKpTeHeh5nPu5AzwVMhOHTg@mail.gmail.com>
On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
>
> So looks like the bulk of these are:
> switch (x) {
> case 0:
> ++x;
> default:
> break;
> }
>
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895
I still think this isn't right -- it's a case statement that runs off
the end without an explicit flow control determination. I think Clang is
right to warn for these, and GCC should also warn.
--
Kees Cook
^ permalink raw reply
* Re: [PATCH][next] net: hns3: fix spelling mistake "memroy" -> "memory"
From: patchwork-bot+netdevbpf @ 2020-11-24 21:30 UTC (permalink / raw)
To: Colin King
Cc: yisen.zhuang, salil.mehta, davem, kuba, tanhuazhong, netdev,
kernel-janitors, linux-kernel
In-Reply-To: <20201123103452.197708-1-colin.king@canonical.com>
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Mon, 23 Nov 2020 10:34:52 +0000 you wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> There are spelling mistakes in two dev_err messages. Fix them.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 2 +-
> drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Here is the summary with links:
- [next] net: hns3: fix spelling mistake "memroy" -> "memory"
https://git.kernel.org/netdev/net-next/c/be419fcacf25
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
From: Kees Cook @ 2020-11-24 21:32 UTC (permalink / raw)
To: James Bottomley
Cc: Gustavo A. R. Silva, Joe Perches, Jakub Kicinski, alsa-devel,
linux-atm-general, reiserfs-devel, linux-iio, linux-wireless,
linux-fbdev, dri-devel, linux-kernel, Nathan Chancellor,
linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
usb-storage, drbd-dev, devel, linux-cifs, rds-devel,
Nick Desaulniers, linux-scsi, linux-rdma, oss-drivers, bridge,
linux-security-module, amd-gfx, linux-stm32, cluster-devel,
linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
tipc-discussion, linux-ext4, linux-media, linux-watchdog, selinux,
linux-arm-msm, intel-gfx, linux-geode, linux-can, linux-block,
linux-gpio, op-tee, linux-mediatek, xen-devel, nouveau,
linux-hams, ceph-devel, virtualization, linux-arm-kernel,
linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev,
linux-decnet-user, linux-mmc, linux-renesas-soc, linux-sctp,
linux-usb, netfilter-devel, linux-crypto, patches,
linux-integrity, target-devel, linux-hardening, Jonathan Cameron,
Greg KH
In-Reply-To: <8f5611bb015e044fa1c0a48147293923c2d904e4.camel@HansenPartnership.com>
On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> Really, no ... something which produces no improvement has no value at
> all ... we really shouldn't be wasting maintainer time with it because
> it has a cost to merge. I'm not sure we understand where the balance
> lies in value vs cost to merge but I am confident in the zero value
> case.
What? We can't measure how many future bugs aren't introduced because the
kernel requires explicit case flow-control statements for all new code.
We already enable -Wimplicit-fallthrough globally, so that's not the
discussion. The issue is that Clang is (correctly) even more strict
than GCC for this, so these are the remaining ones to fix for full Clang
coverage too.
People have spent more time debating this already than it would have
taken to apply the patches. :)
This is about robustness and language wrangling. It's a big code-base,
and this is the price of our managing technical debt for permanent
robustness improvements. (The numbers I ran from Gustavo's earlier
patches were that about 10% of the places adjusted were identified as
legitimate bugs being fixed. This final series may be lower, but there
are still bugs being found from it -- we need to finish this and shut
the door on it for good.)
--
Kees Cook
^ permalink raw reply
* Re: [PATCH] net/ethernet/freescale: Fix incorrect IS_ERR_VALUE macro usages
From: Li Yang @ 2020-11-24 21:44 UTC (permalink / raw)
To: Wei Li, Zhao Qiang
Cc: David S. Miller, Jakub Kicinski, Paul Gortmaker, Kumar Gala,
Timur Tabi, Netdev, linuxppc-dev, lkml, guohanjun
In-Reply-To: <20201124062234.678-1-liwei391@huawei.com>
On Tue, Nov 24, 2020 at 12:24 AM Wei Li <liwei391@huawei.com> wrote:
>
> IS_ERR_VALUE macro should be used only with unsigned long type.
> Especially it works incorrectly with unsigned shorter types on
> 64bit machines.
This is truly a problem for the driver to run on 64-bit architectures.
But from an earlier discussion
https://patchwork.kernel.org/project/linux-kbuild/patch/1464384685-347275-1-git-send-email-arnd@arndb.de/,
the preferred solution would be removing the IS_ERR_VALUE() usage or
make the values to be unsigned long.
It looks like we are having a bigger problem with the 64-bit support
for the driver that the offset variables can also be real pointers
which cannot be held with 32-bit data types(when uf_info->bd_mem_part
== MEM_PART_SYSTEM). So actually we have to change these offsets to
unsigned long, otherwise we are having more serious issues on 64-bit
systems. Are you willing to make such changes or you want us to deal
with it?
Regards,
Leo
>
> Fixes: 4c35630ccda5 ("[POWERPC] Change rheap functions to use ulongs instead of pointers")
> Signed-off-by: Wei Li <liwei391@huawei.com>
> ---
> drivers/net/ethernet/freescale/ucc_geth.c | 30 +++++++++++------------
> 1 file changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
> index 714b501be7d0..8656d9be256a 100644
> --- a/drivers/net/ethernet/freescale/ucc_geth.c
> +++ b/drivers/net/ethernet/freescale/ucc_geth.c
> @@ -286,7 +286,7 @@ static int fill_init_enet_entries(struct ucc_geth_private *ugeth,
> else {
> init_enet_offset =
> qe_muram_alloc(thread_size, thread_alignment);
> - if (IS_ERR_VALUE(init_enet_offset)) {
> + if (IS_ERR_VALUE((unsigned long)(int)init_enet_offset)) {
> if (netif_msg_ifup(ugeth))
> pr_err("Can not allocate DPRAM memory\n");
> qe_put_snum((u8) snum);
> @@ -2223,7 +2223,7 @@ static int ucc_geth_alloc_tx(struct ucc_geth_private *ugeth)
> ugeth->tx_bd_ring_offset[j] =
> qe_muram_alloc(length,
> UCC_GETH_TX_BD_RING_ALIGNMENT);
> - if (!IS_ERR_VALUE(ugeth->tx_bd_ring_offset[j]))
> + if (!IS_ERR_VALUE((unsigned long)(int)ugeth->tx_bd_ring_offset[j]))
> ugeth->p_tx_bd_ring[j] =
> (u8 __iomem *) qe_muram_addr(ugeth->
> tx_bd_ring_offset[j]);
> @@ -2300,7 +2300,7 @@ static int ucc_geth_alloc_rx(struct ucc_geth_private *ugeth)
> ugeth->rx_bd_ring_offset[j] =
> qe_muram_alloc(length,
> UCC_GETH_RX_BD_RING_ALIGNMENT);
> - if (!IS_ERR_VALUE(ugeth->rx_bd_ring_offset[j]))
> + if (!IS_ERR_VALUE((unsigned long)(int)ugeth->rx_bd_ring_offset[j]))
> ugeth->p_rx_bd_ring[j] =
> (u8 __iomem *) qe_muram_addr(ugeth->
> rx_bd_ring_offset[j]);
> @@ -2510,7 +2510,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
> ugeth->tx_glbl_pram_offset =
> qe_muram_alloc(sizeof(struct ucc_geth_tx_global_pram),
> UCC_GETH_TX_GLOBAL_PRAM_ALIGNMENT);
> - if (IS_ERR_VALUE(ugeth->tx_glbl_pram_offset)) {
> + if (IS_ERR_VALUE((unsigned long)(int)ugeth->tx_glbl_pram_offset)) {
> if (netif_msg_ifup(ugeth))
> pr_err("Can not allocate DPRAM memory for p_tx_glbl_pram\n");
> return -ENOMEM;
> @@ -2530,7 +2530,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
> sizeof(struct ucc_geth_thread_data_tx) +
> 32 * (numThreadsTxNumerical == 1),
> UCC_GETH_THREAD_DATA_ALIGNMENT);
> - if (IS_ERR_VALUE(ugeth->thread_dat_tx_offset)) {
> + if (IS_ERR_VALUE((unsigned long)(int)ugeth->thread_dat_tx_offset)) {
> if (netif_msg_ifup(ugeth))
> pr_err("Can not allocate DPRAM memory for p_thread_data_tx\n");
> return -ENOMEM;
> @@ -2557,7 +2557,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
> qe_muram_alloc(ug_info->numQueuesTx *
> sizeof(struct ucc_geth_send_queue_qd),
> UCC_GETH_SEND_QUEUE_QUEUE_DESCRIPTOR_ALIGNMENT);
> - if (IS_ERR_VALUE(ugeth->send_q_mem_reg_offset)) {
> + if (IS_ERR_VALUE((unsigned long)(int)ugeth->send_q_mem_reg_offset)) {
> if (netif_msg_ifup(ugeth))
> pr_err("Can not allocate DPRAM memory for p_send_q_mem_reg\n");
> return -ENOMEM;
> @@ -2597,7 +2597,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
> ugeth->scheduler_offset =
> qe_muram_alloc(sizeof(struct ucc_geth_scheduler),
> UCC_GETH_SCHEDULER_ALIGNMENT);
> - if (IS_ERR_VALUE(ugeth->scheduler_offset)) {
> + if (IS_ERR_VALUE((unsigned long)(int)ugeth->scheduler_offset)) {
> if (netif_msg_ifup(ugeth))
> pr_err("Can not allocate DPRAM memory for p_scheduler\n");
> return -ENOMEM;
> @@ -2644,7 +2644,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
> qe_muram_alloc(sizeof
> (struct ucc_geth_tx_firmware_statistics_pram),
> UCC_GETH_TX_STATISTICS_ALIGNMENT);
> - if (IS_ERR_VALUE(ugeth->tx_fw_statistics_pram_offset)) {
> + if (IS_ERR_VALUE((unsigned long)(int)ugeth->tx_fw_statistics_pram_offset)) {
> if (netif_msg_ifup(ugeth))
> pr_err("Can not allocate DPRAM memory for p_tx_fw_statistics_pram\n");
> return -ENOMEM;
> @@ -2681,7 +2681,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
> ugeth->rx_glbl_pram_offset =
> qe_muram_alloc(sizeof(struct ucc_geth_rx_global_pram),
> UCC_GETH_RX_GLOBAL_PRAM_ALIGNMENT);
> - if (IS_ERR_VALUE(ugeth->rx_glbl_pram_offset)) {
> + if (IS_ERR_VALUE((unsigned long)(int)ugeth->rx_glbl_pram_offset)) {
> if (netif_msg_ifup(ugeth))
> pr_err("Can not allocate DPRAM memory for p_rx_glbl_pram\n");
> return -ENOMEM;
> @@ -2700,7 +2700,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
> qe_muram_alloc(numThreadsRxNumerical *
> sizeof(struct ucc_geth_thread_data_rx),
> UCC_GETH_THREAD_DATA_ALIGNMENT);
> - if (IS_ERR_VALUE(ugeth->thread_dat_rx_offset)) {
> + if (IS_ERR_VALUE((unsigned long)(int)ugeth->thread_dat_rx_offset)) {
> if (netif_msg_ifup(ugeth))
> pr_err("Can not allocate DPRAM memory for p_thread_data_rx\n");
> return -ENOMEM;
> @@ -2721,7 +2721,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
> qe_muram_alloc(sizeof
> (struct ucc_geth_rx_firmware_statistics_pram),
> UCC_GETH_RX_STATISTICS_ALIGNMENT);
> - if (IS_ERR_VALUE(ugeth->rx_fw_statistics_pram_offset)) {
> + if (IS_ERR_VALUE((unsigned long)(int)ugeth->rx_fw_statistics_pram_offset)) {
> if (netif_msg_ifup(ugeth))
> pr_err("Can not allocate DPRAM memory for p_rx_fw_statistics_pram\n");
> return -ENOMEM;
> @@ -2741,7 +2741,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
> qe_muram_alloc(ug_info->numQueuesRx *
> sizeof(struct ucc_geth_rx_interrupt_coalescing_entry)
> + 4, UCC_GETH_RX_INTERRUPT_COALESCING_ALIGNMENT);
> - if (IS_ERR_VALUE(ugeth->rx_irq_coalescing_tbl_offset)) {
> + if (IS_ERR_VALUE((unsigned long)(int)ugeth->rx_irq_coalescing_tbl_offset)) {
> if (netif_msg_ifup(ugeth))
> pr_err("Can not allocate DPRAM memory for p_rx_irq_coalescing_tbl\n");
> return -ENOMEM;
> @@ -2807,7 +2807,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
> (sizeof(struct ucc_geth_rx_bd_queues_entry) +
> sizeof(struct ucc_geth_rx_prefetched_bds)),
> UCC_GETH_RX_BD_QUEUES_ALIGNMENT);
> - if (IS_ERR_VALUE(ugeth->rx_bd_qs_tbl_offset)) {
> + if (IS_ERR_VALUE((unsigned long)(int)ugeth->rx_bd_qs_tbl_offset)) {
> if (netif_msg_ifup(ugeth))
> pr_err("Can not allocate DPRAM memory for p_rx_bd_qs_tbl\n");
> return -ENOMEM;
> @@ -2892,7 +2892,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
> ugeth->exf_glbl_param_offset =
> qe_muram_alloc(sizeof(struct ucc_geth_exf_global_pram),
> UCC_GETH_RX_EXTENDED_FILTERING_GLOBAL_PARAMETERS_ALIGNMENT);
> - if (IS_ERR_VALUE(ugeth->exf_glbl_param_offset)) {
> + if (IS_ERR_VALUE((unsigned long)(int)ugeth->exf_glbl_param_offset)) {
> if (netif_msg_ifup(ugeth))
> pr_err("Can not allocate DPRAM memory for p_exf_glbl_param\n");
> return -ENOMEM;
> @@ -3026,7 +3026,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
>
> /* Allocate InitEnet command parameter structure */
> init_enet_pram_offset = qe_muram_alloc(sizeof(struct ucc_geth_init_pram), 4);
> - if (IS_ERR_VALUE(init_enet_pram_offset)) {
> + if (IS_ERR_VALUE((unsigned long)(int)init_enet_pram_offset)) {
> if (netif_msg_ifup(ugeth))
> pr_err("Can not allocate DPRAM memory for p_init_enet_pram\n");
> return -ENOMEM;
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH] entry: Fix boot for !CONFIG_GENERIC_ENTRY
From: Kees Cook @ 2020-11-24 21:45 UTC (permalink / raw)
To: Gabriel Krisman Bertazi
Cc: Jann Horn, Arnd Bergmann, Andy Lutomirski, Thomas Gleixner,
Naresh Kamboju, open list, Netdev, bpf, lkft-triage, Linux ARM,
Daniel Borkmann, Andrii Nakryiko, Song Liu, Yonghong Song,
Andy Lutomirski, Sumit Semwal, Arnd Bergmann, YiFei Zhu
In-Reply-To: <87a6v8qd9p.fsf_-_@collabora.com>
On Mon, Nov 23, 2020 at 10:54:58AM -0500, Gabriel Krisman Bertazi wrote:
> Gabriel Krisman Bertazi <krisman@collabora.com> writes:
>
> > Jann Horn <jannh@google.com> writes:
> >> As part of fixing this, it might be a good idea to put "enum
> >> syscall_work_bit" behind a "#ifdef CONFIG_GENERIC_ENTRY" to avoid
> >> future accidents like this?
> >
> > Hi Jan, Arnd,
> >
> > That is correct. This is a copy pasta mistake. My apologies. I didn't
> > have a !GENERIC_ENTRY device to test, but just the ifdef would have
> > caught it.
>
> I have patched it as suggested. Tested on qemu for arm32 and on bare
> metal for x86-64.
>
> Once again, my apologies for the mistake.
>
> -- >8 --
> Subject: [PATCH] entry: Fix boot for !CONFIG_GENERIC_ENTRY
>
> A copy-pasta mistake tries to set SYSCALL_WORK flags instead of TIF
> flags for !CONFIG_GENERIC_ENTRY. Also, add safeguards to catch this at
> compilation time.
>
> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> Suggested-by: Jann Horn <jannh@google.com>
> Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
Thanks for getting this fixed!
3136b93c3fb2 ("entry: Expose helpers to migrate TIF to SYSCALL_WORK flags")
Reviewed-by: Kees Cook <keescook@chromium.org>
--
Kees Cook
^ permalink raw reply
* Re: [PATCH bpf v2] net, xsk: Avoid taking multiple skbuff references
From: Daniel Borkmann @ 2020-11-24 21:50 UTC (permalink / raw)
To: Björn Töpel, ast, netdev, bpf
Cc: Björn Töpel, jonathan.lemon, yhs, weqaar.janjua,
magnus.karlsson, weqaar.a.janjua
In-Reply-To: <20201123175600.146255-1-bjorn.topel@gmail.com>
On 11/23/20 6:56 PM, Björn Töpel wrote:
> From: Björn Töpel <bjorn.topel@intel.com>
>
> Commit 642e450b6b59 ("xsk: Do not discard packet when NETDEV_TX_BUSY")
> addressed the problem that packets were discarded from the Tx AF_XDP
> ring, when the driver returned NETDEV_TX_BUSY. Part of the fix was
> bumping the skbuff reference count, so that the buffer would not be
> freed by dev_direct_xmit(). A reference count larger than one means
> that the skbuff is "shared", which is not the case.
>
> If the "shared" skbuff is sent to the generic XDP receive path,
> netif_receive_generic_xdp(), and pskb_expand_head() is entered the
> BUG_ON(skb_shared(skb)) will trigger.
>
> This patch adds a variant to dev_direct_xmit(), __dev_direct_xmit(),
> where a user can select the skbuff free policy. This allows AF_XDP to
> avoid bumping the reference count, but still keep the NETDEV_TX_BUSY
> behavior.
>
> Reported-by: Yonghong Song <yhs@fb.com>
> Fixes: 642e450b6b59 ("xsk: Do not discard packet when NETDEV_TX_BUSY")
> Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
Yeah looks better! Applied, thanks!
^ permalink raw reply
* [PATCH net-next v2] mptcp: be careful on MPTCP-level ack.
From: Paolo Abeni @ 2020-11-24 21:51 UTC (permalink / raw)
To: netdev; +Cc: Jakub Kicinski, mptcp, Eric Dumazet
We can enter the main mptcp_recvmsg() loop even when
no subflows are connected. As note by Eric, that would
result in a divide by zero oops on ack generation.
Address the issue by checking the subflow status before
sending the ack.
Additionally protect mptcp_recvmsg() against invocation
with weird socket states.
v1 -> v2:
- removed unneeded inline keyword - Jakub
Reported-and-suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
Fixes: ea4ca586b16f ("mptcp: refine MPTCP-level ack scheduling")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
net/mptcp/protocol.c | 67 ++++++++++++++++++++++++++++++++------------
1 file changed, 49 insertions(+), 18 deletions(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 4b7794835fea..371a5e691a9a 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -419,31 +419,57 @@ static bool mptcp_subflow_active(struct mptcp_subflow_context *subflow)
return ((1 << ssk->sk_state) & (TCPF_ESTABLISHED | TCPF_CLOSE_WAIT));
}
-static void mptcp_send_ack(struct mptcp_sock *msk, bool force)
+static bool tcp_can_send_ack(const struct sock *ssk)
+{
+ return !((1 << inet_sk_state_load(ssk)) &
+ (TCPF_SYN_SENT | TCPF_SYN_RECV | TCPF_TIME_WAIT | TCPF_CLOSE));
+}
+
+static void mptcp_send_ack(struct mptcp_sock *msk)
{
struct mptcp_subflow_context *subflow;
- struct sock *pick = NULL;
mptcp_for_each_subflow(msk, subflow) {
struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
- if (force) {
- lock_sock(ssk);
+ lock_sock(ssk);
+ if (tcp_can_send_ack(ssk))
tcp_send_ack(ssk);
- release_sock(ssk);
- continue;
- }
-
- /* if the hintes ssk is still active, use it */
- pick = ssk;
- if (ssk == msk->ack_hint)
- break;
+ release_sock(ssk);
}
- if (!force && pick) {
- lock_sock(pick);
- tcp_cleanup_rbuf(pick, 1);
- release_sock(pick);
+}
+
+static bool mptcp_subflow_cleanup_rbuf(struct sock *ssk)
+{
+ int ret;
+
+ lock_sock(ssk);
+ ret = tcp_can_send_ack(ssk);
+ if (ret)
+ tcp_cleanup_rbuf(ssk, 1);
+ release_sock(ssk);
+ return ret;
+}
+
+static void mptcp_cleanup_rbuf(struct mptcp_sock *msk)
+{
+ struct mptcp_subflow_context *subflow;
+
+ /* if the hinted ssk is still active, try to use it */
+ if (likely(msk->ack_hint)) {
+ mptcp_for_each_subflow(msk, subflow) {
+ struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
+
+ if (msk->ack_hint == ssk &&
+ mptcp_subflow_cleanup_rbuf(ssk))
+ return;
+ }
}
+
+ /* otherwise pick the first active subflow */
+ mptcp_for_each_subflow(msk, subflow)
+ if (mptcp_subflow_cleanup_rbuf(mptcp_subflow_tcp_sock(subflow)))
+ return;
}
static bool mptcp_check_data_fin(struct sock *sk)
@@ -494,7 +520,7 @@ static bool mptcp_check_data_fin(struct sock *sk)
ret = true;
mptcp_set_timeout(sk, NULL);
- mptcp_send_ack(msk, true);
+ mptcp_send_ack(msk);
mptcp_close_wake_up(sk);
}
return ret;
@@ -1579,6 +1605,11 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
return -EOPNOTSUPP;
lock_sock(sk);
+ if (unlikely(sk->sk_state == TCP_LISTEN)) {
+ copied = -ENOTCONN;
+ goto out_err;
+ }
+
timeo = sock_rcvtimeo(sk, nonblock);
len = min_t(size_t, len, INT_MAX);
@@ -1604,7 +1635,7 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
/* be sure to advertise window change */
old_space = READ_ONCE(msk->old_wspace);
if ((tcp_space(sk) - old_space) >= old_space)
- mptcp_send_ack(msk, false);
+ mptcp_cleanup_rbuf(msk);
/* only the master socket status is relevant here. The exit
* conditions mirror closely tcp_recvmsg()
--
2.26.2
^ permalink raw reply related
* Re: [PATCH][V2] libbpf: add support for canceling cached_cons advance
From: Daniel Borkmann @ 2020-11-24 21:58 UTC (permalink / raw)
To: Magnus Karlsson, Li RongQing; +Cc: Network Development, bpf, Karlsson, Magnus
In-Reply-To: <CAJ8uoz0WNm6no8NRehgUH5RiGgvjJkKeD-Yyoah8xJerpLhgdg@mail.gmail.com>
On 11/24/20 9:12 AM, Magnus Karlsson wrote:
> On Tue, Nov 24, 2020 at 8:33 AM Li RongQing <lirongqing@baidu.com> wrote:
>>
>> Add a new function for returning descriptors the user received
>> after an xsk_ring_cons__peek call. After the application has
>> gotten a number of descriptors from a ring, it might not be able
>> to or want to process them all for various reasons. Therefore,
>> it would be useful to have an interface for returning or
>> cancelling a number of them so that they are returned to the ring.
>>
>> This patch adds a new function called xsk_ring_cons__cancel that
>> performs this operation on nb descriptors counted from the end of
>> the batch of descriptors that was received through the peek call.
>>
>> Signed-off-by: Li RongQing <lirongqing@baidu.com>
>> [ Magnus Karlsson: rewrote changelog ]
>> Cc: Magnus Karlsson <magnus.karlsson@intel.com>
>> ---
>> diff with v1: fix the building, and rewrote changelog
>>
>> tools/lib/bpf/xsk.h | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/tools/lib/bpf/xsk.h b/tools/lib/bpf/xsk.h
>> index 1069c46364ff..1719a327e5f9 100644
>> --- a/tools/lib/bpf/xsk.h
>> +++ b/tools/lib/bpf/xsk.h
>> @@ -153,6 +153,12 @@ static inline size_t xsk_ring_cons__peek(struct xsk_ring_cons *cons,
>> return entries;
>> }
>>
>> +static inline void xsk_ring_cons__cancel(struct xsk_ring_cons *cons,
>> + size_t nb)
>> +{
>> + cons->cached_cons -= nb;
>> +}
>> +
>> static inline void xsk_ring_cons__release(struct xsk_ring_cons *cons, size_t nb)
>> {
>> /* Make sure data has been read before indicating we are done
>> --
>> 2.17.3
>
> Thank you RongQing.
>
> Acked-by: Magnus Karlsson <magnus.karlsson@intel.com>
@Magnus: shouldn't the xsk_ring_cons__cancel() nb type be '__u32 nb' instead?
Thanks,
Daniel
^ permalink raw reply
* [PATCH v2] net: phy: realtek: read actual speed on rtl8211f to detect downshift
From: Antonio Borneo @ 2020-11-24 21:59 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Jakub Kicinski, netdev, Yonglong Liu, Willy Liu
Cc: Antonio Borneo, linuxarm, Salil Mehta, linux-stm32, linux-kernel
In-Reply-To: <20201124143848.874894-1-antonio.borneo@st.com>
The rtl8211f supports downshift and before commit 5502b218e001
("net: phy: use phy_resolve_aneg_linkmode in genphy_read_status")
the read-back of register MII_CTRL1000 was used to detect the
negotiated link speed.
The code added in commit d445dff2df60 ("net: phy: realtek: read
actual speed to detect downshift") is working fine also for this
phy and it's trivial re-using it to restore the downshift
detection on rtl8211f.
Add the phy specific read_status() pointing to the existing
function rtlgen_read_status().
Signed-off-by: Antonio Borneo <antonio.borneo@st.com>
Link: https://lore.kernel.org/r/478f871a-583d-01f1-9cc5-2eea56d8c2a7@huawei.com
---
To: Andrew Lunn <andrew@lunn.ch>
To: Heiner Kallweit <hkallweit1@gmail.com>
To: Russell King <linux@armlinux.org.uk>
To: "David S. Miller" <davem@davemloft.net>
To: Jakub Kicinski <kuba@kernel.org>
To: netdev@vger.kernel.org
To: Yonglong Liu <liuyonglong@huawei.com>
To: Willy Liu <willy.liu@realtek.com>
Cc: linuxarm@huawei.com
Cc: Salil Mehta <salil.mehta@huawei.com>
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-kernel@vger.kernel.org
In-Reply-To: <20201124143848.874894-1-antonio.borneo@st.com>
V1 => V2
move from a generic implementation affecting every phy
to a rtl8211f specific implementation
---
drivers/net/phy/realtek.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 575580d3ffe0..8ff8a4edc173 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -621,6 +621,7 @@ static struct phy_driver realtek_drvs[] = {
PHY_ID_MATCH_EXACT(0x001cc916),
.name = "RTL8211F Gigabit Ethernet",
.config_init = &rtl8211f_config_init,
+ .read_status = rtlgen_read_status,
.ack_interrupt = &rtl8211f_ack_interrupt,
.config_intr = &rtl8211f_config_intr,
.suspend = genphy_suspend,
base-commit: 9bd2702d292cb7b565b09e949d30288ab7a26d51
--
2.29.2
^ permalink raw reply related
* [PATCH v2 net] enetc: Let the hardware auto-advance the taprio base-time of 0
From: Vladimir Oltean @ 2020-11-24 22:00 UTC (permalink / raw)
To: Jakub Kicinski, netdev, Po Liu, Claudiu Manoil; +Cc: Vinicius Costa Gomes
The tc-taprio base time indicates the beginning of the tc-taprio
schedule, which is cyclic by definition (where the length of the cycle
in nanoseconds is called the cycle time). The base time is a 64-bit PTP
time in the TAI domain.
Logically, the base-time should be a future time. But that imposes some
restrictions to user space, which has to retrieve the current PTP time
from the NIC first, then calculate a base time that will still be larger
than the base time by the time the kernel driver programs this value
into the hardware. Actually ensuring that the programmed base time is in
the future is still a problem even if the kernel alone deals with this -
what the proposed patch does is to "reserve" 100 ms for potential
delays, but otherwise this is an unsolved problem in the general case.
Luckily, the enetc hardware already advances a base-time that is in the
past into a congruent time in the immediate future, according to the
same formula that can be found in the software implementation of taprio
(in taprio_get_start_time):
/* Schedule the start time for the beginning of the next
* cycle.
*/
n = div64_s64(ktime_sub_ns(now, base), cycle);
*start = ktime_add_ns(base, (n + 1) * cycle);
There's only one problem: the driver doesn't let the hardware do that.
It interferes with the base-time passed from user space, by special-casing
the situation when the base-time is zero, and replaces that with the
current PTP time. This changes the intended effective base-time of the
schedule, which will in the end have a different phase offset than if
the base-time of 0.000000000 was to be advanced by an integer multiple
of the cycle-time.
Fixes: 34c6adf1977b ("enetc: Configure the Time-Aware Scheduler via tc-taprio offload")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
Changes in v2:
- Now letting the hardware completely deal with advancing base times in
the past.
drivers/net/ethernet/freescale/enetc/enetc_qos.c | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_qos.c b/drivers/net/ethernet/freescale/enetc/enetc_qos.c
index aeb21dc48099..a9aee219fb58 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_qos.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_qos.c
@@ -92,18 +92,8 @@ static int enetc_setup_taprio(struct net_device *ndev,
gcl_config->atc = 0xff;
gcl_config->acl_len = cpu_to_le16(gcl_len);
- if (!admin_conf->base_time) {
- gcl_data->btl =
- cpu_to_le32(enetc_rd(&priv->si->hw, ENETC_SICTR0));
- gcl_data->bth =
- cpu_to_le32(enetc_rd(&priv->si->hw, ENETC_SICTR1));
- } else {
- gcl_data->btl =
- cpu_to_le32(lower_32_bits(admin_conf->base_time));
- gcl_data->bth =
- cpu_to_le32(upper_32_bits(admin_conf->base_time));
- }
-
+ gcl_data->btl = cpu_to_le32(lower_32_bits(admin_conf->base_time));
+ gcl_data->bth = cpu_to_le32(upper_32_bits(admin_conf->base_time));
gcl_data->ct = cpu_to_le32(admin_conf->cycle_time);
gcl_data->cte = cpu_to_le32(admin_conf->cycle_time_extension);
--
2.25.1
^ permalink raw reply related
* [PATCH v3 net] enetc: Let the hardware auto-advance the taprio base-time of 0
From: Vladimir Oltean @ 2020-11-24 22:02 UTC (permalink / raw)
To: Jakub Kicinski, netdev, Po Liu, Claudiu Manoil; +Cc: Vinicius Costa Gomes
The tc-taprio base time indicates the beginning of the tc-taprio
schedule, which is cyclic by definition (where the length of the cycle
in nanoseconds is called the cycle time). The base time is a 64-bit PTP
time in the TAI domain.
Logically, the base-time should be a future time. But that imposes some
restrictions to user space, which has to retrieve the current PTP time
from the NIC first, then calculate a base time that will still be larger
than the base time by the time the kernel driver programs this value
into the hardware. Actually ensuring that the programmed base time is in
the future is still a problem even if the kernel alone deals with this.
Luckily, the enetc hardware already advances a base-time that is in the
past into a congruent time in the immediate future, according to the
same formula that can be found in the software implementation of taprio
(in taprio_get_start_time):
/* Schedule the start time for the beginning of the next
* cycle.
*/
n = div64_s64(ktime_sub_ns(now, base), cycle);
*start = ktime_add_ns(base, (n + 1) * cycle);
There's only one problem: the driver doesn't let the hardware do that.
It interferes with the base-time passed from user space, by special-casing
the situation when the base-time is zero, and replaces that with the
current PTP time. This changes the intended effective base-time of the
schedule, which will in the end have a different phase offset than if
the base-time of 0.000000000 was to be advanced by an integer multiple
of the cycle-time.
Fixes: 34c6adf1977b ("enetc: Configure the Time-Aware Scheduler via tc-taprio offload")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
Changes in v3:
- Removed an obsolete phrase from commit message.
Changes in v2:
- Now letting the hardware completely deal with advancing base times in
the past.
drivers/net/ethernet/freescale/enetc/enetc_qos.c | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_qos.c b/drivers/net/ethernet/freescale/enetc/enetc_qos.c
index aeb21dc48099..a9aee219fb58 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_qos.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_qos.c
@@ -92,18 +92,8 @@ static int enetc_setup_taprio(struct net_device *ndev,
gcl_config->atc = 0xff;
gcl_config->acl_len = cpu_to_le16(gcl_len);
- if (!admin_conf->base_time) {
- gcl_data->btl =
- cpu_to_le32(enetc_rd(&priv->si->hw, ENETC_SICTR0));
- gcl_data->bth =
- cpu_to_le32(enetc_rd(&priv->si->hw, ENETC_SICTR1));
- } else {
- gcl_data->btl =
- cpu_to_le32(lower_32_bits(admin_conf->base_time));
- gcl_data->bth =
- cpu_to_le32(upper_32_bits(admin_conf->base_time));
- }
-
+ gcl_data->btl = cpu_to_le32(lower_32_bits(admin_conf->base_time));
+ gcl_data->bth = cpu_to_le32(upper_32_bits(admin_conf->base_time));
gcl_data->ct = cpu_to_le32(admin_conf->cycle_time);
gcl_data->cte = cpu_to_le32(admin_conf->cycle_time_extension);
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v3 1/1] xdp: remove the function xsk_map_inc
From: Daniel Borkmann @ 2020-11-24 22:11 UTC (permalink / raw)
To: Zhu Yanjun, magnus.karlsson, bjorn.topel, davem, netdev; +Cc: Zhu Yanjun
In-Reply-To: <1606143915-25335-1-git-send-email-yanjunz@nvidia.com>
On 11/23/20 4:05 PM, Zhu Yanjun wrote:
> From: Zhu Yanjun <zyjzyj2000@gmail.com>
>
> The function xsk_map_inc is a simple wrapper of bpf_map_inc and
> always returns zero. As such, replacing this function with bpf_map_inc
> and removing the test code.
>
> Signed-off-by: Zhu Yanjun <zyjzyj2000@gmail.com>
> ---
> net/xdp/xsk.c | 2 +-
> net/xdp/xsk.h | 1 -
> net/xdp/xskmap.c | 13 +------------
> 3 files changed, 2 insertions(+), 14 deletions(-)
>
> diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> index cfbec3989a76..a3c1f07d77d8 100644
> --- a/net/xdp/xsk.c
> +++ b/net/xdp/xsk.c
> @@ -548,7 +548,7 @@ static struct xsk_map *xsk_get_map_list_entry(struct xdp_sock *xs,
> node = list_first_entry_or_null(&xs->map_list, struct xsk_map_node,
> node);
> if (node) {
> - WARN_ON(xsk_map_inc(node->map));
> + bpf_map_inc(&node->map->map);
> map = node->map;
> *map_entry = node->map_entry;
> }
> diff --git a/net/xdp/xsk.h b/net/xdp/xsk.h
> index b9e896cee5bb..0aad25c0e223 100644
> --- a/net/xdp/xsk.h
> +++ b/net/xdp/xsk.h
> @@ -41,7 +41,6 @@ static inline struct xdp_sock *xdp_sk(struct sock *sk)
>
> void xsk_map_try_sock_delete(struct xsk_map *map, struct xdp_sock *xs,
> struct xdp_sock **map_entry);
> -int xsk_map_inc(struct xsk_map *map);
> void xsk_map_put(struct xsk_map *map);
> void xsk_clear_pool_at_qid(struct net_device *dev, u16 queue_id);
> int xsk_reg_pool_at_qid(struct net_device *dev, struct xsk_buff_pool *pool,
> diff --git a/net/xdp/xskmap.c b/net/xdp/xskmap.c
> index 49da2b8ace8b..6b7e9a72b101 100644
> --- a/net/xdp/xskmap.c
> +++ b/net/xdp/xskmap.c
> @@ -11,12 +11,6 @@
>
> #include "xsk.h"
>
> -int xsk_map_inc(struct xsk_map *map)
> -{
> - bpf_map_inc(&map->map);
> - return 0;
> -}
> -
> void xsk_map_put(struct xsk_map *map)
> {
So, the xsk_map_put() is defined as:
void xsk_map_put(struct xsk_map *map)
{
bpf_map_put(&map->map);
}
What is the reason to get rid of xsk_map_inc() but not xsk_map_put() wrapper?
Can't we just remove both while we're at it?
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH net-next] net: warn if gso_type isn't set for a GSO SKB
From: Jakub Kicinski @ 2020-11-24 22:11 UTC (permalink / raw)
To: Heiner Kallweit
Cc: David Miller, Eric Dumazet, netdev@vger.kernel.org,
Linux Kernel Mailing List
In-Reply-To: <97c78d21-7f0b-d843-df17-3589f224d2cf@gmail.com>
On Sat, 21 Nov 2020 00:22:20 +0100 Heiner Kallweit wrote:
> In bug report [0] a warning in r8169 driver was reported that was
> caused by an invalid GSO SKB (gso_type was 0). See [1] for a discussion
> about this issue. Still the origin of the invalid GSO SKB isn't clear.
>
> It shouldn't be a network drivers task to check for invalid GSO SKB's.
> Also, even if issue [0] can be fixed, we can't be sure that a
> similar issue doesn't pop up again at another place.
> Therefore let gso_features_check() check for such invalid GSO SKB's.
>
> [0] https://bugzilla.kernel.org/show_bug.cgi?id=209423
> [1] https://www.spinics.net/lists/netdev/msg690794.html
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH net-next 1/6] ethtool: Extend link modes settings uAPI with lanes
From: Michal Kubecek @ 2020-11-24 22:12 UTC (permalink / raw)
To: Danielle Ratson
Cc: Jiri Pirko, Andrew Lunn, Jakub Kicinski, Ido Schimmel,
netdev@vger.kernel.org, davem@davemloft.net, Jiri Pirko,
f.fainelli@gmail.com, mlxsw, Ido Schimmel,
johannes@sipsolutions.net
In-Reply-To: <DM6PR12MB45163DF0113510194127C0ABD8FC0@DM6PR12MB4516.namprd12.prod.outlook.com>
On Mon, Nov 23, 2020 at 09:47:53AM +0000, Danielle Ratson wrote:
>
>
> > -----Original Message-----
> > From: Michal Kubecek <mkubecek@suse.cz>
> > Sent: Thursday, October 22, 2020 7:28 PM
> > To: Danielle Ratson <danieller@nvidia.com>
> > Cc: Jiri Pirko <jiri@resnulli.us>; Andrew Lunn <andrew@lunn.ch>; Jakub Kicinski <kuba@kernel.org>; Ido Schimmel
> > <idosch@idosch.org>; netdev@vger.kernel.org; davem@davemloft.net; Jiri Pirko <jiri@nvidia.com>; f.fainelli@gmail.com; mlxsw
> > <mlxsw@nvidia.com>; Ido Schimmel <idosch@nvidia.com>; johannes@sipsolutions.net
> > Subject: Re: [PATCH net-next 1/6] ethtool: Extend link modes settings uAPI with lanes
> >
> > On Thu, Oct 22, 2020 at 06:15:48AM +0000, Danielle Ratson wrote:
> > > > -----Original Message-----
> > > > From: Michal Kubecek <mkubecek@suse.cz>
> > > > Sent: Wednesday, October 21, 2020 11:48 AM
> > > >
> > > > Ah, right, it does. But as you extend struct ethtool_link_ksettings
> > > > and drivers will need to be updated to provide this information,
> > > > wouldn't it be more useful to let the driver provide link mode in
> > > > use instead (and derive number of lanes from it)?
> > >
> > > This is the way it is done with the speed parameter, so I have aligned
> > > it to it. Why the lanes should be done differently comparing to the
> > > speed?
> >
> > Speed and duplex have worked this way since ages and the interface was probably introduced back in times when combination of
> > speed and duplex was sufficient to identify the link mode. This is no longer the case and even adding number of lanes wouldn't make
> > the combination unique. So if we are going to extend the interface now and update drivers to provide extra information, I believe it
> > would be more useful to provide full information.
> >
> > Michal
>
> Hi Michal,
>
> What do you think of passing the link modes you have suggested as a
> bitmask, similar to "supported", that contains only one positive bit?
> Something like that:
>
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index afae2beacbc3..dd946c88daa3 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -127,6 +127,7 @@ struct ethtool_link_ksettings {
> __ETHTOOL_DECLARE_LINK_MODE_MASK(supported);
> __ETHTOOL_DECLARE_LINK_MODE_MASK(advertising);
> __ETHTOOL_DECLARE_LINK_MODE_MASK(lp_advertising);
> + __ETHTOOL_DECLARE_LINK_MODE_MASK(chosen);
> } link_modes;
> u32 lanes;
> };
>
> Do you have perhaps a better suggestion?
Not sure if it's better but as we know there is only one mode, we could
simply pass the index. We would still need to reserve a special value
for none/unknown but getting an index would make lookup easier.
> And the speed and duplex parameters should be removed from being
> passed like as well, right?
We cannot remove them from struct ethtool_link_settings and the ioctl
and netlink messages as those are part of UAPI and we have to preserve
backward compatibility. But drivers which provide link mode would not
need to fill speed and duplex in their ->get_link_ksettings() as the
common code could do that for them.
Michal
^ permalink raw reply
* Re: [PATCH] net/ethernet/freescale: Fix incorrect IS_ERR_VALUE macro usages
From: Li Yang @ 2020-11-24 22:13 UTC (permalink / raw)
To: Wei Li, Zhao Qiang
Cc: David S. Miller, Jakub Kicinski, Paul Gortmaker, Kumar Gala,
Timur Tabi, Netdev, linuxppc-dev, lkml, guohanjun
In-Reply-To: <CADRPPNQDW4w-4so=smxqLnkBpDzF82NPXmpZ-pyVz_aTwVzREw@mail.gmail.com>
On Tue, Nov 24, 2020 at 3:44 PM Li Yang <leoyang.li@nxp.com> wrote:
>
> On Tue, Nov 24, 2020 at 12:24 AM Wei Li <liwei391@huawei.com> wrote:
> >
> > IS_ERR_VALUE macro should be used only with unsigned long type.
> > Especially it works incorrectly with unsigned shorter types on
> > 64bit machines.
>
> This is truly a problem for the driver to run on 64-bit architectures.
> But from an earlier discussion
> https://patchwork.kernel.org/project/linux-kbuild/patch/1464384685-347275-1-git-send-email-arnd@arndb.de/,
> the preferred solution would be removing the IS_ERR_VALUE() usage or
> make the values to be unsigned long.
>
> It looks like we are having a bigger problem with the 64-bit support
> for the driver that the offset variables can also be real pointers
> which cannot be held with 32-bit data types(when uf_info->bd_mem_part
> == MEM_PART_SYSTEM). So actually we have to change these offsets to
> unsigned long, otherwise we are having more serious issues on 64-bit
> systems. Are you willing to make such changes or you want us to deal
> with it?
Well, it looks like this hardware block was never integrated on a
64-bit SoC and will very likely to keep so. So probably we can keep
the driver 32-bit only. It is currently limited to PPC32 in Kconfig,
how did you build it for 64-bit?
>
> Regards,
> Leo
> >
> > Fixes: 4c35630ccda5 ("[POWERPC] Change rheap functions to use ulongs instead of pointers")
> > Signed-off-by: Wei Li <liwei391@huawei.com>
> > ---
> > drivers/net/ethernet/freescale/ucc_geth.c | 30 +++++++++++------------
> > 1 file changed, 15 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
> > index 714b501be7d0..8656d9be256a 100644
> > --- a/drivers/net/ethernet/freescale/ucc_geth.c
> > +++ b/drivers/net/ethernet/freescale/ucc_geth.c
> > @@ -286,7 +286,7 @@ static int fill_init_enet_entries(struct ucc_geth_private *ugeth,
> > else {
> > init_enet_offset =
> > qe_muram_alloc(thread_size, thread_alignment);
> > - if (IS_ERR_VALUE(init_enet_offset)) {
> > + if (IS_ERR_VALUE((unsigned long)(int)init_enet_offset)) {
> > if (netif_msg_ifup(ugeth))
> > pr_err("Can not allocate DPRAM memory\n");
> > qe_put_snum((u8) snum);
> > @@ -2223,7 +2223,7 @@ static int ucc_geth_alloc_tx(struct ucc_geth_private *ugeth)
> > ugeth->tx_bd_ring_offset[j] =
> > qe_muram_alloc(length,
> > UCC_GETH_TX_BD_RING_ALIGNMENT);
> > - if (!IS_ERR_VALUE(ugeth->tx_bd_ring_offset[j]))
> > + if (!IS_ERR_VALUE((unsigned long)(int)ugeth->tx_bd_ring_offset[j]))
> > ugeth->p_tx_bd_ring[j] =
> > (u8 __iomem *) qe_muram_addr(ugeth->
> > tx_bd_ring_offset[j]);
> > @@ -2300,7 +2300,7 @@ static int ucc_geth_alloc_rx(struct ucc_geth_private *ugeth)
> > ugeth->rx_bd_ring_offset[j] =
> > qe_muram_alloc(length,
> > UCC_GETH_RX_BD_RING_ALIGNMENT);
> > - if (!IS_ERR_VALUE(ugeth->rx_bd_ring_offset[j]))
> > + if (!IS_ERR_VALUE((unsigned long)(int)ugeth->rx_bd_ring_offset[j]))
> > ugeth->p_rx_bd_ring[j] =
> > (u8 __iomem *) qe_muram_addr(ugeth->
> > rx_bd_ring_offset[j]);
> > @@ -2510,7 +2510,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
> > ugeth->tx_glbl_pram_offset =
> > qe_muram_alloc(sizeof(struct ucc_geth_tx_global_pram),
> > UCC_GETH_TX_GLOBAL_PRAM_ALIGNMENT);
> > - if (IS_ERR_VALUE(ugeth->tx_glbl_pram_offset)) {
> > + if (IS_ERR_VALUE((unsigned long)(int)ugeth->tx_glbl_pram_offset)) {
> > if (netif_msg_ifup(ugeth))
> > pr_err("Can not allocate DPRAM memory for p_tx_glbl_pram\n");
> > return -ENOMEM;
> > @@ -2530,7 +2530,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
> > sizeof(struct ucc_geth_thread_data_tx) +
> > 32 * (numThreadsTxNumerical == 1),
> > UCC_GETH_THREAD_DATA_ALIGNMENT);
> > - if (IS_ERR_VALUE(ugeth->thread_dat_tx_offset)) {
> > + if (IS_ERR_VALUE((unsigned long)(int)ugeth->thread_dat_tx_offset)) {
> > if (netif_msg_ifup(ugeth))
> > pr_err("Can not allocate DPRAM memory for p_thread_data_tx\n");
> > return -ENOMEM;
> > @@ -2557,7 +2557,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
> > qe_muram_alloc(ug_info->numQueuesTx *
> > sizeof(struct ucc_geth_send_queue_qd),
> > UCC_GETH_SEND_QUEUE_QUEUE_DESCRIPTOR_ALIGNMENT);
> > - if (IS_ERR_VALUE(ugeth->send_q_mem_reg_offset)) {
> > + if (IS_ERR_VALUE((unsigned long)(int)ugeth->send_q_mem_reg_offset)) {
> > if (netif_msg_ifup(ugeth))
> > pr_err("Can not allocate DPRAM memory for p_send_q_mem_reg\n");
> > return -ENOMEM;
> > @@ -2597,7 +2597,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
> > ugeth->scheduler_offset =
> > qe_muram_alloc(sizeof(struct ucc_geth_scheduler),
> > UCC_GETH_SCHEDULER_ALIGNMENT);
> > - if (IS_ERR_VALUE(ugeth->scheduler_offset)) {
> > + if (IS_ERR_VALUE((unsigned long)(int)ugeth->scheduler_offset)) {
> > if (netif_msg_ifup(ugeth))
> > pr_err("Can not allocate DPRAM memory for p_scheduler\n");
> > return -ENOMEM;
> > @@ -2644,7 +2644,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
> > qe_muram_alloc(sizeof
> > (struct ucc_geth_tx_firmware_statistics_pram),
> > UCC_GETH_TX_STATISTICS_ALIGNMENT);
> > - if (IS_ERR_VALUE(ugeth->tx_fw_statistics_pram_offset)) {
> > + if (IS_ERR_VALUE((unsigned long)(int)ugeth->tx_fw_statistics_pram_offset)) {
> > if (netif_msg_ifup(ugeth))
> > pr_err("Can not allocate DPRAM memory for p_tx_fw_statistics_pram\n");
> > return -ENOMEM;
> > @@ -2681,7 +2681,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
> > ugeth->rx_glbl_pram_offset =
> > qe_muram_alloc(sizeof(struct ucc_geth_rx_global_pram),
> > UCC_GETH_RX_GLOBAL_PRAM_ALIGNMENT);
> > - if (IS_ERR_VALUE(ugeth->rx_glbl_pram_offset)) {
> > + if (IS_ERR_VALUE((unsigned long)(int)ugeth->rx_glbl_pram_offset)) {
> > if (netif_msg_ifup(ugeth))
> > pr_err("Can not allocate DPRAM memory for p_rx_glbl_pram\n");
> > return -ENOMEM;
> > @@ -2700,7 +2700,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
> > qe_muram_alloc(numThreadsRxNumerical *
> > sizeof(struct ucc_geth_thread_data_rx),
> > UCC_GETH_THREAD_DATA_ALIGNMENT);
> > - if (IS_ERR_VALUE(ugeth->thread_dat_rx_offset)) {
> > + if (IS_ERR_VALUE((unsigned long)(int)ugeth->thread_dat_rx_offset)) {
> > if (netif_msg_ifup(ugeth))
> > pr_err("Can not allocate DPRAM memory for p_thread_data_rx\n");
> > return -ENOMEM;
> > @@ -2721,7 +2721,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
> > qe_muram_alloc(sizeof
> > (struct ucc_geth_rx_firmware_statistics_pram),
> > UCC_GETH_RX_STATISTICS_ALIGNMENT);
> > - if (IS_ERR_VALUE(ugeth->rx_fw_statistics_pram_offset)) {
> > + if (IS_ERR_VALUE((unsigned long)(int)ugeth->rx_fw_statistics_pram_offset)) {
> > if (netif_msg_ifup(ugeth))
> > pr_err("Can not allocate DPRAM memory for p_rx_fw_statistics_pram\n");
> > return -ENOMEM;
> > @@ -2741,7 +2741,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
> > qe_muram_alloc(ug_info->numQueuesRx *
> > sizeof(struct ucc_geth_rx_interrupt_coalescing_entry)
> > + 4, UCC_GETH_RX_INTERRUPT_COALESCING_ALIGNMENT);
> > - if (IS_ERR_VALUE(ugeth->rx_irq_coalescing_tbl_offset)) {
> > + if (IS_ERR_VALUE((unsigned long)(int)ugeth->rx_irq_coalescing_tbl_offset)) {
> > if (netif_msg_ifup(ugeth))
> > pr_err("Can not allocate DPRAM memory for p_rx_irq_coalescing_tbl\n");
> > return -ENOMEM;
> > @@ -2807,7 +2807,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
> > (sizeof(struct ucc_geth_rx_bd_queues_entry) +
> > sizeof(struct ucc_geth_rx_prefetched_bds)),
> > UCC_GETH_RX_BD_QUEUES_ALIGNMENT);
> > - if (IS_ERR_VALUE(ugeth->rx_bd_qs_tbl_offset)) {
> > + if (IS_ERR_VALUE((unsigned long)(int)ugeth->rx_bd_qs_tbl_offset)) {
> > if (netif_msg_ifup(ugeth))
> > pr_err("Can not allocate DPRAM memory for p_rx_bd_qs_tbl\n");
> > return -ENOMEM;
> > @@ -2892,7 +2892,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
> > ugeth->exf_glbl_param_offset =
> > qe_muram_alloc(sizeof(struct ucc_geth_exf_global_pram),
> > UCC_GETH_RX_EXTENDED_FILTERING_GLOBAL_PARAMETERS_ALIGNMENT);
> > - if (IS_ERR_VALUE(ugeth->exf_glbl_param_offset)) {
> > + if (IS_ERR_VALUE((unsigned long)(int)ugeth->exf_glbl_param_offset)) {
> > if (netif_msg_ifup(ugeth))
> > pr_err("Can not allocate DPRAM memory for p_exf_glbl_param\n");
> > return -ENOMEM;
> > @@ -3026,7 +3026,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
> >
> > /* Allocate InitEnet command parameter structure */
> > init_enet_pram_offset = qe_muram_alloc(sizeof(struct ucc_geth_init_pram), 4);
> > - if (IS_ERR_VALUE(init_enet_pram_offset)) {
> > + if (IS_ERR_VALUE((unsigned long)(int)init_enet_pram_offset)) {
> > if (netif_msg_ifup(ugeth))
> > pr_err("Can not allocate DPRAM memory for p_init_enet_pram\n");
> > return -ENOMEM;
> > --
> > 2.17.1
> >
^ permalink raw reply
* RE: [PATCH v4 2/4] net: socket: rework SIOC?IFMAP ioctls
From: David Laight @ 2020-11-24 22:12 UTC (permalink / raw)
To: 'Arnd Bergmann'; +Cc: netdev@vger.kernel.org, Arnd Bergmann
In-Reply-To: <CAK8P3a08F1Xk2Vz69CUN=sJcBkqZvcrkd06qrmG3SMR8VhBN4A@mail.gmail.com>
From: Arnd Bergmann
> Sent: 24 November 2020 19:06
>
> On Tue, Nov 24, 2020 at 5:13 PM David Laight <David.Laight@aculab.com> wrote:
> >
> > From: Arnd Bergmann
> > > Sent: 24 November 2020 15:18
> > >
> > > SIOCGIFMAP and SIOCSIFMAP currently require compat_alloc_user_space()
> > > and copy_in_user() for compat mode.
> > >
> > > Move the compat handling into the location where the structures are
> > > actually used, to avoid using those interfaces and get a clearer
> > > implementation.
> > >
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > ---
> > > changes in v3:
> > > - complete rewrite
> > ...
> > > include/linux/compat.h | 18 ++++++------
> > > net/core/dev_ioctl.c | 64 +++++++++++++++++++++++++++++++++---------
> > > net/socket.c | 39 ++-----------------------
> > > 3 files changed, 62 insertions(+), 59 deletions(-)
> > >
> > > diff --git a/include/linux/compat.h b/include/linux/compat.h
> > > index 08dbd34bb7a5..47496c5eb5eb 100644
> > > --- a/include/linux/compat.h
> > > +++ b/include/linux/compat.h
> > > @@ -96,6 +96,15 @@ struct compat_iovec {
> > > compat_size_t iov_len;
> > > };
> > >
> > > +struct compat_ifmap {
> > > + compat_ulong_t mem_start;
> > > + compat_ulong_t mem_end;
> > > + unsigned short base_addr;
> > > + unsigned char irq;
> > > + unsigned char dma;
> > > + unsigned char port;
> > > +};
> >
> > Isn't the only difference the number of pad bytes at the end?
>
> No, the main difference is in the first two fields, which are
> 'unsigned long' and therefore different. The three-byte padding
> is in fact the same on all architectures (including x86) that
> have a compat mode, though it might be different on
> m68k and arm-oabi, which have slightly special struct
> alignment rules.
>
> It could be done with two assignments and a memcpy, but
> I like the individual assignments better here.
Gah my brain hurts today.
I was just thinking of the alignment and padding, not the sizes.
You could read the compat structure to 'mem_end' and
then move the first two fields forward.
But, I guess, this structure doesn't have many fields.
What you really need for these copies is COBOL's 'move corresponding'.
(Which wasn't implemented by the only COBOL compiler I've used.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [net PATCH] tcp: Set ECT0 bit in tos/tclass for synack when BPF needs ECN
From: Jakub Kicinski @ 2020-11-24 22:14 UTC (permalink / raw)
To: Alexander Duyck
Cc: netdev, bpf, daniel, kafai, kernel-team, edumazet, brakmo,
alexanderduyck
In-Reply-To: <160593039663.2604.1374502006916871573.stgit@localhost.localdomain>
On Fri, 20 Nov 2020 19:47:44 -0800 Alexander Duyck wrote:
> From: Alexander Duyck <alexanderduyck@fb.com>
>
> When a BPF program is used to select between a type of TCP congestion
> control algorithm that uses either ECN or not there is a case where the
> synack for the frame was coming up without the ECT0 bit set. A bit of
> research found that this was due to the final socket being configured to
> dctcp while the listener socket was staying in cubic.
>
> To reproduce it all that is needed is to monitor TCP traffic while running
> the sample bpf program "samples/bpf/tcp_cong_kern.c". What is observed,
> assuming tcp_dctcp module is loaded or compiled in and the traffic matches
> the rules in the sample file, is that for all frames with the exception of
> the synack the ECT0 bit is set.
>
> To address that it is necessary to make one additional call to
> tcp_bpf_ca_needs_ecn using the request socket and then use the output of
> that to set the ECT0 bit for the tos/tclass of the packet.
>
> Fixes: 91b5b21c7c16 ("bpf: Add support for changing congestion control")
> Signed-off-by: Alexander Duyck <alexanderduyck@fb.com>
Applied, thank you!
^ permalink raw reply
* Re: [PATCH net-next 0/3] mvneta: access skb_shared_info only on last frag
From: Lorenzo Bianconi @ 2020-11-24 22:18 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, lorenzo.bianconi, davem, brouer, echaudro, john.fastabend,
borkmann, alexei.starovoitov
In-Reply-To: <20201124122639.6fa91460@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
[-- Attachment #1: Type: text/plain, Size: 731 bytes --]
> On Fri, 20 Nov 2020 18:05:41 +0100 Lorenzo Bianconi wrote:
> > Build skb_shared_info on mvneta_rx_swbm stack and sync it to xdp_buff
> > skb_shared_info area only on the last fragment.
> > Avoid avoid unnecessary xdp_buff initialization in mvneta_rx_swbm routine.
> > This a preliminary series to complete xdp multi-buff in mvneta driver.
>
> Looks fine, but since you need this for XDP multi-buff it should
> probably go via bpf-next, right?
>
> Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Hi Jakub,
thx for the review. Since the series changes networking-only bits I sent it for
net-next, but I agree bpf-next is better.
@Alexei, Daniel: is it fine to merge the series in bpf-next?
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox