* Re: [PATCH] net: dsa: mv88e6xxx: Skip cmode writable for mv88e6*41 if unchanged
From: Nathan Rossi @ 2022-04-26 10:45 UTC (permalink / raw)
To: Paolo Abeni
Cc: Marek Behún, netdev, linux-kernel, Andrew Lunn,
Vivien Didelot, Florian Fainelli, Vladimir Oltean,
David S. Miller, Jakub Kicinski
In-Reply-To: <43773a65a27cb714e3319b06b0215fcb0471aae6.camel@redhat.com>
On Tue, 26 Apr 2022 at 17:50, Paolo Abeni <pabeni@redhat.com> wrote:
>
> Hello,
>
> On Sat, 2022-04-23 at 15:25 +0200, Marek Behún wrote:
> > On Sat, 23 Apr 2022 13:20:35 +0000
> > Nathan Rossi <nathan@nathanrossi.com> wrote:
> >
> > > The mv88e6341_port_set_cmode function always calls the set writable
> > > regardless of whether the current cmode is different from the desired
> > > cmode. This is problematic for specific configurations of the mv88e6341
> > > and mv88e6141 (in single chip adddressing mode?) where the hidden
> > > registers are not accessible.
> >
> > I don't have a problem with skipping setting cmode writable if cmode is
> > not being changed. But hidden registers should be accessible regardless
> > of whether you are using single chip addressing mode or not. You need
> > to find why it isn't working for you, this is a bug.
>
> For the records, I read the above as requiring a fix the root cause, so
> I'm not applying this patch. Please correct me if I'm wrong.
You are correct. Sorry I forgot to reply to this thread after posting
the root cause fix.
For reference the root cause fix to the issue mentioned by this patch
is https://lore.kernel.org/netdev/20220425070454.348584-1-nathan@nathanrossi.com/.
Thanks,
Nathan
>
> Thanks,
>
> Paolo
>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: mailbox: qcom-ipcc: simplify the example
From: Krzysztof Kozlowski @ 2022-04-26 10:36 UTC (permalink / raw)
To: Jassi Brar
Cc: Manivannan Sadhasivam, Bjorn Andersson, Krzysztof Kozlowski,
Paolo Abeni, linux-arm-msm, Linux Kernel Mailing List,
Devicetree List, Andy Gross, netdev, Rob Herring, Alex Elder,
Jakub Kicinski, David S. Miller, Rob Herring
In-Reply-To: <CABb+yY3uRxKdQ_Q-yvWipmOqLNbJXmJ141oYJnq1di_Yu66T_Q@mail.gmail.com>
On 20/04/2022 16:22, Jassi Brar wrote:
> On Wed, Apr 20, 2022 at 3:42 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 02/04/2022 17:55, Krzysztof Kozlowski wrote:
>>> Consumer examples in the bindings of resource providers are trivial,
>>> useless and duplicating code. Additionally the incomplete qcom,smp2p
>>> example triggers DT schema warnings.
>>>
>>> Cleanup the example by removing the consumer part and fixing the
>>> indentation to DT schema convention.
>>>
>>> Reported-by: Rob Herring <robh@kernel.org>
>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>
>> Jassi,
>> Do you plan to pick this mailbox patch?
>>
> Yes, I do. I am ok too, if you want it through some other tree as a
> part of some bigger patchset.
It's not going through any other tree, so please pick it up.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net-next v4 1/2] rtnetlink: add extack support in fdb del handlers
From: kernel test robot @ 2022-04-26 10:23 UTC (permalink / raw)
To: Alaa Mohamed, netdev
Cc: llvm, kbuild-all, outreachy, roopa, jdenham, sbrivio,
jesse.brandeburg, anthony.l.nguyen, davem, kuba, pabeni,
vladimir.oltean, claudiu.manoil, alexandre.belloni, shshaikh,
manishc, razor, intel-wired-lan, linux-kernel, UNGLinuxDriver,
GR-Linux-NIC-Dev, bridge, eng.alaamohamedsoliman.am
In-Reply-To: <8847c5d670c7ee11890d75f58a4922c5cb542f20.1650896000.git.eng.alaamohamedsoliman.am@gmail.com>
Hi Alaa,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on horms-ipvs/master]
[also build test ERROR on net/master linus/master v5.18-rc4]
[cannot apply to net-next/master next-20220422]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/intel-lab-lkp/linux/commits/Alaa-Mohamed/propagate-extack-to-vxlan_fdb_delete/20220425-222644
base: https://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs.git master
config: riscv-randconfig-r002-20220425 (https://download.01.org/0day-ci/archive/20220426/202204261831.S6mBmtgP-lkp@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 1cddcfdc3c683b393df1a5c9063252eb60e52818)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install riscv cross compiling tool for clang build
# apt-get install binutils-riscv64-linux-gnu
# https://github.com/intel-lab-lkp/linux/commit/5e9c3e146040a4e37b45ca18c3b42c3dfd6d0a0e
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Alaa-Mohamed/propagate-extack-to-vxlan_fdb_delete/20220425-222644
git checkout 5e9c3e146040a4e37b45ca18c3b42c3dfd6d0a0e
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=riscv SHELL=/bin/bash drivers/net/ethernet/mscc/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> drivers/net/ethernet/mscc/ocelot_net.c:784:70: error: too many arguments to function call, expected 5, have 6
return ocelot_fdb_del(ocelot, port, addr, vid, ocelot_port->bridge, extack);
~~~~~~~~~~~~~~ ^~~~~~
include/soc/mscc/ocelot.h:893:5: note: 'ocelot_fdb_del' declared here
int ocelot_fdb_del(struct ocelot *ocelot, int port, const unsigned char *addr,
^
1 error generated.
vim +784 drivers/net/ethernet/mscc/ocelot_net.c
774
775 static int ocelot_port_fdb_del(struct ndmsg *ndm, struct nlattr *tb[],
776 struct net_device *dev,
777 const unsigned char *addr, u16 vid, struct netlink_ext_ack *extack)
778 {
779 struct ocelot_port_private *priv = netdev_priv(dev);
780 struct ocelot_port *ocelot_port = &priv->port;
781 struct ocelot *ocelot = ocelot_port->ocelot;
782 int port = priv->chip_port;
783
> 784 return ocelot_fdb_del(ocelot, port, addr, vid, ocelot_port->bridge, extack);
785 }
786
--
0-DAY CI Kernel Test Service
https://01.org/lkp
^ permalink raw reply
* Re: [PATCH v3] net: dsa: mv88e6xxx: Fix port_hidden_wait to account for port_base_addr
From: patchwork-bot+netdevbpf @ 2022-04-26 10:30 UTC (permalink / raw)
To: Nathan Rossi
Cc: netdev, linux-kernel, andrew, vivien.didelot, f.fainelli, olteanv,
davem, kuba, pabeni, kabel
In-Reply-To: <20220425070454.348584-1-nathan@nathanrossi.com>
Hello:
This patch was applied to netdev/net.git (master)
by Paolo Abeni <pabeni@redhat.com>:
On Mon, 25 Apr 2022 07:04:54 +0000 you wrote:
> The other port_hidden functions rely on the port_read/port_write
> functions to access the hidden control port. These functions apply the
> offset for port_base_addr where applicable. Update port_hidden_wait to
> use the port_wait_bit so that port_base_addr offsets are accounted for
> when waiting for the busy bit to change.
>
> Without the offset the port_hidden_wait function would timeout on
> devices that have a non-zero port_base_addr (e.g. MV88E6141), however
> devices that have a zero port_base_addr would operate correctly (e.g.
> MV88E6390).
>
> [...]
Here is the summary with links:
- [v3] net: dsa: mv88e6xxx: Fix port_hidden_wait to account for port_base_addr
https://git.kernel.org/netdev/net/c/24cbdb910bb6
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH v2] batman-adv: remove unnecessary type castings
From: Yu Zhe @ 2022-04-26 10:29 UTC (permalink / raw)
To: mareklindner, sw, a, sven, davem, kuba, pabeni
Cc: b.a.t.m.a.n, netdev, linux-kernel, liqiong, kernel-janitors,
hukun, Yu Zhe, kernel test robot
In-Reply-To: <20220425113635.1609532-1-yuzhe@nfschina.com>
Signed-off-by: Yu Zhe <yuzhe@nfschina.com>
[sven@narfation.org: Fix missing const in batadv_choose* functions]
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Reported-by: kernel test robot <lkp@intel.com>
---
v2:
- fix discarding 'const' qualifier from pointer target type
---
net/batman-adv/bridge_loop_avoidance.c | 4 ++--
net/batman-adv/translation-table.c | 12 ++++++------
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/net/batman-adv/bridge_loop_avoidance.c b/net/batman-adv/bridge_loop_avoidance.c
index 7f8a14d99cdb..37ce6cfb3520 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -65,7 +65,7 @@ batadv_bla_send_announce(struct batadv_priv *bat_priv,
*/
static inline u32 batadv_choose_claim(const void *data, u32 size)
{
- struct batadv_bla_claim *claim = (struct batadv_bla_claim *)data;
+ const struct batadv_bla_claim *claim = data;
u32 hash = 0;
hash = jhash(&claim->addr, sizeof(claim->addr), hash);
@@ -86,7 +86,7 @@ static inline u32 batadv_choose_backbone_gw(const void *data, u32 size)
const struct batadv_bla_backbone_gw *gw;
u32 hash = 0;
- gw = (struct batadv_bla_backbone_gw *)data;
+ gw = data;
hash = jhash(&gw->orig, sizeof(gw->orig), hash);
hash = jhash(&gw->vid, sizeof(gw->vid), hash);
diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c
index 8478034d3abf..01d30c1e412c 100644
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -103,10 +103,10 @@ static bool batadv_compare_tt(const struct hlist_node *node, const void *data2)
*/
static inline u32 batadv_choose_tt(const void *data, u32 size)
{
- struct batadv_tt_common_entry *tt;
+ const struct batadv_tt_common_entry *tt;
u32 hash = 0;
- tt = (struct batadv_tt_common_entry *)data;
+ tt = data;
hash = jhash(&tt->addr, ETH_ALEN, hash);
hash = jhash(&tt->vid, sizeof(tt->vid), hash);
@@ -2766,7 +2766,7 @@ static void batadv_tt_tvlv_generate(struct batadv_priv *bat_priv,
u32 i;
tt_tot = batadv_tt_entries(tt_len);
- tt_change = (struct batadv_tvlv_tt_change *)tvlv_buff;
+ tt_change = tvlv_buff;
if (!valid_cb)
return;
@@ -3994,7 +3994,7 @@ static void batadv_tt_tvlv_ogm_handler_v1(struct batadv_priv *bat_priv,
if (tvlv_value_len < sizeof(*tt_data))
return;
- tt_data = (struct batadv_tvlv_tt_data *)tvlv_value;
+ tt_data = tvlv_value;
tvlv_value_len -= sizeof(*tt_data);
num_vlan = ntohs(tt_data->num_vlan);
@@ -4037,7 +4037,7 @@ static int batadv_tt_tvlv_unicast_handler_v1(struct batadv_priv *bat_priv,
if (tvlv_value_len < sizeof(*tt_data))
return NET_RX_SUCCESS;
- tt_data = (struct batadv_tvlv_tt_data *)tvlv_value;
+ tt_data = tvlv_value;
tvlv_value_len -= sizeof(*tt_data);
tt_vlan_len = sizeof(struct batadv_tvlv_tt_vlan_data);
@@ -4129,7 +4129,7 @@ static int batadv_roam_tvlv_unicast_handler_v1(struct batadv_priv *bat_priv,
goto out;
batadv_inc_counter(bat_priv, BATADV_CNT_TT_ROAM_ADV_RX);
- roaming_adv = (struct batadv_tvlv_roam_adv *)tvlv_value;
+ roaming_adv = tvlv_value;
batadv_dbg(BATADV_DBG_TT, bat_priv,
"Received ROAMING_ADV from %pM (client %pM)\n",
--
2.25.1
^ permalink raw reply related
* Re: [RFC PATCH v4 07/15] landlock: user space API network support
From: Konstantin Meskhidze @ 2022-04-26 10:17 UTC (permalink / raw)
To: Mickaël Salaün
Cc: willemdebruijn.kernel, linux-security-module, netdev,
netfilter-devel, yusongping, artem.kuzin, anton.sirazetdinov
In-Reply-To: <dbe702e7-ee63-c665-a989-255b0c1212cc@digikod.net>
4/12/2022 7:10 PM, Mickaël Salaün пишет:
>
> On 12/04/2022 16:05, Konstantin Meskhidze wrote:
>>
>>
>> 4/12/2022 4:48 PM, Mickaël Salaün пишет:
>>>
>>> On 12/04/2022 13:21, Mickaël Salaün wrote:
>>>>
>>>> On 09/03/2022 14:44, Konstantin Meskhidze wrote:
>>>
>>> [...]
>>>
>>>>> @@ -184,7 +185,7 @@ SYSCALL_DEFINE3(landlock_create_ruleset,
>>>>>
>>>>> /* Checks content (and 32-bits cast). */
>>>>> if ((ruleset_attr.handled_access_fs |
>>>>> LANDLOCK_MASK_ACCESS_FS) !=
>>>>> - LANDLOCK_MASK_ACCESS_FS)
>>>>> + LANDLOCK_MASK_ACCESS_FS)
>>>>
>>>> Don't add cosmetic changes. FYI, I'm relying on the way Vim does
>>>> line cuts, which is mostly tabs. Please try to do the same.
>>>
>>> Well, let's make it simple and avoid tacit rules. I'll update most of
>>> the existing Landlock code and tests to be formatted with
>>> clang-format (-i *.[ch]), and I'll update the landlock-wip branch so
>>> that you can base your next patch series on it. There should be some
>>> exceptions that need customization but we'll see that in the next
>>> series. Anyway, don't worry too much, just make sure you don't have
>>> style-only changes in your patches.
>>
>> I have already rebased my next patch series on your landlock-wip
>> branch. So I will wait for your changes meanwhile refactoring my v5
>> patch series according your comments.
>
> Good.
>
>>
>> Also I want to discuss adding demo in sandboxer.c to show how landlock
>> supports network sandboxing:
>>
>> - Add additional args like "LL_NET_BIND=port1:...:portN"
>> - Add additional args like "LL_NET_CONNECT=port1:...:portN"
>> - execv 2 bash procceses:
>> 1. first bash listens in loop - $ nc -l -k -p <port1> -v
>> 2. second bash to connects the first one - $ nc <ip> <port>
>>
>> What do you think? its possible to present this demo in the next v5
>> patch series.
>
> This looks good! I think LL_TCP_BIND and LL_TCP_CONNECT would fit better
> though.
> Got it. Thanks
> I'm not sure if I already said that, but please remove the "RFC " part
> for the next series.
Ok.
> .
^ permalink raw reply
* [PATCH net] tcp: fix F-RTO may not work correctly when receiving DSACK
From: Pengcheng Yang @ 2022-04-26 10:03 UTC (permalink / raw)
To: Eric Dumazet, Neal Cardwell, Yuchung Cheng, netdev
Cc: David S. Miller, Hideaki YOSHIFUJI, David Ahern, Jakub Kicinski,
Paolo Abeni, Pengcheng Yang
Currently DSACK is regarded as a dupack, which may cause
F-RTO to incorrectly enter "loss was real" when receiving
DSACK.
Packetdrill to demonstrate:
// Enable F-RTO and TLP
0 `sysctl -q net.ipv4.tcp_frto=2`
0 `sysctl -q net.ipv4.tcp_early_retrans=3`
0 `sysctl -q net.ipv4.tcp_congestion_control=cubic`
// Establish a connection
+0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0
// RTT 10ms, RTO 210ms
+.1 < S 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>
+0 > S. 0:0(0) ack 1 <...>
+.01 < . 1:1(0) ack 1 win 257
+0 accept(3, ..., ...) = 4
// Send 2 data segments
+0 write(4, ..., 2000) = 2000
+0 > P. 1:2001(2000) ack 1
// TLP
+.022 > P. 1001:2001(1000) ack 1
// Continue to send 8 data segments
+0 write(4, ..., 10000) = 10000
+0 > P. 2001:10001(8000) ack 1
// RTO
+.188 > . 1:1001(1000) ack 1
// The original data is acked and new data is sent(F-RTO step 2.b)
+0 < . 1:1(0) ack 2001 win 257
+0 > P. 10001:12001(2000) ack 1
// D-SACK caused by TLP is regarded as a dupack, this results in
// the incorrect judgment of "loss was real"(F-RTO step 3.a)
+.022 < . 1:1(0) ack 2001 win 257 <sack 1001:2001,nop,nop>
// Never-retransmitted data(3001:4001) are acked and
// expect to switch to open state(F-RTO step 3.b)
+0 < . 1:1(0) ack 4001 win 257
+0 %{ assert tcpi_ca_state == 0, tcpi_ca_state }%
Fixes: e33099f96d99 ("tcp: implement RFC5682 F-RTO")
Signed-off-by: Pengcheng Yang <yangpc@wangsu.com>
---
net/ipv4/tcp_input.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 1595b76..c54accc 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3867,7 +3867,8 @@ static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag)
tcp_process_tlp_ack(sk, ack, flag);
if (tcp_ack_is_dubious(sk, flag)) {
- if (!(flag & (FLAG_SND_UNA_ADVANCED | FLAG_NOT_DUP))) {
+ if (!(flag & (FLAG_SND_UNA_ADVANCED |
+ FLAG_NOT_DUP | FLAG_DSACKING_ACK))) {
num_dupack = 1;
/* Consider if pure acks were aggregated in tcp_add_backlog() */
if (!(flag & FLAG_DATA))
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCHv2 bpf-next 1/4] kallsyms: Add kallsyms_lookup_names function
From: Masami Hiramatsu @ 2022-04-26 10:01 UTC (permalink / raw)
To: Jiri Olsa
Cc: Jiri Olsa, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
netdev, bpf, lkml, Martin KaFai Lau, Song Liu, Yonghong Song,
John Fastabend, KP Singh
In-Reply-To: <YmJPcU9dahEatb0f@krava>
Hi Jiri,
Sorry for replying late.
On Fri, 22 Apr 2022 08:47:13 +0200
Jiri Olsa <olsajiri@gmail.com> wrote:
> On Tue, Apr 19, 2022 at 10:26:05AM +0200, Jiri Olsa wrote:
>
> SNIP
>
> > > > +static int kallsyms_callback(void *data, const char *name,
> > > > + struct module *mod, unsigned long addr)
> > > > +{
> > > > + struct kallsyms_data *args = data;
> > > > +
> > > > + if (!bsearch(&name, args->syms, args->cnt, sizeof(*args->syms), symbols_cmp))
> > > > + return 0;
> > > > +
> > > > + addr = ftrace_location(addr);
> > > > + if (!addr)
> > > > + return 0;
> > >
> > > Ooops, wait. Did you do this last version? I missed this point.
> > > This changes the meanings of the kernel function.
> >
> > yes, it was there before ;-) and you're right.. so some archs can
> > return different address, I did not realize that
> >
> > >
> > > > +
> > > > + args->addrs[args->found++] = addr;
> > > > + return args->found == args->cnt ? 1 : 0;
> > > > +}
> > > > +
> > > > +/**
> > > > + * kallsyms_lookup_names - Lookup addresses for array of symbols
> > >
> > > More correctly "Lookup 'ftraced' addresses for array of sorted symbols", right?
> > >
> > > I'm not sure, we can call it as a 'kallsyms' API, since this is using
> > > kallsyms but doesn't return symbol address, but ftrace address.
> > > I think this name misleads user to expect returning symbol address.
> > >
> > > > + *
> > > > + * @syms: array of symbols pointers symbols to resolve, must be
> > > > + * alphabetically sorted
> > > > + * @cnt: number of symbols/addresses in @syms/@addrs arrays
> > > > + * @addrs: array for storing resulting addresses
> > > > + *
> > > > + * This function looks up addresses for array of symbols provided in
> > > > + * @syms array (must be alphabetically sorted) and stores them in
> > > > + * @addrs array, which needs to be big enough to store at least @cnt
> > > > + * addresses.
> > >
> > > Hmm, sorry I changed my mind. I rather like to expose kallsyms_on_each_symbol()
> > > and provide this API from fprobe or ftrace, because this returns ftrace address
> > > and thus this is only used from fprobe.
> >
> > ok, so how about:
> >
> > int ftrace_lookup_symbols(const char **sorted_syms, size_t cnt, unsigned long *addrs);
>
> quick question.. is it ok if it stays in kalsyms.c object?
I think if this is for the ftrace API, I think it should be in the ftrace.c, and
it can remove unneeded #ifdefs in C code.
>
> so we don't need to expose kallsyms_on_each_symbol,
> and it stays in 'kalsyms' place
We don't need to expose it to modules, but just make it into a global scope.
I don't think that doesn't cause a problem.
Thank you,
>
> jirka
>
>
>
> diff --git a/include/linux/kallsyms.h b/include/linux/kallsyms.h
> index ce1bd2fbf23e..177e0b13c8c5 100644
> --- a/include/linux/kallsyms.h
> +++ b/include/linux/kallsyms.h
> @@ -72,6 +72,7 @@ int kallsyms_on_each_symbol(int (*fn)(void *, const char *, struct module *,
> #ifdef CONFIG_KALLSYMS
> /* Lookup the address for a symbol. Returns 0 if not found. */
> unsigned long kallsyms_lookup_name(const char *name);
> +int ftrace_lookup_symbols(const char **sorted_syms, size_t cnt, unsigned long *addrs);
>
> extern int kallsyms_lookup_size_offset(unsigned long addr,
> unsigned long *symbolsize,
> @@ -103,6 +104,11 @@ static inline unsigned long kallsyms_lookup_name(const char *name)
> return 0;
> }
>
> +static inline int ftrace_lookup_symbols(const char **sorted_syms, size_t cnt, unsigned long *addrs);
> +{
> + return -ERANGE;
> +}
> +
> static inline int kallsyms_lookup_size_offset(unsigned long addr,
> unsigned long *symbolsize,
> unsigned long *offset)
> diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
> index 79f2eb617a62..1e7136a765a9 100644
> --- a/kernel/kallsyms.c
> +++ b/kernel/kallsyms.c
> @@ -29,6 +29,7 @@
> #include <linux/compiler.h>
> #include <linux/module.h>
> #include <linux/kernel.h>
> +#include <linux/bsearch.h>
>
> /*
> * These will be re-linked against their real values
> @@ -228,7 +229,7 @@ unsigned long kallsyms_lookup_name(const char *name)
> return module_kallsyms_lookup_name(name);
> }
>
> -#ifdef CONFIG_LIVEPATCH
> +#if defined(CONFIG_LIVEPATCH) || defined(CONFIG_FPROBE)
> /*
> * Iterate over all symbols in vmlinux. For symbols from modules use
> * module_kallsyms_on_each_symbol instead.
> @@ -572,6 +573,73 @@ int sprint_backtrace_build_id(char *buffer, unsigned long address)
> return __sprint_symbol(buffer, address, -1, 1, 1);
> }
>
> +#ifdef CONFIG_FPROBE
> +static int symbols_cmp(const void *a, const void *b)
> +{
> + const char **str_a = (const char **) a;
> + const char **str_b = (const char **) b;
> +
> + return strcmp(*str_a, *str_b);
> +}
> +
> +struct kallsyms_data {
> + unsigned long *addrs;
> + const char **syms;
> + size_t cnt;
> + size_t found;
> +};
> +
> +static int kallsyms_callback(void *data, const char *name,
> + struct module *mod, unsigned long addr)
> +{
> + struct kallsyms_data *args = data;
> +
> + if (!bsearch(&name, args->syms, args->cnt, sizeof(*args->syms), symbols_cmp))
> + return 0;
> +
> + addr = ftrace_location(addr);
> + if (!addr)
> + return 0;
> +
> + args->addrs[args->found++] = addr;
> + return args->found == args->cnt ? 1 : 0;
> +}
> +
> +/**
> + * ftrace_lookup_symbols - Lookup addresses for array of symbols
> + *
> + * @sorted_syms: array of symbols pointers symbols to resolve,
> + * must be alphabetically sorted
> + * @cnt: number of symbols/addresses in @syms/@addrs arrays
> + * @addrs: array for storing resulting addresses
> + *
> + * This function looks up addresses for array of symbols provided in
> + * @syms array (must be alphabetically sorted) and stores them in
> + * @addrs array, which needs to be big enough to store at least @cnt
> + * addresses.
> + *
> + * This function returns 0 if all provided symbols are found,
> + * -ESRCH otherwise.
> + */
> +int ftrace_lookup_symbols(const char **sorted_syms, size_t cnt, unsigned long *addrs)
> +{
> + struct kallsyms_data args;
> +
> + args.addrs = addrs;
> + args.syms = sorted_syms;
> + args.cnt = cnt;
> + args.found = 0;
> + kallsyms_on_each_symbol(kallsyms_callback, &args);
> +
> + return args.found == args.cnt ? 0 : -ESRCH;
> +}
> +#else
> +int ftrace_lookup_symbols(const char **sorted_syms, size_t cnt, unsigned long *addrs)
> +{
> + return -ERANGE;
> +}
> +#endif /* CONFIG_FPROBE */
> +
> /* To avoid using get_symbol_offset for every symbol, we carry prefix along. */
> struct kallsym_iter {
> loff_t pos;
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH v9 00/32] virtio pci support VIRTIO_F_RING_RESET (refactor vring)
From: Xuan Zhuo @ 2022-04-26 9:59 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: virtualization, Jeff Dike, Richard Weinberger, Anton Ivanov,
Jason Wang, David S. Miller, Jakub Kicinski, Hans de Goede,
Mark Gross, Vadim Pasternak, Bjorn Andersson, Mathieu Poirier,
Cornelia Huck, Halil Pasic, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Alexander Gordeev, Sven Schnelle,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Johannes Berg, Vincent Whitchurch, linux-um,
netdev, platform-driver-x86, linux-remoteproc, linux-s390, kvm,
bpf
In-Reply-To: <20220426055423-mutt-send-email-mst@kernel.org>
On Tue, 26 Apr 2022 05:55:41 -0400, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Wed, Apr 06, 2022 at 11:43:14AM +0800, Xuan Zhuo wrote:
> > The virtio spec already supports the virtio queue reset function. This patch set
> > is to add this function to the kernel. The relevant virtio spec information is
> > here:
> >
> > https://github.com/oasis-tcs/virtio-spec/issues/124
> >
> > Also regarding MMIO support for queue reset, I plan to support it after this
> > patch is passed.
>
> Regarding the spec, there's now an issue proposing
> some changes to the interface. What do you think about that
> proposal? Could you respond on that thread on the virtio TC mailing list?
I have read that thread. And also asked some questions. I will follow that
thread.
Grateful.
>
>
> > This patch set implements the refactoring of vring. Finally, the
> > virtuque_resize() interface is provided based on the reset function of the
> > transport layer.
> >
> > Test environment:
> > Host: 4.19.91
> > Qemu: QEMU emulator version 6.2.50 (with vq reset support)
> > Test Cmd: ethtool -G eth1 rx $1 tx $2; ethtool -g eth1
> >
> > The default is split mode, modify Qemu virtio-net to add PACKED feature to test
> > packed mode.
> >
> > Qemu code:
> > https://github.com/fengidri/qemu/compare/89f3bfa3265554d1d591ee4d7f1197b6e3397e84...master
> >
> > In order to simplify the review of this patch set, the function of reusing
> > the old buffers after resize will be introduced in subsequent patch sets.
> >
> > Please review. Thanks.
> >
> > v9:
> > 1. Provide a virtqueue_resize() interface directly
> > 2. A patch set including vring resize, virtio pci reset, virtio-net resize
> > 3. No more separate structs
> >
> > v8:
> > 1. Provide a virtqueue_reset() interface directly
> > 2. Split the two patch sets, this is the first part
> > 3. Add independent allocation helper for allocating state, extra
> >
> > v7:
> > 1. fix #6 subject typo
> > 2. fix #6 ring_size_in_bytes is uninitialized
> > 3. check by: make W=12
> >
> > v6:
> > 1. virtio_pci: use synchronize_irq(irq) to sync the irq callbacks
> > 2. Introduce virtqueue_reset_vring() to implement the reset of vring during
> > the reset process. May use the old vring if num of the vq not change.
> > 3. find_vqs() support sizes to special the max size of each vq
> >
> > v5:
> > 1. add virtio-net support set_ringparam
> >
> > v4:
> > 1. just the code of virtio, without virtio-net
> > 2. Performing reset on a queue is divided into these steps:
> > 1. reset_vq: reset one vq
> > 2. recycle the buffer from vq by virtqueue_detach_unused_buf()
> > 3. release the ring of the vq by vring_release_virtqueue()
> > 4. enable_reset_vq: re-enable the reset queue
> > 3. Simplify the parameters of enable_reset_vq()
> > 4. add container structures for virtio_pci_common_cfg
> >
> > v3:
> > 1. keep vq, irq unreleased
> >
> > Xuan Zhuo (32):
> > virtio: add helper virtqueue_get_vring_max_size()
> > virtio: struct virtio_config_ops add callbacks for queue_reset
> > virtio_ring: update the document of the virtqueue_detach_unused_buf
> > for queue reset
> > virtio_ring: remove the arg vq of vring_alloc_desc_extra()
> > virtio_ring: extract the logic of freeing vring
> > virtio_ring: split: extract the logic of alloc queue
> > virtio_ring: split: extract the logic of alloc state and extra
> > virtio_ring: split: extract the logic of attach vring
> > virtio_ring: split: extract the logic of vq init
> > virtio_ring: split: introduce virtqueue_reinit_split()
> > virtio_ring: split: introduce virtqueue_resize_split()
> > virtio_ring: packed: extract the logic of alloc queue
> > virtio_ring: packed: extract the logic of alloc state and extra
> > virtio_ring: packed: extract the logic of attach vring
> > virtio_ring: packed: extract the logic of vq init
> > virtio_ring: packed: introduce virtqueue_reinit_packed()
> > virtio_ring: packed: introduce virtqueue_resize_packed()
> > virtio_ring: introduce virtqueue_resize()
> > virtio_pci: struct virtio_pci_common_cfg add queue_notify_data
> > virtio: queue_reset: add VIRTIO_F_RING_RESET
> > virtio_pci: queue_reset: update struct virtio_pci_common_cfg and
> > option functions
> > virtio_pci: queue_reset: extract the logic of active vq for modern pci
> > virtio_pci: queue_reset: support VIRTIO_F_RING_RESET
> > virtio: find_vqs() add arg sizes
> > virtio_pci: support the arg sizes of find_vqs()
> > virtio_mmio: support the arg sizes of find_vqs()
> > virtio: add helper virtio_find_vqs_ctx_size()
> > virtio_net: set the default max ring size by find_vqs()
> > virtio_net: get ringparam by virtqueue_get_vring_max_size()
> > virtio_net: split free_unused_bufs()
> > virtio_net: support rx/tx queue resize
> > virtio_net: support set_ringparam
> >
> > arch/um/drivers/virtio_uml.c | 3 +-
> > drivers/net/virtio_net.c | 219 +++++++-
> > drivers/platform/mellanox/mlxbf-tmfifo.c | 3 +
> > drivers/remoteproc/remoteproc_virtio.c | 3 +
> > drivers/s390/virtio/virtio_ccw.c | 4 +
> > drivers/virtio/virtio_mmio.c | 11 +-
> > drivers/virtio/virtio_pci_common.c | 28 +-
> > drivers/virtio/virtio_pci_common.h | 3 +-
> > drivers/virtio/virtio_pci_legacy.c | 8 +-
> > drivers/virtio/virtio_pci_modern.c | 149 +++++-
> > drivers/virtio/virtio_pci_modern_dev.c | 36 ++
> > drivers/virtio/virtio_ring.c | 626 ++++++++++++++++++-----
> > drivers/virtio/virtio_vdpa.c | 3 +
> > include/linux/virtio.h | 6 +
> > include/linux/virtio_config.h | 38 +-
> > include/linux/virtio_pci_modern.h | 2 +
> > include/uapi/linux/virtio_config.h | 7 +-
> > include/uapi/linux/virtio_pci.h | 14 +
> > 18 files changed, 964 insertions(+), 199 deletions(-)
> >
> > --
> > 2.31.0
>
^ permalink raw reply
* Re: [PATCH] net: phy: marvell10g: fix return value on error
From: patchwork-bot+netdevbpf @ 2022-04-26 10:00 UTC (permalink / raw)
To: Baruch Siach; +Cc: linux, kabel, netdev, baruch.siach
In-Reply-To: <f47cb031aeae873bb008ba35001607304a171a20.1650868058.git.baruch@tkos.co.il>
Hello:
This patch was applied to netdev/net.git (master)
by Paolo Abeni <pabeni@redhat.com>:
On Mon, 25 Apr 2022 09:27:38 +0300 you wrote:
> From: Baruch Siach <baruch.siach@siklu.com>
>
> Return back the error value that we get from phy_read_mmd().
>
> Fixes: c84786fa8f91 ("net: phy: marvell10g: read copper results from CSSR1")
> Signed-off-by: Baruch Siach <baruch.siach@siklu.com>
>
> [...]
Here is the summary with links:
- net: phy: marvell10g: fix return value on error
https://git.kernel.org/netdev/net/c/0ed9704b660b
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v9 00/32] virtio pci support VIRTIO_F_RING_RESET (refactor vring)
From: Michael S. Tsirkin @ 2022-04-26 9:55 UTC (permalink / raw)
To: Xuan Zhuo
Cc: virtualization, Jeff Dike, Richard Weinberger, Anton Ivanov,
Jason Wang, David S. Miller, Jakub Kicinski, Hans de Goede,
Mark Gross, Vadim Pasternak, Bjorn Andersson, Mathieu Poirier,
Cornelia Huck, Halil Pasic, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Alexander Gordeev, Sven Schnelle,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Johannes Berg, Vincent Whitchurch, linux-um,
netdev, platform-driver-x86, linux-remoteproc, linux-s390, kvm,
bpf
In-Reply-To: <20220406034346.74409-1-xuanzhuo@linux.alibaba.com>
On Wed, Apr 06, 2022 at 11:43:14AM +0800, Xuan Zhuo wrote:
> The virtio spec already supports the virtio queue reset function. This patch set
> is to add this function to the kernel. The relevant virtio spec information is
> here:
>
> https://github.com/oasis-tcs/virtio-spec/issues/124
>
> Also regarding MMIO support for queue reset, I plan to support it after this
> patch is passed.
Regarding the spec, there's now an issue proposing
some changes to the interface. What do you think about that
proposal? Could you respond on that thread on the virtio TC mailing list?
> This patch set implements the refactoring of vring. Finally, the
> virtuque_resize() interface is provided based on the reset function of the
> transport layer.
>
> Test environment:
> Host: 4.19.91
> Qemu: QEMU emulator version 6.2.50 (with vq reset support)
> Test Cmd: ethtool -G eth1 rx $1 tx $2; ethtool -g eth1
>
> The default is split mode, modify Qemu virtio-net to add PACKED feature to test
> packed mode.
>
> Qemu code:
> https://github.com/fengidri/qemu/compare/89f3bfa3265554d1d591ee4d7f1197b6e3397e84...master
>
> In order to simplify the review of this patch set, the function of reusing
> the old buffers after resize will be introduced in subsequent patch sets.
>
> Please review. Thanks.
>
> v9:
> 1. Provide a virtqueue_resize() interface directly
> 2. A patch set including vring resize, virtio pci reset, virtio-net resize
> 3. No more separate structs
>
> v8:
> 1. Provide a virtqueue_reset() interface directly
> 2. Split the two patch sets, this is the first part
> 3. Add independent allocation helper for allocating state, extra
>
> v7:
> 1. fix #6 subject typo
> 2. fix #6 ring_size_in_bytes is uninitialized
> 3. check by: make W=12
>
> v6:
> 1. virtio_pci: use synchronize_irq(irq) to sync the irq callbacks
> 2. Introduce virtqueue_reset_vring() to implement the reset of vring during
> the reset process. May use the old vring if num of the vq not change.
> 3. find_vqs() support sizes to special the max size of each vq
>
> v5:
> 1. add virtio-net support set_ringparam
>
> v4:
> 1. just the code of virtio, without virtio-net
> 2. Performing reset on a queue is divided into these steps:
> 1. reset_vq: reset one vq
> 2. recycle the buffer from vq by virtqueue_detach_unused_buf()
> 3. release the ring of the vq by vring_release_virtqueue()
> 4. enable_reset_vq: re-enable the reset queue
> 3. Simplify the parameters of enable_reset_vq()
> 4. add container structures for virtio_pci_common_cfg
>
> v3:
> 1. keep vq, irq unreleased
>
> Xuan Zhuo (32):
> virtio: add helper virtqueue_get_vring_max_size()
> virtio: struct virtio_config_ops add callbacks for queue_reset
> virtio_ring: update the document of the virtqueue_detach_unused_buf
> for queue reset
> virtio_ring: remove the arg vq of vring_alloc_desc_extra()
> virtio_ring: extract the logic of freeing vring
> virtio_ring: split: extract the logic of alloc queue
> virtio_ring: split: extract the logic of alloc state and extra
> virtio_ring: split: extract the logic of attach vring
> virtio_ring: split: extract the logic of vq init
> virtio_ring: split: introduce virtqueue_reinit_split()
> virtio_ring: split: introduce virtqueue_resize_split()
> virtio_ring: packed: extract the logic of alloc queue
> virtio_ring: packed: extract the logic of alloc state and extra
> virtio_ring: packed: extract the logic of attach vring
> virtio_ring: packed: extract the logic of vq init
> virtio_ring: packed: introduce virtqueue_reinit_packed()
> virtio_ring: packed: introduce virtqueue_resize_packed()
> virtio_ring: introduce virtqueue_resize()
> virtio_pci: struct virtio_pci_common_cfg add queue_notify_data
> virtio: queue_reset: add VIRTIO_F_RING_RESET
> virtio_pci: queue_reset: update struct virtio_pci_common_cfg and
> option functions
> virtio_pci: queue_reset: extract the logic of active vq for modern pci
> virtio_pci: queue_reset: support VIRTIO_F_RING_RESET
> virtio: find_vqs() add arg sizes
> virtio_pci: support the arg sizes of find_vqs()
> virtio_mmio: support the arg sizes of find_vqs()
> virtio: add helper virtio_find_vqs_ctx_size()
> virtio_net: set the default max ring size by find_vqs()
> virtio_net: get ringparam by virtqueue_get_vring_max_size()
> virtio_net: split free_unused_bufs()
> virtio_net: support rx/tx queue resize
> virtio_net: support set_ringparam
>
> arch/um/drivers/virtio_uml.c | 3 +-
> drivers/net/virtio_net.c | 219 +++++++-
> drivers/platform/mellanox/mlxbf-tmfifo.c | 3 +
> drivers/remoteproc/remoteproc_virtio.c | 3 +
> drivers/s390/virtio/virtio_ccw.c | 4 +
> drivers/virtio/virtio_mmio.c | 11 +-
> drivers/virtio/virtio_pci_common.c | 28 +-
> drivers/virtio/virtio_pci_common.h | 3 +-
> drivers/virtio/virtio_pci_legacy.c | 8 +-
> drivers/virtio/virtio_pci_modern.c | 149 +++++-
> drivers/virtio/virtio_pci_modern_dev.c | 36 ++
> drivers/virtio/virtio_ring.c | 626 ++++++++++++++++++-----
> drivers/virtio/virtio_vdpa.c | 3 +
> include/linux/virtio.h | 6 +
> include/linux/virtio_config.h | 38 +-
> include/linux/virtio_pci_modern.h | 2 +
> include/uapi/linux/virtio_config.h | 7 +-
> include/uapi/linux/virtio_pci.h | 14 +
> 18 files changed, 964 insertions(+), 199 deletions(-)
>
> --
> 2.31.0
^ permalink raw reply
* Re: [PATCH] batman-adv: remove unnecessary type castings
From: yuzhe @ 2022-04-26 9:52 UTC (permalink / raw)
To: Sven Eckelmann, mareklindner, sw, a, davem, kuba, pabeni
Cc: b.a.t.m.a.n, netdev, linux-kernel, liqiong, kernel-janitors
In-Reply-To: <2133162.nbW41nx31j@ripper>
I agree, this patch is better. And I have tested, no sparse warning anymore.
Thank your for your help.
在 2022/4/25 20:50, Sven Eckelmann 写道:
>
> On Monday, 25 April 2022 13:36:35 CEST Yu Zhe wrote:
>
>>
>> remove unnecessary void* type castings.
>>
>> Signed-off-by: Yu Zhe<yuzhe@nfschina.com>
>> ---
>> net/batman-adv/translation-table.c | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>
> If you send a second version then please use `git format-patch -v2 ...` to
> format the patch. Now it looks in patchworks like you've resent the first
> version again. And please also add a little changelog after "---" which
> explains what you've changed. It is trivial in this little patch but still
> might be useful.
>
> Regarding the patch: Now you've removed bridge_loop_avoidance.c +
> batadv_choose_tt instead of fixing your patch. I would really prefer this
> patch version:
>
> https://git.open-mesh.org/linux-merge.git/commitdiff/8864d2fcf04385cabb8c8bb159f1f2ba5790cf71
>
> Kind regards,
> Sven
>
^ permalink raw reply
* Re: [PATCH v2] net: usb: qmi_wwan: add support for Sierra Wireless EM7590
From: patchwork-bot+netdevbpf @ 2022-04-26 9:50 UTC (permalink / raw)
To: Ethan Yang
Cc: bjorn, davem, kuba, pabeni, netdev, linux-usb, linux-kernel,
gchiang, etyang
In-Reply-To: <20220425054028.5444-1-etyang@sierrawireless.com>
Hello:
This patch was applied to netdev/net-next.git (master)
by Paolo Abeni <pabeni@redhat.com>:
On Mon, 25 Apr 2022 13:40:28 +0800 you wrote:
> From: Ethan Yang <etyang@sierrawireless.com>
>
> add support for Sierra Wireless EM7590 0xc081 composition.
>
> Signed-off-by: Ethan Yang <etyang@sierrawireless.com>
> ---
> drivers/net/usb/qmi_wwan.c | 1 +
> 1 file changed, 1 insertion(+)
Here is the summary with links:
- [v2] net: usb: qmi_wwan: add support for Sierra Wireless EM7590
https://git.kernel.org/netdev/net-next/c/561215482cc6
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH RFC 4/5] net/tls: Add support for PF_TLSH (a TLS handshake listener)
From: Hannes Reinecke @ 2022-04-26 9:43 UTC (permalink / raw)
To: Jakub Kicinski, Chuck Lever
Cc: netdev, linux-nfs, linux-nvme, linux-cifs, linux-fsdevel, ak,
borisp, simo
In-Reply-To: <20220425101459.15484d17@kernel.org>
On 4/25/22 19:14, Jakub Kicinski wrote:
> On Mon, 18 Apr 2022 12:49:50 -0400 Chuck Lever wrote:
>> In-kernel TLS consumers need a way to perform a TLS handshake. In
>> the absence of a handshake implementation in the kernel itself, a
>> mechanism to perform the handshake in user space, using an existing
>> TLS handshake library, is necessary.
>>
>> I've designed a way to pass a connected kernel socket endpoint to
>> user space using the traditional listen/accept mechanism. accept(2)
>> gives us a well-understood way to materialize a socket endpoint as a
>> normal file descriptor in a specific user space process. Like any
>> open socket descriptor, the accepted FD can then be passed to a
>> library such as openSSL to perform a TLS handshake.
>>
>> This prototype currently handles only initiating client-side TLS
>> handshakes. Server-side handshakes and key renegotiation are left
>> to do.
>>
>> Security Considerations
>> ~~~~~~~~ ~~~~~~~~~~~~~~
>>
>> This prototype is net-namespace aware.
>>
>> The kernel has no mechanism to attest that the listening user space
>> agent is trustworthy.
>>
>> Currently the prototype does not handle multiple listeners that
>> overlap -- multiple listeners in the same net namespace that have
>> overlapping bind addresses.
>
> Create the socket in user space, do all the handshakes you need there
> and then pass it to the kernel. This is how NBD + TLS works. Scales
> better and requires much less kernel code.
>
But we can't, as the existing mechanisms (at least for NVMe) creates the
socket in-kernel.
Having to create the socket in userspace would require a completely new
interface for nvme and will not be backwards compatible.
Not to mention having to rework the nvme driver to accept sockets from
userspace instead of creating them internally.
With this approach we can keep existing infrastructure, and can get a
common implementation for either transport.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer
^ permalink raw reply
* Re: [RFC PATCH v4 10/15] seltest/landlock: add tests for bind() hooks
From: Konstantin Meskhidze @ 2022-04-26 9:35 UTC (permalink / raw)
To: Mickaël Salaün
Cc: willemdebruijn.kernel, linux-security-module, netdev,
netfilter-devel, yusongping, artem.kuzin, anton.sirazetdinov
In-Reply-To: <0b0ddf78-12fa-ab52-ba3a-c819ed9d2ccd@digikod.net>
4/8/2022 7:41 PM, Mickaël Salaün пишет:
>
> On 06/04/2022 16:12, Konstantin Meskhidze wrote:
>>
>>
>> 4/4/2022 12:44 PM, Mickaël Salaün пишет:
>>>
>>> On 04/04/2022 10:28, Konstantin Meskhidze wrote:
>>>>
>>>>
>>>> 4/1/2022 7:52 PM, Mickaël Salaün пишет:
>>>
>>> [...]
>>>
>>>>>> +static int create_socket(struct __test_metadata *const _metadata)
>>>>>> +{
>>>>>> +
>>>>>> + int sockfd;
>>>>>> +
>>>>>> + sockfd = socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, 0);
>>>>>> + ASSERT_LE(0, sockfd);
>>>>>> + /* Allows to reuse of local address */
>>>>>> + ASSERT_EQ(0, setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR,
>>>>>> &one, sizeof(one)));
>>>>>
>>>>> Why is it required?
>>>>
>>>> Without SO_REUSEADDR there is an error that a socket's port is in
>>>> use.
>>>
>>> I'm sure there is, but why is this port reused? I think this means
>>> that there is an issue in the tests and that could hide potential
>>> issue with the tests (and then with the kernel code). Could you
>>> investigate and find the problem? This would make these tests reliable.
>> The next scenario is possible here:
>> "In order for a network connection to close, both ends have to send
>> FIN (final) packets, which indicate they will not send any additional
>> data, and both ends must ACK (acknowledge) each other's FIN packets.
>> The FIN packets are initiated by the application performing a close(),
>> a shutdown(), or an exit(). The ACKs are handled by the kernel after
>> the close() has completed. Because of this, it is possible for the
>> process to complete before the kernel has released the associated
>> network resource, and this port cannot be bound to another process
>> until the kernel has decided that it is done."
>> https://hea-www.harvard.edu/~fine/Tech/addrinuse.html.
>>
>> So in this case we have busy port in network selfttest and one of the
>> solution is to set SO_REUSEADDR socket option, "which explicitly
>> allows a process to bind to a port which remains in TIME_WAIT (it
>> still only allows a single process to be bound to that port). This is
>> the both the simplest and the most effective option for reducing the
>> "address already in use" error".
>
> In know what this option does, but I'm wondering what do you need it for
> these tests: which specific line requires it and why? Isn't it a side
> effect of running partial tests? I'm worried that this hides some issues
> in the tests that may make them flaky.
>
I need it cause we have a possibility here that process (launching
tests) has to wait the kernel's releasing the associated network socket
after closing it.
>
>>>
>>> Without removing the need to find this issue, the next series should
>>> use a network namespace per test, which will confine such issue from
>>> other tests and the host.
>>
>> So there are 2 options here:
>> 1. Using SO_REUSEADDR option
>> 2. Using network namespace.
>>
>> I prefer the first option - "the simplest and the most effective one"
>
> If SO_REUSEADDR is really required (and justified), then it should be
> used. Either it is required or not, we should use a dedicated network
> namespace for each test anyway. This enables to not mess with the host
> and not be impacted by it neither (e.g. if some process already use such
> ports).
>
Ok. I update the code.
>
>>
>>>
>>> [...]
> .
^ permalink raw reply
* Re: [PATCHv2 net-next] net/af_packet: add VLAN support for AF_PACKET SOCK_RAW GSO
From: patchwork-bot+netdevbpf @ 2022-04-26 9:30 UTC (permalink / raw)
To: Hangbin Liu
Cc: netdev, mst, jasowang, davem, kuba, pabeni, maximmi,
WillemdeBruijnwillemdebruijn.kernel, bnemeth, mpattric, edumazet
In-Reply-To: <20220425014502.985464-1-liuhangbin@gmail.com>
Hello:
This patch was applied to netdev/net-next.git (master)
by Paolo Abeni <pabeni@redhat.com>:
On Mon, 25 Apr 2022 09:45:02 +0800 you wrote:
> Currently, the kernel drops GSO VLAN tagged packet if it's created with
> socket(AF_PACKET, SOCK_RAW, 0) plus virtio_net_hdr.
>
> The reason is AF_PACKET doesn't adjust the skb network header if there is
> a VLAN tag. Then after virtio_net_hdr_set_proto() called, the skb->protocol
> will be set to ETH_P_IP/IPv6. And in later inet/ipv6_gso_segment() the skb
> is dropped as network header position is invalid.
>
> [...]
Here is the summary with links:
- [PATCHv2,net-next] net/af_packet: add VLAN support for AF_PACKET SOCK_RAW GSO
https://git.kernel.org/netdev/net-next/c/dfed913e8b55
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [Patch bpf-next v1 0/4] sockmap: some performance optimizations
From: Jakub Sitnicki @ 2022-04-26 9:27 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, Cong Wang
In-Reply-To: <20220410161042.183540-1-xiyou.wangcong@gmail.com>
On Sun, Apr 10, 2022 at 09:10 AM -07, Cong Wang wrote:
> From: Cong Wang <cong.wang@bytedance.com>
>
> This patchset contains two optimizations for sockmap. The first one
> eliminates a skb_clone() and the second one eliminates a memset(). After
> this patchset, the throughput of UDP transmission via sockmap gets
> improved by 61%.
That's a pretty exact number ;-)
Is this a measurement from metrics collected from a production
enviroment, or were you using a synthetic benchmark?
If it was the latter, would you be able to share the tooling?
I'm looking at extending the fio net engine with sockmap support, so
that we can have a reference benchmark. It would be helpful to see which
sockmap setup scenarios are worth focusing on.
Thanks,
Jakub
^ permalink raw reply
* Re: [RFC PATCH] Bluetooth: core: Allow bind HCI socket user channel when HCI is UP.
From: Vasyl Vavrychuk @ 2022-04-26 9:24 UTC (permalink / raw)
To: Marcel Holtmann, Vasyl Vavrychuk
Cc: LKML, open list:NETWORKING [GENERAL], BlueZ, Johan Hedberg,
Luiz Augusto von Dentz, David S. Miller, Jakub Kicinski,
Paolo Abeni
In-Reply-To: <9EA1D51C-D316-49CF-A7F8-765C58C18880@holtmann.org>
Hi, Marcel,
On 4/22/2022 12:20 PM, Marcel Holtmann wrote:
> Hi Vasyl,
>
>> This is needed for user-space to ensure that HCI init scheduled from
>> hci_register_dev is completed.
>>
>> Function hci_register_dev queues power_on workqueue which will run
>> hci_power_on > hci_dev_do_open. Function hci_dev_do_open sets HCI_INIT
>> for some time.
>>
>> It is not allowed to bind to HCI socket user channel when HCI_INIT is
>> set. As result, bind might fail when user-space program is run early
>> enough during boot.
>>
>> Now, user-space program can first issue HCIDEVUP ioctl to ensure HCI
>> init scheduled at hci_register_dev was completed.
>>
>> Signed-off-by: Vasyl Vavrychuk <vasyl.vavrychuk@opensynergy.com>
>> ---
>> net/bluetooth/hci_sock.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
>> index 33b3c0ffc339..c98de809f856 100644
>> --- a/net/bluetooth/hci_sock.c
>> +++ b/net/bluetooth/hci_sock.c
>> @@ -1194,9 +1194,7 @@ static int hci_sock_bind(struct socket *sock, struct sockaddr *addr,
>>
>> if (test_bit(HCI_INIT, &hdev->flags) ||
>> hci_dev_test_flag(hdev, HCI_SETUP) ||
>> - hci_dev_test_flag(hdev, HCI_CONFIG) ||
>> - (!hci_dev_test_flag(hdev, HCI_AUTO_OFF) &&
>> - test_bit(HCI_UP, &hdev->flags))) {
>> + hci_dev_test_flag(hdev, HCI_CONFIG)) {
>> err = -EBUSY;
>> hci_dev_put(hdev);
>> goto done;
>
> I am not following the reasoning here. It is true that the device has to run init before you can do something with it. From mgmt interface your device will only be announced when it is really ready.
Sorry, I am not familiar with mgmt interface. I obtain device using
HCIGETDEVLIST.
BTW. I have pushed related patch [1]. Comparing to this patch, [1] is
less intrusive since it does not effect user-space semantics.
Patch [1] allows to ensure that device is not in HCI_INIT state by running
hciconfig hci0 down
This will either wait for HCI_INIT complete and then powers HCI down, or
cancels pending power_on.
If we apply [1], we can still consider an optimization to allow binding
during HCI_INIT since this optimization will allow me to ommit extra
hciconfig hci0 down
[1]:
https://lore.kernel.org/linux-bluetooth/20220426081823.21557-1-vasyl.vavrychuk@opensynergy.com/T/#u
Kind regards,
Vasyl
^ permalink raw reply
* Re: [PATCH iproute2-next v2 2/2] f_flower: Check args with num_of_vlans
From: Boris Sukholitko @ 2022-04-26 9:17 UTC (permalink / raw)
To: David Ahern
Cc: netdev, David S . Miller, Jakub Kicinski, Jamal Hadi Salim,
Cong Wang, Jiri Pirko, Gustavo A . R . Silva, Vladimir Oltean,
Eric Dumazet, zhang kai, Yoshiki Komachi, Ilya Lifshits
In-Reply-To: <20220426021111.GA25966@u2004-local>
[-- Attachment #1: Type: text/plain, Size: 576 bytes --]
On Mon, Apr 25, 2022 at 08:11:11PM -0600, David Ahern wrote:
> On Tue, Apr 12, 2022 at 01:03:43PM +0300, Boris Sukholitko wrote:
> > Having more than one vlan allows matching on the vlan tag parameters.
> > This patch changes vlan key validation to take number of vlan tags into
> > account.
> >
> > Signed-off-by: Boris Sukholitko <boris.sukholitko@broadcom.com>
> > ---
> > tc/f_flower.c | 41 +++++++++++++++++++++++------------------
> > 1 file changed, 23 insertions(+), 18 deletions(-)
> >
>
> does not apply cleanly to iproute2-next
Rebased in v3.
Thanks,
Boris.
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4221 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v4 03/15] landlock: landlock_find/insert_rule refactoring (TCP port 0)
From: Konstantin Meskhidze @ 2022-04-26 9:15 UTC (permalink / raw)
To: Mickaël Salaün, willemdebruijn.kernel
Cc: linux-security-module, netdev, netfilter-devel, yusongping,
artem.kuzin, anton.sirazetdinov
In-Reply-To: <0e5afeaf-0569-d0b5-b701-0f611d103732@digikod.net>
4/12/2022 2:07 PM, Mickaël Salaün пишет:
>
> On 23/03/2022 09:41, Konstantin Meskhidze wrote:
>>
>>
>> 3/22/2022 4:24 PM, Mickaël Salaün пишет:
>>>
>
> [...]
>>> The remaining question is: should we need to accept 0 as a valid TCP
>>> port? Can it be used? How does the kernel handle it?
>>
>> I agree that must be a check for port 0 in add_rule_net_service(),
>> cause unlike most port numbers, port 0 is a reserved port in TCP/IP
>> networking, meaning that it should not be used in TCP or UDP messages.
>> Also network traffic sent across the internet to hosts listening on
>> port 0 might be generated from network attackers or accidentally by
>> applications programmed incorrectly.
>> Source: https://www.lifewire.com/port-0-in-tcp-and-udp-818145
>
> OK, so denying this port by default without a way to allow it should not
> be an issue. I guess an -EINVAL error would make sense when trying to
> allow this port. This should be documented in a comment (with a link to
> the RFC/section) and a dedicated test should check that behavior.
>
> What is the behavior of firewalls (e.g. Netfiler) when trying to filter
> port 0?
To be honest I don't know. I'm trying to check it.
>
> This doesn't seem to be settle though:
> https://www.austingroupbugs.net/view.php?id=1068
>
> Interesting article:
> https://z3r0trust.medium.com/socket-programming-the-bizarre-tcp-ip-port-0-saga-fcfbc0e0a276
Thanks. I will check.
>
> .
^ permalink raw reply
* [PATCH iproute2-next v3 0/2] f_flower: match on the number of vlan tags
From: Boris Sukholitko @ 2022-04-26 9:14 UTC (permalink / raw)
To: netdev, David Ahern; +Cc: Ilya Lifshits, Boris Sukholitko
[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]
Hi,
Our customers in the fiber telecom world have network configurations
where they would like to control their traffic according to the number
of tags appearing in the packet.
For example, TR247 GPON conformance test suite specification mostly
talks about untagged, single, double tagged packets and gives lax
guidelines on the vlan protocol vs. number of vlan tags.
This is different from the common IT networks where 802.1Q and 802.1ad
protocols are usually describe single and double tagged packet. GPON
configurations that we work with have arbitrary mix the above protocols
and number of vlan tags in the packet.
The following patch series implement number of vlans flower filter. They
add num_of_vlans flower filter as an alternative to vlan ethtype protocol
matching. The end result is that the following command becomes possible:
tc filter add dev eth1 ingress flower \
num_of_vlans 1 vlan_prio 5 action drop
Also, from our logs, we have redirect rules such that:
tc filter add dev $GPON ingress flower num_of_vlans $N \
action mirred egress redirect dev $DEV
where N can range from 0 to 3 and $DEV is the function of $N.
Also there are rules setting skb mark based on the number of vlans:
tc filter add dev $GPON ingress flower num_of_vlans $N vlan_prio \
$P action skbedit mark $M
Thanks,
Boris.
- v3: rebased to the latest iproute2-next
- v2: add missing f_flower subject prefix
Boris Sukholitko (2):
f_flower: Add num of vlans parameter
f_flower: Check args with num_of_vlans
tc/f_flower.c | 57 ++++++++++++++++++++++++++++++++++++---------------
1 file changed, 41 insertions(+), 16 deletions(-)
--
2.29.2
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4221 bytes --]
^ permalink raw reply
* [PATCH iproute2-next v3 2/2] f_flower: Check args with num_of_vlans
From: Boris Sukholitko @ 2022-04-26 9:14 UTC (permalink / raw)
To: netdev, David Ahern; +Cc: Ilya Lifshits, Boris Sukholitko
In-Reply-To: <20220426091417.7153-1-boris.sukholitko@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 4870 bytes --]
Having more than one vlan allows matching on the vlan tag parameters.
This patch changes vlan key validation to take number of vlan tags into
account.
Signed-off-by: Boris Sukholitko <boris.sukholitko@broadcom.com>
---
tc/f_flower.c | 41 +++++++++++++++++++++++------------------
1 file changed, 23 insertions(+), 18 deletions(-)
diff --git a/tc/f_flower.c b/tc/f_flower.c
index 25ffd295..fbb7042f 100644
--- a/tc/f_flower.c
+++ b/tc/f_flower.c
@@ -160,21 +160,23 @@ err:
return err;
}
-static bool eth_type_vlan(__be16 ethertype)
+static bool eth_type_vlan(__be16 ethertype, bool good_num_of_vlans)
{
return ethertype == htons(ETH_P_8021Q) ||
- ethertype == htons(ETH_P_8021AD);
+ ethertype == htons(ETH_P_8021AD) ||
+ good_num_of_vlans;
}
static int flower_parse_vlan_eth_type(char *str, __be16 eth_type, int type,
__be16 *p_vlan_eth_type,
- struct nlmsghdr *n)
+ struct nlmsghdr *n, bool good_num_of_vlans)
{
__be16 vlan_eth_type;
- if (!eth_type_vlan(eth_type)) {
- fprintf(stderr, "Can't set \"%s\" if ethertype isn't 802.1Q or 802.1AD\n",
- type == TCA_FLOWER_KEY_VLAN_ETH_TYPE ? "vlan_ethtype" : "cvlan_ethtype");
+ if (!eth_type_vlan(eth_type, good_num_of_vlans)) {
+ fprintf(stderr, "Can't set \"%s\" if ethertype isn't 802.1Q or 802.1AD and num_of_vlans %s\n",
+ type == TCA_FLOWER_KEY_VLAN_ETH_TYPE ? "vlan_ethtype" : "cvlan_ethtype",
+ type == TCA_FLOWER_KEY_VLAN_ETH_TYPE ? "is 0" : "less than 2");
return -1;
}
@@ -1425,6 +1427,7 @@ static int flower_parse_opt(struct filter_util *qu, char *handle,
__be16 tc_proto = TC_H_MIN(t->tcm_info);
__be16 eth_type = tc_proto;
__be16 vlan_ethtype = 0;
+ __u8 num_of_vlans = 0;
__u8 ip_proto = 0xff;
__u32 flags = 0;
__u32 mtf = 0;
@@ -1527,8 +1530,6 @@ static int flower_parse_opt(struct filter_util *qu, char *handle,
invarg("\"indev\" not a valid ifname", *argv);
addattrstrz(n, MAX_MSG, TCA_FLOWER_INDEV, *argv);
} else if (matches(*argv, "num_of_vlans") == 0) {
- __u8 num_of_vlans;
-
NEXT_ARG();
ret = get_u8(&num_of_vlans, *argv, 10);
if (ret < 0) {
@@ -1541,8 +1542,9 @@ static int flower_parse_opt(struct filter_util *qu, char *handle,
__u16 vid;
NEXT_ARG();
- if (!eth_type_vlan(tc_proto)) {
- fprintf(stderr, "Can't set \"vlan_id\" if ethertype isn't 802.1Q or 802.1AD\n");
+ if (!eth_type_vlan(tc_proto, num_of_vlans > 0)) {
+ fprintf(stderr, "Can't set \"vlan_id\" if ethertype isn't 802.1Q or 802.1AD"
+ " and num_of_vlans is 0\n");
return -1;
}
ret = get_u16(&vid, *argv, 10);
@@ -1555,8 +1557,9 @@ static int flower_parse_opt(struct filter_util *qu, char *handle,
__u8 vlan_prio;
NEXT_ARG();
- if (!eth_type_vlan(tc_proto)) {
- fprintf(stderr, "Can't set \"vlan_prio\" if ethertype isn't 802.1Q or 802.1AD\n");
+ if (!eth_type_vlan(tc_proto, num_of_vlans > 0)) {
+ fprintf(stderr, "Can't set \"vlan_prio\" if ethertype isn't 802.1Q or 802.1AD"
+ " and num_of_vlans is 0\n");
return -1;
}
ret = get_u8(&vlan_prio, *argv, 10);
@@ -1570,7 +1573,7 @@ static int flower_parse_opt(struct filter_util *qu, char *handle,
NEXT_ARG();
ret = flower_parse_vlan_eth_type(*argv, eth_type,
TCA_FLOWER_KEY_VLAN_ETH_TYPE,
- &vlan_ethtype, n);
+ &vlan_ethtype, n, num_of_vlans > 0);
if (ret < 0)
return -1;
/* get new ethtype for later parsing */
@@ -1579,8 +1582,9 @@ static int flower_parse_opt(struct filter_util *qu, char *handle,
__u16 vid;
NEXT_ARG();
- if (!eth_type_vlan(vlan_ethtype)) {
- fprintf(stderr, "Can't set \"cvlan_id\" if inner vlan ethertype isn't 802.1Q or 802.1AD\n");
+ if (!eth_type_vlan(vlan_ethtype, num_of_vlans > 1)) {
+ fprintf(stderr, "Can't set \"cvlan_id\" if inner vlan ethertype isn't 802.1Q or 802.1AD"
+ " and num_of_vlans is less than 2\n");
return -1;
}
ret = get_u16(&vid, *argv, 10);
@@ -1593,8 +1597,9 @@ static int flower_parse_opt(struct filter_util *qu, char *handle,
__u8 cvlan_prio;
NEXT_ARG();
- if (!eth_type_vlan(vlan_ethtype)) {
- fprintf(stderr, "Can't set \"cvlan_prio\" if inner vlan ethertype isn't 802.1Q or 802.1AD\n");
+ if (!eth_type_vlan(vlan_ethtype, num_of_vlans > 1)) {
+ fprintf(stderr, "Can't set \"cvlan_prio\" if inner vlan ethertype isn't 802.1Q or 802.1AD"
+ " and num_of_vlans is less than 2\n");
return -1;
}
ret = get_u8(&cvlan_prio, *argv, 10);
@@ -1609,7 +1614,7 @@ static int flower_parse_opt(struct filter_util *qu, char *handle,
/* get new ethtype for later parsing */
ret = flower_parse_vlan_eth_type(*argv, vlan_ethtype,
TCA_FLOWER_KEY_CVLAN_ETH_TYPE,
- ð_type, n);
+ ð_type, n, num_of_vlans > 1);
if (ret < 0)
return -1;
} else if (matches(*argv, "mpls") == 0) {
--
2.29.2
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4221 bytes --]
^ permalink raw reply related
* [PATCH iproute2-next v3 1/2] f_flower: Add num of vlans parameter
From: Boris Sukholitko @ 2022-04-26 9:14 UTC (permalink / raw)
To: netdev, David Ahern; +Cc: Ilya Lifshits, Boris Sukholitko
In-Reply-To: <20220426091417.7153-1-boris.sukholitko@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 2385 bytes --]
Our customers in the fiber telecom world have network configurations
where they would like to control their traffic according to the number
of tags appearing in the packet.
For example, TR247 GPON conformance test suite specification mostly
talks about untagged, single, double tagged packets and gives lax
guidelines on the vlan protocol vs. number of vlan tags.
This is different from the common IT networks where 802.1Q and 802.1ad
protocols are usually describe single and double tagged packet. GPON
configurations that we work with have arbitrary mix the above protocols
and number of vlan tags in the packet.
This patch adds num_of_vlans flower key and associated print and parse
routines. The following command becomes possible:
tc filter add dev eth1 ingress flower num_of_vlans 1 action drop
Signed-off-by: Boris Sukholitko <boris.sukholitko@broadcom.com>
---
tc/f_flower.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/tc/f_flower.c b/tc/f_flower.c
index 686cf121..25ffd295 100644
--- a/tc/f_flower.c
+++ b/tc/f_flower.c
@@ -48,6 +48,7 @@ static void explain(void)
"\n"
"Where: MATCH-LIST := [ MATCH-LIST ] MATCH\n"
" MATCH := { indev DEV-NAME |\n"
+ " num_of_vlans VLANS_COUNT |\n"
" vlan_id VID |\n"
" vlan_prio PRIORITY |\n"
" vlan_ethtype [ ipv4 | ipv6 | ETH-TYPE ] |\n"
@@ -1525,6 +1526,17 @@ static int flower_parse_opt(struct filter_util *qu, char *handle,
if (check_ifname(*argv))
invarg("\"indev\" not a valid ifname", *argv);
addattrstrz(n, MAX_MSG, TCA_FLOWER_INDEV, *argv);
+ } else if (matches(*argv, "num_of_vlans") == 0) {
+ __u8 num_of_vlans;
+
+ NEXT_ARG();
+ ret = get_u8(&num_of_vlans, *argv, 10);
+ if (ret < 0) {
+ fprintf(stderr, "Illegal \"num_of_vlans\"\n");
+ return -1;
+ }
+ addattr8(n, MAX_MSG,
+ TCA_FLOWER_KEY_NUM_OF_VLANS, num_of_vlans);
} else if (matches(*argv, "vlan_id") == 0) {
__u16 vid;
@@ -2694,6 +2706,14 @@ static int flower_print_opt(struct filter_util *qu, FILE *f,
open_json_object("keys");
+ if (tb[TCA_FLOWER_KEY_NUM_OF_VLANS]) {
+ struct rtattr *attr = tb[TCA_FLOWER_KEY_NUM_OF_VLANS];
+
+ print_nl();
+ print_uint(PRINT_ANY, "num_of_vlans", " num_of_vlans %d",
+ rta_getattr_u8(attr));
+ }
+
if (tb[TCA_FLOWER_KEY_VLAN_ID]) {
struct rtattr *attr = tb[TCA_FLOWER_KEY_VLAN_ID];
--
2.29.2
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4221 bytes --]
^ permalink raw reply related
* [Patch net-next] net: dsa: ksz9477: move get_stats64 to ksz_common.c
From: Arun Ramadoss @ 2022-04-26 9:10 UTC (permalink / raw)
To: linux-kernel, netdev
Cc: Paolo Abeni, Jakub Kicinski, David S. Miller, Vladimir Oltean,
Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
Woojung Huh, Oleksij Rempel
The mib counters for the ksz9477 is same for the ksz9477 switch and
LAN937x switch. Hence moving it to ksz_common.c file in order to have it
generic function. The DSA hook get_stats64 now can call ksz_get_stats64.
Signed-off-by: Arun Ramadoss <arun.ramadoss@microchip.com>
Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
drivers/net/dsa/microchip/ksz9477.c | 98 +-------------------------
drivers/net/dsa/microchip/ksz_common.c | 96 +++++++++++++++++++++++++
drivers/net/dsa/microchip/ksz_common.h | 3 +
3 files changed, 101 insertions(+), 96 deletions(-)
diff --git a/drivers/net/dsa/microchip/ksz9477.c b/drivers/net/dsa/microchip/ksz9477.c
index 4f617fee9a4e..48c90e4cda30 100644
--- a/drivers/net/dsa/microchip/ksz9477.c
+++ b/drivers/net/dsa/microchip/ksz9477.c
@@ -65,100 +65,6 @@ static const struct {
{ 0x83, "tx_discards" },
};
-struct ksz9477_stats_raw {
- u64 rx_hi;
- u64 rx_undersize;
- u64 rx_fragments;
- u64 rx_oversize;
- u64 rx_jabbers;
- u64 rx_symbol_err;
- u64 rx_crc_err;
- u64 rx_align_err;
- u64 rx_mac_ctrl;
- u64 rx_pause;
- u64 rx_bcast;
- u64 rx_mcast;
- u64 rx_ucast;
- u64 rx_64_or_less;
- u64 rx_65_127;
- u64 rx_128_255;
- u64 rx_256_511;
- u64 rx_512_1023;
- u64 rx_1024_1522;
- u64 rx_1523_2000;
- u64 rx_2001;
- u64 tx_hi;
- u64 tx_late_col;
- u64 tx_pause;
- u64 tx_bcast;
- u64 tx_mcast;
- u64 tx_ucast;
- u64 tx_deferred;
- u64 tx_total_col;
- u64 tx_exc_col;
- u64 tx_single_col;
- u64 tx_mult_col;
- u64 rx_total;
- u64 tx_total;
- u64 rx_discards;
- u64 tx_discards;
-};
-
-static void ksz9477_r_mib_stats64(struct ksz_device *dev, int port)
-{
- struct rtnl_link_stats64 *stats;
- struct ksz9477_stats_raw *raw;
- struct ksz_port_mib *mib;
-
- mib = &dev->ports[port].mib;
- stats = &mib->stats64;
- raw = (struct ksz9477_stats_raw *)mib->counters;
-
- spin_lock(&mib->stats64_lock);
-
- stats->rx_packets = raw->rx_bcast + raw->rx_mcast + raw->rx_ucast;
- stats->tx_packets = raw->tx_bcast + raw->tx_mcast + raw->tx_ucast;
-
- /* HW counters are counting bytes + FCS which is not acceptable
- * for rtnl_link_stats64 interface
- */
- stats->rx_bytes = raw->rx_total - stats->rx_packets * ETH_FCS_LEN;
- stats->tx_bytes = raw->tx_total - stats->tx_packets * ETH_FCS_LEN;
-
- stats->rx_length_errors = raw->rx_undersize + raw->rx_fragments +
- raw->rx_oversize;
-
- stats->rx_crc_errors = raw->rx_crc_err;
- stats->rx_frame_errors = raw->rx_align_err;
- stats->rx_dropped = raw->rx_discards;
- stats->rx_errors = stats->rx_length_errors + stats->rx_crc_errors +
- stats->rx_frame_errors + stats->rx_dropped;
-
- stats->tx_window_errors = raw->tx_late_col;
- stats->tx_fifo_errors = raw->tx_discards;
- stats->tx_aborted_errors = raw->tx_exc_col;
- stats->tx_errors = stats->tx_window_errors + stats->tx_fifo_errors +
- stats->tx_aborted_errors;
-
- stats->multicast = raw->rx_mcast;
- stats->collisions = raw->tx_total_col;
-
- spin_unlock(&mib->stats64_lock);
-}
-
-static void ksz9477_get_stats64(struct dsa_switch *ds, int port,
- struct rtnl_link_stats64 *s)
-{
- struct ksz_device *dev = ds->priv;
- struct ksz_port_mib *mib;
-
- mib = &dev->ports[port].mib;
-
- spin_lock(&mib->stats64_lock);
- memcpy(s, &mib->stats64, sizeof(*s));
- spin_unlock(&mib->stats64_lock);
-}
-
static void ksz_cfg(struct ksz_device *dev, u32 addr, u8 bits, bool set)
{
regmap_update_bits(dev->regmap[0], addr, bits, set ? bits : 0);
@@ -1462,7 +1368,7 @@ static const struct dsa_switch_ops ksz9477_switch_ops = {
.port_mdb_del = ksz9477_port_mdb_del,
.port_mirror_add = ksz9477_port_mirror_add,
.port_mirror_del = ksz9477_port_mirror_del,
- .get_stats64 = ksz9477_get_stats64,
+ .get_stats64 = ksz_get_stats64,
.port_change_mtu = ksz9477_change_mtu,
.port_max_mtu = ksz9477_max_mtu,
};
@@ -1653,7 +1559,7 @@ static const struct ksz_dev_ops ksz9477_dev_ops = {
.port_setup = ksz9477_port_setup,
.r_mib_cnt = ksz9477_r_mib_cnt,
.r_mib_pkt = ksz9477_r_mib_pkt,
- .r_mib_stat64 = ksz9477_r_mib_stats64,
+ .r_mib_stat64 = ksz_r_mib_stats64,
.freeze_mib = ksz9477_freeze_mib,
.port_init_cnt = ksz9477_port_init_cnt,
.shutdown = ksz9477_reset_switch,
diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/microchip/ksz_common.c
index 9b9f570ebb0b..10f127b09e58 100644
--- a/drivers/net/dsa/microchip/ksz_common.c
+++ b/drivers/net/dsa/microchip/ksz_common.c
@@ -20,6 +20,102 @@
#include "ksz_common.h"
+struct ksz_stats_raw {
+ u64 rx_hi;
+ u64 rx_undersize;
+ u64 rx_fragments;
+ u64 rx_oversize;
+ u64 rx_jabbers;
+ u64 rx_symbol_err;
+ u64 rx_crc_err;
+ u64 rx_align_err;
+ u64 rx_mac_ctrl;
+ u64 rx_pause;
+ u64 rx_bcast;
+ u64 rx_mcast;
+ u64 rx_ucast;
+ u64 rx_64_or_less;
+ u64 rx_65_127;
+ u64 rx_128_255;
+ u64 rx_256_511;
+ u64 rx_512_1023;
+ u64 rx_1024_1522;
+ u64 rx_1523_2000;
+ u64 rx_2001;
+ u64 tx_hi;
+ u64 tx_late_col;
+ u64 tx_pause;
+ u64 tx_bcast;
+ u64 tx_mcast;
+ u64 tx_ucast;
+ u64 tx_deferred;
+ u64 tx_total_col;
+ u64 tx_exc_col;
+ u64 tx_single_col;
+ u64 tx_mult_col;
+ u64 rx_total;
+ u64 tx_total;
+ u64 rx_discards;
+ u64 tx_discards;
+};
+
+void ksz_r_mib_stats64(struct ksz_device *dev, int port)
+{
+ struct rtnl_link_stats64 *stats;
+ struct ksz_stats_raw *raw;
+ struct ksz_port_mib *mib;
+
+ mib = &dev->ports[port].mib;
+ stats = &mib->stats64;
+ raw = (struct ksz_stats_raw *)mib->counters;
+
+ spin_lock(&mib->stats64_lock);
+
+ stats->rx_packets = raw->rx_bcast + raw->rx_mcast + raw->rx_ucast;
+ stats->tx_packets = raw->tx_bcast + raw->tx_mcast + raw->tx_ucast;
+
+ /* HW counters are counting bytes + FCS which is not acceptable
+ * for rtnl_link_stats64 interface
+ */
+ stats->rx_bytes = raw->rx_total - stats->rx_packets * ETH_FCS_LEN;
+ stats->tx_bytes = raw->tx_total - stats->tx_packets * ETH_FCS_LEN;
+
+ stats->rx_length_errors = raw->rx_undersize + raw->rx_fragments +
+ raw->rx_oversize;
+
+ stats->rx_crc_errors = raw->rx_crc_err;
+ stats->rx_frame_errors = raw->rx_align_err;
+ stats->rx_dropped = raw->rx_discards;
+ stats->rx_errors = stats->rx_length_errors + stats->rx_crc_errors +
+ stats->rx_frame_errors + stats->rx_dropped;
+
+ stats->tx_window_errors = raw->tx_late_col;
+ stats->tx_fifo_errors = raw->tx_discards;
+ stats->tx_aborted_errors = raw->tx_exc_col;
+ stats->tx_errors = stats->tx_window_errors + stats->tx_fifo_errors +
+ stats->tx_aborted_errors;
+
+ stats->multicast = raw->rx_mcast;
+ stats->collisions = raw->tx_total_col;
+
+ spin_unlock(&mib->stats64_lock);
+}
+EXPORT_SYMBOL_GPL(ksz_r_mib_stats64);
+
+void ksz_get_stats64(struct dsa_switch *ds, int port,
+ struct rtnl_link_stats64 *s)
+{
+ struct ksz_device *dev = ds->priv;
+ struct ksz_port_mib *mib;
+
+ mib = &dev->ports[port].mib;
+
+ spin_lock(&mib->stats64_lock);
+ memcpy(s, &mib->stats64, sizeof(*s));
+ spin_unlock(&mib->stats64_lock);
+}
+EXPORT_SYMBOL_GPL(ksz_get_stats64);
+
void ksz_update_port_member(struct ksz_device *dev, int port)
{
struct ksz_port *p = &dev->ports[port];
diff --git a/drivers/net/dsa/microchip/ksz_common.h b/drivers/net/dsa/microchip/ksz_common.h
index 4d978832c448..28cda79b090f 100644
--- a/drivers/net/dsa/microchip/ksz_common.h
+++ b/drivers/net/dsa/microchip/ksz_common.h
@@ -151,6 +151,9 @@ int ksz9477_switch_register(struct ksz_device *dev);
void ksz_update_port_member(struct ksz_device *dev, int port);
void ksz_init_mib_timer(struct ksz_device *dev);
+void ksz_r_mib_stats64(struct ksz_device *dev, int port);
+void ksz_get_stats64(struct dsa_switch *ds, int port,
+ struct rtnl_link_stats64 *s);
/* Common DSA access functions */
base-commit: de6dd626d7082eda383ec77a5e06093c82122d10
--
2.33.0
^ permalink raw reply related
* Re: [Patch bpf-next v1 1/4] tcp: introduce tcp_read_skb()
From: Jakub Sitnicki @ 2022-04-26 9:11 UTC (permalink / raw)
To: Cong Wang
Cc: netdev, Cong Wang, Eric Dumazet, John Fastabend, Daniel Borkmann
In-Reply-To: <20220410161042.183540-2-xiyou.wangcong@gmail.com>
On Sun, Apr 10, 2022 at 09:10 AM -07, Cong Wang wrote:
> From: Cong Wang <cong.wang@bytedance.com>
>
> This patch inroduces tcp_read_skb() based on tcp_read_sock(),
> a preparation for the next patch which actually introduces
> a new sock ops.
>
> TCP is special here, because it has tcp_read_sock() which is
> mainly used by splice(). tcp_read_sock() supports partial read
> and arbitrary offset, neither of them is needed for sockmap.
>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: John Fastabend <john.fastabend@gmail.com>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Jakub Sitnicki <jakub@cloudflare.com>
> Signed-off-by: Cong Wang <cong.wang@bytedance.com>
> ---
> include/net/tcp.h | 2 ++
> net/ipv4/tcp.c | 72 +++++++++++++++++++++++++++++++++++++++++------
> 2 files changed, 66 insertions(+), 8 deletions(-)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 6d50a662bf89..f0d4ce6855e1 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -667,6 +667,8 @@ void tcp_get_info(struct sock *, struct tcp_info *);
> /* Read 'sendfile()'-style from a TCP socket */
> int tcp_read_sock(struct sock *sk, read_descriptor_t *desc,
> sk_read_actor_t recv_actor);
> +int tcp_read_skb(struct sock *sk, read_descriptor_t *desc,
> + sk_read_actor_t recv_actor);
Do you think it would be worth adding docs for the newly added function?
Why it exists and how is it different from the tcp_read_sock which has
the same interface?
[...]
^ 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