* Re: CFS for Netdev 0x16 open!
From: Ferenc Fejes @ 2022-08-11 11:17 UTC (permalink / raw)
To: jhs@mojatatu.com, linux-wireless@vger.kernel.org,
people@netdevconf.info, lwn@lwn.net,
netfilter-devel@vger.kernel.org, netdev@vger.kernel.org
Cc: prog-committee-0x16@netdevconf.info, board@netdevconf.info
In-Reply-To: <CAM0EoMn_4k_w_maX=0=tmiK5k1nTEWpByGP+83qiJHdM0DbigA@mail.gmail.com>
Dear Jamal!
On Tue, 2022-06-07 at 12:36 -0400, Jamal Hadi Salim wrote:
> We are pleased to announce the opening of Call For
> Submissions(CFS) for Netdev 0x16.
>
> For overview of topics, submissions and requirements
> please visit:
> https://netdevconf.info/0x16/submit-proposal.html
>
> For all submitted sessions, we employ a blind
> review process carried out by the Program Committee.
> Please refer to:
> https://www.netdevconf.info/0x16/pc_review.html
>
> Important dates:
> Closing of CFS: Wed, Sept. 7, 2022
> Notification by: Thu, Sept. 15, 2022
> Conference dates: Oct 24th - 28th, 2022
Sorry for spamming it here, but unfortunaltey seems like the
"submissions-0x16@netdevconf.info" address not working (or not yet). I
sent a question to that address but it bounced back all of my mailboxes
including gmail (assuming there must be on the recepient side if any).
>
> cheers,
> jamal (on behalf of the Netdev Society)
Best,
Ferenc
^ permalink raw reply
* Re: [PATCH v7 1/4] vdpa: Add suspend operation
From: Michael S. Tsirkin @ 2022-08-11 11:23 UTC (permalink / raw)
To: Dan Carpenter
Cc: Eugenio Pérez, kvm, linux-kernel, Jason Wang, virtualization,
netdev, dinang, martinpo, Wu Zongyong, Piotr.Uminski,
gautam.dawar, ecree.xilinx, martinh, Stefano Garzarella, pabloc,
habetsm.xilinx, lvivier, Zhu Lingshan, tanuj.kamde, Longpeng,
lulu, hanand, Parav Pandit, Si-Wei Liu, Eli Cohen, Xie Yongji,
Zhang Min, Christophe JAILLET
In-Reply-To: <20220811101507.GU3460@kadam>
On Thu, Aug 11, 2022 at 01:15:08PM +0300, Dan Carpenter wrote:
> On Thu, Aug 11, 2022 at 04:27:32AM -0400, Michael S. Tsirkin wrote:
> > On Wed, Aug 10, 2022 at 07:15:09PM +0200, Eugenio Pérez wrote:
> > > This operation is optional: It it's not implemented, backend feature bit
> > > will not be exposed.
> > >
> > > Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
> > > Message-Id: <20220623160738.632852-2-eperezma@redhat.com>
> > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> >
> > What is this message id doing here?
> >
>
> I like the Message-Id tag. It means you can `b4 mbox <mesg-id>` and get
> the thread.
Yes it makes sense in git. But I don't see what it does in this patch
posted to the list. It seems to refer to the previous version of the
patch here. Which is ok I guess but better called out e.g.
Previous-version: <20220623160738.632852-2-eperezma@redhat.com>
> Linus has complained (rough remembering) that everyone is using the
> Link: tag for links to the patch itself. It's supposed to be for Links
> to bugzilla or to the spec or whatever. Extra information, too much to
> put in the commit message. Now the Link tag is useless because it either
> points to the patch or to a bugzilla. Depend on what you want it to do,
> it *always* points to the opposite thing.
>
> But I can't remember what people settled on as the alternative to use
> to link to lore...
>
> In theory, we should be able to figure out the link to lore automatically
> and there have been a couple projects which tried to do this but they
> can't make it work 100%. Maintainers massage and reformat the patches
> too much before applying them.
>
> regards,
> dan carpenter
^ permalink raw reply
* [PATCH net] mlxsw: minimal: Fix deadlock in ports creation
From: Petr Machata @ 2022-08-11 9:57 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev
Cc: linux-kernel, Petr Machata, Vadim Pasternak, Ido Schimmel
From: Vadim Pasternak <vadimp@nvidia.com>
Drop devl_lock() / devl_unlock() from ports creation and removal flows
since the devlink instance lock is now taken by mlxsw_core.
Fixes: 72a4c8c94efa ("mlxsw: convert driver to use unlocked devlink API during init/fini")
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Petr Machata <petrm@nvidia.com>
---
drivers/net/ethernet/mellanox/mlxsw/minimal.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/minimal.c b/drivers/net/ethernet/mellanox/mlxsw/minimal.c
index d9bf584234a6..bb1cd4bae82e 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/minimal.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/minimal.c
@@ -328,7 +328,6 @@ static void mlxsw_m_port_module_unmap(struct mlxsw_m *mlxsw_m, u8 module)
static int mlxsw_m_ports_create(struct mlxsw_m *mlxsw_m)
{
unsigned int max_ports = mlxsw_core_max_ports(mlxsw_m->core);
- struct devlink *devlink = priv_to_devlink(mlxsw_m->core);
u8 last_module = max_ports;
int i;
int err;
@@ -357,7 +356,6 @@ static int mlxsw_m_ports_create(struct mlxsw_m *mlxsw_m)
}
/* Create port objects for each valid entry */
- devl_lock(devlink);
for (i = 0; i < mlxsw_m->max_ports; i++) {
if (mlxsw_m->module_to_port[i] > 0) {
err = mlxsw_m_port_create(mlxsw_m,
@@ -367,7 +365,6 @@ static int mlxsw_m_ports_create(struct mlxsw_m *mlxsw_m)
goto err_module_to_port_create;
}
}
- devl_unlock(devlink);
return 0;
@@ -377,7 +374,6 @@ static int mlxsw_m_ports_create(struct mlxsw_m *mlxsw_m)
mlxsw_m_port_remove(mlxsw_m,
mlxsw_m->module_to_port[i]);
}
- devl_unlock(devlink);
i = max_ports;
err_module_to_port_map:
for (i--; i > 0; i--)
@@ -390,10 +386,8 @@ static int mlxsw_m_ports_create(struct mlxsw_m *mlxsw_m)
static void mlxsw_m_ports_remove(struct mlxsw_m *mlxsw_m)
{
- struct devlink *devlink = priv_to_devlink(mlxsw_m->core);
int i;
- devl_lock(devlink);
for (i = 0; i < mlxsw_m->max_ports; i++) {
if (mlxsw_m->module_to_port[i] > 0) {
mlxsw_m_port_remove(mlxsw_m,
@@ -401,7 +395,6 @@ static void mlxsw_m_ports_remove(struct mlxsw_m *mlxsw_m)
mlxsw_m_port_module_unmap(mlxsw_m, i);
}
}
- devl_unlock(devlink);
kfree(mlxsw_m->module_to_port);
kfree(mlxsw_m->ports);
--
2.35.3
^ permalink raw reply related
* Re: [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry flag to drivers
From: Ido Schimmel @ 2022-08-11 11:28 UTC (permalink / raw)
To: netdev
Cc: Vladimir Oltean, davem, kuba, netdev, Andrew Lunn, Vivien Didelot,
Florian Fainelli, Eric Dumazet, Paolo Abeni, Jiri Pirko,
Ivan Vecera, Roopa Prabhu, Nikolay Aleksandrov, Shuah Khan,
Daniel Borkmann, linux-kernel, bridge, linux-kselftest
In-Reply-To: <2491232d5c017d94ca3213197a3fb283@kapio-technology.com>
On Wed, Aug 10, 2022 at 10:40:45AM +0200, netdev@kapio-technology.com wrote:
> On 2022-08-10 09:21, Ido Schimmel wrote:
> > On Tue, Aug 09, 2022 at 10:00:49PM +0200, netdev@kapio-technology.com
> > wrote:
> > > On 2022-08-09 11:20, Ido Schimmel wrote:
> > > > On Mon, Aug 01, 2022 at 05:33:49PM +0200, netdev@kapio-technology.com
> > > > wrote:
> > > > > On 2022-07-13 14:39, Ido Schimmel wrote:
> > > > >
> > > > > >
> > > > > > What are "Storm Prevention" and "zero-DPV" FDB entries?
> > > > > >
> > > > >
> > > > > For the zero-DPV entries, I can summarize:
> > > > >
> > > > > Since a CPU can become saturated from constant SA Miss Violations
> > > > > from a
> > > > > denied source, source MAC address are masked by loading a zero-DPV
> > > > > (Destination Port Vector) entry in the ATU. As the address now
> > > > > appears in
> > > > > the database it will not cause more Miss Violations. ANY port trying
> > > > > to send
> > > > > a frame to this unauthorized address is discarded. Any locked port
> > > > > trying to
> > > > > use this unauthorized address has its frames discarded too (as the
> > > > > ports SA
> > > > > bit is not set in the ATU entry).
> > > >
> > > > What happens to unlocked ports that have learning enabled and are trying
> > > > to use this address as SMAC? AFAICT, at least in the bridge driver, the
> > > > locked entry will roam, but will keep the "locked" flag, which is
> > > > probably not what we want. Let's see if we can agree on these semantics
> > > > for a "locked" entry:
> > >
> > > The next version of this will block forwarding to locked entries in
> > > the
> > > bridge, so they will behave like the zero-DPV entries.
> >
> > I'm talking about roaming, not forwarding. Let's say you have a locked
> > entry with MAC X pointing to port Y. Now you get a packet with SMAC X
> > from port Z which is unlocked. Will the FDB entry roam to port Z? I
> > think it should, but at least in current implementation it seems that
> > the "locked" flag will not be reset and having locked entries pointing
> > to an unlocked port looks like a bug.
> >
>
> Remember that zero-DPV entries blackhole (mask) the MAC, so whenever a
> packet appears with the same MAC on another port it is just dropped in the
What do you mean by "same MAC"? As SMAC or DMAC? I'm talking about SMAC
and when the packet is received via an unlocked port. Why would such a
packet be dropped?
> HW, so there is no possibility of doing any CPU processing in this case.
> Only after the timeout (5 min) can the MAC get a normal ATU on an open port.
> For the bridge to do what you suggest, a FDB search would be needed afaics,
> and this might be in a process sensitive part of the code, thus leading to
> too heavy a cost.
When learning is enabled the bridge already performs a lookup on the
SMAC.
TBH, I don't think this is progressing well because there is too much
discrepancy between how this feature works in the bridge driver and in
the hardware you work with.
I suggest to first define the model in the bridge driver and then take
care of the offload. My suggestion is to send another RFC with only the
bridge changes with emphasize on the following aspects:
* Forwarding rules for "locked" entries. Do they drop matching packets?
Forward them? Or not considered at all for forwarding?
* Roaming rules for "locked" entries. Can they roam between locked
ports? Can they roam from a locked port to an unlocked port and
vice versa? Or are they completely sticky?
* Ageing rule for "locked" entries. Are these entries subject to the
ageing time or are they static? If they are not static, are they
refreshed by incoming traffic from a locked port or not?
* MAB enablement. New option? Overload an existing one? No option?
The commit messages should explain these design choices and new tests
cases should verify the desired behavior.
Once we have an agreement we can work out the switchdev/mv88e6xxx parts
and eventually the entire thing can be merged together. Fair?
^ permalink raw reply
* Re: [PATCH net] mlxsw: minimal: Fix deadlock in ports creation
From: Petr Machata @ 2022-08-11 11:44 UTC (permalink / raw)
To: Petr Machata
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev, linux-kernel, Vadim Pasternak, Ido Schimmel, Jiri Pirko
In-Reply-To: <f4afce5ab0318617f3866b85274be52542d59b32.1660211614.git.petrm@nvidia.com>
CC'ing Jiri, which I forgot to do.
Petr Machata <petrm@nvidia.com> writes:
> From: Vadim Pasternak <vadimp@nvidia.com>
>
> Drop devl_lock() / devl_unlock() from ports creation and removal flows
> since the devlink instance lock is now taken by mlxsw_core.
>
> Fixes: 72a4c8c94efa ("mlxsw: convert driver to use unlocked devlink API during init/fini")
> Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
> Signed-off-by: Ido Schimmel <idosch@nvidia.com>
> Signed-off-by: Petr Machata <petrm@nvidia.com>
> ---
> drivers/net/ethernet/mellanox/mlxsw/minimal.c | 7 -------
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlxsw/minimal.c b/drivers/net/ethernet/mellanox/mlxsw/minimal.c
> index d9bf584234a6..bb1cd4bae82e 100644
> --- a/drivers/net/ethernet/mellanox/mlxsw/minimal.c
> +++ b/drivers/net/ethernet/mellanox/mlxsw/minimal.c
> @@ -328,7 +328,6 @@ static void mlxsw_m_port_module_unmap(struct mlxsw_m *mlxsw_m, u8 module)
> static int mlxsw_m_ports_create(struct mlxsw_m *mlxsw_m)
> {
> unsigned int max_ports = mlxsw_core_max_ports(mlxsw_m->core);
> - struct devlink *devlink = priv_to_devlink(mlxsw_m->core);
> u8 last_module = max_ports;
> int i;
> int err;
> @@ -357,7 +356,6 @@ static int mlxsw_m_ports_create(struct mlxsw_m *mlxsw_m)
> }
>
> /* Create port objects for each valid entry */
> - devl_lock(devlink);
> for (i = 0; i < mlxsw_m->max_ports; i++) {
> if (mlxsw_m->module_to_port[i] > 0) {
> err = mlxsw_m_port_create(mlxsw_m,
> @@ -367,7 +365,6 @@ static int mlxsw_m_ports_create(struct mlxsw_m *mlxsw_m)
> goto err_module_to_port_create;
> }
> }
> - devl_unlock(devlink);
>
> return 0;
>
> @@ -377,7 +374,6 @@ static int mlxsw_m_ports_create(struct mlxsw_m *mlxsw_m)
> mlxsw_m_port_remove(mlxsw_m,
> mlxsw_m->module_to_port[i]);
> }
> - devl_unlock(devlink);
> i = max_ports;
> err_module_to_port_map:
> for (i--; i > 0; i--)
> @@ -390,10 +386,8 @@ static int mlxsw_m_ports_create(struct mlxsw_m *mlxsw_m)
>
> static void mlxsw_m_ports_remove(struct mlxsw_m *mlxsw_m)
> {
> - struct devlink *devlink = priv_to_devlink(mlxsw_m->core);
> int i;
>
> - devl_lock(devlink);
> for (i = 0; i < mlxsw_m->max_ports; i++) {
> if (mlxsw_m->module_to_port[i] > 0) {
> mlxsw_m_port_remove(mlxsw_m,
> @@ -401,7 +395,6 @@ static void mlxsw_m_ports_remove(struct mlxsw_m *mlxsw_m)
> mlxsw_m_port_module_unmap(mlxsw_m, i);
> }
> }
> - devl_unlock(devlink);
>
> kfree(mlxsw_m->module_to_port);
> kfree(mlxsw_m->ports);
^ permalink raw reply
* Re: [PATCH net-next 01/10] net/smc: remove locks smc_client_lgr_pending and smc_server_lgr_pending
From: kernel test robot @ 2022-08-11 11:51 UTC (permalink / raw)
To: D. Wythe, kgraul, wenjia
Cc: kbuild-all, kuba, davem, netdev, linux-s390, linux-rdma
In-Reply-To: <075ff0be35660efac638448cdae7f7e7e04199d4.1660152975.git.alibuda@linux.alibaba.com>
Hi Wythe",
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/intel-lab-lkp/linux/commits/D-Wythe/net-smc-optimize-the-parallelism-of-SMC-R-connections/20220811-014942
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git f86d1fbbe7858884d6754534a0afbb74fc30bc26
config: x86_64-randconfig-s021 (https://download.01.org/0day-ci/archive/20220811/202208111933.9PvuHltH-lkp@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-3) 11.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.4-39-gce1a6720-dirty
# https://github.com/intel-lab-lkp/linux/commit/2c1c2e644fb8dbce9b8a004e604792340cbfccb8
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review D-Wythe/net-smc-optimize-the-parallelism-of-SMC-R-connections/20220811-014942
git checkout 2c1c2e644fb8dbce9b8a004e604792340cbfccb8
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=x86_64 SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>
sparse warnings: (new ones prefixed by >>)
>> net/smc/smc_core.c:49:24: sparse: sparse: symbol 'smc_lgr_manager' was not declared. Should it be static?
--
0-DAY CI Kernel Test Service
https://01.org/lkp
^ permalink raw reply
* [PATCH] net: ipa: Fix comment typo
From: Jason Wang @ 2022-08-11 11:52 UTC (permalink / raw)
To: edumazet; +Cc: elder, davem, kuba, pabeni, netdev, linux-kernel, Jason Wang
The double `is' is duplicated in the comment, remove one.
Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
---
drivers/net/ipa/ipa_reg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ipa/ipa_reg.h b/drivers/net/ipa/ipa_reg.h
index a5b355384d4a..6f35438cda89 100644
--- a/drivers/net/ipa/ipa_reg.h
+++ b/drivers/net/ipa/ipa_reg.h
@@ -48,7 +48,7 @@ struct ipa;
*
* The offset of registers related to resource types is computed by a macro
* that is supplied a parameter "rt". The "rt" represents a resource type,
- * which is is a member of the ipa_resource_type_src enumerated type for
+ * which is a member of the ipa_resource_type_src enumerated type for
* source endpoint resources or the ipa_resource_type_dst enumerated type
* for destination endpoint resources.
*
--
2.36.1
^ permalink raw reply related
* [PATCH] net/fddi: Fix comment typo
From: Jason Wang @ 2022-08-11 11:54 UTC (permalink / raw)
To: edumazet; +Cc: davem, kuba, pabeni, netdev, linux-kernel, Jason Wang
The double `the' is duplicated in the comment, remove one.
Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
---
drivers/net/fddi/skfp/h/hwmtm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/fddi/skfp/h/hwmtm.h b/drivers/net/fddi/skfp/h/hwmtm.h
index 76c4a709d73d..e97db826cdd4 100644
--- a/drivers/net/fddi/skfp/h/hwmtm.h
+++ b/drivers/net/fddi/skfp/h/hwmtm.h
@@ -348,7 +348,7 @@ do { \
* This macro is invoked by the OS-specific before it left the
* function mac_drv_rx_complete. This macro calls mac_drv_fill_rxd
* if the number of used RxDs is equal or lower than the
- * the given low water mark.
+ * given low water mark.
*
* para low_water low water mark of used RxD's
*
--
2.36.1
^ permalink raw reply related
* [PATCH] bnx2x: Fix comment typo
From: Jason Wang @ 2022-08-11 11:56 UTC (permalink / raw)
To: edumazet
Cc: aelior, skalluru, manishc, davem, kuba, pabeni, netdev,
linux-kernel, Jason Wang
The double `the' is duplicated in the comment, remove one.
Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
index 7071604f9984..02808513ffe4 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
@@ -13844,7 +13844,7 @@ static void bnx2x_check_kr2_wa(struct link_params *params,
/* Once KR2 was disabled, wait 5 seconds before checking KR2 recovery
* Since some switches tend to reinit the AN process and clear the
- * the advertised BP/NP after ~2 seconds causing the KR2 to be disabled
+ * advertised BP/NP after ~2 seconds causing the KR2 to be disabled
* and recovered many times
*/
if (vars->check_kr2_recovery_cnt > 0) {
--
2.36.1
^ permalink raw reply related
* [PATCH] net: cxgb3: Fix comment typo
From: Jason Wang @ 2022-08-11 11:57 UTC (permalink / raw)
To: edumazet; +Cc: rajur, davem, kuba, pabeni, netdev, linux-kernel, Jason Wang
The double `the' is duplicated in the comment, remove one.
Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
---
drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c
index 84604aff53ce..89256b866840 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c
@@ -243,7 +243,7 @@ static int cxgb_ulp_iscsi_ctl(struct adapter *adapter, unsigned int req,
/*
* on rx, the iscsi pdu has to be < rx page size and the
- * the max rx data length programmed in TP
+ * max rx data length programmed in TP
*/
val = min(adapter->params.tp.rx_pg_size,
((t3_read_reg(adapter, A_TP_PARA_REG2)) >>
--
2.36.1
^ permalink raw reply related
* Re: [PATCH net] mlxsw: minimal: Fix deadlock in ports creation
From: Jiri Pirko @ 2022-08-11 11:59 UTC (permalink / raw)
To: Petr Machata
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev, linux-kernel, Vadim Pasternak, Ido Schimmel
In-Reply-To: <87wnbf57bw.fsf@nvidia.com>
Thu, Aug 11, 2022 at 01:44:17PM CEST, petrm@nvidia.com wrote:
>CC'ing Jiri, which I forgot to do.
Oups, I forgot the minimal driver. Sorry about that.
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
^ permalink raw reply
* [PATCH] wifi: iwlwifi: Fix comment typo
From: Jason Wang @ 2022-08-11 11:59 UTC (permalink / raw)
To: davem
Cc: gregory.greenman, kvalo, edumazet, kuba, pabeni, luciano.coelho,
johannes.berg, mordechay.goodstein, nathan.errera, quic_srirrama,
linux-wireless, netdev, linux-kernel, Jason Wang
The double `if' is duplicated in the comment, remove one.
Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
index ff0d3b3df140..323588e262a6 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
@@ -2724,7 +2724,7 @@ int iwl_mvm_sta_rx_agg(struct iwl_mvm *mvm, struct ieee80211_sta *sta,
/*
* The division below will be OK if either the cache line size
* can be divided by the entry size (ALIGN will round up) or if
- * if the entry size can be divided by the cache line size, in
+ * the entry size can be divided by the cache line size, in
* which case the ALIGN() will do nothing.
*/
BUILD_BUG_ON(SMP_CACHE_BYTES % sizeof(baid_data->entries[0]) &&
--
2.36.1
^ permalink raw reply related
* Re: [PATCH] net: ipa: Fix comment typo
From: Alex Elder @ 2022-08-11 12:01 UTC (permalink / raw)
To: Jason Wang, edumazet; +Cc: elder, davem, kuba, pabeni, netdev, linux-kernel
In-Reply-To: <20220811115259.64225-1-wangborong@cdjrlc.com>
On 8/11/22 6:52 AM, Jason Wang wrote:
> The double `is' is duplicated in the comment, remove one.
>
> Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
I know this is not the only instance of a duplicate word in
the comments in this driver. I (and others) keep finding them.
It might be nice if someone tried to take care of as many as
can be found in a single patch.
In any case, this looks good.
Reviewed-by: Alex Elder <elder@linaro.org>
> ---
> drivers/net/ipa/ipa_reg.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ipa/ipa_reg.h b/drivers/net/ipa/ipa_reg.h
> index a5b355384d4a..6f35438cda89 100644
> --- a/drivers/net/ipa/ipa_reg.h
> +++ b/drivers/net/ipa/ipa_reg.h
> @@ -48,7 +48,7 @@ struct ipa;
> *
> * The offset of registers related to resource types is computed by a macro
> * that is supplied a parameter "rt". The "rt" represents a resource type,
> - * which is is a member of the ipa_resource_type_src enumerated type for
> + * which is a member of the ipa_resource_type_src enumerated type for
> * source endpoint resources or the ipa_resource_type_dst enumerated type
> * for destination endpoint resources.
> *
^ permalink raw reply
* [PATCH] iwlwifi: Fix comment typo
From: Jason Wang @ 2022-08-11 12:00 UTC (permalink / raw)
To: davem
Cc: gregory.greenman, kvalo, edumazet, kuba, pabeni, mkl, keescook,
linux-wireless, netdev, linux-kernel, Jason Wang
The double `only' is duplicated in the comment, remove one.
Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
---
drivers/net/wireless/intel/iwlwifi/dvm/commands.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/commands.h b/drivers/net/wireless/intel/iwlwifi/dvm/commands.h
index 75a4b8e26232..5c81de8f1a17 100644
--- a/drivers/net/wireless/intel/iwlwifi/dvm/commands.h
+++ b/drivers/net/wireless/intel/iwlwifi/dvm/commands.h
@@ -2021,7 +2021,7 @@ struct iwl_spectrum_notification {
u8 channel;
u8 type; /* see enum iwl_measurement_type */
u8 reserved1;
- /* NOTE: cca_ofdm, cca_cck, basic_type, and histogram are only only
+ /* NOTE: cca_ofdm, cca_cck, basic_type, and histogram are only
* valid if applicable for measurement type requested. */
__le32 cca_ofdm; /* cca fraction time in 40Mhz clock periods */
__le32 cca_cck; /* cca fraction time in 44Mhz clock periods */
--
2.36.1
^ permalink raw reply related
* [PATCH] iwlwifi: mvm: Fix comment typo
From: Jason Wang @ 2022-08-11 11:58 UTC (permalink / raw)
To: davem
Cc: gregory.greenman, kvalo, edumazet, kuba, pabeni, luciano.coelho,
johannes.berg, miriam.rachel.korenblit, linux-wireless, netdev,
linux-kernel, Jason Wang
The double `the' is duplicated in the comment, remove one.
Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/phy-ctxt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/phy-ctxt.c b/drivers/net/wireless/intel/iwlwifi/mvm/phy-ctxt.c
index a3cefbc43e80..abf8585bf3bd 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/phy-ctxt.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/phy-ctxt.c
@@ -29,7 +29,7 @@ u8 iwl_mvm_get_channel_width(struct cfg80211_chan_def *chandef)
/*
* Maps the driver specific control channel position (relative to the center
- * freq) definitions to the the fw values
+ * freq) definitions to the fw values
*/
u8 iwl_mvm_get_ctrl_pos(struct cfg80211_chan_def *chandef)
{
--
2.36.1
^ permalink raw reply related
* [PATCH] mwifiex: Fix comment typo
From: Jason Wang @ 2022-08-11 12:02 UTC (permalink / raw)
To: ganapathi017
Cc: amitkarwar, sharvari.harisangam, huxinming820, kvalo, davem,
edumazet, kuba, pabeni, linux-wireless, netdev, linux-kernel,
Jason Wang
The double `the' is duplicated in the comment, remove one.
Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
---
drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
index bd835288ce57..a04b66284af4 100644
--- a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
+++ b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
@@ -335,7 +335,7 @@ mwifiex_11n_create_rx_reorder_tbl(struct mwifiex_private *priv, u8 *ta,
struct mwifiex_sta_node *node;
/*
- * If we get a TID, ta pair which is already present dispatch all the
+ * If we get a TID, ta pair which is already present dispatch all
* the packets and move the window size until the ssn
*/
tbl = mwifiex_11n_get_rx_reorder_tbl(priv, tid, ta);
--
2.36.1
^ permalink raw reply related
* [PATCH] ath9k: Fix comment typo
From: Jason Wang @ 2022-08-11 12:02 UTC (permalink / raw)
To: kvalo
Cc: toke, davem, edumazet, kuba, pabeni, linux-wireless, netdev,
linux-kernel, Jason Wang
The double `the' is duplicated in the comment, remove one.
Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
---
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index dc0e5ea25673..090ff0600c81 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -1744,7 +1744,7 @@ static void ar9003_hw_spectral_scan_config(struct ath_hw *ah,
REG_SET_BIT(ah, AR_PHY_RADAR_0, AR_PHY_RADAR_0_FFT_ENA);
REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN, AR_PHY_SPECTRAL_SCAN_ENABLE);
- /* on AR93xx and newer, count = 0 will make the the chip send
+ /* on AR93xx and newer, count = 0 will make the chip send
* spectral samples endlessly. Check if this really was intended,
* and fix otherwise.
*/
--
2.36.1
^ permalink raw reply related
* [PATCH] wifi: p54: Fix comment typo
From: Jason Wang @ 2022-08-11 12:03 UTC (permalink / raw)
To: kvalo
Cc: chunkeey, davem, edumazet, kuba, pabeni, linux-wireless, netdev,
linux-kernel, Jason Wang
The double `to' is duplicated in the comment, remove one.
Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
---
drivers/net/wireless/intersil/p54/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intersil/p54/main.c b/drivers/net/wireless/intersil/p54/main.c
index b925e327e091..e127453ab51a 100644
--- a/drivers/net/wireless/intersil/p54/main.c
+++ b/drivers/net/wireless/intersil/p54/main.c
@@ -635,7 +635,7 @@ static int p54_get_survey(struct ieee80211_hw *dev, int idx,
/*
* hw/fw has not accumulated enough sample sets.
* Wait for 100ms, this ought to be enough to
- * to get at least one non-null set of channel
+ * get at least one non-null set of channel
* usage statistics.
*/
msleep(100);
--
2.36.1
^ permalink raw reply related
* [PATCH net-next] net: skb: prevent the split of kfree_skb_reason() by gcc
From: menglong8.dong @ 2022-08-11 12:07 UTC (permalink / raw)
To: kuba
Cc: ojeda, ndesaulniers, davem, edumazet, pabeni, asml.silence,
imagedong, luiz.von.dentz, vasily.averin, jk, linux-kernel,
netdev
From: Menglong Dong <imagedong@tencent.com>
Sometimes, gcc will optimize the function by spliting it to two or
more functions. In this case, kfree_skb_reason() is splited to
kfree_skb_reason and kfree_skb_reason.part.0. However, the
function/tracepoint trace_kfree_skb() in it needs the return address
of kfree_skb_reason().
This split makes the call chains becomes:
kfree_skb_reason() -> kfree_skb_reason.part.0 -> trace_kfree_skb()
which makes the return address that passed to trace_kfree_skb() be
kfree_skb().
Therefore, prevent this kind of optimization to kfree_skb_reason() by
making the optimize level to "O1". I think these should be better
method instead of this "O1", but I can't figure it out......
This optimization CAN happen, which depend on the behavior of gcc.
I'm not able to reproduce it in the latest kernel code, but it happens
in my kernel of version 5.4.119. Maybe the latest code already do someting
that prevent this happen?
Signed-off-by: Menglong Dong <imagedong@tencent.com>
---
include/linux/compiler_attributes.h | 2 ++
net/core/skbuff.c | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/linux/compiler_attributes.h b/include/linux/compiler_attributes.h
index 445e80517cab..51f7c13bca98 100644
--- a/include/linux/compiler_attributes.h
+++ b/include/linux/compiler_attributes.h
@@ -371,4 +371,6 @@
*/
#define __weak __attribute__((__weak__))
+#define __nofnsplit __attribute__((optimize("O1")))
+
#endif /* __LINUX_COMPILER_ATTRIBUTES_H */
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 974bbbbe7138..ff9ccbc032b9 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -777,7 +777,8 @@ EXPORT_SYMBOL(__kfree_skb);
* hit zero. Meanwhile, pass the drop reason to 'kfree_skb'
* tracepoint.
*/
-void kfree_skb_reason(struct sk_buff *skb, enum skb_drop_reason reason)
+void __nofnsplit
+kfree_skb_reason(struct sk_buff *skb, enum skb_drop_reason reason)
{
if (!skb_unref(skb))
return;
--
2.36.1
^ permalink raw reply related
* Re: [PATCH net-next 00/10] net/smc: optimize the parallelism of SMC-R connections
From: Karsten Graul @ 2022-08-11 12:31 UTC (permalink / raw)
To: D. Wythe, wenjia; +Cc: kuba, davem, netdev, linux-s390, linux-rdma
In-Reply-To: <cover.1660152975.git.alibuda@linux.alibaba.com>
On 10/08/2022 19:47, D. Wythe wrote:
> From: "D. Wythe" <alibuda@linux.alibaba.com>
>
> This patch set attempts to optimize the parallelism of SMC-R connections,
> mainly to reduce unnecessary blocking on locks, and to fix exceptions that
> occur after thoses optimization.
This are very interesting changes. Please allow us to review and test on
the s390 architecture. Thank you for this submission!
^ permalink raw reply
* Re: [RFCv7 PATCH net-next 16/36] treewide: use replace features '0' by netdev_empty_features
From: Alexander Lobakin @ 2022-08-11 12:35 UTC (permalink / raw)
To: shenjian (K)
Cc: Alexander Lobakin, davem, kuba, andrew, ecree.xilinx, hkallweit1,
saeed, leon, netdev, linuxarm
In-Reply-To: <7b6eb064-a649-8a26-8eff-2ad2b2457c22@huawei.com>
From: "shenjian (K)" <shenjian15@huawei.com>
Date: Wed, 10 Aug 2022 20:25:38 +0800
> 在 2022/8/10 18:48, Alexander Lobakin 写道:
> > From: Jian Shen <shenjian15@huawei.com>
> > Date: Wed, 10 Aug 2022 11:06:04 +0800
> >
> >> For the prototype of netdev_features_t will be changed from
> >> u64 to bitmap, so it's unable to assignment with 0 directly.
> >> Replace it with netdev_empty_features.
> > Hmm, why not just netdev_features_zero() instead?
> > There's a couple places where empty netdev_features are needed, but
> > they're not probably worth a separate and rather pointless empty
> > variable, you could create one on the stack there.
> As replied before, the new netdev_features_t supports being
> assigned directly, so use netdev_emtpy_features looks
> more simple.
Dunno, looks reduntant. For declaring onstack variables, one can
simply:
netdev_features_t feat = { };
For zeroing in the code it's a bit more complex:
feat = (typeof(feat)){ };
But I can't remember empty complex variables in the kernel code
declared just to ease type initialization.
Hmm, how about
#define netdev_empty_features ((netdev_features_t){ })
?
It would work just as your variable, but without creating any
globals.
Before converting netdev_features to a structure, you can define
it just as `0`.
>
> >> Signed-off-by: Jian Shen <shenjian15@huawei.com>
> >> ---
> >> drivers/hsi/clients/ssi_protocol.c | 2 +-
> >> drivers/net/caif/caif_serial.c | 2 +-
> >> drivers/net/ethernet/amazon/ena/ena_netdev.c | 2 +-
> >> drivers/net/ethernet/broadcom/b44.c | 2 +-
> >> drivers/net/ethernet/broadcom/tg3.c | 2 +-
> >> drivers/net/ethernet/dnet.c | 2 +-
> >> drivers/net/ethernet/ec_bhf.c | 2 +-
> >> drivers/net/ethernet/emulex/benet/be_main.c | 2 +-
> >> drivers/net/ethernet/ethoc.c | 2 +-
> >> drivers/net/ethernet/huawei/hinic/hinic_main.c | 5 +++--
> >> drivers/net/ethernet/ibm/ibmvnic.c | 6 +++---
> >> drivers/net/ethernet/intel/iavf/iavf_main.c | 9 +++++----
> >> drivers/net/ethernet/microsoft/mana/mana_en.c | 2 +-
> >> drivers/net/ethernet/sfc/ef10.c | 2 +-
> >> drivers/net/tap.c | 2 +-
> >> drivers/net/tun.c | 2 +-
> >> drivers/net/usb/cdc-phonet.c | 3 ++-
> >> drivers/net/usb/lan78xx.c | 2 +-
> >> drivers/s390/net/qeth_core_main.c | 2 +-
> >> drivers/usb/gadget/function/f_phonet.c | 3 ++-
> >> net/dccp/ipv4.c | 2 +-
> >> net/dccp/ipv6.c | 2 +-
> >> net/ethtool/features.c | 2 +-
> >> net/ethtool/ioctl.c | 6 ++++--
> >> net/ipv4/af_inet.c | 2 +-
> >> net/ipv4/tcp.c | 2 +-
> >> net/ipv4/tcp_ipv4.c | 2 +-
> >> net/ipv6/af_inet6.c | 2 +-
> >> net/ipv6/inet6_connection_sock.c | 2 +-
> >> net/ipv6/tcp_ipv6.c | 2 +-
> >> net/openvswitch/datapath.c | 2 +-
> >> 31 files changed, 44 insertions(+), 38 deletions(-)
> > [...]
> >
> >> --
> >> 2.33.0
> > Thanks,
> > Olek
> > .
> >
> Thanks,
> Jian
Thanks,
Olek
^ permalink raw reply
* Re: [PATCH v7 1/4] vdpa: Add suspend operation
From: Dan Carpenter @ 2022-08-11 12:40 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Eugenio Pérez, kvm, linux-kernel, Jason Wang, virtualization,
netdev, dinang, martinpo, Wu Zongyong, Piotr.Uminski,
gautam.dawar, ecree.xilinx, martinh, Stefano Garzarella, pabloc,
habetsm.xilinx, lvivier, Zhu Lingshan, tanuj.kamde, Longpeng,
lulu, hanand, Parav Pandit, Si-Wei Liu, Eli Cohen, Xie Yongji,
Zhang Min, Christophe JAILLET
In-Reply-To: <20220811072125-mutt-send-email-mst@kernel.org>
On Thu, Aug 11, 2022 at 07:23:44AM -0400, Michael S. Tsirkin wrote:
> On Thu, Aug 11, 2022 at 01:15:08PM +0300, Dan Carpenter wrote:
> > On Thu, Aug 11, 2022 at 04:27:32AM -0400, Michael S. Tsirkin wrote:
> > > On Wed, Aug 10, 2022 at 07:15:09PM +0200, Eugenio Pérez wrote:
> > > > This operation is optional: It it's not implemented, backend feature bit
> > > > will not be exposed.
> > > >
> > > > Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
> > > > Message-Id: <20220623160738.632852-2-eperezma@redhat.com>
> > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > >
> > > What is this message id doing here?
> > >
> >
> > I like the Message-Id tag. It means you can `b4 mbox <mesg-id>` and get
> > the thread.
>
> Yes it makes sense in git. But I don't see what it does in this patch
> posted to the list.
Ah. Okay. I misunderstood.
> It seems to refer to the previous version of the
> patch here. Which is ok I guess but better called out e.g.
>
> Previous-version: <20220623160738.632852-2-eperezma@redhat.com>
>
Let's not go over board with storing previous threads. That seems like
a headache...
regards,
dan carpenter
^ permalink raw reply
* [PATCH] virtio_net: fix endian-ness for RSS
From: Michael S. Tsirkin @ 2022-08-11 12:51 UTC (permalink / raw)
To: linux-kernel
Cc: Andrew Melnychenko, Jason Wang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, virtualization, netdev
Using native endian-ness for device supplied fields is wrong
on BE platforms. Sparse warns about this.
Fixes: 91f41f01d219 ("drivers/net/virtio_net: Added RSS hash report.")
Cc: "Andrew Melnychenko" <andrew@daynix.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
drivers/net/virtio_net.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index d9c434b00e9b..6e9868c860bc 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1208,7 +1208,7 @@ static void virtio_skb_set_hash(const struct virtio_net_hdr_v1_hash *hdr_hash,
if (!hdr_hash || !skb)
return;
- switch ((int)hdr_hash->hash_report) {
+ switch (__le16_to_cpu(hdr_hash->hash_report)) {
case VIRTIO_NET_HASH_REPORT_TCPv4:
case VIRTIO_NET_HASH_REPORT_UDPv4:
case VIRTIO_NET_HASH_REPORT_TCPv6:
@@ -1226,7 +1226,7 @@ static void virtio_skb_set_hash(const struct virtio_net_hdr_v1_hash *hdr_hash,
default:
rss_hash_type = PKT_HASH_TYPE_NONE;
}
- skb_set_hash(skb, (unsigned int)hdr_hash->hash_value, rss_hash_type);
+ skb_set_hash(skb, __le32_to_cpu(hdr_hash->hash_value), rss_hash_type);
}
static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq,
--
MST
^ permalink raw reply related
* Re: [PATCH v2 net-next] net: ethernet: ti: davinci_mdio: Add workaround for errata i2329
From: Andrew Lunn @ 2022-08-11 12:57 UTC (permalink / raw)
To: Ravi Gunasekaran
Cc: davem, edumazet, kuba, pabeni, linux-omap, netdev, linux-kernel,
linux-arm-kernel, kishon, vigneshr
In-Reply-To: <9d17ab9f-1679-4af1-f85c-a538cb330d7b@ti.com>
> Devices may or may not be configured for runtime autosuspend, and perhaps
> may not even use runtime PM. pm_runtime_enabled() and the autosuspend
> configuration could be addressed by checking against
> dev->power.use_autosuspend flag. But if the runtime PM functions are added
> to the bit banging core, would it not restrict the usage of
> pm_runtime_put_*() variants for others?
My assumption is, any calls to pm_runtime_* functions will effectively
do nothing if the driver does not have support for it. I could be
wrong about this, and it jumps through a NULL pointer and explodes,
but that would be a bad design.
> There is atleast one device sh_eth, which is not configured for autosuspend
> but uses the bit bang core in sh_mdiobb_read() and invokes regular runtime
> PM functions.
And that is the point of moving it into the core. It would of just
worked for you.
If you don't feel comfortable with making this unconditional, please
put runtime pm enabled version of mdiobb_read/mdiobb_write() in the
core and swap sh_eth and any other drivers to using them.
Andrew
^ permalink raw reply
* Re: [syzbot] WARNING in ieee80211_ibss_csa_beacon
From: syzbot @ 2022-08-11 13:01 UTC (permalink / raw)
To: code, davem, johannes, kuba, linux-kernel, linux-wireless, netdev,
syzkaller-bugs
In-Reply-To: <1828ba28d43.27f8b7ca86738.4232033862850200536@siddh.me>
Hello,
syzbot tried to test the proposed patch but the build/boot failed:
active interface with an up link
[ 50.263416][ T3638] bond0: (slave bond_slave_1): Enslaving as an active interface with an up link
[ 50.285671][ T3638] team0: Port device team_slave_0 added
[ 50.292792][ T3638] team0: Port device team_slave_1 added
[ 50.310141][ T3638] batman_adv: batadv0: Adding interface: batadv_slave_0
[ 50.317225][ T3638] batman_adv: batadv0: The MTU of interface batadv_slave_0 is too small (1500) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1560 would solve the problem.
[ 50.343683][ T3638] batman_adv: batadv0: Not using interface batadv_slave_0 (retrying later): interface not active
[ 50.356731][ T3638] batman_adv: batadv0: Adding interface: batadv_slave_1
[ 50.364022][ T3638] batman_adv: batadv0: The MTU of interface batadv_slave_1 is too small (1500) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1560 would solve the problem.
[ 50.390221][ T3638] batman_adv: batadv0: Not using interface batadv_slave_1 (retrying later): interface not active
[ 50.416765][ T3638] device hsr_slave_0 entered promiscuous mode
[ 50.423796][ T3638] device hsr_slave_1 entered promiscuous mode
[ 50.500816][ T3638] netdevsim netdevsim0 netdevsim0: renamed from eth0
[ 50.511693][ T3638] netdevsim netdevsim0 netdevsim1: renamed from eth1
[ 50.521112][ T3638] netdevsim netdevsim0 netdevsim2: renamed from eth2
[ 50.530709][ T3638] netdevsim netdevsim0 netdevsim3: renamed from eth3
[ 50.551898][ T3638] bridge0: port 2(bridge_slave_1) entered blocking state
[ 50.559135][ T3638] bridge0: port 2(bridge_slave_1) entered forwarding state
[ 50.566985][ T3638] bridge0: port 1(bridge_slave_0) entered blocking state
[ 50.574182][ T3638] bridge0: port 1(bridge_slave_0) entered forwarding state
[ 50.620324][ T3638] 8021q: adding VLAN 0 to HW filter on device bond0
[ 50.634712][ T14] IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
[ 50.644519][ T14] bridge0: port 1(bridge_slave_0) entered disabled state
[ 50.653256][ T14] bridge0: port 2(bridge_slave_1) entered disabled state
[ 50.661875][ T14] IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
[ 50.675639][ T3638] 8021q: adding VLAN 0 to HW filter on device team0
[ 50.686683][ T14] IPv6: ADDRCONF(NETDEV_CHANGE): bridge_slave_0: link becomes ready
[ 50.696048][ T14] bridge0: port 1(bridge_slave_0) entered blocking state
[ 50.703313][ T14] bridge0: port 1(bridge_slave_0) entered forwarding state
[ 50.716587][ T143] IPv6: ADDRCONF(NETDEV_CHANGE): bridge_slave_1: link becomes ready
[ 50.726078][ T143] bridge0: port 2(bridge_slave_1) entered blocking state
[ 50.733163][ T143] bridge0: port 2(bridge_slave_1) entered forwarding state
[ 50.751866][ T14] IPv6: ADDRCONF(NETDEV_CHANGE): team_slave_0: link becomes ready
[ 50.766290][ T14] IPv6: ADDRCONF(NETDEV_CHANGE): team0: link becomes ready
[ 50.775160][ T14] IPv6: ADDRCONF(NETDEV_CHANGE): team_slave_1: link becomes ready
[ 50.787909][ T3650] IPv6: ADDRCONF(NETDEV_CHANGE): hsr_slave_0: link becomes ready
[ 50.800188][ T3638] hsr0: Slave B (hsr_slave_1) is not up; please bring it up to get a fully working HSR network
[ 50.812187][ T3638] IPv6: ADDRCONF(NETDEV_CHANGE): hsr0: link becomes ready
[ 50.821509][ T14] IPv6: ADDRCONF(NETDEV_CHANGE): hsr_slave_1: link becomes ready
[ 50.845246][ T3638] 8021q: adding VLAN 0 to HW filter on device batadv0
[ 50.853191][ T6] IPv6: ADDRCONF(NETDEV_CHANGE): vxcan0: link becomes ready
[ 50.861297][ T6] IPv6: ADDRCONF(NETDEV_CHANGE): vxcan1: link becomes ready
[ 50.976504][ T143] IPv6: ADDRCONF(NETDEV_CHANGE): veth0_virt_wifi: link becomes ready
[ 50.990346][ T6] IPv6: ADDRCONF(NETDEV_CHANGE): veth0_vlan: link becomes ready
[ 51.001733][ T6] IPv6: ADDRCONF(NETDEV_CHANGE): vlan0: link becomes ready
[ 51.009609][ T6] IPv6: ADDRCONF(NETDEV_CHANGE): vlan1: link becomes ready
[ 51.018756][ T3638] device veth0_vlan entered promiscuous mode
[ 51.033199][ T3638] device veth1_vlan entered promiscuous mode
[ 51.053599][ T3650] IPv6: ADDRCONF(NETDEV_CHANGE): macvlan0: link becomes ready
[ 51.063508][ T3650] IPv6: ADDRCONF(NETDEV_CHANGE): macvlan1: link becomes ready
[ 51.072555][ T3650] IPv6: ADDRCONF(NETDEV_CHANGE): veth0_macvtap: link becomes ready
[ 51.084230][ T3638] device veth0_macvtap entered promiscuous mode
[ 51.093816][ T3638] device veth1_macvtap entered promiscuous mode
[ 51.116192][ T3638] batman_adv: batadv0: Interface activated: batadv_slave_0
[ 51.124686][ T6] IPv6: ADDRCONF(NETDEV_CHANGE): veth0_to_batadv: link becomes ready
[ 51.136685][ T6] IPv6: ADDRCONF(NETDEV_CHANGE): macvtap0: link becomes ready
[ 51.149935][ T3638] batman_adv: batadv0: Interface activated: batadv_slave_1
[ 51.158614][ T3650] IPv6: ADDRCONF(NETDEV_CHANGE): batadv_slave_1: link becomes ready
[ 51.168462][ T3650] IPv6: ADDRCONF(NETDEV_CHANGE): veth1_to_batadv: link becomes ready
[ 51.182170][ T3638] netdevsim netdevsim0 netdevsim0: set [1, 0] type 2 family 0 port 6081 - 0
[ 51.192643][ T3638] netdevsim netdevsim0 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0
[ 51.202462][ T3638] netdevsim netdevsim0 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0
[ 51.212143][ T3638] netdevsim netdevsim0 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0
[ 51.299438][ T29] wlan0: Created IBSS using preconfigured BSSID 50:50:50:50:50:50
[ 51.310951][ T29] wlan0: Creating new IBSS network, BSSID 50:50:50:50:50:50
[ 51.322462][ T143] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 51.335671][ T2494] wlan1: Created IBSS using preconfigured BSSID 50:50:50:50:50:50
[ 51.344772][ T2494] wlan1: Creating new IBSS network, BSSID 50:50:50:50:50:50
[ 51.353568][ T143] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
2022/08/11 13:00:39 building call list...
[ 51.514478][ T3638] ------------[ cut here ]------------
[ 51.520140][ T3638] ODEBUG: assert_init not available (active state 0) object type: timer_list hint: 0x0
[ 51.530079][ T3638] WARNING: CPU: 0 PID: 3638 at lib/debugobjects.c:505 debug_object_assert_init+0x1fa/0x250
[ 51.540259][ T3638] Modules linked in:
[ 51.544336][ T3638] CPU: 0 PID: 3638 Comm: syz-executor.0 Not tainted 5.19.0-syzkaller #0
[ 51.552766][ T3638] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022
[ 51.563627][ T3638] RIP: 0010:debug_object_assert_init+0x1fa/0x250
[ 51.570150][ T3638] Code: e8 eb 83 d1 fd 4c 8b 45 00 48 c7 c7 60 9f 6a 8a 48 c7 c6 60 9c 6a 8a 48 c7 c2 00 a1 6a 8a 31 c9 49 89 d9 31 c0 e8 66 73 4e fd <0f> 0b ff 05 9a 20 8a 09 48 83 c5 38 48 89 e8 48 c1 e8 03 42 80 3c
[ 51.590417][ T3638] RSP: 0018:ffffc90003b0f8c8 EFLAGS: 00010046
[ 51.596584][ T3638] RAX: af76cc1e655f6400 RBX: 0000000000000000 RCX: ffff888014741d40
[ 51.604841][ T3638] RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
[ 51.612846][ T3638] RBP: ffffffff8a0fc700 R08: ffffffff8165f59d R09: ffffed1017384f14
[ 51.621025][ T3638] R10: ffffed1017384f14 R11: 1ffff11017384f13 R12: dffffc0000000000
[ 51.629090][ T3638] R13: ffff88807f3d09d0 R14: 0000000000000011 R15: ffffffff90029988
[ 51.637103][ T3638] FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
[ 51.646131][ T3638] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 51.652815][ T3638] CR2: 000000c00060a001 CR3: 0000000020940000 CR4: 00000000003506f0
[ 51.660973][ T3638] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 51.668940][ T3638] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 51.677688][ T3638] Call Trace:
[ 51.680962][ T3638] <TASK>
[ 51.683992][ T3638] del_timer+0x3d/0x2d0
[ 51.688212][ T3638] ? try_to_grab_pending+0xb1/0x700
[ 51.693412][ T3638] try_to_grab_pending+0xbf/0x700
[ 51.698619][ T3638] __cancel_work_timer+0x81/0x5b0
[ 51.703983][ T3638] ? mgmt_send_event_skb+0x2ee/0x4e0
[ 51.709401][ T3638] ? kmem_cache_free+0x95/0x1d0
[ 51.714437][ T3638] ? mgmt_send_event_skb+0x2ee/0x4e0
[ 51.719724][ T3638] mgmt_index_removed+0x244/0x330
[ 51.725464][ T3638] hci_unregister_dev+0x28e/0x460
[ 51.730623][ T3638] ? vhci_open+0x360/0x360
[ 51.735209][ T3638] vhci_release+0x7f/0xd0
[ 51.739538][ T3638] __fput+0x3b9/0x820
[ 51.743800][ T3638] task_work_run+0x146/0x1c0
[ 51.748501][ T3638] do_exit+0x4ed/0x1f30
[ 51.752680][ T3638] ? rcu_read_lock_sched_held+0x41/0xb0
[ 51.758365][ T3638] do_group_exit+0x23b/0x2f0
[ 51.762963][ T3638] ? _raw_spin_unlock_irq+0x1f/0x40
[ 51.768653][ T3638] ? lockdep_hardirqs_on+0x8d/0x130
[ 51.774245][ T3638] get_signal+0x16a3/0x1700
[ 51.779122][ T3638] arch_do_signal_or_restart+0x29/0x5d0
[ 51.784691][ T3638] exit_to_user_mode_loop+0x74/0x150
[ 51.790147][ T3638] exit_to_user_mode_prepare+0xb2/0x140
[ 51.796127][ T3638] syscall_exit_to_user_mode+0x26/0x60
[ 51.802152][ T3638] do_syscall_64+0x49/0x90
[ 51.806773][ T3638] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 51.812939][ T3638] RIP: 0033:0x4191dc
[ 51.817111][ T3638] Code: Unable to access opcode bytes at RIP 0x4191b2.
[ 51.823960][ T3638] RSP: 002b:00007fffcb50dcd0 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[ 51.832477][ T3638] RAX: fffffffffffffe00 RBX: 00007fffcb50dd90 RCX: 00000000004191dc
[ 51.840566][ T3638] RDX: 0000000000000050 RSI: 0000000000568020 RDI: 00000000000000f9
[ 51.848559][ T3638] RBP: 0000000000000003 R08: 0000000000000000 R09: 0079746972756365
[ 51.857099][ T3638] R10: 00000000005436a0 R11: 0000000000000246 R12: 0000000000000032
[ 51.865523][ T3638] R13: 000000000000c8b1 R14: 0000000000000000 R15: 00007fffcb50ddd0
[ 51.873863][ T3638] </TASK>
[ 51.876995][ T3638] Kernel panic - not syncing: panic_on_warn set ...
[ 51.883575][ T3638] CPU: 0 PID: 3638 Comm: syz-executor.0 Not tainted 5.19.0-syzkaller #0
[ 51.892096][ T3638] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022
[ 51.902161][ T3638] Call Trace:
[ 51.905527][ T3638] <TASK>
[ 51.908545][ T3638] dump_stack_lvl+0x131/0x1c8
[ 51.913322][ T3638] panic+0x26b/0x693
[ 51.917497][ T3638] ? __warn+0x131/0x220
[ 51.921826][ T3638] ? debug_object_assert_init+0x1fa/0x250
[ 51.927674][ T3638] __warn+0x1fa/0x220
[ 51.931700][ T3638] ? debug_object_assert_init+0x1fa/0x250
[ 51.937520][ T3638] report_bug+0x1b3/0x2d0
[ 51.941878][ T3638] handle_bug+0x3d/0x70
[ 51.946174][ T3638] exc_invalid_op+0x16/0x40
[ 51.950780][ T3638] asm_exc_invalid_op+0x16/0x20
[ 51.955734][ T3638] RIP: 0010:debug_object_assert_init+0x1fa/0x250
[ 51.962102][ T3638] Code: e8 eb 83 d1 fd 4c 8b 45 00 48 c7 c7 60 9f 6a 8a 48 c7 c6 60 9c 6a 8a 48 c7 c2 00 a1 6a 8a 31 c9 49 89 d9 31 c0 e8 66 73 4e fd <0f> 0b ff 05 9a 20 8a 09 48 83 c5 38 48 89 e8 48 c1 e8 03 42 80 3c
[ 51.981793][ T3638] RSP: 0018:ffffc90003b0f8c8 EFLAGS: 00010046
[ 51.988057][ T3638] RAX: af76cc1e655f6400 RBX: 0000000000000000 RCX: ffff888014741d40
[ 51.996245][ T3638] RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
[ 52.005054][ T3638] RBP: ffffffff8a0fc700 R08: ffffffff8165f59d R09: ffffed1017384f14
[ 52.013065][ T3638] R10: ffffed1017384f14 R11: 1ffff11017384f13 R12: dffffc0000000000
[ 52.021767][ T3638] R13: ffff88807f3d09d0 R14: 0000000000000011 R15: ffffffff90029988
[ 52.031524][ T3638] ? __wake_up_klogd+0xcd/0x100
[ 52.036840][ T3638] ? debug_object_assert_init+0x1fa/0x250
[ 52.042873][ T3638] del_timer+0x3d/0x2d0
[ 52.047348][ T3638] ? try_to_grab_pending+0xb1/0x700
[ 52.052749][ T3638] try_to_grab_pending+0xbf/0x700
[ 52.057800][ T3638] __cancel_work_timer+0x81/0x5b0
[ 52.062831][ T3638] ? mgmt_send_event_skb+0x2ee/0x4e0
[ 52.068345][ T3638] ? kmem_cache_free+0x95/0x1d0
[ 52.073224][ T3638] ? mgmt_send_event_skb+0x2ee/0x4e0
[ 52.078681][ T3638] mgmt_index_removed+0x244/0x330
[ 52.083977][ T3638] hci_unregister_dev+0x28e/0x460
[ 52.089128][ T3638] ? vhci_open+0x360/0x360
[ 52.093621][ T3638] vhci_release+0x7f/0xd0
[ 52.097961][ T3638] __fput+0x3b9/0x820
[ 52.102128][ T3638] task_work_run+0x146/0x1c0
[ 52.106746][ T3638] do_exit+0x4ed/0x1f30
[ 52.110908][ T3638] ? rcu_read_lock_sched_held+0x41/0xb0
[ 52.116673][ T3638] do_group_exit+0x23b/0x2f0
[ 52.121452][ T3638] ? _raw_spin_unlock_irq+0x1f/0x40
[ 52.126661][ T3638] ? lockdep_hardirqs_on+0x8d/0x130
[ 52.131858][ T3638] get_signal+0x16a3/0x1700
[ 52.136804][ T3638] arch_do_signal_or_restart+0x29/0x5d0
[ 52.142556][ T3638] exit_to_user_mode_loop+0x74/0x150
[ 52.147840][ T3638] exit_to_user_mode_prepare+0xb2/0x140
[ 52.153731][ T3638] syscall_exit_to_user_mode+0x26/0x60
[ 52.159196][ T3638] do_syscall_64+0x49/0x90
[ 52.163644][ T3638] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 52.169629][ T3638] RIP: 0033:0x4191dc
[ 52.173526][ T3638] Code: Unable to access opcode bytes at RIP 0x4191b2.
[ 52.180458][ T3638] RSP: 002b:00007fffcb50dcd0 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[ 52.189133][ T3638] RAX: fffffffffffffe00 RBX: 00007fffcb50dd90 RCX: 00000000004191dc
[ 52.197189][ T3638] RDX: 0000000000000050 RSI: 0000000000568020 RDI: 00000000000000f9
[ 52.205251][ T3638] RBP: 0000000000000003 R08: 0000000000000000 R09: 0079746972756365
[ 52.213269][ T3638] R10: 00000000005436a0 R11: 0000000000000246 R12: 0000000000000032
[ 52.221332][ T3638] R13: 000000000000c8b1 R14: 0000000000000000 R15: 00007fffcb50ddd0
[ 52.229405][ T3638] </TASK>
[ 52.232869][ T3638] Kernel Offset: disabled
[ 52.237327][ T3638] Rebooting in 86400 seconds..
syzkaller build log:
go env (err=<nil>)
GO111MODULE="auto"
GOARCH="amd64"
GOBIN=""
GOCACHE="/syzkaller/.cache/go-build"
GOENV="/syzkaller/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/syzkaller/jobs/linux/gopath/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/syzkaller/jobs/linux/gopath"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/syzkaller/jobs/linux/gopath/src/github.com/google/syzkaller/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1977670166=/tmp/go-build -gno-record-gcc-switches"
git status (err=<nil>)
HEAD detached at 607e3baf1
nothing to commit, working tree clean
go list -f '{{.Stale}}' ./sys/syz-sysgen | grep -q false || go install ./sys/syz-sysgen
make .descriptions
bin/syz-sysgen
touch .descriptions
GOOS=linux GOARCH=amd64 go build "-ldflags=-s -w -X github.com/google/syzkaller/prog.GitRevision=607e3baf1c25928040d05fc22eff6fce7edd709e -X 'github.com/google/syzkaller/prog.gitRevisionDate=20210324-183421'" "-tags=syz_target syz_os_linux syz_arch_amd64 " -o ./bin/linux_amd64/syz-fuzzer github.com/google/syzkaller/syz-fuzzer
GOOS=linux GOARCH=amd64 go build "-ldflags=-s -w -X github.com/google/syzkaller/prog.GitRevision=607e3baf1c25928040d05fc22eff6fce7edd709e -X 'github.com/google/syzkaller/prog.gitRevisionDate=20210324-183421'" "-tags=syz_target syz_os_linux syz_arch_amd64 " -o ./bin/linux_amd64/syz-execprog github.com/google/syzkaller/tools/syz-execprog
GOOS=linux GOARCH=amd64 go build "-ldflags=-s -w -X github.com/google/syzkaller/prog.GitRevision=607e3baf1c25928040d05fc22eff6fce7edd709e -X 'github.com/google/syzkaller/prog.gitRevisionDate=20210324-183421'" "-tags=syz_target syz_os_linux syz_arch_amd64 " -o ./bin/linux_amd64/syz-stress github.com/google/syzkaller/tools/syz-stress
mkdir -p ./bin/linux_amd64
gcc -o ./bin/linux_amd64/syz-executor executor/executor.cc \
-m64 -O2 -pthread -Wall -Werror -Wparentheses -Wunused-const-variable -Wframe-larger-than=16384 -static -fpermissive -w -DGOOS_linux=1 -DGOARCH_amd64=1 \
-DHOSTGOOS_linux=1 -DGIT_REVISION=\"607e3baf1c25928040d05fc22eff6fce7edd709e\"
Error text is too large and was truncated, full error text is at:
https://syzkaller.appspot.com/x/error.txt?x=13730f25080000
Tested on:
commit: 64737995 wifi: mac80211: Don't finalize CSA in IBSS mo..
git tree: https://github.com/siddhpant/linux.git warning_ibss_csa_beacon
kernel config: https://syzkaller.appspot.com/x/.config?x=9b770cb261c0c061
dashboard link: https://syzkaller.appspot.com/bug?extid=b6c9fe29aefe68e4ad34
compiler: Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2
Note: no patches were applied.
^ 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