* Re: [PATCH][next] rtlwifi: btcoexist: remove redundant variable fw_ps_state
From: Larry Finger @ 2018-01-09 16:48 UTC (permalink / raw)
To: Colin King, Ping-Ke Shih, Kalle Valo, Yan-Hsuan Chuang,
linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20180109164329.15919-1-colin.king@canonical.com>
On 01/09/2018 10:43 AM, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Variable fw_ps_state is assigned a value but it is never read, hence
> it is redundant and can be removed.
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Thanks,
Larry
>
> Cleans up clang warning:
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c:736:2:
> warning: Value stored to 'fw_ps_state' is never read
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> index 5f3eda31187a..873bf9303d5d 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> @@ -677,7 +677,7 @@ static void halbtc_display_wifi_status(struct btc_coexist *btcoexist,
> u32 wifi_link_status = 0x0;
> bool bt_hs_on = false, under_ips = false, under_lps = false;
> bool low_power = false, dc_mode = false;
> - u8 wifi_chnl = 0, wifi_hs_chnl = 0, fw_ps_state;
> + u8 wifi_chnl = 0, wifi_hs_chnl = 0;
> u8 ap_num = 0;
>
> wifi_link_status = halbtc_get_wifi_link_status(btcoexist);
> @@ -733,7 +733,6 @@ static void halbtc_display_wifi_status(struct btc_coexist *btcoexist,
> dc_mode = true; /*TODO*/
> under_ips = rtlpriv->psc.inactive_pwrstate == ERFOFF ? 1 : 0;
> under_lps = rtlpriv->psc.dot11_psmode == EACTIVE ? 0 : 1;
> - fw_ps_state = 0;
> low_power = 0; /*TODO*/
> seq_printf(m, "\n %-35s = %s%s%s%s",
> "Power Status",
>
^ permalink raw reply
* Re: [PATCH v2] b43: Replace mdelay with usleep_range in b43_radio_2057_init_post
From: Larry Finger @ 2018-01-09 16:49 UTC (permalink / raw)
To: Jia-Ju Bai, kvalo, kstewart, johannes.berg, tiwai, gregkh,
colin.king, andrew.zaborowski
Cc: linux-kernel, linux-wireless, netdev, b43-dev
In-Reply-To: <1515462006-6144-1-git-send-email-baijiaju1990@gmail.com>
On 01/08/2018 07:40 PM, Jia-Ju Bai wrote:
> b43_radio_2057_init_post is not called in an interrupt handler
> nor holding a spinlock.
> The function mdelay in it can be replaced with usleep_range,
> to reduce busy wait.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
> ---
> v2:
> * Replace mdelay with usleep_range, instead of msleep in v1.
> Thank Larry for good advice.
> ---
I agree that a sleep of 2-3 ms should be OK here.
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Larry
> drivers/net/wireless/broadcom/b43/phy_n.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/broadcom/b43/phy_n.c b/drivers/net/wireless/broadcom/b43/phy_n.c
> index a5557d7..f2a2f41 100644
> --- a/drivers/net/wireless/broadcom/b43/phy_n.c
> +++ b/drivers/net/wireless/broadcom/b43/phy_n.c
> @@ -1031,7 +1031,7 @@ static void b43_radio_2057_init_post(struct b43_wldev *dev)
>
> b43_radio_set(dev, R2057_RFPLL_MISC_CAL_RESETN, 0x78);
> b43_radio_set(dev, R2057_XTAL_CONFIG2, 0x80);
> - mdelay(2);
> + usleep_range(2000, 3000);
> b43_radio_mask(dev, R2057_RFPLL_MISC_CAL_RESETN, ~0x78);
> b43_radio_mask(dev, R2057_XTAL_CONFIG2, ~0x80);
>
>
^ permalink raw reply
* Re: [PATCH] docs-rst: networking: wire up msg_zerocopy
From: David Miller @ 2018-01-09 16:50 UTC (permalink / raw)
To: rppt; +Cc: linux-doc, corbet, mchehab, willemb, netdev
In-Reply-To: <1515394217-24725-1-git-send-email-rppt@linux.vnet.ibm.com>
From: Mike Rapoport <rppt@linux.vnet.ibm.com>
Date: Mon, 8 Jan 2018 08:50:17 +0200
> Fix the following 'make htmldocs' complaint:
>
> Documentation/networking/msg_zerocopy.rst:: WARNING: document isn't included in any toctree.
>
> Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
Does someone else want to take this?
Otherwise I can.
^ permalink raw reply
* Aw: Re: dvb usb issues since kernel 4.9
From: Josef Griebichler @ 2018-01-09 16:51 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Peter Zijlstra, Mauro Carvalho Chehab, Alan Stern,
Greg Kroah-Hartman, linux-usb, Eric Dumazet, Rik van Riel,
Paolo Abeni, Hannes Frederic Sowa, linux-kernel, netdev,
Jonathan Corbet, LMML, David Miller, torvalds
In-Reply-To: <20180108231656.3bbd1968@redhat.com>
Hi Linus,
your patch works very good for me and others (please see https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=77006#post77006). No errors in recordings any more.
The patch was also tested on x86_64 (Revo 3700) with positive effect.
I agree with the forum poster, that there's still an issue when recording and watching livetv at same time. I also get audio dropouts and audio is out of sync.
According to user smp kernel 4.9.73 with your patch on rpi and according to user jahutchi kernel 4.11.12 on x86_64 have no such issues.
I don't know if this dropouts are related to this topic.
If of any help I could provide perf output on raspberry with libreelec and tvheadend.
Regards,
Josef
Gesendet: Montag, 08. Januar 2018 um 23:16 Uhr
Von: "Jesper Dangaard Brouer" <jbrouer@redhat.com>
An: "Peter Zijlstra" <peterz@infradead.org>
Cc: "Josef Griebichler" <griebichler.josef@gmx.at>, "Mauro Carvalho Chehab" <mchehab@s-opensource.com>, "Alan Stern" <stern@rowland.harvard.edu>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, linux-usb@vger.kernel.org, "Eric Dumazet" <edumazet@google.com>, "Rik van Riel" <riel@redhat.com>, "Paolo Abeni" <pabeni@redhat.com>, "Hannes Frederic Sowa" <hannes@redhat.com>, linux-kernel <linux-kernel@vger.kernel.org>, netdev <netdev@vger.kernel.org>, "Jonathan Corbet" <corbet@lwn.net>, LMML <linux-media@vger.kernel.org>, "David Miller" <davem@davemloft.net>, torvalds@linux-foundation.org
Betreff: Re: dvb usb issues since kernel 4.9
On Mon, 8 Jan 2018 22:44:27 +0100
Peter Zijlstra <peterz@infradead.org> wrote:
> On Mon, Jan 08, 2018 at 10:31:09PM +0100, Jesper Dangaard Brouer wrote:
> > I did expected the issue to get worse, when you load the Pi with
> > network traffic, as now the softirq time-budget have to be shared
> > between networking and USB/DVB. Thus, I guess you are running TCP and
> > USB/mpeg2ts on the same CPU (why when you have 4 CPUs?...)
>
> Isn't networking also over USB on the Pi ?
Darn, that is true. Looking at the dmesg output in http://ix.io/DOg:
[ 0.405942] usbcore: registered new interface driver smsc95xx
[ 5.821104] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
I don't know enough about USB... is it possible to control which CPU
handles the individual USB ports, or on some other level (than ports)?
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer[http://www.linkedin.com/in/brouer]
^ permalink raw reply
* Re: [PATCH] net: caif: use strlcpy() instead of strncpy()
From: David Miller @ 2018-01-09 16:53 UTC (permalink / raw)
To: wangxiongfeng2; +Cc: netdev, arnd, linux-kernel
In-Reply-To: <1515411780-27246-1-git-send-email-wangxiongfeng2@huawei.com>
From: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Date: Mon, 8 Jan 2018 19:43:00 +0800
> From: Xiongfeng Wang <xiongfeng.wang@linaro.org>
>
> gcc-8 reports
>
> net/caif/caif_dev.c: In function 'caif_enroll_dev':
> ./include/linux/string.h:245:9: warning: '__builtin_strncpy' output may
> be truncated copying 15 bytes from a string of length 15
> [-Wstringop-truncation]
>
> net/caif/cfctrl.c: In function 'cfctrl_linkup_request':
> ./include/linux/string.h:245:9: warning: '__builtin_strncpy' output may
> be truncated copying 15 bytes from a string of length 15
> [-Wstringop-truncation]
>
> net/caif/cfcnfg.c: In function 'caif_connect_client':
> ./include/linux/string.h:245:9: warning: '__builtin_strncpy' output may
> be truncated copying 15 bytes from a string of length 15
> [-Wstringop-truncation]
>
> The compiler require that the input param 'len' of strncpy() should be
> greater than the length of the src string, so that '\0' is copied as
> well. We can just use strlcpy() to avoid this warning.
>
> Signed-off-by: Xiongfeng Wang <xiongfeng.wang@linaro.org>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next 0/3] ethtool ringparam upper bound
From: David Miller @ 2018-01-09 16:55 UTC (permalink / raw)
To: tariqt; +Cc: netdev, eranbe, eugenia
In-Reply-To: <1515420026-11970-1-git-send-email-tariqt@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Date: Mon, 8 Jan 2018 16:00:23 +0200
> This patchset by Jenny adds sanity checks in ethtool ringparam
> operation for input upper bounds, similarly to what's done in
> ethtool_set_channels.
>
> The checks are added in patch 1, using a call to get_ringparam
> prior to calling set_ringparam NDO.
>
> Patch 2 changes the function's behavior in mlx4_en, so that
> it returns an error for out-of-range input, instead of rounding
> it to closest valid, similar to mlx5e.
>
> Patch 3 removes the upper bound checks in mlx5e_ethtool_set_ringparam
> as it becomes redundant.
>
> Series generated against net-next commit:
> f66faae2f80a Merge branch 'ipv6-ipv4-nexthop-align'
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH] docs-rst: networking: wire up msg_zerocopy
From: Jonathan Corbet @ 2018-01-09 16:55 UTC (permalink / raw)
To: David Miller; +Cc: rppt, linux-doc, mchehab, willemb, netdev
In-Reply-To: <20180109.115049.1741019841084791938.davem@davemloft.net>
On Tue, 09 Jan 2018 11:50:49 -0500 (EST)
David Miller <davem@davemloft.net> wrote:
> From: Mike Rapoport <rppt@linux.vnet.ibm.com>
> Date: Mon, 8 Jan 2018 08:50:17 +0200
>
> > Fix the following 'make htmldocs' complaint:
> >
> > Documentation/networking/msg_zerocopy.rst:: WARNING: document isn't included in any toctree.
> >
> > Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
>
> Does someone else want to take this?
>
> Otherwise I can.
I can certainly take it (or the equivalent patch posted by Tobin a few
days earlier) through the docs tree. I've been holding off, though,
under the impression that you'd rather take networking docs patches
yourself. Either is fine. Unless you say you've grabbed it, I'll do so
in the near future.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH] wireless: broadcom: radio_2056: delete duplicated macro definitions
From: Larry Finger @ 2018-01-09 16:57 UTC (permalink / raw)
To: Rasmus Villemoes, Kalle Valo
Cc: linux-wireless, b43-dev, linux-kernel, netdev
In-Reply-To: <20180108212659.24049-1-linux@rasmusvillemoes.dk>
On 01/08/2018 03:26 PM, Rasmus Villemoes wrote:
> Ctrl-V was hit twice when these macros were inserted:
>
> $ sed -n '9,527p' ./drivers/net/wireless/broadcom/b43/radio_2056.h | md5sum
> 4db53450c59d9939e903d4e4ba6bc9b1 -
> $ sed -n '528,1046p' ./drivers/net/wireless/broadcom/b43/radio_2056.h | md5sum
> 4db53450c59d9939e903d4e4ba6bc9b1 -
>
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
The subject line is wrong here. You should refer to the driver, not the file
being changed. For historical reasons, wireless is not mentioned, nor is
broadcom in a subject. Thus the subject should be "b43: Delete duplicated macro
definitions".
For the commit message, I would not try to state how the error occurred, nor the
sed command needed to verify the duplication. A simple "A number of macros are
entered twice." should suffice. If you removed something that was needed, the
compiler would complain.
NACK
Larry
> ---
> drivers/net/wireless/broadcom/b43/radio_2056.h | 519 -------------------------
> 1 file changed, 519 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/b43/radio_2056.h b/drivers/net/wireless/broadcom/b43/radio_2056.h
> index 59297fdce5e3..779b80ea072f 100644
> --- a/drivers/net/wireless/broadcom/b43/radio_2056.h
> +++ b/drivers/net/wireless/broadcom/b43/radio_2056.h
> @@ -525,525 +525,6 @@
> #define B2056_VCM_MASK 0x1C
> #define B2056_RSSI_VCM_SHIFT 0x02
>
> -#define B2056_SYN (0x0 << 12)
> -#define B2056_TX0 (0x2 << 12)
> -#define B2056_TX1 (0x3 << 12)
> -#define B2056_RX0 (0x6 << 12)
> -#define B2056_RX1 (0x7 << 12)
> -#define B2056_ALLTX (0xE << 12)
> -#define B2056_ALLRX (0xF << 12)
> -
> -#define B2056_SYN_RESERVED_ADDR0 0x00
> -#define B2056_SYN_IDCODE 0x01
> -#define B2056_SYN_RESERVED_ADDR2 0x02
> -#define B2056_SYN_RESERVED_ADDR3 0x03
> -#define B2056_SYN_RESERVED_ADDR4 0x04
> -#define B2056_SYN_RESERVED_ADDR5 0x05
> -#define B2056_SYN_RESERVED_ADDR6 0x06
> -#define B2056_SYN_RESERVED_ADDR7 0x07
> -#define B2056_SYN_COM_CTRL 0x08
> -#define B2056_SYN_COM_PU 0x09
> -#define B2056_SYN_COM_OVR 0x0A
> -#define B2056_SYN_COM_RESET 0x0B
> -#define B2056_SYN_COM_RCAL 0x0C
> -#define B2056_SYN_COM_RC_RXLPF 0x0D
> -#define B2056_SYN_COM_RC_TXLPF 0x0E
> -#define B2056_SYN_COM_RC_RXHPF 0x0F
> -#define B2056_SYN_RESERVED_ADDR16 0x10
> -#define B2056_SYN_RESERVED_ADDR17 0x11
> -#define B2056_SYN_RESERVED_ADDR18 0x12
> -#define B2056_SYN_RESERVED_ADDR19 0x13
> -#define B2056_SYN_RESERVED_ADDR20 0x14
> -#define B2056_SYN_RESERVED_ADDR21 0x15
> -#define B2056_SYN_RESERVED_ADDR22 0x16
> -#define B2056_SYN_RESERVED_ADDR23 0x17
> -#define B2056_SYN_RESERVED_ADDR24 0x18
> -#define B2056_SYN_RESERVED_ADDR25 0x19
> -#define B2056_SYN_RESERVED_ADDR26 0x1A
> -#define B2056_SYN_RESERVED_ADDR27 0x1B
> -#define B2056_SYN_RESERVED_ADDR28 0x1C
> -#define B2056_SYN_RESERVED_ADDR29 0x1D
> -#define B2056_SYN_RESERVED_ADDR30 0x1E
> -#define B2056_SYN_RESERVED_ADDR31 0x1F
> -#define B2056_SYN_GPIO_MASTER1 0x20
> -#define B2056_SYN_GPIO_MASTER2 0x21
> -#define B2056_SYN_TOPBIAS_MASTER 0x22
> -#define B2056_SYN_TOPBIAS_RCAL 0x23
> -#define B2056_SYN_AFEREG 0x24
> -#define B2056_SYN_TEMPPROCSENSE 0x25
> -#define B2056_SYN_TEMPPROCSENSEIDAC 0x26
> -#define B2056_SYN_TEMPPROCSENSERCAL 0x27
> -#define B2056_SYN_LPO 0x28
> -#define B2056_SYN_VDDCAL_MASTER 0x29
> -#define B2056_SYN_VDDCAL_IDAC 0x2A
> -#define B2056_SYN_VDDCAL_STATUS 0x2B
> -#define B2056_SYN_RCAL_MASTER 0x2C
> -#define B2056_SYN_RCAL_CODE_OUT 0x2D
> -#define B2056_SYN_RCCAL_CTRL0 0x2E
> -#define B2056_SYN_RCCAL_CTRL1 0x2F
> -#define B2056_SYN_RCCAL_CTRL2 0x30
> -#define B2056_SYN_RCCAL_CTRL3 0x31
> -#define B2056_SYN_RCCAL_CTRL4 0x32
> -#define B2056_SYN_RCCAL_CTRL5 0x33
> -#define B2056_SYN_RCCAL_CTRL6 0x34
> -#define B2056_SYN_RCCAL_CTRL7 0x35
> -#define B2056_SYN_RCCAL_CTRL8 0x36
> -#define B2056_SYN_RCCAL_CTRL9 0x37
> -#define B2056_SYN_RCCAL_CTRL10 0x38
> -#define B2056_SYN_RCCAL_CTRL11 0x39
> -#define B2056_SYN_ZCAL_SPARE1 0x3A
> -#define B2056_SYN_ZCAL_SPARE2 0x3B
> -#define B2056_SYN_PLL_MAST1 0x3C
> -#define B2056_SYN_PLL_MAST2 0x3D
> -#define B2056_SYN_PLL_MAST3 0x3E
> -#define B2056_SYN_PLL_BIAS_RESET 0x3F
> -#define B2056_SYN_PLL_XTAL0 0x40
> -#define B2056_SYN_PLL_XTAL1 0x41
> -#define B2056_SYN_PLL_XTAL3 0x42
> -#define B2056_SYN_PLL_XTAL4 0x43
> -#define B2056_SYN_PLL_XTAL5 0x44
> -#define B2056_SYN_PLL_XTAL6 0x45
> -#define B2056_SYN_PLL_REFDIV 0x46
> -#define B2056_SYN_PLL_PFD 0x47
> -#define B2056_SYN_PLL_CP1 0x48
> -#define B2056_SYN_PLL_CP2 0x49
> -#define B2056_SYN_PLL_CP3 0x4A
> -#define B2056_SYN_PLL_LOOPFILTER1 0x4B
> -#define B2056_SYN_PLL_LOOPFILTER2 0x4C
> -#define B2056_SYN_PLL_LOOPFILTER3 0x4D
> -#define B2056_SYN_PLL_LOOPFILTER4 0x4E
> -#define B2056_SYN_PLL_LOOPFILTER5 0x4F
> -#define B2056_SYN_PLL_MMD1 0x50
> -#define B2056_SYN_PLL_MMD2 0x51
> -#define B2056_SYN_PLL_VCO1 0x52
> -#define B2056_SYN_PLL_VCO2 0x53
> -#define B2056_SYN_PLL_MONITOR1 0x54
> -#define B2056_SYN_PLL_MONITOR2 0x55
> -#define B2056_SYN_PLL_VCOCAL1 0x56
> -#define B2056_SYN_PLL_VCOCAL2 0x57
> -#define B2056_SYN_PLL_VCOCAL4 0x58
> -#define B2056_SYN_PLL_VCOCAL5 0x59
> -#define B2056_SYN_PLL_VCOCAL6 0x5A
> -#define B2056_SYN_PLL_VCOCAL7 0x5B
> -#define B2056_SYN_PLL_VCOCAL8 0x5C
> -#define B2056_SYN_PLL_VCOCAL9 0x5D
> -#define B2056_SYN_PLL_VCOCAL10 0x5E
> -#define B2056_SYN_PLL_VCOCAL11 0x5F
> -#define B2056_SYN_PLL_VCOCAL12 0x60
> -#define B2056_SYN_PLL_VCOCAL13 0x61
> -#define B2056_SYN_PLL_VREG 0x62
> -#define B2056_SYN_PLL_STATUS1 0x63
> -#define B2056_SYN_PLL_STATUS2 0x64
> -#define B2056_SYN_PLL_STATUS3 0x65
> -#define B2056_SYN_LOGEN_PU0 0x66
> -#define B2056_SYN_LOGEN_PU1 0x67
> -#define B2056_SYN_LOGEN_PU2 0x68
> -#define B2056_SYN_LOGEN_PU3 0x69
> -#define B2056_SYN_LOGEN_PU5 0x6A
> -#define B2056_SYN_LOGEN_PU6 0x6B
> -#define B2056_SYN_LOGEN_PU7 0x6C
> -#define B2056_SYN_LOGEN_PU8 0x6D
> -#define B2056_SYN_LOGEN_BIAS_RESET 0x6E
> -#define B2056_SYN_LOGEN_RCCR1 0x6F
> -#define B2056_SYN_LOGEN_VCOBUF1 0x70
> -#define B2056_SYN_LOGEN_MIXER1 0x71
> -#define B2056_SYN_LOGEN_MIXER2 0x72
> -#define B2056_SYN_LOGEN_BUF1 0x73
> -#define B2056_SYN_LOGENBUF2 0x74
> -#define B2056_SYN_LOGEN_BUF3 0x75
> -#define B2056_SYN_LOGEN_BUF4 0x76
> -#define B2056_SYN_LOGEN_DIV1 0x77
> -#define B2056_SYN_LOGEN_DIV2 0x78
> -#define B2056_SYN_LOGEN_DIV3 0x79
> -#define B2056_SYN_LOGEN_ACL1 0x7A
> -#define B2056_SYN_LOGEN_ACL2 0x7B
> -#define B2056_SYN_LOGEN_ACL3 0x7C
> -#define B2056_SYN_LOGEN_ACL4 0x7D
> -#define B2056_SYN_LOGEN_ACL5 0x7E
> -#define B2056_SYN_LOGEN_ACL6 0x7F
> -#define B2056_SYN_LOGEN_ACLOUT 0x80
> -#define B2056_SYN_LOGEN_ACLCAL1 0x81
> -#define B2056_SYN_LOGEN_ACLCAL2 0x82
> -#define B2056_SYN_LOGEN_ACLCAL3 0x83
> -#define B2056_SYN_CALEN 0x84
> -#define B2056_SYN_LOGEN_PEAKDET1 0x85
> -#define B2056_SYN_LOGEN_CORE_ACL_OVR 0x86
> -#define B2056_SYN_LOGEN_RX_DIFF_ACL_OVR 0x87
> -#define B2056_SYN_LOGEN_TX_DIFF_ACL_OVR 0x88
> -#define B2056_SYN_LOGEN_RX_CMOS_ACL_OVR 0x89
> -#define B2056_SYN_LOGEN_TX_CMOS_ACL_OVR 0x8A
> -#define B2056_SYN_LOGEN_VCOBUF2 0x8B
> -#define B2056_SYN_LOGEN_MIXER3 0x8C
> -#define B2056_SYN_LOGEN_BUF5 0x8D
> -#define B2056_SYN_LOGEN_BUF6 0x8E
> -#define B2056_SYN_LOGEN_CBUFRX1 0x8F
> -#define B2056_SYN_LOGEN_CBUFRX2 0x90
> -#define B2056_SYN_LOGEN_CBUFRX3 0x91
> -#define B2056_SYN_LOGEN_CBUFRX4 0x92
> -#define B2056_SYN_LOGEN_CBUFTX1 0x93
> -#define B2056_SYN_LOGEN_CBUFTX2 0x94
> -#define B2056_SYN_LOGEN_CBUFTX3 0x95
> -#define B2056_SYN_LOGEN_CBUFTX4 0x96
> -#define B2056_SYN_LOGEN_CMOSRX1 0x97
> -#define B2056_SYN_LOGEN_CMOSRX2 0x98
> -#define B2056_SYN_LOGEN_CMOSRX3 0x99
> -#define B2056_SYN_LOGEN_CMOSRX4 0x9A
> -#define B2056_SYN_LOGEN_CMOSTX1 0x9B
> -#define B2056_SYN_LOGEN_CMOSTX2 0x9C
> -#define B2056_SYN_LOGEN_CMOSTX3 0x9D
> -#define B2056_SYN_LOGEN_CMOSTX4 0x9E
> -#define B2056_SYN_LOGEN_VCOBUF2_OVRVAL 0x9F
> -#define B2056_SYN_LOGEN_MIXER3_OVRVAL 0xA0
> -#define B2056_SYN_LOGEN_BUF5_OVRVAL 0xA1
> -#define B2056_SYN_LOGEN_BUF6_OVRVAL 0xA2
> -#define B2056_SYN_LOGEN_CBUFRX1_OVRVAL 0xA3
> -#define B2056_SYN_LOGEN_CBUFRX2_OVRVAL 0xA4
> -#define B2056_SYN_LOGEN_CBUFRX3_OVRVAL 0xA5
> -#define B2056_SYN_LOGEN_CBUFRX4_OVRVAL 0xA6
> -#define B2056_SYN_LOGEN_CBUFTX1_OVRVAL 0xA7
> -#define B2056_SYN_LOGEN_CBUFTX2_OVRVAL 0xA8
> -#define B2056_SYN_LOGEN_CBUFTX3_OVRVAL 0xA9
> -#define B2056_SYN_LOGEN_CBUFTX4_OVRVAL 0xAA
> -#define B2056_SYN_LOGEN_CMOSRX1_OVRVAL 0xAB
> -#define B2056_SYN_LOGEN_CMOSRX2_OVRVAL 0xAC
> -#define B2056_SYN_LOGEN_CMOSRX3_OVRVAL 0xAD
> -#define B2056_SYN_LOGEN_CMOSRX4_OVRVAL 0xAE
> -#define B2056_SYN_LOGEN_CMOSTX1_OVRVAL 0xAF
> -#define B2056_SYN_LOGEN_CMOSTX2_OVRVAL 0xB0
> -#define B2056_SYN_LOGEN_CMOSTX3_OVRVAL 0xB1
> -#define B2056_SYN_LOGEN_CMOSTX4_OVRVAL 0xB2
> -#define B2056_SYN_LOGEN_ACL_WAITCNT 0xB3
> -#define B2056_SYN_LOGEN_CORE_CALVALID 0xB4
> -#define B2056_SYN_LOGEN_RX_CMOS_CALVALID 0xB5
> -#define B2056_SYN_LOGEN_TX_CMOS_VALID 0xB6
> -
> -#define B2056_TX_RESERVED_ADDR0 0x00
> -#define B2056_TX_IDCODE 0x01
> -#define B2056_TX_RESERVED_ADDR2 0x02
> -#define B2056_TX_RESERVED_ADDR3 0x03
> -#define B2056_TX_RESERVED_ADDR4 0x04
> -#define B2056_TX_RESERVED_ADDR5 0x05
> -#define B2056_TX_RESERVED_ADDR6 0x06
> -#define B2056_TX_RESERVED_ADDR7 0x07
> -#define B2056_TX_COM_CTRL 0x08
> -#define B2056_TX_COM_PU 0x09
> -#define B2056_TX_COM_OVR 0x0A
> -#define B2056_TX_COM_RESET 0x0B
> -#define B2056_TX_COM_RCAL 0x0C
> -#define B2056_TX_COM_RC_RXLPF 0x0D
> -#define B2056_TX_COM_RC_TXLPF 0x0E
> -#define B2056_TX_COM_RC_RXHPF 0x0F
> -#define B2056_TX_RESERVED_ADDR16 0x10
> -#define B2056_TX_RESERVED_ADDR17 0x11
> -#define B2056_TX_RESERVED_ADDR18 0x12
> -#define B2056_TX_RESERVED_ADDR19 0x13
> -#define B2056_TX_RESERVED_ADDR20 0x14
> -#define B2056_TX_RESERVED_ADDR21 0x15
> -#define B2056_TX_RESERVED_ADDR22 0x16
> -#define B2056_TX_RESERVED_ADDR23 0x17
> -#define B2056_TX_RESERVED_ADDR24 0x18
> -#define B2056_TX_RESERVED_ADDR25 0x19
> -#define B2056_TX_RESERVED_ADDR26 0x1A
> -#define B2056_TX_RESERVED_ADDR27 0x1B
> -#define B2056_TX_RESERVED_ADDR28 0x1C
> -#define B2056_TX_RESERVED_ADDR29 0x1D
> -#define B2056_TX_RESERVED_ADDR30 0x1E
> -#define B2056_TX_RESERVED_ADDR31 0x1F
> -#define B2056_TX_IQCAL_GAIN_BW 0x20
> -#define B2056_TX_LOFT_FINE_I 0x21
> -#define B2056_TX_LOFT_FINE_Q 0x22
> -#define B2056_TX_LOFT_COARSE_I 0x23
> -#define B2056_TX_LOFT_COARSE_Q 0x24
> -#define B2056_TX_TX_COM_MASTER1 0x25
> -#define B2056_TX_TX_COM_MASTER2 0x26
> -#define B2056_TX_RXIQCAL_TXMUX 0x27
> -#define B2056_TX_TX_SSI_MASTER 0x28
> -#define B2056_TX_IQCAL_VCM_HG 0x29
> -#define B2056_TX_IQCAL_IDAC 0x2A
> -#define B2056_TX_TSSI_VCM 0x2B
> -#define B2056_TX_TX_AMP_DET 0x2C
> -#define B2056_TX_TX_SSI_MUX 0x2D
> -#define B2056_TX_TSSIA 0x2E
> -#define B2056_TX_TSSIG 0x2F
> -#define B2056_TX_TSSI_MISC1 0x30
> -#define B2056_TX_TSSI_MISC2 0x31
> -#define B2056_TX_TSSI_MISC3 0x32
> -#define B2056_TX_PA_SPARE1 0x33
> -#define B2056_TX_PA_SPARE2 0x34
> -#define B2056_TX_INTPAA_MASTER 0x35
> -#define B2056_TX_INTPAA_GAIN 0x36
> -#define B2056_TX_INTPAA_BOOST_TUNE 0x37
> -#define B2056_TX_INTPAA_IAUX_STAT 0x38
> -#define B2056_TX_INTPAA_IAUX_DYN 0x39
> -#define B2056_TX_INTPAA_IMAIN_STAT 0x3A
> -#define B2056_TX_INTPAA_IMAIN_DYN 0x3B
> -#define B2056_TX_INTPAA_CASCBIAS 0x3C
> -#define B2056_TX_INTPAA_PASLOPE 0x3D
> -#define B2056_TX_INTPAA_PA_MISC 0x3E
> -#define B2056_TX_INTPAG_MASTER 0x3F
> -#define B2056_TX_INTPAG_GAIN 0x40
> -#define B2056_TX_INTPAG_BOOST_TUNE 0x41
> -#define B2056_TX_INTPAG_IAUX_STAT 0x42
> -#define B2056_TX_INTPAG_IAUX_DYN 0x43
> -#define B2056_TX_INTPAG_IMAIN_STAT 0x44
> -#define B2056_TX_INTPAG_IMAIN_DYN 0x45
> -#define B2056_TX_INTPAG_CASCBIAS 0x46
> -#define B2056_TX_INTPAG_PASLOPE 0x47
> -#define B2056_TX_INTPAG_PA_MISC 0x48
> -#define B2056_TX_PADA_MASTER 0x49
> -#define B2056_TX_PADA_IDAC 0x4A
> -#define B2056_TX_PADA_CASCBIAS 0x4B
> -#define B2056_TX_PADA_GAIN 0x4C
> -#define B2056_TX_PADA_BOOST_TUNE 0x4D
> -#define B2056_TX_PADA_SLOPE 0x4E
> -#define B2056_TX_PADG_MASTER 0x4F
> -#define B2056_TX_PADG_IDAC 0x50
> -#define B2056_TX_PADG_CASCBIAS 0x51
> -#define B2056_TX_PADG_GAIN 0x52
> -#define B2056_TX_PADG_BOOST_TUNE 0x53
> -#define B2056_TX_PADG_SLOPE 0x54
> -#define B2056_TX_PGAA_MASTER 0x55
> -#define B2056_TX_PGAA_IDAC 0x56
> -#define B2056_TX_PGAA_GAIN 0x57
> -#define B2056_TX_PGAA_BOOST_TUNE 0x58
> -#define B2056_TX_PGAA_SLOPE 0x59
> -#define B2056_TX_PGAA_MISC 0x5A
> -#define B2056_TX_PGAG_MASTER 0x5B
> -#define B2056_TX_PGAG_IDAC 0x5C
> -#define B2056_TX_PGAG_GAIN 0x5D
> -#define B2056_TX_PGAG_BOOST_TUNE 0x5E
> -#define B2056_TX_PGAG_SLOPE 0x5F
> -#define B2056_TX_PGAG_MISC 0x60
> -#define B2056_TX_MIXA_MASTER 0x61
> -#define B2056_TX_MIXA_BOOST_TUNE 0x62
> -#define B2056_TX_MIXG 0x63
> -#define B2056_TX_MIXG_BOOST_TUNE 0x64
> -#define B2056_TX_BB_GM_MASTER 0x65
> -#define B2056_TX_GMBB_GM 0x66
> -#define B2056_TX_GMBB_IDAC 0x67
> -#define B2056_TX_TXLPF_MASTER 0x68
> -#define B2056_TX_TXLPF_RCCAL 0x69
> -#define B2056_TX_TXLPF_RCCAL_OFF0 0x6A
> -#define B2056_TX_TXLPF_RCCAL_OFF1 0x6B
> -#define B2056_TX_TXLPF_RCCAL_OFF2 0x6C
> -#define B2056_TX_TXLPF_RCCAL_OFF3 0x6D
> -#define B2056_TX_TXLPF_RCCAL_OFF4 0x6E
> -#define B2056_TX_TXLPF_RCCAL_OFF5 0x6F
> -#define B2056_TX_TXLPF_RCCAL_OFF6 0x70
> -#define B2056_TX_TXLPF_BW 0x71
> -#define B2056_TX_TXLPF_GAIN 0x72
> -#define B2056_TX_TXLPF_IDAC 0x73
> -#define B2056_TX_TXLPF_IDAC_0 0x74
> -#define B2056_TX_TXLPF_IDAC_1 0x75
> -#define B2056_TX_TXLPF_IDAC_2 0x76
> -#define B2056_TX_TXLPF_IDAC_3 0x77
> -#define B2056_TX_TXLPF_IDAC_4 0x78
> -#define B2056_TX_TXLPF_IDAC_5 0x79
> -#define B2056_TX_TXLPF_IDAC_6 0x7A
> -#define B2056_TX_TXLPF_OPAMP_IDAC 0x7B
> -#define B2056_TX_TXLPF_MISC 0x7C
> -#define B2056_TX_TXSPARE1 0x7D
> -#define B2056_TX_TXSPARE2 0x7E
> -#define B2056_TX_TXSPARE3 0x7F
> -#define B2056_TX_TXSPARE4 0x80
> -#define B2056_TX_TXSPARE5 0x81
> -#define B2056_TX_TXSPARE6 0x82
> -#define B2056_TX_TXSPARE7 0x83
> -#define B2056_TX_TXSPARE8 0x84
> -#define B2056_TX_TXSPARE9 0x85
> -#define B2056_TX_TXSPARE10 0x86
> -#define B2056_TX_TXSPARE11 0x87
> -#define B2056_TX_TXSPARE12 0x88
> -#define B2056_TX_TXSPARE13 0x89
> -#define B2056_TX_TXSPARE14 0x8A
> -#define B2056_TX_TXSPARE15 0x8B
> -#define B2056_TX_TXSPARE16 0x8C
> -#define B2056_TX_STATUS_INTPA_GAIN 0x8D
> -#define B2056_TX_STATUS_PAD_GAIN 0x8E
> -#define B2056_TX_STATUS_PGA_GAIN 0x8F
> -#define B2056_TX_STATUS_GM_TXLPF_GAIN 0x90
> -#define B2056_TX_STATUS_TXLPF_BW 0x91
> -#define B2056_TX_STATUS_TXLPF_RC 0x92
> -#define B2056_TX_GMBB_IDAC0 0x93
> -#define B2056_TX_GMBB_IDAC1 0x94
> -#define B2056_TX_GMBB_IDAC2 0x95
> -#define B2056_TX_GMBB_IDAC3 0x96
> -#define B2056_TX_GMBB_IDAC4 0x97
> -#define B2056_TX_GMBB_IDAC5 0x98
> -#define B2056_TX_GMBB_IDAC6 0x99
> -#define B2056_TX_GMBB_IDAC7 0x9A
> -
> -#define B2056_RX_RESERVED_ADDR0 0x00
> -#define B2056_RX_IDCODE 0x01
> -#define B2056_RX_RESERVED_ADDR2 0x02
> -#define B2056_RX_RESERVED_ADDR3 0x03
> -#define B2056_RX_RESERVED_ADDR4 0x04
> -#define B2056_RX_RESERVED_ADDR5 0x05
> -#define B2056_RX_RESERVED_ADDR6 0x06
> -#define B2056_RX_RESERVED_ADDR7 0x07
> -#define B2056_RX_COM_CTRL 0x08
> -#define B2056_RX_COM_PU 0x09
> -#define B2056_RX_COM_OVR 0x0A
> -#define B2056_RX_COM_RESET 0x0B
> -#define B2056_RX_COM_RCAL 0x0C
> -#define B2056_RX_COM_RC_RXLPF 0x0D
> -#define B2056_RX_COM_RC_TXLPF 0x0E
> -#define B2056_RX_COM_RC_RXHPF 0x0F
> -#define B2056_RX_RESERVED_ADDR16 0x10
> -#define B2056_RX_RESERVED_ADDR17 0x11
> -#define B2056_RX_RESERVED_ADDR18 0x12
> -#define B2056_RX_RESERVED_ADDR19 0x13
> -#define B2056_RX_RESERVED_ADDR20 0x14
> -#define B2056_RX_RESERVED_ADDR21 0x15
> -#define B2056_RX_RESERVED_ADDR22 0x16
> -#define B2056_RX_RESERVED_ADDR23 0x17
> -#define B2056_RX_RESERVED_ADDR24 0x18
> -#define B2056_RX_RESERVED_ADDR25 0x19
> -#define B2056_RX_RESERVED_ADDR26 0x1A
> -#define B2056_RX_RESERVED_ADDR27 0x1B
> -#define B2056_RX_RESERVED_ADDR28 0x1C
> -#define B2056_RX_RESERVED_ADDR29 0x1D
> -#define B2056_RX_RESERVED_ADDR30 0x1E
> -#define B2056_RX_RESERVED_ADDR31 0x1F
> -#define B2056_RX_RXIQCAL_RXMUX 0x20
> -#define B2056_RX_RSSI_PU 0x21
> -#define B2056_RX_RSSI_SEL 0x22
> -#define B2056_RX_RSSI_GAIN 0x23
> -#define B2056_RX_RSSI_NB_IDAC 0x24
> -#define B2056_RX_RSSI_WB2I_IDAC_1 0x25
> -#define B2056_RX_RSSI_WB2I_IDAC_2 0x26
> -#define B2056_RX_RSSI_WB2Q_IDAC_1 0x27
> -#define B2056_RX_RSSI_WB2Q_IDAC_2 0x28
> -#define B2056_RX_RSSI_POLE 0x29
> -#define B2056_RX_RSSI_WB1_IDAC 0x2A
> -#define B2056_RX_RSSI_MISC 0x2B
> -#define B2056_RX_LNAA_MASTER 0x2C
> -#define B2056_RX_LNAA_TUNE 0x2D
> -#define B2056_RX_LNAA_GAIN 0x2E
> -#define B2056_RX_LNA_A_SLOPE 0x2F
> -#define B2056_RX_BIASPOLE_LNAA1_IDAC 0x30
> -#define B2056_RX_LNAA2_IDAC 0x31
> -#define B2056_RX_LNA1A_MISC 0x32
> -#define B2056_RX_LNAG_MASTER 0x33
> -#define B2056_RX_LNAG_TUNE 0x34
> -#define B2056_RX_LNAG_GAIN 0x35
> -#define B2056_RX_LNA_G_SLOPE 0x36
> -#define B2056_RX_BIASPOLE_LNAG1_IDAC 0x37
> -#define B2056_RX_LNAG2_IDAC 0x38
> -#define B2056_RX_LNA1G_MISC 0x39
> -#define B2056_RX_MIXA_MASTER 0x3A
> -#define B2056_RX_MIXA_VCM 0x3B
> -#define B2056_RX_MIXA_CTRLPTAT 0x3C
> -#define B2056_RX_MIXA_LOB_BIAS 0x3D
> -#define B2056_RX_MIXA_CORE_IDAC 0x3E
> -#define B2056_RX_MIXA_CMFB_IDAC 0x3F
> -#define B2056_RX_MIXA_BIAS_AUX 0x40
> -#define B2056_RX_MIXA_BIAS_MAIN 0x41
> -#define B2056_RX_MIXA_BIAS_MISC 0x42
> -#define B2056_RX_MIXA_MAST_BIAS 0x43
> -#define B2056_RX_MIXG_MASTER 0x44
> -#define B2056_RX_MIXG_VCM 0x45
> -#define B2056_RX_MIXG_CTRLPTAT 0x46
> -#define B2056_RX_MIXG_LOB_BIAS 0x47
> -#define B2056_RX_MIXG_CORE_IDAC 0x48
> -#define B2056_RX_MIXG_CMFB_IDAC 0x49
> -#define B2056_RX_MIXG_BIAS_AUX 0x4A
> -#define B2056_RX_MIXG_BIAS_MAIN 0x4B
> -#define B2056_RX_MIXG_BIAS_MISC 0x4C
> -#define B2056_RX_MIXG_MAST_BIAS 0x4D
> -#define B2056_RX_TIA_MASTER 0x4E
> -#define B2056_RX_TIA_IOPAMP 0x4F
> -#define B2056_RX_TIA_QOPAMP 0x50
> -#define B2056_RX_TIA_IMISC 0x51
> -#define B2056_RX_TIA_QMISC 0x52
> -#define B2056_RX_TIA_GAIN 0x53
> -#define B2056_RX_TIA_SPARE1 0x54
> -#define B2056_RX_TIA_SPARE2 0x55
> -#define B2056_RX_BB_LPF_MASTER 0x56
> -#define B2056_RX_AACI_MASTER 0x57
> -#define B2056_RX_RXLPF_IDAC 0x58
> -#define B2056_RX_RXLPF_OPAMPBIAS_LOWQ 0x59
> -#define B2056_RX_RXLPF_OPAMPBIAS_HIGHQ 0x5A
> -#define B2056_RX_RXLPF_BIAS_DCCANCEL 0x5B
> -#define B2056_RX_RXLPF_OUTVCM 0x5C
> -#define B2056_RX_RXLPF_INVCM_BODY 0x5D
> -#define B2056_RX_RXLPF_CC_OP 0x5E
> -#define B2056_RX_RXLPF_GAIN 0x5F
> -#define B2056_RX_RXLPF_Q_BW 0x60
> -#define B2056_RX_RXLPF_HP_CORNER_BW 0x61
> -#define B2056_RX_RXLPF_RCCAL_HPC 0x62
> -#define B2056_RX_RXHPF_OFF0 0x63
> -#define B2056_RX_RXHPF_OFF1 0x64
> -#define B2056_RX_RXHPF_OFF2 0x65
> -#define B2056_RX_RXHPF_OFF3 0x66
> -#define B2056_RX_RXHPF_OFF4 0x67
> -#define B2056_RX_RXHPF_OFF5 0x68
> -#define B2056_RX_RXHPF_OFF6 0x69
> -#define B2056_RX_RXHPF_OFF7 0x6A
> -#define B2056_RX_RXLPF_RCCAL_LPC 0x6B
> -#define B2056_RX_RXLPF_OFF_0 0x6C
> -#define B2056_RX_RXLPF_OFF_1 0x6D
> -#define B2056_RX_RXLPF_OFF_2 0x6E
> -#define B2056_RX_RXLPF_OFF_3 0x6F
> -#define B2056_RX_RXLPF_OFF_4 0x70
> -#define B2056_RX_UNUSED 0x71
> -#define B2056_RX_VGA_MASTER 0x72
> -#define B2056_RX_VGA_BIAS 0x73
> -#define B2056_RX_VGA_BIAS_DCCANCEL 0x74
> -#define B2056_RX_VGA_GAIN 0x75
> -#define B2056_RX_VGA_HP_CORNER_BW 0x76
> -#define B2056_RX_VGABUF_BIAS 0x77
> -#define B2056_RX_VGABUF_GAIN_BW 0x78
> -#define B2056_RX_TXFBMIX_A 0x79
> -#define B2056_RX_TXFBMIX_G 0x7A
> -#define B2056_RX_RXSPARE1 0x7B
> -#define B2056_RX_RXSPARE2 0x7C
> -#define B2056_RX_RXSPARE3 0x7D
> -#define B2056_RX_RXSPARE4 0x7E
> -#define B2056_RX_RXSPARE5 0x7F
> -#define B2056_RX_RXSPARE6 0x80
> -#define B2056_RX_RXSPARE7 0x81
> -#define B2056_RX_RXSPARE8 0x82
> -#define B2056_RX_RXSPARE9 0x83
> -#define B2056_RX_RXSPARE10 0x84
> -#define B2056_RX_RXSPARE11 0x85
> -#define B2056_RX_RXSPARE12 0x86
> -#define B2056_RX_RXSPARE13 0x87
> -#define B2056_RX_RXSPARE14 0x88
> -#define B2056_RX_RXSPARE15 0x89
> -#define B2056_RX_RXSPARE16 0x8A
> -#define B2056_RX_STATUS_LNAA_GAIN 0x8B
> -#define B2056_RX_STATUS_LNAG_GAIN 0x8C
> -#define B2056_RX_STATUS_MIXTIA_GAIN 0x8D
> -#define B2056_RX_STATUS_RXLPF_GAIN 0x8E
> -#define B2056_RX_STATUS_VGA_BUF_GAIN 0x8F
> -#define B2056_RX_STATUS_RXLPF_Q 0x90
> -#define B2056_RX_STATUS_RXLPF_BUF_BW 0x91
> -#define B2056_RX_STATUS_RXLPF_VGA_HPC 0x92
> -#define B2056_RX_STATUS_RXLPF_RC 0x93
> -#define B2056_RX_STATUS_HPC_RC 0x94
> -
> -#define B2056_LNA1_A_PU 0x01
> -#define B2056_LNA2_A_PU 0x02
> -#define B2056_LNA1_G_PU 0x01
> -#define B2056_LNA2_G_PU 0x02
> -#define B2056_MIXA_PU_I 0x01
> -#define B2056_MIXA_PU_Q 0x02
> -#define B2056_MIXA_PU_GM 0x10
> -#define B2056_MIXG_PU_I 0x01
> -#define B2056_MIXG_PU_Q 0x02
> -#define B2056_MIXG_PU_GM 0x10
> -#define B2056_TIA_PU 0x01
> -#define B2056_BB_LPF_PU 0x20
> -#define B2056_W1_PU 0x02
> -#define B2056_W2_PU 0x04
> -#define B2056_NB_PU 0x08
> -#define B2056_RSSI_W1_SEL 0x02
> -#define B2056_RSSI_W2_SEL 0x04
> -#define B2056_RSSI_NB_SEL 0x08
> -#define B2056_VCM_MASK 0x1C
> -#define B2056_RSSI_VCM_SHIFT 0x02
> -
> struct b43_nphy_channeltab_entry_rev3 {
> /* The channel frequency in MHz */
> u16 freq;
>
^ permalink raw reply
* Re: [PATCH v2] net: ipv4: emulate READ_ONCE() on ->hdrincl bit-field in raw_sendmsg()
From: David Miller @ 2018-01-09 16:59 UTC (permalink / raw)
To: nstange
Cc: kuznet, yoshfuji, simo.ghannam, mkubecek, mbenes, sbrivio, netdev,
linux-kernel
In-Reply-To: <20180108145444.19457-1-nstange@suse.de>
From: Nicolai Stange <nstange@suse.de>
Date: Mon, 8 Jan 2018 15:54:44 +0100
> Commit 8f659a03a0ba ("net: ipv4: fix for a race condition in
> raw_sendmsg") fixed the issue of possibly inconsistent ->hdrincl handling
> due to concurrent updates by reading this bit-field member into a local
> variable and using the thus stabilized value in subsequent tests.
>
> However, aforementioned commit also adds the (correct) comment that
>
> /* hdrincl should be READ_ONCE(inet->hdrincl)
> * but READ_ONCE() doesn't work with bit fields
> */
>
> because as it stands, the compiler is free to shortcut or even eliminate
> the local variable at its will.
>
> Note that I have not seen anything like this happening in reality and thus,
> the concern is a theoretical one.
>
> However, in order to be on the safe side, emulate a READ_ONCE() on the
> bit-field by doing it on the local 'hdrincl' variable itself:
>
> int hdrincl = inet->hdrincl;
> hdrincl = READ_ONCE(hdrincl);
>
> This breaks the chain in the sense that the compiler is not allowed
> to replace subsequent reads from hdrincl with reloads from inet->hdrincl.
>
> Fixes: 8f659a03a0ba ("net: ipv4: fix for a race condition in raw_sendmsg")
> Signed-off-by: Nicolai Stange <nstange@suse.de>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH 0/2] Ether fixes for the SolutionEngine771x boards
From: Sergei Shtylyov @ 2018-01-09 17:06 UTC (permalink / raw)
To: David Miller; +Cc: ysato, dalias, linux-sh, netdev
In-Reply-To: <20180109.113915.2115013830186148164.davem@davemloft.net>
On 01/09/2018 07:39 PM, David Miller wrote:
>>>> Here's the series of 2 patches against Linus' repo. This series should
>>>> (hoplefully) fix the Ether support on the SolutionEngine771x boards...
>>>>
>>>> [1/2] SolutionEngine771x: fix Ether platform data
>>>> [2/2] SolutionEngine771x: add Ether TSU resource
>>> Looks like this doesn't go through my tree.
>>
>> Yeah, we have the SH kernel maintained now... but I have a bad feeling
>> looking at their patchwork: it shows no recently applied patches. :-/
>>
>>> Let me know if it should.
>>
>> We'll wait and see, I think...
>
> So, any update on this?
Joking? ;-)
They don't reply to a fix for a month...
MBR, Sergei
^ permalink raw reply
* kcm: memory leak in kcm_sendmsg
From: Dmitry Vyukov @ 2018-01-09 17:14 UTC (permalink / raw)
To: David Miller, Tom Herbert, Cong Wang, Al Viro, Eric Dumazet,
xiaolou4617, Tobias Klauser, Eric Biggers, netdev, LKML,
syzkaller
[-- Attachment #1: Type: text/plain, Size: 2537 bytes --]
Hello,
syzkaller has discovered the following memory leak:
unreferenced object 0xffff8800655d5e20 (size 512):
comm "a.out", pid 10342, jiffies 4295928494 (age 24.051s)
hex dump (first 32 bytes):
80 6b 5d 65 00 88 ff ff 69 63 65 73 2f 76 69 72 .k]e....ices/vir
74 75 61 6c 2f 6e 65 74 2f 74 75 6e 6c 30 2f 71 tual/net/tunl0/q
backtrace:
[<0000000017222de2>] kmemleak_alloc_recursive
include/linux/kmemleak.h:55 [inline]
[<0000000017222de2>] slab_post_alloc_hook mm/slab.h:440 [inline]
[<0000000017222de2>] slab_alloc_node mm/slub.c:2725 [inline]
[<0000000017222de2>] __kmalloc_node_track_caller+0x19f/0x360 mm/slub.c:4320
[<00000000468595b2>] __kmalloc_reserve.isra.39+0x3a/0xe0
net/core/skbuff.c:137
[<000000005d645735>] __alloc_skb+0x144/0x7c0 net/core/skbuff.c:205
[<0000000076b4c539>] alloc_skb include/linux/skbuff.h:983 [inline]
[<0000000076b4c539>] kcm_sendmsg+0x66a/0x2480 net/kcm/kcmsock.c:968
[<0000000035be3c2b>] sock_sendmsg_nosec net/socket.c:636 [inline]
[<0000000035be3c2b>] sock_sendmsg+0xd2/0x120 net/socket.c:646
[<00000000abbae6ad>] SYSC_sendto+0x3de/0x640 net/socket.c:1727
[<00000000b55ba03b>] SyS_sendto+0x40/0x50 net/socket.c:1695
[<000000005d14bb62>] entry_SYSCALL_64_fastpath+0x23/0x9a
[<0000000000cf1810>] 0xffffffffffffffff
unreferenced object 0xffff880053801e40 (size 232):
comm "a.out", pid 10342, jiffies 4295928494 (age 24.051s)
hex dump (first 32 bytes):
c0 20 80 53 00 88 ff ff 00 00 00 00 00 00 00 00 . .S............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000519e860b>] kmemleak_alloc_recursive
include/linux/kmemleak.h:55 [inline]
[<00000000519e860b>] slab_post_alloc_hook mm/slab.h:440 [inline]
[<00000000519e860b>] slab_alloc_node mm/slub.c:2725 [inline]
[<00000000519e860b>] kmem_cache_alloc_node+0x12d/0x2a0 mm/slub.c:2761
[<000000001a066279>] __alloc_skb+0x103/0x7c0 net/core/skbuff.c:193
[<0000000076b4c539>] alloc_skb include/linux/skbuff.h:983 [inline]
[<0000000076b4c539>] kcm_sendmsg+0x66a/0x2480 net/kcm/kcmsock.c:968
[<0000000035be3c2b>] sock_sendmsg_nosec net/socket.c:636 [inline]
[<0000000035be3c2b>] sock_sendmsg+0xd2/0x120 net/socket.c:646
[<00000000abbae6ad>] SYSC_sendto+0x3de/0x640 net/socket.c:1727
[<00000000b55ba03b>] SyS_sendto+0x40/0x50 net/socket.c:1695
[<000000005d14bb62>] entry_SYSCALL_64_fastpath+0x23/0x9a
[<0000000000cf1810>] 0xffffffffffffffff
Reproducer is attached. On 4.15-rc7.
[-- Attachment #2: kcm.c --]
[-- Type: text/x-csrc, Size: 12385 bytes --]
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#define _GNU_SOURCE
#include <dirent.h>
#include <endian.h>
#include <errno.h>
#include <linux/futex.h>
#include <pthread.h>
#include <sched.h>
#include <signal.h>
#include <stdarg.h>
#include <stdbool.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/mount.h>
#include <sys/prctl.h>
#include <sys/resource.h>
#include <sys/syscall.h>
#include <sys/time.h>
#include <sys/wait.h>
#include <time.h>
#include <unistd.h>
__attribute__((noreturn)) static void doexit(int status)
{
volatile unsigned i;
syscall(__NR_exit_group, status);
for (i = 0;; i++) {
}
}
#include <errno.h>
#include <setjmp.h>
#include <signal.h>
#include <stdarg.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/stat.h>
const int kFailStatus = 67;
const int kRetryStatus = 69;
static void fail(const char* msg, ...)
{
int e = errno;
va_list args;
va_start(args, msg);
vfprintf(stderr, msg, args);
va_end(args);
fprintf(stderr, " (errno %d)\n", e);
doexit((e == ENOMEM || e == EAGAIN) ? kRetryStatus : kFailStatus);
}
static void exitf(const char* msg, ...)
{
int e = errno;
va_list args;
va_start(args, msg);
vfprintf(stderr, msg, args);
va_end(args);
fprintf(stderr, " (errno %d)\n", e);
doexit(kRetryStatus);
}
static __thread int skip_segv;
static __thread jmp_buf segv_env;
static void segv_handler(int sig, siginfo_t* info, void* uctx)
{
uintptr_t addr = (uintptr_t)info->si_addr;
const uintptr_t prog_start = 1 << 20;
const uintptr_t prog_end = 100 << 20;
if (__atomic_load_n(&skip_segv, __ATOMIC_RELAXED) &&
(addr < prog_start || addr > prog_end)) {
_longjmp(segv_env, 1);
}
doexit(sig);
}
static void install_segv_handler()
{
struct sigaction sa;
memset(&sa, 0, sizeof(sa));
sa.sa_handler = SIG_IGN;
syscall(SYS_rt_sigaction, 0x20, &sa, NULL, 8);
syscall(SYS_rt_sigaction, 0x21, &sa, NULL, 8);
memset(&sa, 0, sizeof(sa));
sa.sa_sigaction = segv_handler;
sa.sa_flags = SA_NODEFER | SA_SIGINFO;
sigaction(SIGSEGV, &sa, NULL);
sigaction(SIGBUS, &sa, NULL);
}
#define NONFAILING(...) \
{ \
__atomic_fetch_add(&skip_segv, 1, __ATOMIC_SEQ_CST); \
if (_setjmp(segv_env) == 0) { \
__VA_ARGS__; \
} \
__atomic_fetch_sub(&skip_segv, 1, __ATOMIC_SEQ_CST); \
}
static uint64_t current_time_ms()
{
struct timespec ts;
if (clock_gettime(CLOCK_MONOTONIC, &ts))
fail("clock_gettime failed");
return (uint64_t)ts.tv_sec * 1000 + (uint64_t)ts.tv_nsec / 1000000;
}
static void use_temporary_dir()
{
char tmpdir_template[] = "./syzkaller.XXXXXX";
char* tmpdir = mkdtemp(tmpdir_template);
if (!tmpdir)
fail("failed to mkdtemp");
if (chmod(tmpdir, 0777))
fail("failed to chmod");
if (chdir(tmpdir))
fail("failed to chdir");
}
static void loop();
static void sandbox_common()
{
prctl(PR_SET_PDEATHSIG, SIGKILL, 0, 0, 0);
setpgrp();
setsid();
struct rlimit rlim;
rlim.rlim_cur = rlim.rlim_max = 128 << 20;
setrlimit(RLIMIT_AS, &rlim);
rlim.rlim_cur = rlim.rlim_max = 8 << 20;
setrlimit(RLIMIT_MEMLOCK, &rlim);
rlim.rlim_cur = rlim.rlim_max = 1 << 20;
setrlimit(RLIMIT_FSIZE, &rlim);
rlim.rlim_cur = rlim.rlim_max = 1 << 20;
setrlimit(RLIMIT_STACK, &rlim);
rlim.rlim_cur = rlim.rlim_max = 0;
setrlimit(RLIMIT_CORE, &rlim);
#define CLONE_NEWCGROUP 0x02000000
unshare(CLONE_NEWNS);
unshare(CLONE_NEWIPC);
unshare(CLONE_NEWCGROUP);
unshare(CLONE_NEWNET);
unshare(CLONE_NEWUTS);
unshare(CLONE_SYSVSEM);
}
static int do_sandbox_none(int executor_pid, bool enable_tun)
{
unshare(CLONE_NEWPID);
int pid = fork();
if (pid < 0)
fail("sandbox fork failed");
if (pid)
return pid;
sandbox_common();
loop();
doexit(1);
}
static void remove_dir(const char* dir)
{
DIR* dp;
struct dirent* ep;
int iter = 0;
retry:
dp = opendir(dir);
if (dp == NULL) {
if (errno == EMFILE) {
exitf("opendir(%s) failed due to NOFILE, exiting", dir);
}
exitf("opendir(%s) failed", dir);
}
while ((ep = readdir(dp))) {
if (strcmp(ep->d_name, ".") == 0 || strcmp(ep->d_name, "..") == 0)
continue;
char filename[FILENAME_MAX];
snprintf(filename, sizeof(filename), "%s/%s", dir, ep->d_name);
struct stat st;
if (lstat(filename, &st))
exitf("lstat(%s) failed", filename);
if (S_ISDIR(st.st_mode)) {
remove_dir(filename);
continue;
}
int i;
for (i = 0;; i++) {
if (unlink(filename) == 0)
break;
if (errno == EROFS) {
break;
}
if (errno != EBUSY || i > 100)
exitf("unlink(%s) failed", filename);
if (umount2(filename, MNT_DETACH))
exitf("umount(%s) failed", filename);
}
}
closedir(dp);
int i;
for (i = 0;; i++) {
if (rmdir(dir) == 0)
break;
if (i < 100) {
if (errno == EROFS) {
break;
}
if (errno == EBUSY) {
if (umount2(dir, MNT_DETACH))
exitf("umount(%s) failed", dir);
continue;
}
if (errno == ENOTEMPTY) {
if (iter < 100) {
iter++;
goto retry;
}
}
}
exitf("rmdir(%s) failed", dir);
}
}
static void test();
void loop()
{
int iter;
for (iter = 0;; iter++) {
char cwdbuf[256];
sprintf(cwdbuf, "./%d", iter);
if (mkdir(cwdbuf, 0777))
fail("failed to mkdir");
int pid = fork();
if (pid < 0)
fail("loop fork failed");
if (pid == 0) {
prctl(PR_SET_PDEATHSIG, SIGKILL, 0, 0, 0);
setpgrp();
if (chdir(cwdbuf))
fail("failed to chdir");
test();
doexit(0);
}
int status = 0;
uint64_t start = current_time_ms();
for (;;) {
int res = waitpid(-1, &status, __WALL | WNOHANG);
if (res == pid)
break;
usleep(1000);
if (current_time_ms() - start > 5 * 1000) {
kill(-pid, SIGKILL);
kill(pid, SIGKILL);
while (waitpid(-1, &status, __WALL) != pid) {
}
break;
}
}
remove_dir(cwdbuf);
}
}
struct thread_t {
int created, running, call;
pthread_t th;
};
static struct thread_t threads[16];
static void execute_call(int call);
static int running;
static int collide;
static void* thr(void* arg)
{
struct thread_t* th = (struct thread_t*)arg;
for (;;) {
while (!__atomic_load_n(&th->running, __ATOMIC_ACQUIRE))
syscall(SYS_futex, &th->running, FUTEX_WAIT, 0, 0);
execute_call(th->call);
__atomic_fetch_sub(&running, 1, __ATOMIC_RELAXED);
__atomic_store_n(&th->running, 0, __ATOMIC_RELEASE);
syscall(SYS_futex, &th->running, FUTEX_WAKE);
}
return 0;
}
static void execute(int num_calls)
{
int call, thread;
running = 0;
for (call = 0; call < num_calls; call++) {
for (thread = 0; thread < sizeof(threads) / sizeof(threads[0]); thread++) {
struct thread_t* th = &threads[thread];
if (!th->created) {
th->created = 1;
pthread_attr_t attr;
pthread_attr_init(&attr);
pthread_attr_setstacksize(&attr, 128 << 10);
pthread_create(&th->th, &attr, thr, th);
}
if (!__atomic_load_n(&th->running, __ATOMIC_ACQUIRE)) {
th->call = call;
__atomic_fetch_add(&running, 1, __ATOMIC_RELAXED);
__atomic_store_n(&th->running, 1, __ATOMIC_RELEASE);
syscall(SYS_futex, &th->running, FUTEX_WAKE);
if (collide && call % 2)
break;
struct timespec ts;
ts.tv_sec = 0;
ts.tv_nsec = 20 * 1000 * 1000;
syscall(SYS_futex, &th->running, FUTEX_WAIT, 1, &ts);
if (running)
usleep((call == num_calls - 1) ? 10000 : 1000);
break;
}
}
}
}
long r[3];
uint64_t procid;
void execute_call(int call)
{
switch (call) {
case 0:
syscall(__NR_mmap, 0x20000000, 0xfff000, 3, 0x32, -1, 0);
break;
case 1:
r[0] = syscall(__NR_socket, 0x29, 0x802, 0);
break;
case 2:
NONFAILING(*(uint64_t*)0x20556915 = 0x20b9cfe4);
NONFAILING(*(uint32_t*)0x2055691d = 0x1c);
NONFAILING(*(uint64_t*)0x20556925 = 0x20812000);
NONFAILING(*(uint64_t*)0x2055692d = 1);
NONFAILING(*(uint64_t*)0x20556935 = 0x20868000);
NONFAILING(*(uint64_t*)0x2055693d = 0);
NONFAILING(*(uint32_t*)0x20556945 = 0);
NONFAILING(*(uint32_t*)0x2055694d = 0);
NONFAILING(*(uint16_t*)0x20b9cfe4 = 0xa);
NONFAILING(*(uint16_t*)0x20b9cfe6 = htobe16(0x4e20 + procid * 4));
NONFAILING(*(uint32_t*)0x20b9cfe8 = 0);
NONFAILING(*(uint8_t*)0x20b9cfec = 0xfe);
NONFAILING(*(uint8_t*)0x20b9cfed = 0x80);
NONFAILING(*(uint8_t*)0x20b9cfee = 0);
NONFAILING(*(uint8_t*)0x20b9cfef = 0);
NONFAILING(*(uint8_t*)0x20b9cff0 = 0);
NONFAILING(*(uint8_t*)0x20b9cff1 = 0);
NONFAILING(*(uint8_t*)0x20b9cff2 = 0);
NONFAILING(*(uint8_t*)0x20b9cff3 = 0);
NONFAILING(*(uint8_t*)0x20b9cff4 = 0);
NONFAILING(*(uint8_t*)0x20b9cff5 = 0);
NONFAILING(*(uint8_t*)0x20b9cff6 = 0);
NONFAILING(*(uint8_t*)0x20b9cff7 = 0);
NONFAILING(*(uint8_t*)0x20b9cff8 = 0);
NONFAILING(*(uint8_t*)0x20b9cff9 = 0);
NONFAILING(*(uint8_t*)0x20b9cffa = 0 + procid * 1);
NONFAILING(*(uint8_t*)0x20b9cffb = 0xaa);
NONFAILING(*(uint32_t*)0x20b9cffc = 0);
NONFAILING(*(uint64_t*)0x20812000 = 0x20cd7fd2);
NONFAILING(*(uint64_t*)0x20812008 = 1);
NONFAILING(memcpy((void*)0x20cd7fd2, "G", 1));
syscall(__NR_sendmmsg, r[0], 0x20556915, 1, 0x8010);
break;
case 3:
NONFAILING(*(uint32_t*)0x205a6000 = r[0]);
if (syscall(__NR_ioctl, r[0], 0x89e2, 0x205a6000) != -1)
NONFAILING(r[1] = *(uint32_t*)0x205a6000);
break;
case 4:
NONFAILING(*(uint32_t*)0x209d0ffc = 0xe8);
if (syscall(__NR_getsockopt, r[1], 0, 0x10, 0x20d7f000, 0x209d0ffc) != -1)
NONFAILING(r[2] = *(uint32_t*)0x20d7f030);
break;
case 5:
NONFAILING(*(uint8_t*)0x20df7fe8 = 0xfe);
NONFAILING(*(uint8_t*)0x20df7fe9 = 0x80);
NONFAILING(*(uint8_t*)0x20df7fea = 0);
NONFAILING(*(uint8_t*)0x20df7feb = 0);
NONFAILING(*(uint8_t*)0x20df7fec = 0);
NONFAILING(*(uint8_t*)0x20df7fed = 0);
NONFAILING(*(uint8_t*)0x20df7fee = 0);
NONFAILING(*(uint8_t*)0x20df7fef = 0);
NONFAILING(*(uint8_t*)0x20df7ff0 = 0);
NONFAILING(*(uint8_t*)0x20df7ff1 = 0);
NONFAILING(*(uint8_t*)0x20df7ff2 = 0);
NONFAILING(*(uint8_t*)0x20df7ff3 = 0);
NONFAILING(*(uint8_t*)0x20df7ff4 = 0);
NONFAILING(*(uint8_t*)0x20df7ff5 = 0);
NONFAILING(*(uint8_t*)0x20df7ff6 = 0 + procid * 1);
NONFAILING(*(uint8_t*)0x20df7ff7 = 0xbb);
NONFAILING(*(uint32_t*)0x20df7ff8 = 8);
NONFAILING(*(uint32_t*)0x20df7ffc = r[2]);
syscall(__NR_ioctl, r[1], 0x8916, 0x20df7fe8);
break;
case 6:
NONFAILING(*(uint64_t*)0x20dc8000 = 0x205d1000);
NONFAILING(*(uint32_t*)0x20dc8008 = 0xa);
NONFAILING(*(uint64_t*)0x20dc8010 = 0x20277000);
NONFAILING(*(uint64_t*)0x20dc8018 = 1);
NONFAILING(*(uint64_t*)0x20dc8020 = 0x20000000);
NONFAILING(*(uint64_t*)0x20dc8028 = 0);
NONFAILING(*(uint32_t*)0x20dc8030 = 0);
NONFAILING(*(uint16_t*)0x205d1000 = 0);
NONFAILING(memcpy((void*)0x205d1002, "./file0", 8));
NONFAILING(*(uint64_t*)0x20277000 = 0x20cc8000);
NONFAILING(*(uint64_t*)0x20277008 = 1);
NONFAILING(memcpy((void*)0x20cc8000, "\xab", 1));
syscall(__NR_sendmsg, r[1], 0x20dc8000, 0);
break;
case 7:
syscall(__NR_sendto, r[0], 0x209ccff0, 0x7fffffff, 0, 0x20000000, 0);
break;
}
}
void test()
{
memset(r, -1, sizeof(r));
execute(8);
collide = 1;
execute(8);
}
int main()
{
char* cwd = get_current_dir_name();
for (procid = 0; procid < 8; procid++) {
if (fork() == 0) {
install_segv_handler();
for (;;) {
if (chdir(cwd))
fail("failed to chdir");
use_temporary_dir();
int pid = do_sandbox_none(procid, false);
int status = 0;
while (waitpid(pid, &status, __WALL) != pid) {
}
}
}
}
sleep(1000000);
return 0;
}
^ permalink raw reply
* Re: [PATCH 23/31] aio: don't print the page size at boot time
From: Jeff Moyer @ 2018-01-09 17:18 UTC (permalink / raw)
To: Christoph Hellwig
Cc: viro, Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-kernel
In-Reply-To: <20180104080043.14506-24-hch@lst.de>
Christoph Hellwig <hch@lst.de> writes:
> The page size is in no way related to the aio code, and printing it in
> the (debug) dmesg at every boot serves no purpose.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jeff Moyer <jmoyer@redhat.com>
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: [PATCH] docs-rst: networking: wire up msg_zerocopy
From: David Miller @ 2018-01-09 17:19 UTC (permalink / raw)
To: rppt; +Cc: linux-doc, corbet, mchehab, willemb, netdev
In-Reply-To: <1515394217-24725-1-git-send-email-rppt@linux.vnet.ibm.com>
From: Mike Rapoport <rppt@linux.vnet.ibm.com>
Date: Mon, 8 Jan 2018 08:50:17 +0200
> Fix the following 'make htmldocs' complaint:
>
> Documentation/networking/msg_zerocopy.rst:: WARNING: document isn't included in any toctree.
>
> Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH] docs-rst: networking: wire up msg_zerocopy
From: David Miller @ 2018-01-09 17:19 UTC (permalink / raw)
To: corbet; +Cc: rppt, linux-doc, mchehab, willemb, netdev
In-Reply-To: <20180109095527.460de32c@lwn.net>
From: Jonathan Corbet <corbet@lwn.net>
Date: Tue, 9 Jan 2018 09:55:27 -0700
> On Tue, 09 Jan 2018 11:50:49 -0500 (EST)
> David Miller <davem@davemloft.net> wrote:
>
>> From: Mike Rapoport <rppt@linux.vnet.ibm.com>
>> Date: Mon, 8 Jan 2018 08:50:17 +0200
>>
>> > Fix the following 'make htmldocs' complaint:
>> >
>> > Documentation/networking/msg_zerocopy.rst:: WARNING: document isn't included in any toctree.
>> >
>> > Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
>>
>> Does someone else want to take this?
>>
>> Otherwise I can.
>
> I can certainly take it (or the equivalent patch posted by Tobin a few
> days earlier) through the docs tree. I've been holding off, though,
> under the impression that you'd rather take networking docs patches
> yourself. Either is fine. Unless you say you've grabbed it, I'll do so
> in the near future.
Oh then I'll take it.
Thanks Jon!
^ permalink raw reply
* Re: [PATCH 24/31] aio: remove an outdated comment in aio_complete
From: Jeff Moyer @ 2018-01-09 17:19 UTC (permalink / raw)
To: Christoph Hellwig
Cc: viro, Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-kernel
In-Reply-To: <20180104080043.14506-25-hch@lst.de>
Christoph Hellwig <hch@lst.de> writes:
> These days we don't treat sync iocbs special in the aio completion code as
> they never use it. Remove the old comment, and move the BUG_ON for a sync
> iocb to the top of the function.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Right, this should have been part of commit 599bd19bdc4c6 ("fs: don't
allow to complete sync iocbs through aio_complete").
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
> ---
> fs/aio.c | 11 ++---------
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/fs/aio.c b/fs/aio.c
> index 03d59593912d..41fc8ce6bc7f 100644
> --- a/fs/aio.c
> +++ b/fs/aio.c
> @@ -1088,6 +1088,8 @@ static void aio_complete(struct kiocb *kiocb, long res, long res2)
> unsigned tail, pos, head;
> unsigned long flags;
>
> + BUG_ON(is_sync_kiocb(kiocb));
> +
> if (kiocb->ki_flags & IOCB_WRITE) {
> struct file *file = kiocb->ki_filp;
>
> @@ -1100,15 +1102,6 @@ static void aio_complete(struct kiocb *kiocb, long res, long res2)
> file_end_write(file);
> }
>
> - /*
> - * Special case handling for sync iocbs:
> - * - events go directly into the iocb for fast handling
> - * - the sync task with the iocb in its stack holds the single iocb
> - * ref, no other paths have a way to get another ref
> - * - the sync task helpfully left a reference to itself in the iocb
> - */
> - BUG_ON(is_sync_kiocb(kiocb));
> -
> if (iocb->ki_list.next) {
> unsigned long flags;
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: [PATCH 0/2] Ether fixes for the SolutionEngine771x boards
From: David Miller @ 2018-01-09 17:21 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: ysato, dalias, linux-sh, netdev
In-Reply-To: <20180106185325.481875686@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Sat, 06 Jan 2018 21:53:25 +0300
> Here's the series of 2 patches against Linus' repo. This series should
> (hoplefully) fix the Ether support on the SolutionEngine771x boards...
>
> [1/2] SolutionEngine771x: fix Ether platform data
> [2/2] SolutionEngine771x: add Ether TSU resource
Applied to 'net', thanks Sergei.
^ permalink raw reply
* Re: [PATCH] ipvlan: fix ipvlan MTU limits
From: Mahesh Bandewar (महेश बंडेवार) @ 2018-01-09 17:21 UTC (permalink / raw)
To: liuqifa
Cc: David Miller, dsahern, mschiffer, idosch, fw, kjlx,
girish.moodalbail, sainath.grandhi, linux-netdev
In-Reply-To: <20180109064837.12916-1-liuqifa@huawei.com>
On Mon, Jan 8, 2018 at 10:48 PM, <liuqifa@huawei.com> wrote:
> From: Keefe Liu <liuqifa@huawei.com>
>
> The MTU of ipvlan interface should not bigger than the phy device, When we
> run following scripts, we will find there are some problems.
> Step1:
> ip link add link eth0 name ipv1 type ipvlan mode l2
> ip netns add net1
> ip link set dev ipv1 netns net1
> Step2:
> ip netns exec net1 ip link set dev ipv1 mtu 1501
> RTNETLINK answers: Invalid argument
> dmesg info: "ipv1: Invalid MTU 1501 requested, hw max 1500"
> Step3:
> ip link set dev eth0 mtu 1600
> ip netns exec net1 ip link set dev ipv1 mtu 1501
> RTNETLINK answers: Invalid argument
> dmesg info: "ipv1: Invalid MTU 1501 requested, hw max 1500"
> Step4:
> ip link set dev eth0 mtu 1400
> ip netns exec net1 ip link set dev ipv1 mtu 1500
> The result of Step2 is we expected, but the result of Step3 and Step4
> are not.
>
> This patch set ipvlan's maximum MTU to ETH_MAX_MTU, and when we change
> the ipvlan device's MTU, ipvlan_change_mtu() will make sure the new MTU
> no larger than the phy device's MTU.
>
> Signed-off-by: Keefe Liu <liuqifa@huawei.com>
> ---
> drivers/net/ipvlan/ipvlan_main.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/net/ipvlan/ipvlan_main.c b/drivers/net/ipvlan/ipvlan_main.c
> index 30cb803..84c007d 100644
> --- a/drivers/net/ipvlan/ipvlan_main.c
> +++ b/drivers/net/ipvlan/ipvlan_main.c
> @@ -380,12 +380,24 @@ static int ipvlan_get_iflink(const struct net_device *dev)
> return ipvlan->phy_dev->ifindex;
> }
>
> +static int ipvlan_change_mtu(struct net_device *dev, int new_mtu)
> +{
> + struct ipvl_dev *ipvlan = netdev_priv(dev);
> +
> + if (ipvlan->phy_dev->mtu < new_mtu)
> + return -EINVAL;
> +
> + dev->mtu = new_mtu;
> + return 0;
> +}
> +
> static const struct net_device_ops ipvlan_netdev_ops = {
> .ndo_init = ipvlan_init,
> .ndo_uninit = ipvlan_uninit,
> .ndo_open = ipvlan_open,
> .ndo_stop = ipvlan_stop,
> .ndo_start_xmit = ipvlan_start_xmit,
> + .ndo_change_mtu = ipvlan_change_mtu,
> .ndo_fix_features = ipvlan_fix_features,
> .ndo_change_rx_flags = ipvlan_change_rx_flags,
> .ndo_set_rx_mode = ipvlan_set_multicast_mac_filter,
> @@ -680,6 +692,8 @@ void ipvlan_link_setup(struct net_device *dev)
> {
> ether_setup(dev);
>
> + dev->min_mtu = 0;
should be ETH_MIN_MTU since we expect the underlying device to be
ETH_ARPHDR and IPvlan deals with IPv4/IPv6.
> + dev->max_mtu = ETH_MAX_MTU;
> dev->priv_flags &= ~(IFF_XMIT_DST_RELEASE | IFF_TX_SKB_SHARING);
> dev->priv_flags |= IFF_UNICAST_FLT | IFF_NO_QUEUE;
> dev->netdev_ops = &ipvlan_netdev_ops;
> --
> 1.8.3.1
>
>
These changes are not sufficient if you want to have different
per-slave mtu settings. One can always change the MTU of the master
device and all per-slave settings will get wiped. I don't think
that's a desired outcome.
^ permalink raw reply
* AF_KEY: memory leak in key_notify_policy
From: Dmitry Vyukov @ 2018-01-09 17:23 UTC (permalink / raw)
To: Steffen Klassert, Herbert Xu, David Miller, netdev, LKML,
Eric Biggers, syzkaller
Hello,
syzkaller has hit the following memory leak on 4.15-rc7:
unreferenced object 0xffff88001ea69cc0 (size 232):
comm "syz-executor6", pid 4338, jiffies 4294719848 (age 11.965s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<000000004139cfa6>] kmemleak_alloc_recursive
include/linux/kmemleak.h:55 [inline]
[<000000004139cfa6>] slab_post_alloc_hook mm/slab.h:440 [inline]
[<000000004139cfa6>] slab_alloc_node mm/slub.c:2725 [inline]
[<000000004139cfa6>] kmem_cache_alloc_node+0x12d/0x2a0 mm/slub.c:2761
[<0000000071fee1f9>] __alloc_skb+0x103/0x7c0 net/core/skbuff.c:193
[<00000000b7305c65>] alloc_skb include/linux/skbuff.h:983 [inline]
[<00000000b7305c65>] pfkey_xfrm_policy2msg_prep+0x29/0x50
net/key/af_key.c:2029
[<000000008b2518b3>] key_notify_policy net/key/af_key.c:2192 [inline]
[<000000008b2518b3>] pfkey_send_policy_notify+0x47f/0x920
net/key/af_key.c:3065
[<0000000038eae3c6>] km_policy_notify+0x198/0x330 net/xfrm/xfrm_state.c:1907
[<000000000c1a40c2>] xfrm_add_policy+0x733/0x9a0 net/xfrm/xfrm_user.c:1613
[<000000001c692c3f>] xfrm_user_rcv_msg+0x454/0x890 net/xfrm/xfrm_user.c:2591
[<0000000048c3aba7>] netlink_rcv_skb+0x275/0x550
net/netlink/af_netlink.c:2408
[<00000000649d0c12>] xfrm_netlink_rcv+0x6f/0x90 net/xfrm/xfrm_user.c:2599
[<00000000c67992ca>] netlink_unicast_kernel
net/netlink/af_netlink.c:1275 [inline]
[<00000000c67992ca>] netlink_unicast+0x567/0x710
net/netlink/af_netlink.c:1301
[<00000000614f28d1>] netlink_sendmsg+0x9c4/0xf60
net/netlink/af_netlink.c:1864
[<000000004abc1891>] sock_sendmsg_nosec net/socket.c:636 [inline]
[<000000004abc1891>] sock_sendmsg+0xd2/0x120 net/socket.c:646
[<0000000067a5f2bd>] ___sys_sendmsg+0x7f6/0x930 net/socket.c:2026
[<00000000ba6aef1c>] __sys_sendmsg+0xe6/0x220 net/socket.c:2060
[<0000000051af4885>] SYSC_sendmsg net/socket.c:2071 [inline]
[<0000000051af4885>] SyS_sendmsg+0x36/0x60 net/socket.c:2067
[<00000000e00c5f48>] entry_SYSCALL_64_fastpath+0x23/0x9a
It seems that key_notify_policy() fails to free the skb when
pfkey_xfrm_policy2msg() fails.
^ permalink raw reply
* Re: Re: dvb usb issues since kernel 4.9
From: Eric Dumazet @ 2018-01-09 17:27 UTC (permalink / raw)
To: Josef Griebichler
Cc: Jesper Dangaard Brouer, Peter Zijlstra, Mauro Carvalho Chehab,
Alan Stern, Greg Kroah-Hartman, linux-usb, Rik van Riel,
Paolo Abeni, Hannes Frederic Sowa, linux-kernel, netdev,
Jonathan Corbet, LMML, David Miller, Linus Torvalds
In-Reply-To: <trinity-920967ce-ab0f-4535-8557-f82a7e667a79-1515516669310@3c-app-gmx-bs24>
On Tue, Jan 9, 2018 at 8:51 AM, Josef Griebichler
<griebichler.josef@gmx.at> wrote:
> Hi Linus,
>
> your patch works very good for me and others (please see https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=77006#post77006). No errors in recordings any more.
> The patch was also tested on x86_64 (Revo 3700) with positive effect.
> I agree with the forum poster, that there's still an issue when recording and watching livetv at same time. I also get audio dropouts and audio is out of sync.
> According to user smp kernel 4.9.73 with your patch on rpi and according to user jahutchi kernel 4.11.12 on x86_64 have no such issues.
> I don't know if this dropouts are related to this topic.
>
> If of any help I could provide perf output on raspberry with libreelec and tvheadend.
>
Sorry to come late to the party.
It seems problem comes from some piece of hardware/driver having some
precise timing prereq, and opportunistic use of softirq/tasklet
(instead maybe of hard irq handlers )
While it is true that softirq might do the job in most cases, we
already have cases where this can be easily defeated,
say if one cpu has suddenly to handle multiple sources of interrupts
for various devices.
NET_RX can easily lock the cpu for 10ms (on HZ=100 builds)
So yes, commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job") has
shown up multiple times in various 'regressions'
simply because it could surface the problem more often.
But even if you revert it, you can still make the faulty
driver/subsystem misbehave by adding more stress to the cpu handling
the IRQ.
Note that networking lacks fine control of its softirq processing.
Some people found/complained that relying more on ksoftirqd was
potentially adding tail latencies.
Maybe the answer is to tune the kernel for small latencies at the
price of small throughput (situation before the patch)
1) Revert the patch
2) get rid of ksoftirqd since it adds unexpected latencies.
3) Let applications that expect to have high throughput make sure to
pin their threads on cpus that are not processing IRQ.
(And make sure to not use irqbalance, and setup IRQ cpu affinities)
^ permalink raw reply
* Re: [PATCH net v2] ipv6: remove null_entry before adding default route
From: David Miller @ 2018-01-09 17:34 UTC (permalink / raw)
To: weiwan; +Cc: netdev, kafai, edumazet
In-Reply-To: <20180108183400.206017-1-tracywwnj@gmail.com>
From: Wei Wang <weiwan@google.com>
Date: Mon, 8 Jan 2018 10:34:00 -0800
> From: Wei Wang <weiwan@google.com>
>
> In the current code, when creating a new fib6 table, tb6_root.leaf gets
> initialized to net->ipv6.ip6_null_entry.
> If a default route is being added with rt->rt6i_metric = 0xffffffff,
> fib6_add() will add this route after net->ipv6.ip6_null_entry. As
> null_entry is shared, it could cause problem.
>
> In order to fix it, set fn->leaf to NULL before calling
> fib6_add_rt2node() when trying to add the first default route.
> And reset fn->leaf to null_entry when adding fails or when deleting the
> last default route.
>
> syzkaller reported the following issue which is fixed by this commit:
...
> Reported-by: syzbot <syzkaller@googlegroups.com>
> Fixes: 66f5d6ce53e6 ("ipv6: replace rwlock with rcu and spinlock in fib6_table")
> Signed-off-by: Wei Wang <weiwan@google.com>
Applied, thank you.
^ permalink raw reply
* Re: [net-next 0/9] tipc: improvements to group messaging
From: David Miller @ 2018-01-09 17:36 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, mohan.krishna.ghanta.krishnamurthy, tung.q.nguyen,
hoang.h.le, canh.d.luu, ying.xue, tipc-discussion
In-Reply-To: <1515440080-27377-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Mon, 8 Jan 2018 20:34:31 +0100
> We make a number of simplifications and improvements to the group
> messaging service. They aim at readability/maintainability of the code
> as well as scalability.
>
> The series is based on commit f9c935db8086 ("tipc: fix problems with
> multipoint-to-point flow control) which has been applied to 'net' but
> not yet to 'net-next'.
Since I just did a net-->net-next merge, I am now able to apply this
series.
Thanks!
^ permalink raw reply
* Re: [PATCH net-next 0/3] r8169: improve runtime pm
From: David Miller @ 2018-01-09 17:39 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, romieu, f.fainelli, netdev
In-Reply-To: <9bc4bf55-04d5-def8-40f2-346902988192@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Mon, 8 Jan 2018 21:34:41 +0100
> On my system with two network ports I found that runtime PM didn't
> suspend the unused port. Therefore I checked runtime pm in this driver
> in somewhat more detail and this series improves runtime pm in general
> and solves the mentioned issue.
>
> Tested on a system with RTL8168evl (MAC version 34).
Series applied, thank you.
^ permalink raw reply
* Re: dvb usb issues since kernel 4.9
From: Mauro Carvalho Chehab @ 2018-01-09 17:42 UTC (permalink / raw)
To: Linus Torvalds, Peter Zijlstra
Cc: Alan Stern, Ingo Molnar, Josef Griebichler, Greg Kroah-Hartman,
USB list, Eric Dumazet, Rik van Riel, Paolo Abeni,
Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel,
netdev, Jonathan Corbet, LMML, David Miller
In-Reply-To: <CA+55aFwuAojr7vAfiRO-2je-wDs7pu+avQZNhX_k9NN=D7_zVQ@mail.gmail.com>
Em Mon, 8 Jan 2018 11:51:04 -0800
Linus Torvalds <torvalds@linux-foundation.org> escreveu:
> On Mon, Jan 8, 2018 at 11:15 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
> >
> > Both dwc2_hsotg and ehci-hcd use the tasklets embedded in the
> > giveback_urb_bh member of struct usb_hcd. See usb_hcd_giveback_urb()
> > in drivers/usb/core/hcd.c; the calls are
> >
> > else if (high_prio_bh)
> > tasklet_hi_schedule(&bh->bh);
> > else
> > tasklet_schedule(&bh->bh);
> >
> > As it turns out, high_prio_bh gets set for interrupt and isochronous
> > URBs but not for bulk and control URBs. The DVB driver in question
> > uses bulk transfers.
>
> Ok, so we could try out something like the appended?
>
> NOTE! I have not tested this at all. It LooksObvious(tm), but...
>
> Linus
> kernel/softirq.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/softirq.c b/kernel/softirq.c
> index 2f5e87f1bae2..97b080956fea 100644
> --- a/kernel/softirq.c
> +++ b/kernel/softirq.c
> @@ -79,12 +79,16 @@ static void wakeup_softirqd(void)
>
> /*
> * If ksoftirqd is scheduled, we do not want to process pending softirqs
> - * right now. Let ksoftirqd handle this at its own rate, to get fairness.
> + * right now. Let ksoftirqd handle this at its own rate, to get fairness,
> + * unless we're doing some of the synchronous softirqs.
> */
> -static bool ksoftirqd_running(void)
> +#define SOFTIRQ_NOW_MASK ((1 << HI_SOFTIRQ) | (1 << TASKLET_SOFTIRQ))
> +static bool ksoftirqd_running(unsigned long pending)
> {
> struct task_struct *tsk = __this_cpu_read(ksoftirqd);
>
> + if (pending & SOFTIRQ_NOW_MASK)
> + return false;
> return tsk && (tsk->state == TASK_RUNNING);
> }
>
> @@ -325,7 +329,7 @@ asmlinkage __visible void do_softirq(void)
>
> pending = local_softirq_pending();
>
> - if (pending && !ksoftirqd_running())
> + if (pending && !ksoftirqd_running(pending))
> do_softirq_own_stack();
>
> local_irq_restore(flags);
> @@ -352,7 +356,7 @@ void irq_enter(void)
>
> static inline void invoke_softirq(void)
> {
> - if (ksoftirqd_running())
> + if (ksoftirqd_running(local_softirq_pending()))
> return;
>
> if (!force_irqthreads) {
Hi Linus,
Patch makes sense to me, although I was not able to test it myself.
I set a RPi3 machine here with vanilla Kernel 4.14.11 running a standard
raspbian distribution (with elevator=deadline). Right now, I'm trying to
reproduce the bug with dvbv5-zap. I may eventually do more tests on
some other slow machines.
Usually, applications like tvheadend records just one channel. So, instead
of a ~58 Mbits/s payload, it uses, typically, ~11 Mbits/s for a HD channel.
This is usually filtered by hardware. Here, I'm forcing to record the
entire TS, in order to make easier to reproduce the issue. So, I'm forcing
a condition that it is usually worse than real usecases (at last for HD - I
I don't have any DVB stream here with a 4K channel).
>From what I checked so far, with vanila upstream Kernel on RPi3, just
receiving a DVB stream - or receiving it and writing to /dev/null works
with or without your patch.
The problem starts to happen when there are concurrency with writes.
On my preliminar tests, writing to a file on an ext4 partition at a
USB stick loses data up to the point to make it useless (1/4 of the data
is lost!). However, writing to a class 10 microSD card is doable.
If you're curious enough, this is what I'm doing (that are the results
while using class 10 microSD card):
$ FILE=/tmp/out.ts; for i in $(seq 1 6); do echo "step $i"; rm $FILE 2>/dev/null; dvbv5-zap -l universal -c ~/vivo-channels.conf NBR -o $FILE -P -t60 2>&1|grep -E "(buffer|received)"; du $FILE 2>/dev/null; done
step 1
Setting buffer length to 7250000
buffer overrun
buffer overrun
buffer overrun
buffer overrun
buffer overrun
buffer overrun
buffer overrun
received 347504652 bytes (5656 Kbytes/sec)
339368 /tmp/out.ts
step 2
Setting buffer length to 7250000
buffer overrun
received 408995880 bytes (6656 Kbytes/sec)
399416 /tmp/out.ts
step 3
Setting buffer length to 7250000
received 412999716 bytes (6722 Kbytes/sec)
403328 /tmp/out.ts
step 4
Setting buffer length to 7250000
buffer overrun
received 415564788 bytes (6763 Kbytes/sec)
405832 /tmp/out.ts
step 5
Setting buffer length to 7250000
received 412999716 bytes (6722 Kbytes/sec)
403324 /tmp/out.ts
step 6
Setting buffer length to 7250000
received 408366080 bytes (6646 Kbytes/sec)
398796 /tmp/out.ts
My plan is to do more tests along this week, and try to tweak a little
bit both userspace and kernelspace, in order to see if I can get better
results.
Thanks,
Mauro
^ permalink raw reply
* sctp: memory leak in sctp_endpoint_init
From: Dmitry Vyukov @ 2018-01-09 17:44 UTC (permalink / raw)
To: Vladislav Yasevich, Neil Horman, David Miller, linux-sctp, netdev,
LKML, syzkaller
[-- Attachment #1: Type: text/plain, Size: 3143 bytes --]
Hello,
syzkaller has hit the following memory leak on 4.15-rc7.
Reproducer is attached.
unferenced object 0xffff88007bbaa720 (size 32):
comm "syz-executor4", pid 12479, jiffies 4295951917 (age 9.779s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000ce041e0c>] kmemleak_alloc_recursive
include/linux/kmemleak.h:55 [inline]
[<00000000ce041e0c>] slab_post_alloc_hook mm/slab.h:440 [inline]
[<00000000ce041e0c>] slab_alloc_node mm/slub.c:2725 [inline]
[<00000000ce041e0c>] slab_alloc mm/slub.c:2733 [inline]
[<00000000ce041e0c>] kmem_cache_alloc_trace+0x126/0x290 mm/slub.c:2750
[<0000000052b69e97>] kmalloc include/linux/slab.h:499 [inline]
[<0000000052b69e97>] kzalloc include/linux/slab.h:688 [inline]
[<0000000052b69e97>] sctp_endpoint_init net/sctp/endpointola.c:66 [inline]
[<0000000052b69e97>] sctp_endpoint_new+0x16d/0xef0
net/sctp/endpointola.c:195
[<00000000b78002d9>] sctp_init_sock+0xc18/0x13e0 net/sctp/socket.c:4490
[<00000000fe5de849>] inet6_create+0xba7/0x1290 net/ipv6/af_inet6.c:255
[<00000000bb006173>] __sock_create+0x521/0x920 net/socket.c:1265
[<00000000a8d6fbc0>] sock_create net/socket.c:1305 [inline]
[<00000000a8d6fbc0>] SYSC_socket net/socket.c:1335 [inline]
[<00000000a8d6fbc0>] SyS_socket+0x102/0x1f0 net/socket.c:1315
[<000000004dc391b5>] entry_SYSCALL_64_fastpath+0x23/0x9a
[<00000000c66d20cc>] 0xffffffffffffffff
2018/01/09 15:50:01 BUG: memory leak
unreferenced object 0xffff88007bbaac30 (size 32):
comm "syz-executor4", pid 12479, jiffies 4295951917 (age 9.791s)
hex dump (first 32 bytes):
f0 45 4b 2a 00 88 ff ff f0 45 4b 2a 00 88 ff ff .EK*.....EK*....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000ce041e0c>] kmemleak_alloc_recursive
include/linux/kmemleak.h:55 [inline]
[<00000000ce041e0c>] slab_post_alloc_hook mm/slab.h:440 [inline]
[<00000000ce041e0c>] slab_alloc_node mm/slub.c:2725 [inline]
[<00000000ce041e0c>] slab_alloc mm/slub.c:2733 [inline]
[<00000000ce041e0c>] kmem_cache_alloc_trace+0x126/0x290 mm/slub.c:2750
[<0000000069bdc070>] kmalloc include/linux/slab.h:499 [inline]
[<0000000069bdc070>] kzalloc include/linux/slab.h:688 [inline]
[<0000000069bdc070>] sctp_auth_shkey_create+0xbb/0x1f0 net/sctp/auth.c:99
[<00000000604efa40>] sctp_endpoint_init net/sctp/endpointola.c:151 [inline]
[<00000000604efa40>] sctp_endpoint_new+0x65b/0xef0
net/sctp/endpointola.c:195
[<00000000b78002d9>] sctp_init_sock+0xc18/0x13e0 net/sctp/socket.c:4490
[<00000000fe5de849>] inet6_create+0xba7/0x1290 net/ipv6/af_inet6.c:255
[<00000000bb006173>] __sock_create+0x521/0x920 net/socket.c:1265
[<00000000a8d6fbc0>] sock_create net/socket.c:1305 [inline]
[<00000000a8d6fbc0>] SYSC_socket net/socket.c:1335 [inline]
[<00000000a8d6fbc0>] SyS_socket+0x102/0x1f0 net/socket.c:1315
[<000000004dc391b5>] entry_SYSCALL_64_fastpath+0x23/0x9a
[<00000000c66d20cc>] 0xffffffffffffffff
[-- Attachment #2: sctp.c --]
[-- Type: text/x-csrc, Size: 2526 bytes --]
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#define _GNU_SOURCE
#include <endian.h>
#include <linux/futex.h>
#include <pthread.h>
#include <stdint.h>
#include <stdlib.h>
#include <string.h>
#include <sys/syscall.h>
#include <unistd.h>
struct thread_t {
int created, running, call;
pthread_t th;
};
static struct thread_t threads[16];
static void execute_call(int call);
static int running;
static int collide;
static void* thr(void* arg)
{
struct thread_t* th = (struct thread_t*)arg;
for (;;) {
while (!__atomic_load_n(&th->running, __ATOMIC_ACQUIRE))
syscall(SYS_futex, &th->running, FUTEX_WAIT, 0, 0);
execute_call(th->call);
__atomic_fetch_sub(&running, 1, __ATOMIC_RELAXED);
__atomic_store_n(&th->running, 0, __ATOMIC_RELEASE);
syscall(SYS_futex, &th->running, FUTEX_WAKE);
}
return 0;
}
static void execute(int num_calls)
{
int call, thread;
running = 0;
for (call = 0; call < num_calls; call++) {
for (thread = 0; thread < sizeof(threads) / sizeof(threads[0]); thread++) {
struct thread_t* th = &threads[thread];
if (!th->created) {
th->created = 1;
pthread_attr_t attr;
pthread_attr_init(&attr);
pthread_attr_setstacksize(&attr, 128 << 10);
pthread_create(&th->th, &attr, thr, th);
}
if (!__atomic_load_n(&th->running, __ATOMIC_ACQUIRE)) {
th->call = call;
__atomic_fetch_add(&running, 1, __ATOMIC_RELAXED);
__atomic_store_n(&th->running, 1, __ATOMIC_RELEASE);
syscall(SYS_futex, &th->running, FUTEX_WAKE);
if (collide && call % 2)
break;
struct timespec ts;
ts.tv_sec = 0;
ts.tv_nsec = 20 * 1000 * 1000;
syscall(SYS_futex, &th->running, FUTEX_WAIT, 1, &ts);
if (running)
usleep((call == num_calls - 1) ? 10000 : 1000);
break;
}
}
}
}
long r[1];
void execute_call(int call)
{
switch (call) {
case 0:
syscall(__NR_mmap, 0x20000000, 0xfff000, 3, 0x32, -1, 0);
break;
case 1:
syscall(__NR_getpid);
break;
case 2:
r[0] = syscall(__NR_socket, 0xa, 5, 0x84);
break;
case 3:
*(uint64_t*)0x2046eff0 = 0;
*(uint64_t*)0x2046eff8 = 0;
syscall(__NR_setrlimit, 7, 0x2046eff0);
break;
case 4:
*(uint32_t*)0x202bf000 = 0;
syscall(__NR_ioctl, r[0], 0x894c, 0x202bf000);
break;
}
}
void loop()
{
memset(r, -1, sizeof(r));
execute(5);
collide = 1;
execute(5);
}
int main()
{
loop();
return 0;
}
^ permalink raw reply
* Re: Re: dvb usb issues since kernel 4.9
From: Linus Torvalds @ 2018-01-09 17:48 UTC (permalink / raw)
To: Eric Dumazet
Cc: Josef Griebichler, Jesper Dangaard Brouer, Peter Zijlstra,
Mauro Carvalho Chehab, Alan Stern, Greg Kroah-Hartman, USB list,
Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, linux-kernel,
netdev, Jonathan Corbet, LMML, David Miller
In-Reply-To: <CANn89iJqRH4uzFJVKyPxc8dN38z319C1O18nTJ-CCidtuOH2+g@mail.gmail.com>
On Tue, Jan 9, 2018 at 9:27 AM, Eric Dumazet <edumazet@google.com> wrote:
>
> So yes, commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job") has
> shown up multiple times in various 'regressions'
> simply because it could surface the problem more often.
> But even if you revert it, you can still make the faulty
> driver/subsystem misbehave by adding more stress to the cpu handling
> the IRQ.
..but that's always true. People sometimes live on the edge - often by
design (ie hardware has been designed/selected to be the crappiest
possible that still work).
That doesn't change anything. A patch that takes "bad things can
happen" to "bad things DO happen" is a bad patch.
> Maybe the answer is to tune the kernel for small latencies at the
> price of small throughput (situation before the patch)
Generally we always want to tune for latency. Throughput is "easy",
but almost never interesting.
Sure, people do batch jobs. And yes, people often _benchmark_
throughput, because it's easy to benchmark. It's much harder to
benchmark latency, even when it's often much more important.
A prime example is the SSD benchmarks in the last few years - they
improved _dramatically_ when people noticed that the real problem was
latency, not the idiotic maximum big-block bandwidth numbers that have
almost zero impact on most people.
Put another way: we already have a very strong implicit bias towards
bandwidth just because it's easier to see and measure.
That means that we generally should strive to have a explicit bias
towards optimizing for latency when that choice comes up. Just to
balance things out (and just to not take the easy way out: bandwidth
can often be improved by adding more layers of buffering and bigger
buffers, and that often ends up really hurting latency).
> 1) Revert the patch
Well, we can revert it only partially - limiting it to just networking
for example.
Just saying "act the way you used to for tasklets" already seems to
have fixed the issue in DVB.
> 2) get rid of ksoftirqd since it adds unexpected latencies.
We can't get rid of it entirely, since the synchronous softirq code
can cause problems too. It's why we have that "maximum of ten
synchronous events" in __do_softirq().
And we don't *want* to get rid of it.
We've _always_ had that small-scale "at some point we can't do it
synchronously any more".
That is a small-scale "don't have horrible latency for _other_ things"
protection. So it's about latency too, it's just about protecting
latency of the rest of the system.
The problem with commit 4cd13c21b207 is that it turns the small-scale
latency issues in softirq handling (they get larger latencies for lots
of hardware interrupts or even from non-preemptible kernel code) into
the _huge_ scale latency of scheduling, and does so in a racy way too.
> 3) Let applications that expect to have high throughput make sure to
> pin their threads on cpus that are not processing IRQ.
> (And make sure to not use irqbalance, and setup IRQ cpu affinities)
The only people that really deal in "thoughput only" tend to be the
HPC people, and they already do things like this.
(The other end of the spectrum is the realtime people that have
extreme latency requirements, who do things like that for the reverse
reason: keeping one or more CPU's reserved for the particular
low-latency realtime job).
Linus
^ 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