* Re: [PATCH] net: tap: clean up an indentation issue
From: David Miller @ 2019-09-27 18:58 UTC (permalink / raw)
To: colin.king; +Cc: netdev, kernel-janitors, linux-kernel
In-Reply-To: <20190927094039.23370-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 27 Sep 2019 10:40:39 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> There is a statement that is indented too deeply, remove
> the extraneous tab.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] vsock/virtio: add support for MSG_PEEK
From: David Miller @ 2019-09-27 18:59 UTC (permalink / raw)
To: matiasevara
Cc: stefanha, kvm, virtualization, netdev, linux-kernel, sgarzare,
eric.dumazet
In-Reply-To: <1569602663-16815-1-git-send-email-matiasevara@gmail.com>
This is net-next material.
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH] i40e: prevent memory leak in i40e_setup_macvlans
From: Bowers, AndrewX @ 2019-09-27 19:01 UTC (permalink / raw)
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
intel-wired-lan@lists.osuosl.org
In-Reply-To: <20190925154831.19044-1-navid.emamdoost@gmail.com>
> -----Original Message-----
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On
> Behalf Of Navid Emamdoost
> Sent: Wednesday, September 25, 2019 8:49 AM
> Cc: netdev@vger.kernel.org; kjlu@umn.edu; linux-kernel@vger.kernel.org;
> emamd001@umn.edu; intel-wired-lan@lists.osuosl.org;
> smccaman@umn.edu; David S. Miller <davem@davemloft.net>; Navid
> Emamdoost <navid.emamdoost@gmail.com>
> Subject: [Intel-wired-lan] [PATCH] i40e: prevent memory leak in
> i40e_setup_macvlans
>
> In i40e_setup_macvlans if i40e_setup_channel fails the allocated memory for
> ch should be released.
>
> Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_main.c | 1 +
> 1 file changed, 1 insertion(+)
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
^ permalink raw reply
* Re: [PATCH] tools: bpf: Use !building_out_of_srctree to determine srctree
From: Shuah Khan @ 2019-09-27 19:03 UTC (permalink / raw)
To: Song Liu
Cc: Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, Networking, bpf, open list, linux-kselftest,
Shuah Khan
In-Reply-To: <CAPhsuW5EncjNRGjt7F_BN2bNhRkf=uXVeDe6NCbJe=K2J+hdyA@mail.gmail.com>
On 9/27/19 12:44 PM, Song Liu wrote:
> On Thu, Sep 26, 2019 at 6:14 PM Shuah Khan <skhan@linuxfoundation.org> wrote:
>>
>> make TARGETS=bpf kselftest fails with:
>>
>> Makefile:127: tools/build/Makefile.include: No such file or directory
>>
>> When the bpf tool make is invoked from tools Makefile, srctree is
>> cleared and the current logic check for srctree equals to empty
>> string to determine srctree location from CURDIR.
>>
>> When the build in invoked from selftests/bpf Makefile, the srctree
>> is set to "." and the same logic used for srctree equals to empty is
>> needed to determine srctree.
>>
>> Check building_out_of_srctree undefined as the condition for both
>> cases to fix "make TARGETS=bpf kselftest" build failure.
>>
>> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
>
> The fix looks reasonable. Thanks!
>
> However, I am still seeing some failure:
>
> make TARGETS=bpf kselftest
> [...]
> test_verifier.c
> /data/users/songliubraving/kernel/linux-git/tools/testing/selftests/bpf/test_stub.o
> /data/users/songliubraving/kernel/linux-git/tools/testing/selftests/bpf/libbpf.a
> -lcap -lelf -lrt -lpthread -o
> /data/users/songliubraving/kernel/linux-git/tools/testing/selftests/bpf/test_verifier
> make[3]: test_verifier.c: Command not found
>
> Is this just a problem with my setup?
>
You are running into the second bpf failure because of the dependency
on the latest llvm. This is known issue with bpf test and it doesn't
compile on 5.4 and maybe even 5.3
You have upgrade to the bleeding edge llvm.
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH net] sch_cbq: validate TCA_CBQ_WRROPT to avoid crash
From: Eric Dumazet @ 2019-09-27 19:57 UTC (permalink / raw)
To: David Miller, edumazet; +Cc: netdev, eric.dumazet, syzkaller
In-Reply-To: <20190927.205524.1304517574378068070.davem@davemloft.net>
On 9/27/19 11:55 AM, David Miller wrote:
> From: Eric Dumazet <edumazet@google.com>
> Date: Thu, 26 Sep 2019 18:24:43 -0700
>
>> syzbot reported a crash in cbq_normalize_quanta() caused
>> by an out of range cl->priority.
> ...
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Reported-by: syzbot <syzkaller@googlegroups.com>
>
> Fixes: tag? -stable?
>
I guess I feel always a bit sad to add :
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Thanks !
^ permalink raw reply
* Re: [PATCH] ieee802154: ca8210: prevent memory leak
From: Stefan Schmidt @ 2019-09-27 20:01 UTC (permalink / raw)
To: Navid Emamdoost
Cc: emamd001, smccaman, kjlu, Harry Morris, Alexander Aring,
David S. Miller, linux-wpan, netdev, linux-kernel
In-Reply-To: <20190917224713.26371-1-navid.emamdoost@gmail.com>
Hello.
On 18.09.19 00:47, Navid Emamdoost wrote:
> In ca8210_probe the allocated pdata needs to be assigned to
> spi_device->dev.platform_data before calling ca8210_get_platform_data.
> Othrwise when ca8210_get_platform_data fails pdata cannot be released.
>
> Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
> ---
> drivers/net/ieee802154/ca8210.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ieee802154/ca8210.c b/drivers/net/ieee802154/ca8210.c
> index b188fce3f641..229d70a897ca 100644
> --- a/drivers/net/ieee802154/ca8210.c
> +++ b/drivers/net/ieee802154/ca8210.c
> @@ -3152,12 +3152,12 @@ static int ca8210_probe(struct spi_device *spi_device)
> goto error;
> }
>
> + priv->spi->dev.platform_data = pdata;
> ret = ca8210_get_platform_data(priv->spi, pdata);
> if (ret) {
> dev_crit(&spi_device->dev, "ca8210_get_platform_data failed\n");
> goto error;
> }
> - priv->spi->dev.platform_data = pdata;
>
> ret = ca8210_dev_com_init(priv);
> if (ret) {
>
As Harry seems to be unavailable I am taking this patch directly.
This patch has been applied to the wpan tree and will be
part of the next pull request to net. Thanks!
regards
Stefan Schmidt
^ permalink raw reply
* Re: [RFC 20/20] RDMA/i40iw: Mark i40iw as deprecated
From: Doug Ledford @ 2019-09-27 20:17 UTC (permalink / raw)
To: gregkh@linuxfoundation.org, Saleem, Shiraz
Cc: Leon Romanovsky, Kirsher, Jeffrey T, jgg@mellanox.com,
netdev@vger.kernel.org, linux-rdma@vger.kernel.org
In-Reply-To: <20190926195517.GA1743170@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]
On Thu, 2019-09-26 at 21:55 +0200, gregkh@linuxfoundation.org wrote:
> On Thu, Sep 26, 2019 at 07:49:44PM +0000, Saleem, Shiraz wrote:
> > > Subject: Re: [RFC 20/20] RDMA/i40iw: Mark i40iw as deprecated
> > >
> > > On Thu, Sep 26, 2019 at 09:45:19AM -0700, Jeff Kirsher wrote:
> > > > From: Shiraz Saleem <shiraz.saleem@intel.com>
> > > >
> > > > Mark i40iw as deprecated/obsolete.
> > > >
> > > > irdma is the replacement driver that supports X722.
> > >
> > > Can you simply delete old one and add MODULE_ALIAS() in new
> > > driver?
> > >
> >
> > Yes, but we thought typically driver has to be deprecated for a few
> > cycles before removing it.
>
> If you completely replace it with something that works the same, why
> keep the old one around at all?
>
> Unless you don't trust your new code? :)
I have yet to see, in over 20 years of kernel experience, a new driver
replace an old driver and not initially be more buggy and troublesome
than the old driver. It takes time and real world usage for the final
issues to get sorted out. During that time, the fallback is often
necessary for those real world users.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [RFC 20/20] RDMA/i40iw: Mark i40iw as deprecated
From: Doug Ledford @ 2019-09-27 20:18 UTC (permalink / raw)
To: Saleem, Shiraz, gregkh@linuxfoundation.org
Cc: Leon Romanovsky, Kirsher, Jeffrey T, jgg@mellanox.com,
netdev@vger.kernel.org, linux-rdma@vger.kernel.org
In-Reply-To: <9DD61F30A802C4429A01CA4200E302A7AC70465F@fmsmsx123.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]
On Fri, 2019-09-27 at 14:28 +0000, Saleem, Shiraz wrote:
> > Subject: Re: [RFC 20/20] RDMA/i40iw: Mark i40iw as deprecated
> >
> > On Thu, Sep 26, 2019 at 07:49:44PM +0000, Saleem, Shiraz wrote:
> > > > Subject: Re: [RFC 20/20] RDMA/i40iw: Mark i40iw as deprecated
> > > >
> > > > On Thu, Sep 26, 2019 at 09:45:19AM -0700, Jeff Kirsher wrote:
> > > > > From: Shiraz Saleem <shiraz.saleem@intel.com>
> > > > >
> > > > > Mark i40iw as deprecated/obsolete.
> > > > >
> > > > > irdma is the replacement driver that supports X722.
> > > >
> > > > Can you simply delete old one and add MODULE_ALIAS() in new
> > > > driver?
> > > >
> > >
> > > Yes, but we thought typically driver has to be deprecated for a
> > > few cycles
> > before removing it.
> >
> > If you completely replace it with something that works the same, why
> > keep the old
> > one around at all?
>
> Agree. Thanks!
>
>
> > Unless you don't trust your new code? :)
> >
> We do :)
I don't....
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH bpf] bpf: Fix a race in reuseport_array_free()
From: Eric Dumazet @ 2019-09-27 20:47 UTC (permalink / raw)
To: Martin Lau, Eric Dumazet
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, Alexei Starovoitov,
Daniel Borkmann, David Miller, Kernel Team
In-Reply-To: <20190927181729.7ep3pp2hiy6l5ixk@kafai-mbp.dhcp.thefacebook.com>
On 9/27/19 11:17 AM, Martin Lau wrote:
> On Fri, Sep 27, 2019 at 10:24:49AM -0700, Eric Dumazet wrote:
>>
>>
>> On 9/27/19 9:52 AM, Martin KaFai Lau wrote:
>>> In reuseport_array_free(), the rcu_read_lock() cannot ensure sk is still
>>> valid. It is because bpf_sk_reuseport_detach() can be called from
>>> __sk_destruct() which is invoked through call_rcu(..., __sk_destruct).
>>
>> We could question why reuseport_detach_sock(sk) is called from __sk_destruct()
>> (after the rcu grace period) instead of sk_destruct() ?
> Agree. It is another way to fix it.
>
> In this patch, I chose to avoid the need to single out a special treatment for
> reuseport_detach_sock() in sk_destruct().
>
> I am happy either way. What do you think?
It seems that since we call reuseport_detach_sock() after the rcu grace period,
another cpu could catch the sk pointer in reuse->socks[] array and use
it right before our cpu frees the socket.
RCU rules are not properly applied here I think.
The rules for deletion are :
1) unpublish object from various lists/arrays/hashes.
2) rcu_grace_period
3) free the object.
If we fix the unpublish (we need to anyway to make the data path safe),
then your patch is not needed ?
What about (totally untested, might be horribly wrong)
diff --git a/net/core/sock.c b/net/core/sock.c
index 07863edbe6fc4842e47ebebf00bc21bc406d9264..d31a4b094797f73ef89110c954aa0a164879362d 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1700,8 +1700,6 @@ static void __sk_destruct(struct rcu_head *head)
sk_filter_uncharge(sk, filter);
RCU_INIT_POINTER(sk->sk_filter, NULL);
}
- if (rcu_access_pointer(sk->sk_reuseport_cb))
- reuseport_detach_sock(sk);
sock_disable_timestamp(sk, SK_FLAGS_TIMESTAMP);
@@ -1728,7 +1726,13 @@ static void __sk_destruct(struct rcu_head *head)
void sk_destruct(struct sock *sk)
{
- if (sock_flag(sk, SOCK_RCU_FREE))
+ bool use_call_rcu = sock_flag(sk, SOCK_RCU_FREE);
+
+ if (rcu_access_pointer(sk->sk_reuseport_cb)) {
+ reuseport_detach_sock(sk);
+ use_call_rcu = true;
+ }
+ if (use_call_rcu)
call_rcu(&sk->sk_rcu, __sk_destruct);
else
__sk_destruct(&sk->sk_rcu);
^ permalink raw reply related
* [PATCH] iwlwifi: fix memory leaks in iwl_pcie_ctxt_info_gen3_init
From: Navid Emamdoost @ 2019-09-27 20:56 UTC (permalink / raw)
Cc: emamd001, smccaman, kjlu, Navid Emamdoost, Johannes Berg,
Emmanuel Grumbach, Luca Coelho, Intel Linux Wireless, Kalle Valo,
David S. Miller, Shaul Triebitz, Sara Sharon, Shahar S Matityahu,
linux-wireless, netdev, linux-kernel
In iwl_pcie_ctxt_info_gen3_init there are cases that the allocated dma
memory is leaked in case of error.
DMA memories prph_scratch, prph_info, and ctxt_info_gen3 are allocated
and initialized to be later assigned to trans_pcie. But in any error case
before such assignment the allocated memories should be released.
First of such error cases happens when iwl_pcie_init_fw_sec fails.
Current implementation correctly releases prph_scratch. But in two
sunsequent error cases where dma_alloc_coherent may fail, such releases
are missing. This commit adds release for prph_scratch when allocation
for prph_info fails, and adds releases for prph_scratch and prph_info
when allocation for ctxt_info_gen3 fails.
Fixes: 2ee824026288 ("iwlwifi: pcie: support context information for 22560 devices")
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
---
.../intel/iwlwifi/pcie/ctxt-info-gen3.c | 36 +++++++++++++------
1 file changed, 25 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info-gen3.c b/drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info-gen3.c
index 75fa8a6aafee..b2759c751822 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info-gen3.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info-gen3.c
@@ -107,13 +107,9 @@ int iwl_pcie_ctxt_info_gen3_init(struct iwl_trans *trans,
/* allocate ucode sections in dram and set addresses */
ret = iwl_pcie_init_fw_sec(trans, fw, &prph_scratch->dram);
- if (ret) {
- dma_free_coherent(trans->dev,
- sizeof(*prph_scratch),
- prph_scratch,
- trans_pcie->prph_scratch_dma_addr);
- return ret;
- }
+ if (ret)
+ goto err_free_prph_scratch;
+
/* Allocate prph information
* currently we don't assign to the prph info anything, but it would get
@@ -121,16 +117,20 @@ int iwl_pcie_ctxt_info_gen3_init(struct iwl_trans *trans,
prph_info = dma_alloc_coherent(trans->dev, sizeof(*prph_info),
&trans_pcie->prph_info_dma_addr,
GFP_KERNEL);
- if (!prph_info)
- return -ENOMEM;
+ if (!prph_info) {
+ ret = -ENOMEM;
+ goto err_free_prph_scratch;
+ }
/* Allocate context info */
ctxt_info_gen3 = dma_alloc_coherent(trans->dev,
sizeof(*ctxt_info_gen3),
&trans_pcie->ctxt_info_dma_addr,
GFP_KERNEL);
- if (!ctxt_info_gen3)
- return -ENOMEM;
+ if (!ctxt_info_gen3) {
+ ret = -ENOMEM;
+ goto err_free_prph_info;
+ }
ctxt_info_gen3->prph_info_base_addr =
cpu_to_le64(trans_pcie->prph_info_dma_addr);
@@ -186,6 +186,20 @@ int iwl_pcie_ctxt_info_gen3_init(struct iwl_trans *trans,
iwl_set_bit(trans, CSR_GP_CNTRL, CSR_AUTO_FUNC_INIT);
return 0;
+
+err_free_prph_info:
+ dma_free_coherent(trans->dev,
+ sizeof(*prph_info),
+ prph_info,
+ trans_pcie->prph_info_dma_addr);
+
+err_free_prph_scratch:
+ dma_free_coherent(trans->dev,
+ sizeof(*prph_scratch),
+ prph_scratch,
+ trans_pcie->prph_scratch_dma_addr);
+ return ret;
+
}
void iwl_pcie_ctxt_info_gen3_free(struct iwl_trans *trans)
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2] riscv: add support for SECCOMP and SECCOMP_FILTER
From: Andy Lutomirski @ 2019-09-27 20:58 UTC (permalink / raw)
To: Palmer Dabbelt
Cc: Kees Cook, David Abdurachmanov, Paul Walmsley, Albert Ou,
Oleg Nesterov, Will Drewry, Shuah Khan, Alexei Starovoitov,
Daniel Borkmann, Martin KaFai Lau, Song Liu, Yonghong Song,
David Abdurachmanov, Thomas Gleixner, Allison Randal,
Alexios Zavras, Anup Patel, Vincent Chen, Alan Kao, linux-riscv,
LKML, open list:KERNEL SELFTEST FRAMEWORK, Network Development,
bpf, me
In-Reply-To: <mhng-c8a768f7-1a90-4228-b654-be9e879c92ec@palmer-si-x1c4>
On Tue, Sep 3, 2019 at 3:27 PM Palmer Dabbelt <palmer@sifive.com> wrote:
>
> On Wed, 28 Aug 2019 10:52:05 PDT (-0700), luto@amacapital.net wrote:
> >
> >
> >> On Aug 25, 2019, at 2:59 PM, Kees Cook <keescook@chromium.org> wrote:
> >>
> >>> On Thu, Aug 22, 2019 at 01:55:22PM -0700, David Abdurachmanov wrote:
> >>> This patch was extensively tested on Fedora/RISCV (applied by default on
> >>> top of 5.2-rc7 kernel for <2 months). The patch was also tested with 5.3-rc
> >>> on QEMU and SiFive Unleashed board.
> >>
> >> Oops, I see the mention of QEMU here. Where's the best place to find
> >> instructions on creating a qemu riscv image/environment?
> >
> > I don’t suppose one of you riscv folks would like to contribute riscv support to virtme? virtme-run —arch=riscv would be quite nice, and the total patch should be just a couple lines. Unfortunately, it helps a lot to understand the subtleties of booting the architecture to write those couple lines :)
>
> What mailing list should I sent this to? You need to use the "virtme" branch
> of kernel.org/palmer/linux.git until I send the defconfig patches.
>
> commit a8bd7b318691891991caea298f9a5ed0f815c322
> gpg: Signature made Tue 03 Sep 2019 03:22:45 PM PDT
> gpg: using RSA key 00CE76D1834960DFCE886DF8EF4CA1502CCBAB41
> gpg: issuer "palmer@dabbelt.com"
> gpg: Good signature from "Palmer Dabbelt <palmer@dabbelt.com>" [ultimate]
> gpg: aka "Palmer Dabbelt <palmer@sifive.com>" [ultimate]
> Author: Palmer Dabbelt <palmer@sifive.com>
> Date: Tue Sep 3 14:39:39 2019 -0700
>
> Add RISC-V support
Could you rebase onto virtme master and resend in some format that
isn't corrupt? git am really doesn't like your patch and, even if I
fix it up manually, your gpg: lines are bogus. You could also send a
PR at https://github.com/amluto/virtme
^ permalink raw reply
* Re: [PATCH net 8/8] net: stmmac: xgmac: Fix RSS not writing all Keys to HW
From: Nick Desaulniers @ 2019-09-27 21:12 UTC (permalink / raw)
To: Jose Abreu
Cc: Network Development, Joao Pinto, Giuseppe Cavallaro,
Alexandre Torgue, David S. Miller, Maxime Coquelin, linux-stm32,
Linux ARM, LKML, clang-built-linux
In-Reply-To: <80dd26ecf7fc82c88dc378d78210df5dd4138812.1569569778.git.Jose.Abreu@synopsys.com>
On Fri, Sep 27, 2019 at 12:49 AM Jose Abreu <Jose.Abreu@synopsys.com> wrote:
>
> The sizeof(cfg->key) is != ARRAY_SIZE(cfg->key). Fix it.
I think the warning was from -Wsizeof-array-div.
>
> Reported-by: kbuild test robot <lkp@intel.com>
> Reported-by: Nick Desaulniers <ndesaulniers@google.com>
I may have reported the kbuild link, but scanning my email, there's
also a report from
Reported-by: Nathan Chancellor <natechancellor@gmail.com>
> Fixes: 76067459c686 ("net: stmmac: Implement RSS and enable it in XGMAC core")
> Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
>
> ---
> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> Cc: Jose Abreu <joabreu@synopsys.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> Cc: netdev@vger.kernel.org
> Cc: linux-stm32@st-md-mailman.stormreply.com
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: Nick Desaulniers <ndesaulniers@google.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
> index 6d8ac2ef4fc2..4a1f52474dbc 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
> @@ -533,7 +533,7 @@ static int dwxgmac2_rss_configure(struct mac_device_info *hw,
> return 0;
> }
>
> - for (i = 0; i < (sizeof(cfg->key) / sizeof(u32)); i++) {
> + for (i = 0; i < (ARRAY_SIZE(cfg->key) / sizeof(u32)); i++) {
cfg is an instance of struct stmmac_rss, which looks like:
125 struct stmmac_rss {
126 int enable;
127 u8 key[STMMAC_RSS_HASH_KEY_SIZE];
128 u32 table[STMMAC_RSS_MAX_TABLE_SIZE];
129 };
yep, LGTM. Thanks for the patch.
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> ret = dwxgmac2_rss_write_reg(ioaddr, true, i, cfg->key[i]);
> if (ret)
> return ret;
> --
> 2.7.4
>
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [PATCH] tools: bpf: Use !building_out_of_srctree to determine srctree
From: Song Liu @ 2019-09-27 21:15 UTC (permalink / raw)
To: Shuah Khan
Cc: Song Liu, Alexei Starovoitov, Daniel Borkmann, Martin Lau,
Yonghong Song, Networking, bpf, open list,
linux-kselftest@vger.kernel.org
In-Reply-To: <5ec40572-5df9-0e5b-5a85-eb53be48b87d@linuxfoundation.org>
> On Sep 27, 2019, at 12:03 PM, Shuah Khan <skhan@linuxfoundation.org> wrote:
>
> On 9/27/19 12:44 PM, Song Liu wrote:
>> On Thu, Sep 26, 2019 at 6:14 PM Shuah Khan <skhan@linuxfoundation.org> wrote:
>>>
>>> make TARGETS=bpf kselftest fails with:
>>>
>>> Makefile:127: tools/build/Makefile.include: No such file or directory
>>>
>>> When the bpf tool make is invoked from tools Makefile, srctree is
>>> cleared and the current logic check for srctree equals to empty
>>> string to determine srctree location from CURDIR.
>>>
>>> When the build in invoked from selftests/bpf Makefile, the srctree
>>> is set to "." and the same logic used for srctree equals to empty is
>>> needed to determine srctree.
>>>
>>> Check building_out_of_srctree undefined as the condition for both
>>> cases to fix "make TARGETS=bpf kselftest" build failure.
>>>
>>> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
>> The fix looks reasonable. Thanks!
>> However, I am still seeing some failure:
>> make TARGETS=bpf kselftest
>> [...]
>> test_verifier.c
>> /data/users/songliubraving/kernel/linux-git/tools/testing/selftests/bpf/test_stub.o
>> /data/users/songliubraving/kernel/linux-git/tools/testing/selftests/bpf/libbpf.a
>> -lcap -lelf -lrt -lpthread -o
>> /data/users/songliubraving/kernel/linux-git/tools/testing/selftests/bpf/test_verifier
>> make[3]: test_verifier.c: Command not found
>> Is this just a problem with my setup?
>
> You are running into the second bpf failure because of the dependency
> on the latest llvm. This is known issue with bpf test and it doesn't
> compile on 5.4 and maybe even 5.3
>
Thanks for the clarification.
Acked-by: Song Liu <songliubraving@fb.com>
^ permalink raw reply
* Re: [PATCH bpf] bpf: Fix a race in reuseport_array_free()
From: Martin Lau @ 2019-09-27 21:22 UTC (permalink / raw)
To: Eric Dumazet
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, Alexei Starovoitov,
Daniel Borkmann, David Miller, Kernel Team
In-Reply-To: <fc762c01-94da-7f72-4fc0-9b76d6bbe3dd@gmail.com>
On Fri, Sep 27, 2019 at 01:47:32PM -0700, Eric Dumazet wrote:
>
>
> On 9/27/19 11:17 AM, Martin Lau wrote:
> > On Fri, Sep 27, 2019 at 10:24:49AM -0700, Eric Dumazet wrote:
> >>
> >>
> >> On 9/27/19 9:52 AM, Martin KaFai Lau wrote:
> >>> In reuseport_array_free(), the rcu_read_lock() cannot ensure sk is still
> >>> valid. It is because bpf_sk_reuseport_detach() can be called from
> >>> __sk_destruct() which is invoked through call_rcu(..., __sk_destruct).
> >>
> >> We could question why reuseport_detach_sock(sk) is called from __sk_destruct()
> >> (after the rcu grace period) instead of sk_destruct() ?
> > Agree. It is another way to fix it.
> >
> > In this patch, I chose to avoid the need to single out a special treatment for
> > reuseport_detach_sock() in sk_destruct().
> >
> > I am happy either way. What do you think?
>
> It seems that since we call reuseport_detach_sock() after the rcu grace period,
> another cpu could catch the sk pointer in reuse->socks[] array and use
> it right before our cpu frees the socket.
>
> RCU rules are not properly applied here I think.
>
> The rules for deletion are :
>
> 1) unpublish object from various lists/arrays/hashes.
Thanks for the analysis. Agreed. Indeed, there is an issue in reuse->socks[]
which is shared with other sockets and they may pick up the destructed
sk from reuse->socks[].
> 2) rcu_grace_period
> 3) free the object.
>
> If we fix the unpublish (we need to anyway to make the data path safe),
> then your patch is not needed ?
Correct, not needed.
>
> What about (totally untested, might be horribly wrong)
I had something similar in mind also. I will take a closer look and
re-spin v2.
>
> diff --git a/net/core/sock.c b/net/core/sock.c
> index 07863edbe6fc4842e47ebebf00bc21bc406d9264..d31a4b094797f73ef89110c954aa0a164879362d 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -1700,8 +1700,6 @@ static void __sk_destruct(struct rcu_head *head)
> sk_filter_uncharge(sk, filter);
> RCU_INIT_POINTER(sk->sk_filter, NULL);
> }
> - if (rcu_access_pointer(sk->sk_reuseport_cb))
> - reuseport_detach_sock(sk);
>
> sock_disable_timestamp(sk, SK_FLAGS_TIMESTAMP);
>
> @@ -1728,7 +1726,13 @@ static void __sk_destruct(struct rcu_head *head)
>
> void sk_destruct(struct sock *sk)
> {
> - if (sock_flag(sk, SOCK_RCU_FREE))
> + bool use_call_rcu = sock_flag(sk, SOCK_RCU_FREE);
> +
> + if (rcu_access_pointer(sk->sk_reuseport_cb)) {
> + reuseport_detach_sock(sk);
> + use_call_rcu = true;
> + }
> + if (use_call_rcu)
> call_rcu(&sk->sk_rcu, __sk_destruct);
> else
> __sk_destruct(&sk->sk_rcu);
^ permalink raw reply
* Re: [PATCH bpf-next 1/5] perf/core: Add PERF_FORMAT_LOST read_format
From: Daniel Xu @ 2019-09-27 21:28 UTC (permalink / raw)
To: Jiri Olsa
Cc: bpf, songliubraving, yhs, andriin, peterz, mingo, acme, ast,
alexander.shishkin, namhyung, linux-kernel, netdev, kernel-team
In-Reply-To: <20190924083342.GA21640@krava>
Hi Jiri,
On Tue Sep 24, 2019 at 10:33 AM Jiri Olsa wrote:
> On Tue, Sep 17, 2019 at 06:30:52AM -0700, Daniel Xu wrote:
>
> SNIP
>
> > + PERF_FORMAT_MAX = 1U << 5, /* non-ABI */
> > };
> >
> > #define PERF_ATTR_SIZE_VER0 64 /* sizeof first published struct */
> > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > index 0463c1151bae..ee08d3ed6299 100644
> > --- a/kernel/events/core.c
> > +++ b/kernel/events/core.c
> > @@ -1715,6 +1715,9 @@ static void __perf_event_read_size(struct perf_event *event, int nr_siblings)
> > if (event->attr.read_format & PERF_FORMAT_ID)
> > entry += sizeof(u64);
> >
> > + if (event->attr.read_format & PERF_FORMAT_LOST)
> > + entry += sizeof(u64);
> > +
> > if (event->attr.read_format & PERF_FORMAT_GROUP) {
> > nr += nr_siblings;
> > size += sizeof(u64);
> > @@ -4734,6 +4737,24 @@ u64 perf_event_read_value(struct perf_event *event, u64 *enabled, u64 *running)
> > }
> > EXPORT_SYMBOL_GPL(perf_event_read_value);
> >
> > +static struct pmu perf_kprobe;
> > +static u64 perf_event_lost(struct perf_event *event)
> > +{
> > + struct ring_buffer *rb;
> > + u64 lost = 0;
> > +
> > + rcu_read_lock();
> > + rb = rcu_dereference(event->rb);
> > + if (likely(!!rb))
> > + lost += local_read(&rb->lost);
> > + rcu_read_unlock();
> > +
> > + if (event->attr.type == perf_kprobe.type)
> > + lost += perf_kprobe_missed(event);
>
> not sure what was the peterz's suggestion, but here you are mixing
> ring buffer's lost count with kprobes missed count, seems wrong
To be honest, I'm not 100% sure what the correct semantics here should
be. I thought it might be less misleading if we included ring buffer
related misses as well.
Regardless, I am ok with either.
> maybe we could add PERF_FORMAT_KPROBE_MISSED
I think the feedback from the last patchset was that we want to keep
the misses unified.
Peter, do you have any thoughts?
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH v3] nfp: abm: fix memory leak in nfp_abm_u32_knode_replace
From: Jakub Kicinski @ 2019-09-27 21:42 UTC (permalink / raw)
To: Markus Elfring
Cc: Navid Emamdoost, netdev, oss-drivers, Navid Emamdoost, Kangjie Lu,
Stephen A McCamant, Colin Ian King, David S. Miller, John Hurley,
Pablo Neira, linux-kernel, kernel-janitors
In-Reply-To: <1cde6417-5942-598b-3670-c0a7227ffe25@web.de>
On Fri, 27 Sep 2019 14:12:42 +0200, Markus Elfring wrote:
> > Updated other gotos to have correct errno returned, too.
>
> How do you think about to add a jump target here?
>
>
> > +++ b/drivers/net/ethernet/netronome/nfp/abm/cls.c
> > @@ -176,8 +176,10 @@ nfp_abm_u32_knode_replace(struct nfp_abm_link *alink,
> > u8 mask, val;
> > int err;
> >
> > - if (!nfp_abm_u32_check_knode(alink->abm, knode, proto, extack))
> > + if (!nfp_abm_u32_check_knode(alink->abm, knode, proto, extack)) {
> > + err = -EOPNOTSUPP;
> > goto err_delete;
> > + }
> >
> > tos_off = proto == htons(ETH_P_IP) ? 16 : 20;
>
> - goto err_delete;
> + goto e_opnotsupp;
>
>
> > @@ -221,7 +227,7 @@ nfp_abm_u32_knode_replace(struct nfp_abm_link *alink,
> >
>
> +e_opnotsupp:
> + err = -EOPNOTSUPP;
>
> > err_delete:
> > nfp_abm_u32_knode_delete(alink, knode);
> > - return -EOPNOTSUPP;
> > + return err;
> > }
> >
> > static int nfp_abm_setup_tc_block_cb(enum tc_setup_type type,
>
>
> Can such a change variant be a bit nicer?
Definitely not.
Looks good as is, thanks Navid!
^ permalink raw reply
* RE: [net-next v3 0/7] new PTP ioctl fixes
From: Keller, Jacob E @ 2019-09-27 22:16 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
Kirsher, Jeffrey T
In-Reply-To: <20190927.202949.1014916876082211694.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Friday, September 27, 2019 11:30 AM
> To: Keller, Jacob E <jacob.e.keller@intel.com>
> Cc: netdev@vger.kernel.org; intel-wired-lan@lists.osuosl.org; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@intel.com>
> Subject: Re: [net-next v3 0/7] new PTP ioctl fixes
>
>
> Bug fixes should target 'net' not 'net-next'
Right, that was my mistake. I think I saw the ioctl change only on the net-next tree so I built the whole series on net-next. Come to think of it, I didn't check the net tree at all. I'll aim to do that better going forward.
Thanks Dave.
Regards,
Jake
^ permalink raw reply
* [PATCH] net/mlx5: fix memory leak in mlx5_fw_fatal_reporter_dump
From: Navid Emamdoost @ 2019-09-27 22:37 UTC (permalink / raw)
Cc: emamd001, kjlu, smccaman, Navid Emamdoost, Saeed Mahameed,
Leon Romanovsky, David S. Miller, netdev, linux-rdma,
linux-kernel
In mlx5_fw_fatal_reporter_dump if mlx5_crdump_collect fails the
allocated memory for cr_data must be released otherwise there will be
memory leak. To fix this, this commit changes the return instruction
into goto error handling.
Fixes: 9b1f29823605 ("net/mlx5: Add support for FW fatal reporter dump")
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
---
drivers/net/ethernet/mellanox/mlx5/core/health.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/health.c b/drivers/net/ethernet/mellanox/mlx5/core/health.c
index d685122d9ff7..c07f3154437c 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/health.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/health.c
@@ -572,7 +572,7 @@ mlx5_fw_fatal_reporter_dump(struct devlink_health_reporter *reporter,
return -ENOMEM;
err = mlx5_crdump_collect(dev, cr_data);
if (err)
- return err;
+ goto free_data;
if (priv_ctx) {
struct mlx5_fw_reporter_ctx *fw_reporter_ctx = priv_ctx;
--
2.17.1
^ permalink raw reply related
* Re: [GIT PULL] 9p updates for 5.4
From: pr-tracker-bot @ 2019-09-27 23:00 UTC (permalink / raw)
To: Dominique Martinet; +Cc: Linus Torvalds, v9fs-developer, linux-kernel, netdev
In-Reply-To: <20190927142725.GA8169@nautica>
The pull request you sent on Fri, 27 Sep 2019 16:27:26 +0200:
> https://github.com/martinetd/linux tags/9p-for-5.4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9977b1a71488742606376c09e19e0074e4403cdf
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* [PATCH net] net: Unpublish sk from sk_reuseport_cb before call_rcu
From: Martin KaFai Lau @ 2019-09-27 23:00 UTC (permalink / raw)
To: netdev; +Cc: David Miller, kernel-team, Eric Dumazet
The "reuse->sock[]" array is shared by multiple sockets. The going away
sk must unpublish itself from "reuse->sock[]" before making call_rcu()
call. However, this unpublish-action is currently done after a grace
period and it may cause use-after-free.
The fix is to move reuseport_detach_sock() to sk_destruct().
Due to the above reason, any socket with sk_reuseport_cb has
to go through the rcu grace period before freeing it.
It is a rather old bug (~3 yrs). The Fixes tag is not necessary
the right commit but it is the one that introduced the SOCK_RCU_FREE
logic and this fix is depending on it.
Fixes: a4298e4522d6 ("net: add SOCK_RCU_FREE socket flag")
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
---
net/core/sock.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index 07863edbe6fc..e23ec80a67bf 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1700,8 +1700,6 @@ static void __sk_destruct(struct rcu_head *head)
sk_filter_uncharge(sk, filter);
RCU_INIT_POINTER(sk->sk_filter, NULL);
}
- if (rcu_access_pointer(sk->sk_reuseport_cb))
- reuseport_detach_sock(sk);
sock_disable_timestamp(sk, SK_FLAGS_TIMESTAMP);
@@ -1728,7 +1726,14 @@ static void __sk_destruct(struct rcu_head *head)
void sk_destruct(struct sock *sk)
{
- if (sock_flag(sk, SOCK_RCU_FREE))
+ bool use_call_rcu = sock_flag(sk, SOCK_RCU_FREE);
+
+ if (rcu_access_pointer(sk->sk_reuseport_cb)) {
+ reuseport_detach_sock(sk);
+ use_call_rcu = true;
+ }
+
+ if (use_call_rcu)
call_rcu(&sk->sk_rcu, __sk_destruct);
else
__sk_destruct(&sk->sk_rcu);
--
2.17.1
^ permalink raw reply related
* Re: DSA driver kernel extension for dsa mv88e6190 switch
From: Zoran Stojsavljevic @ 2019-09-27 23:00 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20190926133810.GD20927@lunn.ch>
Hello Andrew,
> You should not need any kernel patches for switch side RGMII
> delays. rgmii-id in the DT for the switch CPU port should be enough.
> Some of the vf610-zii platforms use it.
It should, but it does NOT work. IT is clearly stated in port.c, in f-n:
static int mv88e6xxx_port_set_rgmii_delay(struct mv88e6xxx_chip *chip, int port,
phy_interface_t mode)
The logic analyser shows MDIO write to register 0x01, which is 0x6003.
Seems the correct value.
But, at the very end, ethtool shows that this clock skew is NOT
inserted. I see on RX side CRC errors. Every ethernet frame while
pinging.
I see another interesting fact, the dmesg, which you could see here:
https://pastebin.com/igXS6eXe
[ 1.182273] DEBUG INFO! <- addr: 0x00 reg: 0x03 val: 0x1901
[ 1.187888] mv88e6085 2188000.ethernet-1:00: switch 0x1900
detected: Marvell 88E6190, revision 1
[ 1.219804] random: fast init done
[ 1.225334] libphy: mv88e6xxx SMI: probed
[ 1.232709] fec 2188000.ethernet eth0: registered PHC device 0
[ 1.547946] DEBUG INFO! <- addr: 0x00 reg: 0x03 val: 0x1901
[ 1.553542] mv88e6085 2188000.ethernet-1:00: switch 0x1900
detected: Marvell 88E6190, revision 1
[ 1.555432] mmcblk1: p1
[ 1.598106] libphy: mv88e6xxx SMI: probed
[ 1.740362] DSA: tree 0 setup
There are two distinct accesses while driver configures the switch. Why???
I was not able to explain this to me... Or find explanation using google?!
> gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>; is wrong. It probably
> should be reset-gpios. The rest looks O.K.
I will follow the advise, but I do not think this is an obstacle.
> Please show me the configuration steps you are doing? How are you
> configuring the FEC and the switch interfaces?
Forgive me for my ignorance, but I have no idea what you have asked me for?
Did you ask me to attach .config file? If not, could you, please,
explain to me more concrete, what did you ask for? Some example would
be perfect!
Thank you,
Zoran
_______
On Thu, Sep 26, 2019 at 3:39 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Thu, Sep 26, 2019 at 03:23:48PM +0200, Zoran Stojsavljevic wrote:
> > Hello Andrew,
> >
> > I would like to thank you for the reply.
> >
> > I do not know if this is the right place to post such the questions,
> > but my best guess is: yes.
> >
> > Since till now I did not make any success to make (using DSA driver)
> > make mv88e6190 single switch to work with any kernel.org. :-(
> >
> > I did ugly workaround as kernel dsa patch, which allowed me to
> > introduce TXC and RXC clock skews between I.MX6 and mv88e6190 (MAC to
> > MAC layer over rgmii).
>
> You should not need any kernel patches for switch side RGMII
> delays. rgmii-id in the DT for the switch CPU port should be enough.
> Some of the vf610-zii platforms use it.
>
> > My DTS mv88e6190 configuration, which I adopted for the custom board I
> > am working on, could be seen here:
> > https://pastebin.com/xpXQYNRX
>
> So you have the FEC using rgmii-id. Which you say does not work? So
> why not use plain rgmii. What you have in port@0 looks correct.
>
> gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>; is wrong. It probably should be
> reset-gpios. The rest looks O.K.
>
>
> > But on another note... I am wondering if I am setting correct kernel
> > configuration for it?!
> >
> > Here is the part of the configuration I made while going through maze
> > of posts from google search results:
> >
> > Switch (and switch-ish) device support @ Networking
> > support->Networking options
> > Distributed Switch Architecture @ Networking support->Networking options
> > Tag driver for Marvell switches using DSA headers @ Networking
> > support->Networking options->Distributed Switch Architecture
> > Tag driver for Marvell switches using EtherType DSA headers @
> > Networking support->Networking options->Distributed Switch
> > Architecture
> > Marvell 88E6xxx Ethernet switch fabric support @ Device
> > Drivers->Network device support->Distributed Switch Architecture
> > drivers
> > Switch Global 2 Registers support @ Device Drivers->Network
> > device support->Distributed Switch Architecture drivers->Marvell
> > 88E6xxx Ethernet switch fabric support
> > Freescale devices @ Device Drivers->Network device
> > support->Ethernet driver support
> > FEC ethernet controller (of ColdFire and some i.MX CPUs) @
> > Device Drivers->Network device support->Ethernet driver
> > support->Freescale devices
> > Marvell devices @ Device Drivers->Network device
> > support->Ethernet driver support
> > Marvell MDIO interface support @ Device Drivers->Network device
> > support->Ethernet driver support->Marvell devices
> > MDIO Bus/PHY emulation with fixed speed/link PHYs @ Device
> > Drivers->Network device support->PHY Device support and infrastructure
> >
> > (Do we need Marvell PHYs option as =y ? I do not think so - should be:
> > is not set)
>
> Yes you do. The PHYs inside the switch are Marvell.
>
> > What possibly I made wrong here (this does not work - I could not get
> > through the switch, and seems that MDIO works (from the logic
> > analyzer), but addresses some 0x1B/0x1C ports, which should NOT be
> > addressed, according to the the DTS configuration shown)?
>
> 0x1b is global1, and 0x1c is global2. These are registers shared by
> all ports.
>
> Please show me the configuration steps you are doing? How are you
> configuring the FEC and the switch interfaces?
>
> Andrew
^ permalink raw reply
* [PATCH RESEND v3 00/26] Add definition for the number of standard PCI BARs
From: Denis Efremov @ 2019-09-27 23:40 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Denis Efremov, linux-kernel, linux-pci, linux-hyperv, x86,
linux-s390, linux-alpha, linux-ia64, linux-arm-kernel, netdev,
linux-fbdev, kvm, linux-scsi, linux-ide, linux-usb, devel,
linux-serial, linux-mmc
In-Reply-To: <20190916204158.6889-3-efremov@linux.com>
Code that iterates over all standard PCI BARs typically uses
PCI_STD_RESOURCE_END, but this is error-prone because it requires
"i <= PCI_STD_RESOURCE_END" rather than something like
"i < PCI_STD_NUM_BARS". We could add such a definition and use it the same
way PCI_SRIOV_NUM_BARS is used. The patchset also replaces constant (6)
with new define PCI_STD_NUM_BARS where appropriate and removes local
declarations for the number of PCI BARs.
Changes in v3:
- Updated commits description.
- Refactored "< PCI_ROM_RESOURCE" with "< PCI_STD_NUM_BARS" in loops.
- Refactored "<= BAR_5" with "< PCI_STD_NUM_BARS" in loops.
- Removed local define GASKET_NUM_BARS.
- Removed local define PCI_NUM_BAR_RESOURCES.
Changes in v2:
- Reversed checks in pci_iomap_range,pci_iomap_wc_range.
- Refactored loops in vfio_pci to keep PCI_STD_RESOURCES.
- Added 2 new patches to replace the magic constant with new define.
- Splitted net patch in v1 to separate stmmac and dwc-xlgmac patches.
Denis Efremov (26):
PCI: Add define for the number of standard PCI BARs
PCI: hv: Use PCI_STD_NUM_BARS
PCI: dwc: Use PCI_STD_NUM_BARS
PCI: endpoint: Use PCI_STD_NUM_BARS
misc: pci_endpoint_test: Use PCI_STD_NUM_BARS
s390/pci: Use PCI_STD_NUM_BARS
x86/PCI: Loop using PCI_STD_NUM_BARS
alpha/PCI: Use PCI_STD_NUM_BARS
ia64: Use PCI_STD_NUM_BARS
stmmac: pci: Loop using PCI_STD_NUM_BARS
net: dwc-xlgmac: Loop using PCI_STD_NUM_BARS
ixgb: use PCI_STD_NUM_BARS
e1000: Use PCI_STD_NUM_BARS
rapidio/tsi721: Loop using PCI_STD_NUM_BARS
efifb: Loop using PCI_STD_NUM_BARS
fbmem: use PCI_STD_NUM_BARS
vfio_pci: Loop using PCI_STD_NUM_BARS
scsi: pm80xx: Use PCI_STD_NUM_BARS
ata: sata_nv: Use PCI_STD_NUM_BARS
staging: gasket: Use PCI_STD_NUM_BARS
serial: 8250_pci: Use PCI_STD_NUM_BARS
pata_atp867x: Use PCI_STD_NUM_BARS
memstick: use PCI_STD_NUM_BARS
USB: core: Use PCI_STD_NUM_BARS
usb: pci-quirks: Use PCI_STD_NUM_BARS
devres: use PCI_STD_NUM_BARS
arch/alpha/kernel/pci-sysfs.c | 8 ++---
arch/ia64/sn/pci/pcibr/pcibr_dma.c | 4 +--
arch/s390/include/asm/pci.h | 5 +--
arch/s390/include/asm/pci_clp.h | 6 ++--
arch/s390/pci/pci.c | 16 +++++-----
arch/s390/pci/pci_clp.c | 6 ++--
arch/x86/pci/common.c | 2 +-
arch/x86/pci/intel_mid_pci.c | 2 +-
drivers/ata/pata_atp867x.c | 2 +-
drivers/ata/sata_nv.c | 2 +-
drivers/memstick/host/jmb38x_ms.c | 2 +-
drivers/misc/pci_endpoint_test.c | 8 ++---
drivers/net/ethernet/intel/e1000/e1000.h | 1 -
drivers/net/ethernet/intel/e1000/e1000_main.c | 2 +-
drivers/net/ethernet/intel/ixgb/ixgb.h | 1 -
drivers/net/ethernet/intel/ixgb/ixgb_main.c | 2 +-
.../net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 +--
.../net/ethernet/synopsys/dwc-xlgmac-pci.c | 2 +-
drivers/pci/controller/dwc/pci-dra7xx.c | 2 +-
.../pci/controller/dwc/pci-layerscape-ep.c | 2 +-
drivers/pci/controller/dwc/pcie-artpec6.c | 2 +-
.../pci/controller/dwc/pcie-designware-plat.c | 2 +-
drivers/pci/controller/dwc/pcie-designware.h | 2 +-
drivers/pci/controller/pci-hyperv.c | 10 +++---
drivers/pci/endpoint/functions/pci-epf-test.c | 10 +++---
drivers/pci/pci-sysfs.c | 4 +--
drivers/pci/pci.c | 13 ++++----
drivers/pci/proc.c | 4 +--
drivers/pci/quirks.c | 4 +--
drivers/rapidio/devices/tsi721.c | 2 +-
drivers/scsi/pm8001/pm8001_hwi.c | 2 +-
drivers/scsi/pm8001/pm8001_init.c | 2 +-
drivers/staging/gasket/gasket_constants.h | 3 --
drivers/staging/gasket/gasket_core.c | 12 +++----
drivers/staging/gasket/gasket_core.h | 4 +--
drivers/tty/serial/8250/8250_pci.c | 8 ++---
drivers/usb/core/hcd-pci.c | 2 +-
drivers/usb/host/pci-quirks.c | 2 +-
drivers/vfio/pci/vfio_pci.c | 11 ++++---
drivers/vfio/pci/vfio_pci_config.c | 32 ++++++++++---------
drivers/vfio/pci/vfio_pci_private.h | 4 +--
drivers/video/fbdev/core/fbmem.c | 4 +--
drivers/video/fbdev/efifb.c | 2 +-
include/linux/pci-epc.h | 2 +-
include/linux/pci.h | 2 +-
include/uapi/linux/pci_regs.h | 1 +
lib/devres.c | 2 +-
47 files changed, 112 insertions(+), 115 deletions(-)
--
2.21.0
^ permalink raw reply
* Re: [PATCH V2 net 1/1] net/tls(TLS_SW): Fix list_del double free caused by a race condition in tls_tx_records
From: Jakub Kicinski @ 2019-09-28 0:37 UTC (permalink / raw)
To: Pooja Trivedi
Cc: netdev, davem, daniel, john.fastabend, davejwatson, aviadye,
borisp, Pooja Trivedi, Mallesham Jatharakonda
In-Reply-To: <CAOrEds=zEh5R_4G1UuT-Ee3LT-ZiTV=1JNWb_4a=5Mb4coFEVg@mail.gmail.com>
On Tue, 24 Sep 2019 12:48:26 -0400, Pooja Trivedi wrote:
> On Mon, Sep 23, 2019 at 8:28 PM Jakub Kicinski wrote:
> > On Sat, 21 Sep 2019 23:19:20 -0400, Pooja Trivedi wrote:
> > > On Wed, Sep 18, 2019 at 5:45 PM Jakub Kicinski wrote:
> > > > On Wed, 18 Sep 2019 17:37:44 -0400, Pooja Trivedi wrote:
> > > > > Hi Jakub,
> > > > >
> > > > > I have explained one potential way for the race to happen in my
> > > > > original message to the netdev mailing list here:
> > > > > https://marc.info/?l=linux-netdev&m=156805120229554&w=2
> > > > >
> > > > > Here is the part out of there that's relevant to your question:
> > > > >
> > > > > -----------------------------------------
> > > > >
> > > > > One potential way for race condition to appear:
> > > > >
> > > > > When under tcp memory pressure, Thread 1 takes the following code path:
> > > > > do_sendfile ---> ... ---> .... ---> tls_sw_sendpage --->
> > > > > tls_sw_do_sendpage ---> tls_tx_records ---> tls_push_sg --->
> > > > > do_tcp_sendpages ---> sk_stream_wait_memory ---> sk_wait_event
> > > >
> > > > Ugh, so do_tcp_sendpages() can also release the lock :/
> > > >
> > > > Since the problem occurs in tls_sw_do_sendpage() and
> > > > tls_sw_do_sendmsg() as well, should we perhaps fix it at that level?
> > >
> > > That won't do because tls_tx_records also gets called when completion
> > > callbacks schedule delayed work. That was the code path that caused
> > > the crash for my test. Cavium's nitrox crypto offload driver calling
> > > tls_encrypt_done, which calls schedule_delayed_work. Delayed work that
> > > was scheduled would then be processed by tx_work_handler.
> > > Notice in my previous reply,
> > > "Thread 2 code path:
> > > tx_work_handler ---> tls_tx_records"
> > >
> > > "Thread 2 code path:
> > > tx_work_handler ---> tls_tx_records"
> >
> > Right, the work handler would obviously also have to obey the exclusion
> > mechanism of choice.
> >
> > Having said that this really does feel like we are trying to lock code,
> > not data here :(
>
> Agree with you and exactly the thought process I went through. So what
> are some other options?
>
> 1) A lock member inside of ctx to protect tx_list
> We are load testing ktls offload with nitrox and the performance was
> quite adversely affected by this. This approach can be explored more,
> but the original design of using socket lock didn't follow this model
> either.
> 2) Allow tagging of individual record inside of tx_list to indicate if
> it has been 'processed'
> This approach would likely protect the data without compromising
> performance. It will allow Thread 2 to proceed with the TX portion of
> tls_tx_records while Thread 1 sleeps waiting for memory. There will
> need to be careful cleanup and backtracking after the thread wakes up
> to ensure a consistent state of tx_list and record transmission.
> The approach has several problems, however -- (a) It could cause
> out-of-order record tx (b) If Thread 1 is waiting for memory, Thread 2
> most likely will (c) Again, socket lock wasn't designed to follow this
> model to begin with
>
>
> Given that socket lock essentially was working as a code protector --
> as an exclusion mechanism to allow only a single writer through
> tls_tx_records at a time -- what other clean ways do we have to fix
> the race without a significant refactor of the design and code?
Very sorry about the delay. I don't think we can maintain the correct
semantics without sleeping :( If we just bail in tls_tx_records() when
there's already another writer the later writer will return from the
system call, even though the data is not pushed into the TCP layer.
What was reason for the performance impact on (1)? My feeling is that
we need to make writers wait to maintain socket write semantics, and
that implies putting writers to sleep, which is indeed very costly..
Perhaps something along the lines of:
if (ctx->in_tcp_sendpages) {
rc = sk_stream_wait_memory(sk, &timeo);
...
}
in tls_tx_records() would be the "most correct" solution? If we get
there and there is already a writer, that means the first writer has
to be waiting for memory, and so should the second..
WDYT?
^ permalink raw reply
* Re: [PATCH bpf-next v11 2/4] bpf: added new helper bpf_get_ns_current_pid_tgid
From: Carlos Antonio Neira Bustos @ 2019-09-28 1:42 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Yonghong Song, Networking, ebiederm@xmission.com,
Jesper Dangaard Brouer, bpf
In-Reply-To: <CAEf4BzYZGh774nS1EaCP4od9gzWqPtePPAGX6J7O+pEosnuYrQ@mail.gmail.com>
On Fri, Sep 27, 2019 at 10:24:46AM -0700, Andrii Nakryiko wrote:
> On Fri, Sep 27, 2019 at 9:59 AM Yonghong Song <yhs@fb.com> wrote:
> >
> >
> >
> > On 9/27/19 9:15 AM, Andrii Nakryiko wrote:
> > > On Thu, Sep 26, 2019 at 1:15 AM Carlos Neira <cneirabustos@gmail.com> wrote:
> > >>
> > >> New bpf helper bpf_get_ns_current_pid_tgid,
> > >> This helper will return pid and tgid from current task
> > >> which namespace matches dev_t and inode number provided,
> > >> this will allows us to instrument a process inside a container.
> > >>
> > >> Signed-off-by: Carlos Neira <cneirabustos@gmail.com>
> > >> ---
> > >> include/linux/bpf.h | 1 +
> > >> include/uapi/linux/bpf.h | 18 +++++++++++++++++-
> > >> kernel/bpf/core.c | 1 +
> > >> kernel/bpf/helpers.c | 32 ++++++++++++++++++++++++++++++++
> > >> kernel/trace/bpf_trace.c | 2 ++
> > >> 5 files changed, 53 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > >> index 5b9d22338606..231001475504 100644
> > >> --- a/include/linux/bpf.h
> > >> +++ b/include/linux/bpf.h
> > >> @@ -1055,6 +1055,7 @@ extern const struct bpf_func_proto bpf_get_local_storage_proto;
> > >> extern const struct bpf_func_proto bpf_strtol_proto;
> > >> extern const struct bpf_func_proto bpf_strtoul_proto;
> > >> extern const struct bpf_func_proto bpf_tcp_sock_proto;
> > >> +extern const struct bpf_func_proto bpf_get_ns_current_pid_tgid_proto;
> > >>
> > >> /* Shared helpers among cBPF and eBPF. */
> > >> void bpf_user_rnd_init_once(void);
> > >> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > >> index 77c6be96d676..9272dc8fb08c 100644
> > >> --- a/include/uapi/linux/bpf.h
> > >> +++ b/include/uapi/linux/bpf.h
> > >> @@ -2750,6 +2750,21 @@ union bpf_attr {
> > >> * **-EOPNOTSUPP** kernel configuration does not enable SYN cookies
> > >> *
> > >> * **-EPROTONOSUPPORT** IP packet version is not 4 or 6
> > >> + *
> > >> + * int bpf_get_ns_current_pid_tgid(u32 dev, u64 inum)
> > >> + * Return
> > >> + * A 64-bit integer containing the current tgid and pid from current task
> > >
> > > Function signature doesn't correspond to the actual return type (int vs u64).
> > >
> > >> + * which namespace inode and dev_t matches , and is create as such:
> > >> + * *current_task*\ **->tgid << 32 \|**
> > >> + * *current_task*\ **->pid**.
> > >> + *
> > >> + * On failure, the returned value is one of the following:
> > >> + *
> > >> + * **-EINVAL** if dev and inum supplied don't match dev_t and inode number
> > >> + * with nsfs of current task.
> > >> + *
> > >> + * **-ENOENT** if /proc/self/ns does not exists.
> > >> + *
> > >> */
> > >
> > > [...]
> > >
> > >> #include "../../lib/kstrtox.h"
> > >>
> > >> @@ -487,3 +489,33 @@ const struct bpf_func_proto bpf_strtoul_proto = {
> > >> .arg4_type = ARG_PTR_TO_LONG,
> > >> };
> > >> #endif
> > >> +
> > >> +BPF_CALL_2(bpf_get_ns_current_pid_tgid, u32, dev, u64, inum)
> > >
> > > Just curious, is dev_t officially specified as u32 and is never
> > > supposed to grow bigger? I wonder if accepting u64 might be more
> > > future-proof API here?
> >
> > This is what we have now in kernel (include/linux/types.h)
> > typedef u32 __kernel_dev_t;
> > typedef __kernel_dev_t dev_t;
> >
> > But userspace dev_t (defined at /usr/include/sys/types.h) have
> > 8 bytes.
> >
> > Agree. Let us just use u64. It won't hurt and also will be fine
> > if kernel internal dev_t becomes 64bit.
>
> Sounds good. Let's not forget to check that conversion to dev_t
> doesn't loose high bits, something like:
>
> if ((u64)(dev_t)dev != dev)
> return -E<something>;
>
> >
> > >
> > >> +{
> > >> + struct task_struct *task = current;
> > >> + struct pid_namespace *pidns;
> > >
> > > [...]
> > >
Thanks Yonghong and Andrii,
I'll include these fixes on V12, I'll work on this over the weekend.
Bests
^ permalink raw reply
* Re: [PATCH V2] net: dsa: microchip: Always set regmap stride to 1
From: Marek Vasut @ 2019-09-28 1:56 UTC (permalink / raw)
To: George McCollister
Cc: netdev, Andrew Lunn, David S . Miller, Florian Fainelli,
Tristram Ha, Vivien Didelot, Woojung Huh
In-Reply-To: <CAFSKS=PFBewpMiMXuPmJXqv=sbYhS8_9k=DrwAXjjPNi7xFwcA@mail.gmail.com>
On 9/26/19 3:52 PM, George McCollister wrote:
> On Wed, Sep 25, 2019 at 5:08 PM Marek Vasut wrote:
>>
>> The regmap stride is set to 1 for regmap describing 8bit registers already.
>> However, for 16/32/64bit registers, the stride is 2/4/8 respectively. This
>> is not correct, as the switch protocol supports unaligned register reads
>> and writes and the KSZ87xx even uses such unaligned register accesses to
>> read e.g. MIB counter.
>>
>> This patch fixes MIB counter access on KSZ87xx.
>
> After looking through a couple hundred pages of register documentation
> for KSZ9477 and KSZ9567 I find only registers that are aligned to
> their width. In my testing the KSZ9567 works fine with and without the
> patch. The only downside is that all of the unaligned registers
> needlessly show up in the debugfs regmap, this doesn't really matter
> though. As long as it fixes the issues on KSZ87xx this looks fine to
> me.
Right.
To avoid exposing all registers through regmap debugfs entries, we would
have to define the regmap constrains for
readable/writeable/volatile/precious registers, which we should
eventually do anyway, but that's way beyond the scope of this fix.
^ 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