* [PATCH net-next v2 3/4] ravb: remove undocumented endianness selection
From: Simon Horman @ 2019-09-05 15:10 UTC (permalink / raw)
To: David Miller, Sergei Shtylyov
Cc: Magnus Damm, netdev, linux-renesas-soc, Simon Horman
In-Reply-To: <20190905151059.26794-1-horms+renesas@verge.net.au>
This patch removes the use of the undocumented BOC bit of the CCC register.
Current documentation for EtherAVB (ravb) describes the offset of what the
driver uses as the BOC bit as reserved and that only a value of 0 should be
written. After some internal investigation with Renesas it remains unclear
why this driver accesses these fields but regardless of what the historical
reasons are the current code is considered incorrect.
Based on work by Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
v2
* New patch broken out of larger patch
---
drivers/net/ethernet/renesas/ravb.h | 1 -
drivers/net/ethernet/renesas/ravb_main.c | 6 ------
2 files changed, 7 deletions(-)
diff --git a/drivers/net/ethernet/renesas/ravb.h b/drivers/net/ethernet/renesas/ravb.h
index 70eeceb7f8ae..bdb051f04b0c 100644
--- a/drivers/net/ethernet/renesas/ravb.h
+++ b/drivers/net/ethernet/renesas/ravb.h
@@ -216,7 +216,6 @@ enum CCC_BIT {
CCC_CSEL_HPB = 0x00010000,
CCC_CSEL_ETH_TX = 0x00020000,
CCC_CSEL_GMII_REF = 0x00030000,
- CCC_BOC = 0x00100000, /* Undocumented? */
CCC_LBME = 0x01000000,
};
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 4d1f274cded0..b538cc6fdbb7 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -447,12 +447,6 @@ static int ravb_dmac_init(struct net_device *ndev)
ravb_ring_format(ndev, RAVB_BE);
ravb_ring_format(ndev, RAVB_NC);
-#if defined(__LITTLE_ENDIAN)
- ravb_modify(ndev, CCC, CCC_BOC, 0);
-#else
- ravb_modify(ndev, CCC, CCC_BOC, CCC_BOC);
-#endif
-
/* Set AVB RX */
ravb_write(ndev,
RCR_EFFS | RCR_ENCF | RCR_ETS0 | RCR_ESF | 0x18000000, RCR);
--
2.11.0
^ permalink raw reply related
* [PATCH net-next v2 4/4] ravb: TROCR register is only present on R-Car Gen3
From: Simon Horman @ 2019-09-05 15:10 UTC (permalink / raw)
To: David Miller, Sergei Shtylyov
Cc: Magnus Damm, netdev, linux-renesas-soc, Simon Horman
In-Reply-To: <20190905151059.26794-1-horms+renesas@verge.net.au>
Only use the TROCR register on R-Car Gen3 as it is not present on other
SoCs.
Offsets used for the undocumented registers are considered reserved and
should not be written to. After some internal investigation with Renesas it
remains unclear why this driver accesses these fields on R-Car Gen2 but
regardless of what the historical reasons are the current code is
considered incorrect.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
v2
* Accumulated tags
* Updated changelog
---
drivers/net/ethernet/renesas/ravb.h | 2 +-
drivers/net/ethernet/renesas/ravb_main.c | 6 ++++--
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/renesas/ravb.h b/drivers/net/ethernet/renesas/ravb.h
index bdb051f04b0c..a9c89d5d8898 100644
--- a/drivers/net/ethernet/renesas/ravb.h
+++ b/drivers/net/ethernet/renesas/ravb.h
@@ -193,7 +193,7 @@ enum ravb_reg {
GECMR = 0x05b0,
MAHR = 0x05c0,
MALR = 0x05c8,
- TROCR = 0x0700, /* Undocumented? */
+ TROCR = 0x0700, /* R-Car Gen3 only */
CEFCR = 0x0740,
FRECR = 0x0748,
TSFRCR = 0x0750,
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index b538cc6fdbb7..de9aa8c47f1c 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -1621,8 +1621,10 @@ static struct net_device_stats *ravb_get_stats(struct net_device *ndev)
stats0 = &priv->stats[RAVB_BE];
stats1 = &priv->stats[RAVB_NC];
- nstats->tx_dropped += ravb_read(ndev, TROCR);
- ravb_write(ndev, 0, TROCR); /* (write clear) */
+ if (priv->chip_id == RCAR_GEN3) {
+ nstats->tx_dropped += ravb_read(ndev, TROCR);
+ ravb_write(ndev, 0, TROCR); /* (write clear) */
+ }
nstats->rx_packets = stats0->rx_packets + stats1->rx_packets;
nstats->tx_packets = stats0->tx_packets + stats1->tx_packets;
--
2.11.0
^ permalink raw reply related
* [PATCH net-next v2 0/4] ravb: remove use of undocumented registers
From: Simon Horman @ 2019-09-05 15:10 UTC (permalink / raw)
To: David Miller, Sergei Shtylyov
Cc: Magnus Damm, netdev, linux-renesas-soc, Simon Horman
Hi,
this short series cleans up the RAVB driver a little.
The first patch corrects the spelling of the FBP field of SFO register.
This register field is unused and should have no run-time effect.
The remaining patches remove the use of undocumented registers
after some consultation with the internal Renesas BSP team.
Changes in v2:
* Corrected mangled state of first patch
* Patches 2/4 and 3/4 split out of a large patch
* Accumulated acks
* Tweaked changelog
* Claimed authorship of all patches
v1 of this series was tested on the following platforms.
No behaviour change is expected in v2.
* E3 Ebisu
* H3 Salvator-XS (ES2.0)
* M3-W Salvator-XS
* M3-N Salvator-XS
* RZ/G1C iW-RainboW-G23S
Simon Horman (4):
ravb: correct typo in FBP field of SFO register
ravb: remove undocumented counter processing
ravb: remove undocumented endianness selection
ravb: TROCR register is only present on R-Car Gen3
drivers/net/ethernet/renesas/ravb.h | 9 ++-------
drivers/net/ethernet/renesas/ravb_main.c | 21 ++++-----------------
2 files changed, 6 insertions(+), 24 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH net-next v2 1/4] ravb: correct typo in FBP field of SFO register
From: Simon Horman @ 2019-09-05 15:10 UTC (permalink / raw)
To: David Miller, Sergei Shtylyov
Cc: Magnus Damm, netdev, linux-renesas-soc, Simon Horman
In-Reply-To: <20190905151059.26794-1-horms+renesas@verge.net.au>
The field name is FBP rather than FPB.
This field is unused and could equally be removed from the driver entirely.
But there seems no harm in leaving as documentation of the presence of the
field.
Based on work by Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
v2 - Simon Horman
* Accumulated tags
* Claimed authorship - a whole one line
* No mangled diff this time
v1 - Simon Horman
* Extracted from larger patch
* Wrote changelog
---
drivers/net/ethernet/renesas/ravb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/renesas/ravb.h b/drivers/net/ethernet/renesas/ravb.h
index ac9195add811..2596a95a4300 100644
--- a/drivers/net/ethernet/renesas/ravb.h
+++ b/drivers/net/ethernet/renesas/ravb.h
@@ -317,7 +317,7 @@ enum UFCD_BIT {
/* SFO */
enum SFO_BIT {
- SFO_FPB = 0x0000003F,
+ SFO_FBP = 0x0000003F,
};
/* RTC */
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] net/skbuff: silence warnings under memory pressure
From: Eric Dumazet @ 2019-09-05 15:06 UTC (permalink / raw)
To: Qian Cai, Eric Dumazet, Sergey Senozhatsky
Cc: Sergey Senozhatsky, Michal Hocko, davem, netdev, linux-mm,
linux-kernel, Petr Mladek, Steven Rostedt
In-Reply-To: <1567692555.5576.91.camel@lca.pw>
On 9/5/19 4:09 PM, Qian Cai wrote:
>
> I feel like you may not follow the thread closely. There are more details
> uncovered in the last few days and narrowed down to the culprits.
>
I have followed the thread closely, thank you very much.
I am happy that the problem is addressed as I suggested.
Ie not individual patches adding selected __GFP_NOWARN.
^ permalink raw reply
* [PATCH] rtlwifi: rtl8821ae: make array static const and remove redundant assignment
From: Colin King @ 2019-09-05 15:00 UTC (permalink / raw)
To: Ping-Ke Shih, Kalle Valo, David S . Miller, Larry Finger,
linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The array channel_all can be make static const rather than populating
it on the stack, this makes the code smaller. Also, variable place
is being initialized with a value that is never read, so this assignment
is redundant and can be removed.
Before:
text data bss dec hex filename
118537 9591 0 128128 1f480 realtek/rtlwifi/rtl8821ae/phy.o
After:
text data bss dec hex filename
118331 9687 0 128018 1f412 realtek/rtlwifi/rtl8821ae/phy.o
Saves 110 bytes, (gcc version 9.2.1, amd64)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c
index 408af144098e..979e434a4e73 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c
@@ -3613,14 +3613,14 @@ u8 rtl8821ae_phy_sw_chnl(struct ieee80211_hw *hw)
u8 _rtl8812ae_get_right_chnl_place_for_iqk(u8 chnl)
{
- u8 channel_all[TARGET_CHNL_NUM_2G_5G_8812] = {
+ static const u8 channel_all[TARGET_CHNL_NUM_2G_5G_8812] = {
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13,
14, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54,
56, 58, 60, 62, 64, 100, 102, 104, 106, 108,
110, 112, 114, 116, 118, 120, 122, 124, 126,
128, 130, 132, 134, 136, 138, 140, 149, 151,
153, 155, 157, 159, 161, 163, 165};
- u8 place = chnl;
+ u8 place;
if (chnl > 14) {
for (place = 14; place < sizeof(channel_all); place++)
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] hostap: remove set but not used variable 'copied' in prism2_io_debug_proc_read
From: Kalle Valo @ 2019-09-05 14:19 UTC (permalink / raw)
To: zhong jiang; +Cc: davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <5D711760.20903@huawei.com>
zhong jiang <zhongjiang@huawei.com> writes:
> On 2019/9/5 21:45, Kalle Valo wrote:
>> zhong jiang <zhongjiang@huawei.com> writes:
>>
>>> Please ignore the patch. Because the hostap_proc.c is marked as 'obsolete'.
>> You mean marked in the MAINTAINERS file? I don't see that as a problem,
>> I can (and should) still apply any patches submitted to hostap driver.
>>
> I hit the following issue when checking the patch by checkpatch.pl
>
> WARNING: drivers/net/wireless/intersil/hostap/hostap_proc.c is marked
> as 'obsolete' in the MAINTAINERS hierarchy.
> No unnecessary modifications please.
>
> I certainly hope it can be appiled to upstream if the above check doesn't matter.
I have no idea why checkpatch says like that and I'm going to just
ignore that warning. As long as the driver is in the tree I think it
should be improved.
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] net/skbuff: silence warnings under memory pressure
From: Qian Cai @ 2019-09-05 14:09 UTC (permalink / raw)
To: Eric Dumazet, Sergey Senozhatsky
Cc: Sergey Senozhatsky, Michal Hocko, davem, netdev, linux-mm,
linux-kernel, Petr Mladek, Steven Rostedt
In-Reply-To: <165827b5-6783-f4f8-69d6-b088dd97eb45@gmail.com>
On Thu, 2019-09-05 at 10:32 +0200, Eric Dumazet wrote:
>
> On 9/4/19 10:42 PM, Qian Cai wrote:
>
> > To summary, those look to me are all good long-term improvement that would
> > reduce the likelihood of this kind of livelock in general especially for
> > other
> > unknown allocations that happen while processing softirqs, but it is still
> > up to
> > the air if it fixes it 100% in all situations as printk() is going to take
> > more
> > time and could deal with console hardware that involve irq_exit() anyway.
> >
> > On the other hand, adding __GPF_NOWARN in the build_skb() allocation will
> > fix
> > this known NET_TX_SOFTIRQ case which is common when softirqd involved at
> > least
> > in short-term. It even have a benefit to reduce the overall warn_alloc()
> > noise
> > out there.
> >
> > I can resubmit with an update changelog. Does it make any sense?
>
> It does not make sense.
>
> We have thousands other GFP_ATOMIC allocations in the networking stacks.
Instead of repeatedly make generalize statements, could you enlighten me with
some concrete examples that have the similar properties which would trigger a
livelock,
- guaranteed GFP_ATOMIC allocations when processing softirq batches.
- the allocation has a fallback mechanism that is unnecessary to warn a failure.
I thought "skb" is a special-case here as every packet sent or received is
handled using this data structure.
>
> Soon you will have to send more and more patches adding __GFP_NOWARN once
> your workloads/tests can hit all these various points.
I doubt so.
>
> It is really time to fix this problem generically, instead of having
> to review hundreds of patches.
>
> This was my initial feedback really, nothing really has changed since.
I feel like you may not follow the thread closely. There are more details
uncovered in the last few days and narrowed down to the culprits.
>
> The ability to send a warning with a stack trace, holding the cpu
> for many milliseconds should not be decided case by case, otherwise
> every call points will decide to opt-out from the harmful warnings.
That is not really the reasons anymore why I asked to add a __GPF_NOWARN here.
^ permalink raw reply
* Re: [PATCH] hostap: remove set but not used variable 'copied' in prism2_io_debug_proc_read
From: zhong jiang @ 2019-09-05 14:10 UTC (permalink / raw)
To: Kalle Valo; +Cc: davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <87zhjij1q6.fsf@tynnyri.adurom.net>
On 2019/9/5 21:45, Kalle Valo wrote:
> zhong jiang <zhongjiang@huawei.com> writes:
>
>> Please ignore the patch. Because the hostap_proc.c is marked as 'obsolete'.
> You mean marked in the MAINTAINERS file? I don't see that as a problem,
> I can (and should) still apply any patches submitted to hostap driver.
>
I hit the following issue when checking the patch by checkpatch.pl
WARNING: drivers/net/wireless/intersil/hostap/hostap_proc.c is marked as 'obsolete' in the MAINTAINERS hierarchy.
No unnecessary modifications please.
I certainly hope it can be appiled to upstream if the above check doesn't matter.
Thanks,
zhong jiang
^ permalink raw reply
* [PATCH] lan743x: remove redundant assignment to variable rx_process_result
From: Colin King @ 2019-09-05 14:01 UTC (permalink / raw)
To: Bryan Whitehead, Microchip Linux Driver Support, David S . Miller,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The variable rx_process_result is being initialized with a value that
is never read and is being re-assigned immediately afterwards. The
assignment is redundant, so replace it with the return from function
lan743x_rx_process_packet.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/microchip/lan743x_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/microchip/lan743x_main.c b/drivers/net/ethernet/microchip/lan743x_main.c
index 15a8be6bad27..a43140f7b5eb 100644
--- a/drivers/net/ethernet/microchip/lan743x_main.c
+++ b/drivers/net/ethernet/microchip/lan743x_main.c
@@ -2172,9 +2172,8 @@ static int lan743x_rx_napi_poll(struct napi_struct *napi, int weight)
}
count = 0;
while (count < weight) {
- int rx_process_result = -1;
+ int rx_process_result = lan743x_rx_process_packet(rx);
- rx_process_result = lan743x_rx_process_packet(rx);
if (rx_process_result == RX_PROCESS_RESULT_PACKET_RECEIVED) {
count++;
} else if (rx_process_result ==
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 0/2] Revert and rework on the metadata accelreation
From: Jason Gunthorpe @ 2019-09-05 13:59 UTC (permalink / raw)
To: Jason Wang
Cc: mst@redhat.com, kvm@vger.kernel.org,
virtualization@lists.linux-foundation.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, aarcange@redhat.com,
jglisse@redhat.com, linux-mm@kvack.org
In-Reply-To: <20190905122736.19768-1-jasowang@redhat.com>
On Thu, Sep 05, 2019 at 08:27:34PM +0800, Jason Wang wrote:
> Hi:
>
> Per request from Michael and Jason, the metadata accelreation is
> reverted in this version and rework in next version.
>
> Please review.
>
> Thanks
>
> Jason Wang (2):
> Revert "vhost: access vq metadata through kernel virtual address"
> vhost: re-introducing metadata acceleration through kernel virtual
> address
There are a bunch of patches in the queue already that will help
vhost, and I a working on one for next cycle that will help alot more
too.
I think you should apply the revert this cycle and rebase the other
patch for next..
Jason
^ permalink raw reply
* pull-request: wireless-drivers 2019-09-05
From: Kalle Valo @ 2019-09-05 13:58 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's a pull request to net tree for v5.3, more info below. Please let
me know if there are any problems.
Kalle
The following changes since commit 089cf7f6ecb266b6a4164919a2e69bd2f938374a:
Linux 5.3-rc7 (2019-09-02 09:57:40 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2019-09-05
for you to fetch changes up to 8b51dc7291473093c821195c4b6af85fadedbc2f:
rsi: fix a double free bug in rsi_91x_deinit() (2019-09-03 16:54:48 +0300)
----------------------------------------------------------------
wireless-drivers fixes for 5.3
Fourth set of fixes for 5.3, and hopefully really the last one. Quite
a few CVE fixes this time but at least to my knowledge none of them
have a known exploit.
mt76
* workaround firmware hang by disabling hardware encryption on MT7630E
* disable 5GHz band for MT7630E as it's not working properly
mwifiex
* fix IE parsing to avoid a heap buffer overflow
iwlwifi
* fix for QuZ device initialisation
rt2x00
* another fix for rekeying
* revert a commit causing degradation in rx signal levels
rsi
* fix a double free
----------------------------------------------------------------
Hui Peng (1):
rsi: fix a double free bug in rsi_91x_deinit()
Luca Coelho (1):
iwlwifi: assign directly to iwl_trans->cfg in QuZ detection
Stanislaw Gruszka (4):
mt76: mt76x0e: don't use hw encryption for MT7630E
mt76: mt76x0e: disable 5GHz band for MT7630E
rt2x00: clear up IV's on key removal
Revert "rt2800: enable TX_PIN_CFG_LNA_PE_ bits per band"
Wen Huang (1):
mwifiex: Fix three heap overflow at parsing element in cfg80211_ap_settings
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 24 +++++++-------
drivers/net/wireless/marvell/mwifiex/ie.c | 3 ++
drivers/net/wireless/marvell/mwifiex/uap_cmd.c | 9 +++++-
drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c | 5 +++
drivers/net/wireless/mediatek/mt76/mt76x0/pci.c | 15 ++++++++-
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 37 +++++++++++-----------
drivers/net/wireless/rsi/rsi_91x_usb.c | 1 -
7 files changed, 60 insertions(+), 34 deletions(-)
^ permalink raw reply
* Re: [PATCH] hostap: remove set but not used variable 'copied' in prism2_io_debug_proc_read
From: Kalle Valo @ 2019-09-05 13:45 UTC (permalink / raw)
To: zhong jiang; +Cc: kvalo, davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <5D6E1DF2.1000109@huawei.com>
zhong jiang <zhongjiang@huawei.com> writes:
> Please ignore the patch. Because the hostap_proc.c is marked as 'obsolete'.
You mean marked in the MAINTAINERS file? I don't see that as a problem,
I can (and should) still apply any patches submitted to hostap driver.
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH V2 net-next 3/7] net: hns3: fix mis-assignment to hdev->reset_level in hclge_reset
From: Huazhong Tan @ 2019-09-05 13:31 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Huazhong Tan
In-Reply-To: <1567690302-16648-1-git-send-email-tanhuazhong@huawei.com>
Since hclge_get_reset_level may return HNAE3_NONE_RESET,
so hdev->reset_level can not be assigned with the return
value in the hclge_reset(), otherwise, it will cause
the use of hdev->reset_level in hclge_reset_event get
into error.
Fixes: 012fcb52f67c ("net: hns3: activate reset timer when calling reset_event")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 0e1225c..76e1c84 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -3619,6 +3619,7 @@ static int hclge_reset_stack(struct hclge_dev *hdev)
static void hclge_reset(struct hclge_dev *hdev)
{
struct hnae3_ae_dev *ae_dev = pci_get_drvdata(hdev->pdev);
+ enum hnae3_reset_type reset_level;
int ret;
/* Initialize ae_dev reset status as well, in case enet layer wants to
@@ -3697,10 +3698,10 @@ static void hclge_reset(struct hclge_dev *hdev)
* it should be handled as soon as possible. since some errors
* need this kind of reset to fix.
*/
- hdev->reset_level = hclge_get_reset_level(ae_dev,
- &hdev->default_reset_request);
- if (hdev->reset_level != HNAE3_NONE_RESET)
- set_bit(hdev->reset_level, &hdev->reset_request);
+ reset_level = hclge_get_reset_level(ae_dev,
+ &hdev->default_reset_request);
+ if (reset_level != HNAE3_NONE_RESET)
+ set_bit(reset_level, &hdev->reset_request);
return;
--
2.7.4
^ permalink raw reply related
* [PATCH V2 net-next 2/7] net: hns3: fix double free bug when setting ringparam
From: Huazhong Tan @ 2019-09-05 13:31 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Huazhong Tan
In-Reply-To: <1567690302-16648-1-git-send-email-tanhuazhong@huawei.com>
The system will panic when change the ringparam in HNS3 drivers:
[ 1459.627727] hns3 0000:bd:00.0 eth6: Changing Tx/Rx ring ds from 1024/1024 to 24/24
[ 1459.635766] hns3 0000:bd:00.0 eth6: link down
[ 1459.640788] BUG: Bad page state in process ethtool pfn:203f75c18
[ 1459.646940] page:ffff7ee4ffd70600 refcount:0 mapcount:0 mapping:ffff993fff40f400 index:0x0 compound_mapcount: 0
[ 1459.656987] flags: 0x9fffe00000010200(slab|head)
[ 1459.661591] raw: 9fffe00000010200 dead000000000100 dead000000000122 ffff993fff40f400
[ 1459.669302] raw: 0000000000000000 0000000080100010 00000000ffffffff 0000000000000000
[ 1459.677016] page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
[ 1459.683432] bad because of flags: 0x200(slab)
[ 1459.687775] Modules linked in: ib_ipoib ib_umad rpcrdma ib_iser libiscsi scsi_transport_iscsi hns_roce_hw_v2 crct10dif_ce hns3 ses hclge hnae3 hisi_hpre hisi_zip qm uacce ip_tables x_tables hisi_sas_v3_hw hisi_sas_main libsas scsi_transport_sas
[ 1459.709329] CPU: 14 PID: 17244 Comm: ethtool Tainted: G O 5.3.0-rc4-00415-gc86f057 #1
[ 1459.718419] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V3.B040.01 07/26/2019
[ 1459.727248] Call trace:
[ 1459.729688] dump_backtrace+0x0/0x150
[ 1459.733335] show_stack+0x24/0x30
[ 1459.736639] dump_stack+0xa0/0xc4
[ 1459.739943] bad_page+0xf0/0x158
[ 1459.743157] free_pages_check_bad+0x84/0xa0
[ 1459.747322] __free_pages_ok+0x348/0x378
[ 1459.751228] page_frag_free+0x80/0x88
[ 1459.754877] skb_free_head+0x38/0x48
[ 1459.758436] skb_release_data+0x134/0x160
[ 1459.762427] skb_release_all+0x30/0x40
[ 1459.766158] consume_skb+0x38/0x108
[ 1459.769633] __dev_kfree_skb_any+0x58/0x68
[ 1459.773718] hns3_fini_ring+0x48/0x58 [hns3]
[ 1459.777970] hns3_set_ringparam+0x2a8/0x418 [hns3]
[ 1459.782741] dev_ethtool+0x5f4/0x2080
[ 1459.786390] dev_ioctl+0x190/0x3d8
[ 1459.789777] sock_do_ioctl+0xf8/0x220
[ 1459.793423] sock_ioctl+0x3bc/0x490
[ 1459.796896] do_vfs_ioctl+0xc4/0x868
[ 1459.800454] ksys_ioctl+0x8c/0xa0
[ 1459.803752] __arm64_sys_ioctl+0x28/0x38
[ 1459.807658] el0_svc_common.constprop.0+0xe0/0x1e0
[ 1459.812426] el0_svc_handler+0x34/0x90
[ 1459.816158] el0_svc+0x10/0x14
[ 1459.819220] Disabling lock debugging due to kernel taint
[ 1459.825182] ------------[ cut here ]------------
Since ndo_stop will reclaim the RX's skb allocated by the driver,
so the backed up ring parameter should not keep this info.
Fixes: a723fb8efe29 ("net: hns3: refine for set ring parameters")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index c52eccc..aa692b1 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -908,9 +908,11 @@ static struct hns3_enet_ring *hns3_backup_ringparam(struct hns3_nic_priv *priv)
if (!tmp_rings)
return NULL;
- for (i = 0; i < handle->kinfo.num_tqps * 2; i++)
+ for (i = 0; i < handle->kinfo.num_tqps * 2; i++) {
memcpy(&tmp_rings[i], priv->ring_data[i].ring,
sizeof(struct hns3_enet_ring));
+ tmp_rings[i].skb = NULL;
+ }
return tmp_rings;
}
--
2.7.4
^ permalink raw reply related
* [PATCH V2 net-next 1/7] net: hns3: fix error VF index when setting VLAN offload
From: Huazhong Tan @ 2019-09-05 13:31 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Jian Shen, Huazhong Tan
In-Reply-To: <1567690302-16648-1-git-send-email-tanhuazhong@huawei.com>
From: Jian Shen <shenjian15@huawei.com>
In original codes, the VF index used incorrectly in function
hclge_set_vlan_rx_offload_cfg() and hclge_set_vlan_rx_offload_cfg().
When VF id is greater than 8, for example 9, it will set the
same bit with VF id 1.
This patch fixes it by using vport->vport_id % HCLGE_VF_NUM_PER_CMD /
HCLGE_VF_NUM_PER_BYTE as the array index, instead of vport->vport_id /
HCLGE_VF_NUM_PER_CMD.
Fixes: 052ece6dc19c ("net: hns3: add ethtool related offload command")
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 2b65f27..0e1225c 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -7691,6 +7691,7 @@ static int hclge_set_vlan_tx_offload_cfg(struct hclge_vport *vport)
struct hclge_vport_vtag_tx_cfg_cmd *req;
struct hclge_dev *hdev = vport->back;
struct hclge_desc desc;
+ u16 bmap_index;
int status;
hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_VLAN_PORT_TX_CFG, false);
@@ -7713,8 +7714,10 @@ static int hclge_set_vlan_tx_offload_cfg(struct hclge_vport *vport)
hnae3_set_bit(req->vport_vlan_cfg, HCLGE_CFG_NIC_ROCE_SEL_B, 0);
req->vf_offset = vport->vport_id / HCLGE_VF_NUM_PER_CMD;
- req->vf_bitmap[req->vf_offset] =
- 1 << (vport->vport_id % HCLGE_VF_NUM_PER_BYTE);
+ bmap_index = vport->vport_id % HCLGE_VF_NUM_PER_CMD /
+ HCLGE_VF_NUM_PER_BYTE;
+ req->vf_bitmap[bmap_index] =
+ 1U << (vport->vport_id % HCLGE_VF_NUM_PER_BYTE);
status = hclge_cmd_send(&hdev->hw, &desc, 1);
if (status)
@@ -7731,6 +7734,7 @@ static int hclge_set_vlan_rx_offload_cfg(struct hclge_vport *vport)
struct hclge_vport_vtag_rx_cfg_cmd *req;
struct hclge_dev *hdev = vport->back;
struct hclge_desc desc;
+ u16 bmap_index;
int status;
hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_VLAN_PORT_RX_CFG, false);
@@ -7746,8 +7750,10 @@ static int hclge_set_vlan_rx_offload_cfg(struct hclge_vport *vport)
vcfg->vlan2_vlan_prionly ? 1 : 0);
req->vf_offset = vport->vport_id / HCLGE_VF_NUM_PER_CMD;
- req->vf_bitmap[req->vf_offset] =
- 1 << (vport->vport_id % HCLGE_VF_NUM_PER_BYTE);
+ bmap_index = vport->vport_id % HCLGE_VF_NUM_PER_CMD /
+ HCLGE_VF_NUM_PER_BYTE;
+ req->vf_bitmap[bmap_index] =
+ 1U << (vport->vport_id % HCLGE_VF_NUM_PER_BYTE);
status = hclge_cmd_send(&hdev->hw, &desc, 1);
if (status)
--
2.7.4
^ permalink raw reply related
* [PATCH V2 net-next 5/7] net: hns3: remove explicit conversion to bool
From: Huazhong Tan @ 2019-09-05 13:31 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Guojia Liao, Huazhong Tan
In-Reply-To: <1567690302-16648-1-git-send-email-tanhuazhong@huawei.com>
From: Guojia Liao <liaoguojia@huawei.com>
Relational and logical operators evaluate to bool,
explicit conversion is overly verbose and unnecessary.
Signed-off-by: Guojia Liao <liaoguojia@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 76e1c84..dde752f 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -6174,7 +6174,7 @@ static void hclge_enable_fd(struct hnae3_handle *handle, bool enable)
bool clear;
hdev->fd_en = enable;
- clear = hdev->fd_active_type == HCLGE_FD_ARFS_ACTIVE ? true : false;
+ clear = hdev->fd_active_type == HCLGE_FD_ARFS_ACTIVE;
if (!enable)
hclge_del_all_fd_entries(handle, clear);
else
--
2.7.4
^ permalink raw reply related
* [PATCH V2 net-next 7/7] net: hns3: make hclge_dbg_get_m7_stats_info static
From: Huazhong Tan @ 2019-09-05 13:31 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Guojia Liao, Huazhong Tan
In-Reply-To: <1567690302-16648-1-git-send-email-tanhuazhong@huawei.com>
From: Guojia Liao <liaoguojia@huawei.com>
hclge_dbg_get_m7_info is used only in the hclge_debugfs.c,
so it should be declared with static.
Signed-off-by: Guojia Liao <liaoguojia@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
index 1c6b501..6dcce48 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
@@ -949,7 +949,7 @@ static void hclge_dbg_dump_rst_info(struct hclge_dev *hdev)
hdev->rst_stats.reset_cnt);
}
-void hclge_dbg_get_m7_stats_info(struct hclge_dev *hdev)
+static void hclge_dbg_get_m7_stats_info(struct hclge_dev *hdev)
{
struct hclge_desc *desc_src, *desc_tmp;
struct hclge_get_m7_bd_cmd *req;
--
2.7.4
^ permalink raw reply related
* [PATCH V2 net-next 4/7] net: hns3: add client node validity judgment
From: Huazhong Tan @ 2019-09-05 13:31 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Peng Li, Huazhong Tan
In-Reply-To: <1567690302-16648-1-git-send-email-tanhuazhong@huawei.com>
From: Peng Li <lipeng321@huawei.com>
HNS3 driver can only unregister client which included in hnae3_client_list.
This patch adds the client node validity judgment.
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hnae3.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.c b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
index 528f624..03ca7d9 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
@@ -138,12 +138,28 @@ EXPORT_SYMBOL(hnae3_register_client);
void hnae3_unregister_client(struct hnae3_client *client)
{
+ struct hnae3_client *client_tmp;
struct hnae3_ae_dev *ae_dev;
+ bool existed = false;
if (!client)
return;
mutex_lock(&hnae3_common_lock);
+
+ list_for_each_entry(client_tmp, &hnae3_client_list, node) {
+ if (client_tmp->type == client->type) {
+ existed = true;
+ break;
+ }
+ }
+
+ if (!existed) {
+ mutex_unlock(&hnae3_common_lock);
+ pr_err("client %s does not exist!\n", client->name);
+ return;
+ }
+
/* un-initialize the client on every matched port */
list_for_each_entry(ae_dev, &hnae3_ae_dev_list, node) {
hnae3_uninit_client_instance(client, ae_dev);
--
2.7.4
^ permalink raw reply related
* [PATCH V2 net-next 6/7] net: hns3: disable loopback setting in hclge_mac_init
From: Huazhong Tan @ 2019-09-05 13:31 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Yufeng Mo, Huazhong Tan
In-Reply-To: <1567690302-16648-1-git-send-email-tanhuazhong@huawei.com>
From: Yufeng Mo <moyufeng@huawei.com>
If the selftest and reset are performed at the same time, the loopback
setting may be still in the enable state after the reset. As a result,
packets cannot be sent out.
This patch fixes this issue by disabling loopback in hclge_mac_init.
Signed-off-by: Yufeng Mo <moyufeng@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 34 +++++++++++++++++++++-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index dde752f..8d4dc1b 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -66,6 +66,7 @@ static void hclge_rfs_filter_expire(struct hclge_dev *hdev);
static void hclge_clear_arfs_rules(struct hnae3_handle *handle);
static enum hnae3_reset_type hclge_get_reset_level(struct hnae3_ae_dev *ae_dev,
unsigned long *addr);
+static int hclge_set_default_loopback(struct hclge_dev *hdev);
static struct hnae3_ae_algo ae_algo;
@@ -2599,6 +2600,10 @@ static int hclge_mac_init(struct hclge_dev *hdev)
return ret;
}
+ ret = hclge_set_default_loopback(hdev);
+ if (ret)
+ return ret;
+
ret = hclge_buffer_alloc(hdev);
if (ret)
dev_err(&hdev->pdev->dev,
@@ -6331,7 +6336,7 @@ static int hclge_set_app_loopback(struct hclge_dev *hdev, bool en)
return ret;
}
-static int hclge_set_serdes_loopback(struct hclge_dev *hdev, bool en,
+static int hclge_cfg_serdes_loopback(struct hclge_dev *hdev, bool en,
enum hnae3_loop loop_mode)
{
#define HCLGE_SERDES_RETRY_MS 10
@@ -6392,6 +6397,17 @@ static int hclge_set_serdes_loopback(struct hclge_dev *hdev, bool en,
dev_err(&hdev->pdev->dev, "serdes loopback set failed in fw\n");
return -EIO;
}
+ return ret;
+}
+
+static int hclge_set_serdes_loopback(struct hclge_dev *hdev, bool en,
+ enum hnae3_loop loop_mode)
+{
+ int ret;
+
+ ret = hclge_cfg_serdes_loopback(hdev, en, loop_mode);
+ if (ret)
+ return ret;
hclge_cfg_mac_mode(hdev, en);
@@ -6535,6 +6551,22 @@ static int hclge_set_loopback(struct hnae3_handle *handle,
return 0;
}
+static int hclge_set_default_loopback(struct hclge_dev *hdev)
+{
+ int ret;
+
+ ret = hclge_set_app_loopback(hdev, false);
+ if (ret)
+ return ret;
+
+ ret = hclge_cfg_serdes_loopback(hdev, false, HNAE3_LOOP_SERIAL_SERDES);
+ if (ret)
+ return ret;
+
+ return hclge_cfg_serdes_loopback(hdev, false,
+ HNAE3_LOOP_PARALLEL_SERDES);
+}
+
static void hclge_reset_tqp_stats(struct hnae3_handle *handle)
{
struct hclge_vport *vport = hclge_get_vport(handle);
--
2.7.4
^ permalink raw reply related
* [PATCH V2 net-next 0/7] net: hns3: add some bugfixes and cleanups
From: Huazhong Tan @ 2019-09-05 13:31 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Huazhong Tan
This patch-set includes bugfixes and cleanups for the HNS3
ethernet controller driver.
[patch 01/07] fixes an error when setting VLAN offload.
[patch 02/07] fixes an double free issue when setting ringparam.
[patch 03/07] fixes a mis-assignment of hdev->reset_level.
[patch 04/07] adds a checking for client's validity.
[patch 05/07] simplifies bool variable's assignment.
[patch 06/07] disables loopback when initializing.
[patch 07/07] makes internal function to static.
Change log:
V1->V2: fixes comment from Sergei Shtylyov.
Guojia Liao (2):
net: hns3: remove explicit conversion to bool
net: hns3: make hclge_dbg_get_m7_stats_info static
Huazhong Tan (2):
net: hns3: fix double free bug when setting ringparam
net: hns3: fix mis-assignment to hdev->reset_level in hclge_reset
Jian Shen (1):
net: hns3: fix error VF index when setting VLAN offload
Peng Li (1):
net: hns3: add client node validity judgment
Yufeng Mo (1):
net: hns3: disable loopback setting in hclge_mac_init
drivers/net/ethernet/hisilicon/hns3/hnae3.c | 16 ++++++
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 4 +-
.../ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c | 2 +-
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 59 ++++++++++++++++++----
4 files changed, 69 insertions(+), 12 deletions(-)
--
2.7.4
^ permalink raw reply
* RE: [PATCH net] net: sched: fix reordering issues
From: John Fastabend @ 2019-09-05 13:27 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller
Cc: netdev, Eric Dumazet, Eric Dumazet, John Fastabend
In-Reply-To: <20190905122022.106680-1-edumazet@google.com>
Eric Dumazet wrote:
> Whenever MQ is not used on a multiqueue device, we experience
> serious reordering problems. Bisection found the cited
> commit.
>
> The issue can be described this way :
>
> - A single qdisc hierarchy is shared by all transmit queues.
> (eg : tc qdisc replace dev eth0 root fq_codel)
>
> - When/if try_bulk_dequeue_skb_slow() dequeues a packet targetting
> a different transmit queue than the one used to build a packet train,
> we stop building the current list and save the 'bad' skb (P1) in a
> special queue. (bad_txq)
>
> - When dequeue_skb() calls qdisc_dequeue_skb_bad_txq() and finds this
> skb (P1), it checks if the associated transmit queues is still in frozen
> state. If the queue is still blocked (by BQL or NIC tx ring full),
> we leave the skb in bad_txq and return NULL.
>
> - dequeue_skb() calls q->dequeue() to get another packet (P2)
>
> The other packet can target the problematic queue (that we found
> in frozen state for the bad_txq packet), but another cpu just ran
> TX completion and made room in the txq that is now ready to accept
> new packets.
>
> - Packet P2 is sent while P1 is still held in bad_txq, P1 might be sent
> at next round. In practice P2 is the lead of a big packet train
> (P2,P3,P4 ...) filling the BQL budget and delaying P1 by many packets :/
>
> To solve this problem, we have to block the dequeue process as long
> as the first packet in bad_txq can not be sent. Reordering issues
> disappear and no side effects have been seen.
>
> Fixes: a53851e2c321 ("net: sched: explicit locking in gso_cpu fallback")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: John Fastabend <john.fastabend@gmail.com>
> ---
> net/sched/sch_generic.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
Dang, missed this case. Thanks!
Acked-by: John Fastabend <john.fastabend@gmail.com>
^ permalink raw reply
* Re: [PATCH REPOST 1/2] can: flexcan: fix deadlock when using self wakeup
From: Sean Nyekjaer @ 2019-09-05 13:17 UTC (permalink / raw)
To: Joakim Zhang, mkl@pengutronix.de, linux-can@vger.kernel.org
Cc: wg@grandegger.com, netdev@vger.kernel.org, dl-linux-imx,
Martin Hundebøll
In-Reply-To: <DB7PR04MB461868320DA0B25CC8255213E6BB0@DB7PR04MB4618.eurprd04.prod.outlook.com>
On 05/09/2019 09.10, Joakim Zhang wrote:
> Hi Sean,
>
> Could you update lastest flexcan driver using linux-can-next/flexcan and then merge below two patches from linux-can/testing?
> d0b53616716e (HEAD -> testing, origin/testing) can: flexcan: add LPSR mode support for i.MX7D
> 803eb6bad65b can: flexcan: fix deadlock when using self wakeup
>
> Best Regards,
> Joakim Zhang
The testing branch have some UBI bugs, when suspending it crashes...
So will have to leave this, until they are resolved :-)
/Sean
^ permalink raw reply
* Re: [PATCH bpf] bpf: fix precision tracking of stack slots
From: Daniel Borkmann @ 2019-09-05 13:15 UTC (permalink / raw)
To: Alexei Starovoitov, davem; +Cc: netdev, bpf, kernel-team
In-Reply-To: <20190903221617.635375-1-ast@kernel.org>
On 9/4/19 12:16 AM, Alexei Starovoitov wrote:
> The problem can be seen in the following two tests:
> 0: (bf) r3 = r10
> 1: (55) if r3 != 0x7b goto pc+0
> 2: (7a) *(u64 *)(r3 -8) = 0
> 3: (79) r4 = *(u64 *)(r10 -8)
> ..
> 0: (85) call bpf_get_prandom_u32#7
> 1: (bf) r3 = r10
> 2: (55) if r3 != 0x7b goto pc+0
> 3: (7b) *(u64 *)(r3 -8) = r0
> 4: (79) r4 = *(u64 *)(r10 -8)
>
> When backtracking need to mark R4 it will mark slot fp-8.
> But ST or STX into fp-8 could belong to the same block of instructions.
> When backtracing is done the parent state may have fp-8 slot
> as "unallocated stack". Which will cause verifier to warn
> and incorrectly reject such programs.
>
> Writes into stack via non-R10 register are rare. llvm always
> generates canonical stack spill/fill.
> For such pathological case fall back to conservative precision
> tracking instead of rejecting.
>
> Reported-by: syzbot+c8d66267fd2b5955287e@syzkaller.appspotmail.com
> Fixes: b5dc0163d8fd ("bpf: precise scalar_value tracking")
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH bpf-next v3 0/4] xsk: various CPU barrier and {READ, WRITE}_ONCE
From: Daniel Borkmann @ 2019-09-05 13:14 UTC (permalink / raw)
To: Björn Töpel, ast, netdev
Cc: magnus.karlsson, magnus.karlsson, bpf, bjorn.topel,
jonathan.lemon, syzbot+c82697e3043781e08802, hdanton, i.maximets
In-Reply-To: <20190904114913.17217-1-bjorn.topel@gmail.com>
On 9/4/19 1:49 PM, Björn Töpel wrote:
> This is a four patch series of various barrier, {READ, WRITE}_ONCE
> cleanups in the AF_XDP socket code. More details can be found in the
> corresponding commit message. Previous revisions: v1 [4] and v2 [5].
>
> For an AF_XDP socket, most control plane operations are done under the
> control mutex (struct xdp_sock, mutex), but there are some places
> where members of the struct is read outside the control mutex. The
> dev, queue_id members are set in bind() and cleared at cleanup. The
> umem, fq, cq, tx, rx, and state member are all assigned in various
> places, e.g. bind() and setsockopt(). When the members are assigned,
> they are protected by the control mutex, but since they are read
> outside the mutex, a WRITE_ONCE is required to avoid store-tearing on
> the read-side.
>
> Prior the state variable was introduced by Ilya, the dev member was
> used to determine whether the socket was bound or not. However, when
> dev was read, proper SMP barriers and READ_ONCE were missing. In order
> to address the missing barriers and READ_ONCE, we start using the
> state variable as a point of synchronization. The state member
> read/write is paired with proper SMP barriers, and from this follows
> that the members described above does not need READ_ONCE statements if
> used in conjunction with state check.
>
> To summarize: The members struct xdp_sock members dev, queue_id, umem,
> fq, cq, tx, rx, and state were read lock-less, with incorrect barriers
> and missing {READ, WRITE}_ONCE. After this series umem, fq, cq, tx,
> rx, and state are read lock-less. When these members are updated,
> WRITE_ONCE is used. When read, READ_ONCE are only used when read
> outside the control mutex (e.g. mmap) or, not synchronized with the
> state member (XSK_BOUND plus smp_rmb())
>
> Thanks,
> Björn
>
> [1] https://lore.kernel.org/bpf/beef16bb-a09b-40f1-7dd0-c323b4b89b17@iogearbox.net/
> [2] https://lwn.net/Articles/793253/
> [3] https://github.com/google/ktsan/wiki/READ_ONCE-and-WRITE_ONCE
> [4] https://lore.kernel.org/bpf/20190822091306.20581-1-bjorn.topel@gmail.com/
> [5] https://lore.kernel.org/bpf/20190826061053.15996-1-bjorn.topel@gmail.com/
>
> v2->v3:
> Minor restructure of commits.
> Improve cover and commit messages. (Daniel)
> v1->v2:
> Removed redundant dev check. (Jonathan)
>
> Björn Töpel (4):
> xsk: avoid store-tearing when assigning queues
> xsk: avoid store-tearing when assigning umem
> xsk: use state member for socket synchronization
> xsk: lock the control mutex in sock_diag interface
>
> net/xdp/xsk.c | 60 ++++++++++++++++++++++++++++++++--------------
> net/xdp/xsk_diag.c | 3 +++
> 2 files changed, 45 insertions(+), 18 deletions(-)
>
Applied, thanks!
^ 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