* Re: [PATCH net-next v2 16/22] bnxt_en: Handle firmware reset.
From: kbuild test robot @ 2019-08-30 17:56 UTC (permalink / raw)
To: Michael Chan; +Cc: kbuild-all, davem, netdev, vasundhara-v.volam, ray.jui
In-Reply-To: <1567137305-5853-17-git-send-email-michael.chan@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 2764 bytes --]
Hi Michael,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Michael-Chan/bnxt_en-health-and-error-recovery/20190830-164635
config: x86_64-randconfig-f001-201934 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-11) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
drivers/net/ethernet/broadcom/bnxt/bnxt.c: In function 'bnxt_fw_reset':
>> drivers/net/ethernet/broadcom/bnxt/bnxt.c:10021:35: error: 'struct bnxt' has no member named 'sriov_cfg'
if (bp->pf.registered_vfs || bp->sriov_cfg) {
^~
drivers/net/ethernet/broadcom/bnxt/bnxt.c: In function 'bnxt_fw_reset_task':
drivers/net/ethernet/broadcom/bnxt/bnxt.c:10418:34: error: 'struct bnxt' has no member named 'sriov_cfg'
if (bp->pf.registered_vfs || bp->sriov_cfg) {
^~
drivers/net/ethernet/broadcom/bnxt/bnxt.c:10425:11: error: 'struct bnxt' has no member named 'sriov_cfg'
bp->sriov_cfg);
^~
vim +10021 drivers/net/ethernet/broadcom/bnxt/bnxt.c
10003
10004 void bnxt_fw_reset(struct bnxt *bp)
10005 {
10006 int rc;
10007
10008 bnxt_rtnl_lock_sp(bp);
10009 if (test_bit(BNXT_STATE_OPEN, &bp->state) &&
10010 !test_bit(BNXT_STATE_IN_FW_RESET, &bp->state)) {
10011 set_bit(BNXT_STATE_IN_FW_RESET, &bp->state);
10012 if (BNXT_PF(bp) && bp->pf.active_vfs) {
10013 rc = bnxt_hwrm_func_qcfg(bp);
10014 if (rc) {
10015 netdev_err(bp->dev, "Firmware reset aborted, first func_qcfg cmd failed, rc = %d\n",
10016 rc);
10017 clear_bit(BNXT_STATE_IN_FW_RESET, &bp->state);
10018 dev_close(bp->dev);
10019 goto fw_reset_exit;
10020 }
10021 if (bp->pf.registered_vfs || bp->sriov_cfg) {
10022 u16 vf_tmo_dsecs = bp->pf.registered_vfs * 10;
10023
10024 if (bp->fw_reset_max_dsecs < vf_tmo_dsecs)
10025 bp->fw_reset_max_dsecs = vf_tmo_dsecs;
10026 bp->fw_reset_state =
10027 BNXT_FW_RESET_STATE_POLL_VF;
10028 bnxt_queue_fw_reset_work(bp, HZ / 10);
10029 goto fw_reset_exit;
10030 }
10031 }
10032 bnxt_fw_reset_close(bp);
10033 bp->fw_reset_state = BNXT_FW_RESET_STATE_ENABLE_DEV;
10034 bnxt_queue_fw_reset_work(bp, bp->fw_reset_min_dsecs * HZ / 10);
10035 }
10036 fw_reset_exit:
10037 bnxt_rtnl_unlock_sp(bp);
10038 }
10039
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 33761 bytes --]
^ permalink raw reply
* Re: [PATCH v3 net-next 2/2] net: dsa: tag_8021q: Restore bridge VLANs when enabling vlan_filtering
From: Vivien Didelot @ 2019-08-30 17:20 UTC (permalink / raw)
To: Vladimir Oltean
Cc: f.fainelli, andrew, idosch, roopa, nikolay, davem, netdev,
Vladimir Oltean
In-Reply-To: <20190830005325.26526-3-olteanv@gmail.com>
Hi Vladimir,
On Fri, 30 Aug 2019 03:53:25 +0300, Vladimir Oltean <olteanv@gmail.com> wrote:
> The bridge core assumes that enabling/disabling vlan_filtering will
> translate into the simple toggling of a flag for switchdev drivers.
>
> That is clearly not the case for sja1105, which alters the VLAN table
> and the pvids in order to obtain port separation in standalone mode.
>
> There are 2 parts to the issue.
>
> First, tag_8021q changes the pvid to a unique per-port rx_vid for frame
> identification. But we need to disable tag_8021q when vlan_filtering
> kicks in, and at that point, the VLAN configured as pvid will have to be
> removed from the filtering table of the ports. With an invalid pvid, the
> ports will drop all traffic. Since the bridge will not call any vlan
> operation through switchdev after enabling vlan_filtering, we need to
> ensure we're in a functional state ourselves. Hence read the pvid that
> the bridge is aware of, and program that into our ports.
>
> Secondly, tag_8021q uses the 1024-3071 range privately in
> vlan_filtering=0 mode. Had the user installed one of these VLANs during
> a previous vlan_filtering=1 session, then upon the next tag_8021q
> cleanup for vlan_filtering to kick in again, VLANs in that range will
> get deleted unconditionally, hence breaking user expectation. So when
> deleting the VLANs, check if the bridge had knowledge about them, and if
> it did, re-apply the settings. Wrap this logic inside a
> dsa_8021q_vid_apply helper function to reduce code duplication.
>
> Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
I have no complaint with this series:
Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
Thanks for sending smaller pieces like this one btw,
Vivien
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] dt-bindings: net: dsa: mt7530: Add support for port 5
From: René van Dorst @ 2019-08-30 17:16 UTC (permalink / raw)
To: Rob Herring
Cc: Sean Wang, Andrew Lunn, Vivien Didelot, Florian Fainelli,
David S . Miller, Matthias Brugger, netdev, linux-arm-kernel,
linux-mediatek, John Crispin, linux-mips, Frank Wunderlich,
devicetree
In-Reply-To: <20190828063520.Horde.4_ak7mcmFhVJlxZWWy2wo3V@www.vdorst.com>
Hi Rob,
<snip>
>>> See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list
>>> of additional
>>> required, optional properties and how the integrated switch subnodes must
>>> be specified.
>>> @@ -94,3 +130,185 @@ Example:
>>> };
>>> };
>>> };
>>> +
>>> +Example 2: MT7621: Port 4 is WAN port: 2nd GMAC -> Port 5 -> PHY port 4.
>>> +
>>> +ð {
>>> + status = "okay";
>>
>> Don't show status in examples.
>
> OK.
>
>> This should show the complete node.
>>
>
I asked this question below in my previous email.
May be you missed it, I hope that you have time soon to answer this so that I
can send a new version.
> To be clear, I should take ethernet node from the mt7621.dtsi [0] or
> mt7623.dtsi [1] and insert the example below?, right?
Greats,
René
>
> Greats,
>
> René
>
> [0]:
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/tree/drivers/staging/mt7621-dts/mt7621.dtsi#n397
> [1]:
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/tree/arch/arm/boot/dts/mt7623.dtsi#n1023
>
>>> +
>>> + gmac0: mac@0 {
>>> + compatible = "mediatek,eth-mac";
>>> + reg = <0>;
>>> + phy-mode = "rgmii";
>>> +
>>> + fixed-link {
>>> + speed = <1000>;
>>> + full-duplex;
>>> + pause;
>>> + };
>>> + };
>>> +
>>> + gmac1: mac@1 {
>>> + compatible = "mediatek,eth-mac";
>>> + reg = <1>;
>>> + phy-mode = "rgmii-txid";
>>> + phy-handle = <&phy4>;
>>> + };
>>> +
>>> + mdio: mdio-bus {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + /* Internal phy */
>>> + phy4: ethernet-phy@4 {
>>> + reg = <4>;
>>> + };
>>> +
>>> + mt7530: switch@1f {
>>> + compatible = "mediatek,mt7621";
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + reg = <0x1f>;
>>> + pinctrl-names = "default";
>>> + mediatek,mcm;
>>> +
>>> + resets = <&rstctrl 2>;
>>> + reset-names = "mcm";
>>> +
>>> + ports {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + port@0 {
>>> + reg = <0>;
>>> + label = "lan0";
>>> + };
>>> +
>>> + port@1 {
>>> + reg = <1>;
>>> + label = "lan1";
>>> + };
>>> +
>>> + port@2 {
>>> + reg = <2>;
>>> + label = "lan2";
>>> + };
>>> +
>>> + port@3 {
>>> + reg = <3>;
>>> + label = "lan3";
>>> + };
>>> +
>>> +/* Commented out. Port 4 is handled by 2nd GMAC.
>>> + port@4 {
>>> + reg = <4>;
>>> + label = "lan4";
>>> + };
>>> +*/
>>> +
>>> + cpu_port0: port@6 {
>>> + reg = <6>;
>>> + label = "cpu";
>>> + ethernet = <&gmac0>;
>>> + phy-mode = "rgmii";
>>> +
>>> + fixed-link {
>>> + speed = <1000>;
>>> + full-duplex;
>>> + pause;
>>> + };
>>> + };
>>> + };
>>> + };
>>> + };
>>> +};
>>> +
>>> +Example 3: MT7621: Port 5 is connected to external PHY: Port 5 ->
>>> external PHY.
>>> +
>>> +ð {
>>> + status = "okay";
>>> +
>>> + gmac0: mac@0 {
>>> + compatible = "mediatek,eth-mac";
>>> + reg = <0>;
>>> + phy-mode = "rgmii";
>>> +
>>> + fixed-link {
>>> + speed = <1000>;
>>> + full-duplex;
>>> + pause;
>>> + };
>>> + };
>>> +
>>> + mdio: mdio-bus {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + /* External phy */
>>> + ephy5: ethernet-phy@7 {
>>> + reg = <7>;
>>> + };
>>> +
>>> + mt7530: switch@1f {
>>> + compatible = "mediatek,mt7621";
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + reg = <0x1f>;
>>> + pinctrl-names = "default";
>>> + mediatek,mcm;
>>> +
>>> + resets = <&rstctrl 2>;
>>> + reset-names = "mcm";
>>> +
>>> + ports {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + port@0 {
>>> + reg = <0>;
>>> + label = "lan0";
>>> + };
>>> +
>>> + port@1 {
>>> + reg = <1>;
>>> + label = "lan1";
>>> + };
>>> +
>>> + port@2 {
>>> + reg = <2>;
>>> + label = "lan2";
>>> + };
>>> +
>>> + port@3 {
>>> + reg = <3>;
>>> + label = "lan3";
>>> + };
>>> +
>>> + port@4 {
>>> + reg = <4>;
>>> + label = "lan4";
>>> + };
>>> +
>>> + port@5 {
>>> + reg = <5>;
>>> + label = "lan5";
>>> + phy-mode = "rgmii";
>>> + phy-handle = <&ephy5>;
>>> + };
>>> +
>>> + cpu_port0: port@6 {
>>> + reg = <6>;
>>> + label = "cpu";
>>> + ethernet = <&gmac0>;
>>> + phy-mode = "rgmii";
>>> +
>>> + fixed-link {
>>> + speed = <1000>;
>>> + full-duplex;
>>> + pause;
>>> + };
>>> + };
>>> + };
>>> + };
>>> + };
>>> +};
>>> --
>>> 2.20.1
>>>
^ permalink raw reply
* Re: [patch net-next rfc 3/7] net: rtnetlink: add commands to add and delete alternative ifnames
From: Jiri Pirko @ 2019-08-30 17:04 UTC (permalink / raw)
To: David Ahern
Cc: Roopa Prabhu, Michal Kubecek, netdev, David Miller,
Jakub Kicinski, Stephen Hemminger, dcbw, Andrew Lunn, parav,
Saeed Mahameed, mlxsw
In-Reply-To: <9ec43634-d2e9-b976-1936-5b7ddc587b76@gmail.com>
Fri, Aug 30, 2019 at 04:47:41PM CEST, dsahern@gmail.com wrote:
>On 8/30/19 8:35 AM, Roopa Prabhu wrote:
>> On Wed, Aug 28, 2019 at 10:26 PM Michal Kubecek <mkubecek@suse.cz> wrote:
>>>
>>> On Wed, Aug 28, 2019 at 09:36:41PM -0700, Roopa Prabhu wrote:
>>>>
>>>> yes, correct. I mentioned that because I was wondering if we can
>>>> think along the same lines for this API.
>>>> eg
>>>> (a) RTM_NEWLINK always replaces the list attribute
>>>> (b) RTM_SETLINK with NLM_F_APPEND always appends to the list attribute
>>>> (c) RTM_DELLINK with NLM_F_APPEND updates the list attribute
>>>>
>>>> (It could be NLM_F_UPDATE if NLM_F_APPEND sounds weird in the del
>>>> case. I have not looked at the full dellink path if it will work
>>>> neatly..its been a busy day )
>>>
>>> AFAICS rtnl_dellink() calls nlmsg_parse_deprecated() so that even
>>> current code would ignore any future attribute in RTM_DELLINK message
>>> (any kernel before the strict validation was introduced definitely will)
>>> and it does not seem to check NLM_F_APPEND or NLM_F_UPDATE either. So
>>> unless I missed something, such message would result in deleting the
>>> network device (if possible) with any kernel not implementing the
>>> feature.
>>
>> ok, ack. yes today it does. I was hinting if that can be changed to
>> support list update with a flag like the RTM_DELLINK AF_BRIDGE does
>> for vlan list del.
>>
>> so to summarize, i think we have discussed the following options to
>> update a netlink list attribute so far:
>> (a) encode an optional attribute/flag in the list attribute in
>> RTM_SETLINK to indicate if it is a add or del
>
>The ALT_IFNAME attribute could also be a struct that has both the string
>and a flag.
Not a struct, please :/
>
>> (b) Use a flag in RTM_SETLINK and RTM_DELINK to indicate add/del
>> (close to bridge vlan add/del)
>> (c) introduce a separate generic msg type to add/del to a list
>> attribute (IIUC this does need a separate msg type per subsystem or
>> netlink API)
>>
>
^ permalink raw reply
* Re: [patch net-next rfc 3/7] net: rtnetlink: add commands to add and delete alternative ifnames
From: Jiri Pirko @ 2019-08-30 17:03 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Michal Kubecek, netdev, David Miller, Jakub Kicinski, David Ahern,
Stephen Hemminger, dcbw, Andrew Lunn, parav, Saeed Mahameed,
mlxsw
In-Reply-To: <CAJieiUgGY4amm_z1VGgBF-3WZceah+R5OVLEi=O2RS8RGpC9dg@mail.gmail.com>
Fri, Aug 30, 2019 at 04:35:23PM CEST, roopa@cumulusnetworks.com wrote:
>On Wed, Aug 28, 2019 at 10:26 PM Michal Kubecek <mkubecek@suse.cz> wrote:
>>
>> On Wed, Aug 28, 2019 at 09:36:41PM -0700, Roopa Prabhu wrote:
>> >
>> > yes, correct. I mentioned that because I was wondering if we can
>> > think along the same lines for this API.
>> > eg
>> > (a) RTM_NEWLINK always replaces the list attribute
>> > (b) RTM_SETLINK with NLM_F_APPEND always appends to the list attribute
>> > (c) RTM_DELLINK with NLM_F_APPEND updates the list attribute
>> >
>> > (It could be NLM_F_UPDATE if NLM_F_APPEND sounds weird in the del
>> > case. I have not looked at the full dellink path if it will work
>> > neatly..its been a busy day )
>>
>> AFAICS rtnl_dellink() calls nlmsg_parse_deprecated() so that even
>> current code would ignore any future attribute in RTM_DELLINK message
>> (any kernel before the strict validation was introduced definitely will)
>> and it does not seem to check NLM_F_APPEND or NLM_F_UPDATE either. So
>> unless I missed something, such message would result in deleting the
>> network device (if possible) with any kernel not implementing the
>> feature.
>
>ok, ack. yes today it does. I was hinting if that can be changed to
>support list update with a flag like the RTM_DELLINK AF_BRIDGE does
>for vlan list del.
>
>so to summarize, i think we have discussed the following options to
>update a netlink list attribute so far:
>(a) encode an optional attribute/flag in the list attribute in
>RTM_SETLINK to indicate if it is a add or del
>(b) Use a flag in RTM_SETLINK and RTM_DELINK to indicate add/del
>(close to bridge vlan add/del)
Nope, bridge vlan add/del is done according to the cmd, not any flag.
>(c) introduce a separate generic msg type to add/del to a list
>attribute (IIUC this does need a separate msg type per subsystem or
>netlink API)
^ permalink raw reply
* [PATCH net] tc-testing: don't hardcode 'ip' in nsPlugin.py
From: Davide Caratti @ 2019-08-30 16:51 UTC (permalink / raw)
To: Hangbin Liu, Roman Mashak, Vlad Buslov, David S. Miller,
Lucas Bates, Nicolas Dichtel, netdev
Cc: Marcelo Ricardo Leitner
the following tdc test fails on Fedora:
# ./tdc.py -e 2638
-- ns/SubPlugin.__init__
Test 2638: Add matchall and try to get it
-----> prepare stage *** Could not execute: "$TC qdisc add dev $DEV1 clsact"
-----> prepare stage *** Error message: "/bin/sh: ip: command not found"
returncode 127; expected [0]
-----> prepare stage *** Aborting test run.
Let nsPlugin.py use the 'IP' variable introduced with commit 92c1a19e2fb9
("tc-tests: added path to ip command in tdc"), so that the path to 'ip' is
correctly resolved to the value we have in tdc_config.py.
# ./tdc.py -e 2638
-- ns/SubPlugin.__init__
Test 2638: Add matchall and try to get it
All test results:
1..1
ok 1 2638 - Add matchall and try to get it
Fixes: 489ce2f42514 ("tc-testing: Restore original behaviour for namespaces in tdc")
Reported-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
.../tc-testing/plugin-lib/nsPlugin.py | 22 +++++++++----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/tools/testing/selftests/tc-testing/plugin-lib/nsPlugin.py b/tools/testing/selftests/tc-testing/plugin-lib/nsPlugin.py
index affa7f2d9670..9539cffa9e5e 100644
--- a/tools/testing/selftests/tc-testing/plugin-lib/nsPlugin.py
+++ b/tools/testing/selftests/tc-testing/plugin-lib/nsPlugin.py
@@ -64,7 +64,7 @@ class SubPlugin(TdcPlugin):
cmdlist.insert(0, self.args.NAMES['NS'])
cmdlist.insert(0, 'exec')
cmdlist.insert(0, 'netns')
- cmdlist.insert(0, 'ip')
+ cmdlist.insert(0, self.args.NAMES['IP'])
else:
pass
@@ -78,16 +78,16 @@ class SubPlugin(TdcPlugin):
return command
def _ports_create(self):
- cmd = 'ip link add $DEV0 type veth peer name $DEV1'
+ cmd = '$IP link add $DEV0 type veth peer name $DEV1'
self._exec_cmd('pre', cmd)
- cmd = 'ip link set $DEV0 up'
+ cmd = '$IP link set $DEV0 up'
self._exec_cmd('pre', cmd)
if not self.args.namespace:
- cmd = 'ip link set $DEV1 up'
+ cmd = '$IP link set $DEV1 up'
self._exec_cmd('pre', cmd)
def _ports_destroy(self):
- cmd = 'ip link del $DEV0'
+ cmd = '$IP link del $DEV0'
self._exec_cmd('post', cmd)
def _ns_create(self):
@@ -97,16 +97,16 @@ class SubPlugin(TdcPlugin):
'''
self._ports_create()
if self.args.namespace:
- cmd = 'ip netns add {}'.format(self.args.NAMES['NS'])
+ cmd = '$IP netns add {}'.format(self.args.NAMES['NS'])
self._exec_cmd('pre', cmd)
- cmd = 'ip link set $DEV1 netns {}'.format(self.args.NAMES['NS'])
+ cmd = '$IP link set $DEV1 netns {}'.format(self.args.NAMES['NS'])
self._exec_cmd('pre', cmd)
- cmd = 'ip -n {} link set $DEV1 up'.format(self.args.NAMES['NS'])
+ cmd = '$IP -n {} link set $DEV1 up'.format(self.args.NAMES['NS'])
self._exec_cmd('pre', cmd)
if self.args.device:
- cmd = 'ip link set $DEV2 netns {}'.format(self.args.NAMES['NS'])
+ cmd = '$IP link set $DEV2 netns {}'.format(self.args.NAMES['NS'])
self._exec_cmd('pre', cmd)
- cmd = 'ip -n {} link set $DEV2 up'.format(self.args.NAMES['NS'])
+ cmd = '$IP -n {} link set $DEV2 up'.format(self.args.NAMES['NS'])
self._exec_cmd('pre', cmd)
def _ns_destroy(self):
@@ -115,7 +115,7 @@ class SubPlugin(TdcPlugin):
devices as well)
'''
if self.args.namespace:
- cmd = 'ip netns delete {}'.format(self.args.NAMES['NS'])
+ cmd = '$IP netns delete {}'.format(self.args.NAMES['NS'])
self._exec_cmd('post', cmd)
def _exec_cmd(self, stage, command):
--
2.20.1
^ permalink raw reply related
* Re: [PATCH V40 23/29] bpf: Restrict bpf when kernel lockdown is in confidentiality mode
From: David Howells @ 2019-08-30 16:32 UTC (permalink / raw)
To: Matthew Garrett
Cc: dhowells, jmorris, linux-security-module, linux-kernel, linux-api,
Alexei Starovoitov, Matthew Garrett, Kees Cook, netdev,
Chun-Yi Lee, Daniel Borkmann
In-Reply-To: <20190820001805.241928-24-matthewgarrett@google.com>
Matthew Garrett <matthewgarrett@google.com> wrote:
> From: David Howells <dhowells@redhat.com>
>
> bpf_read() and bpf_read_str() could potentially be abused to (eg) allow
> private keys in kernel memory to be leaked. Disable them if the kernel
> has been locked down in confidentiality mode.
>
> Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Signed-off-by: Matthew Garrett <mjg59@google.com>
> Reviewed-by: Kees Cook <keescook@chromium.org>
> cc: netdev@vger.kernel.org
> cc: Chun-Yi Lee <jlee@suse.com>
> cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Signed-off-by: James Morris <jmorris@namei.org>
Signed-off-by: David Howells <dhowells@redhat.com>
^ permalink raw reply
* Re: [PATCH] net/skbuff: silence warnings under memory pressure
From: Eric Dumazet @ 2019-08-30 16:15 UTC (permalink / raw)
To: Qian Cai, Eric Dumazet, davem; +Cc: netdev, linux-mm, linux-kernel
In-Reply-To: <1567178728.5576.32.camel@lca.pw>
On 8/30/19 5:25 PM, Qian Cai wrote:
> On Fri, 2019-08-30 at 17:11 +0200, Eric Dumazet wrote:
>>
>> On 8/30/19 4:57 PM, Qian Cai wrote:
>>> When running heavy memory pressure workloads, the system is throwing
>>> endless warnings below due to the allocation could fail from
>>> __build_skb(), and the volume of this call could be huge which may
>>> generate a lot of serial console output and cosumes all CPUs as
>>> warn_alloc() could be expensive by calling dump_stack() and then
>>> show_mem().
>>>
>>> Fix it by silencing the warning in this call site. Also, it seems
>>> unnecessary to even print a warning at all if the allocation failed in
>>> __build_skb(), as it may just retransmit the packet and retry.
>>>
>>
>> Same patches are showing up there and there from time to time.
>>
>> Why is this particular spot interesting, against all others not adding
>> __GFP_NOWARN ?
>>
>> Are we going to have hundred of patches adding __GFP_NOWARN at various points,
>> or should we get something generic to not flood the syslog in case of memory
>> pressure ?
>>
>
> From my testing which uses LTP oom* tests. There are only 3 places need to be
> patched. The other two are in IOMMU code for both Intel and AMD. The place is
> particular interesting because it could cause the system with floating serial
> console output for days without making progress in OOM. I suppose it ends up in
> a looping condition that warn_alloc() would end up generating more calls into
> __build_skb() via ksoftirqd.
>
Yes, but what about other tests done by other people ?
You do not really answer my last question, which was really the point I tried
to make.
If there is a risk of flooding the syslog, we should fix this generically
in mm layer, not adding hundred of __GFP_NOWARN all over the places.
Maybe just make __GFP_NOWARN the default, I dunno.
^ permalink raw reply
* Re: [PATCH net-next 03/14] bnxt_en: Refactor bnxt_sriov_enable().
From: Michael Chan @ 2019-08-30 16:00 UTC (permalink / raw)
To: Leon Romanovsky
Cc: David Miller, Netdev, Vasundhara Volam, Jiri Pirko, Ray Jui
In-Reply-To: <20190830091838.GC12611@unreal>
On Fri, Aug 30, 2019 at 2:18 AM Leon Romanovsky <leon@kernel.org> wrote:
>
> On Mon, Aug 26, 2019 at 09:00:45AM +0300, Leon Romanovsky wrote:
> > On Sun, Aug 25, 2019 at 11:54:54PM -0400, Michael Chan wrote:
> > > Refactor the hardware/firmware configuration portion in
> > > bnxt_sriov_enable() into a new function bnxt_cfg_hw_sriov(). This
> > > new function can be called after a firmware reset to reconfigure the
> > > VFs previously enabled.
> >
> > I wonder what does it mean for already bound VFs to vfio driver?
> > Will you rebind them as well? Can I assume that FW error in one VF
> > will trigger "restart" of other VFs too?
>
> Care to reply?
>
>
Sorry, I missed your email earlier.
A firmware reset/recovery has no direct effect on a VF or any function
if it is just idle. The PCI interface of any function does not get
reset.
If a VF driver (Linux VF driver, DPDK driver, etc) has initialized on
that function, meaning it has exchanged messages with firmware to
register itself and to allocate resources (such as rings), then the
firmware reset will require all those resources to be re-discovered
and re-initialized. These VF resources are initially assigned by the
PF. So this refactored function on the PF is to re-assign these
resources back to the VF after the firmware reset. Again, if the VF
is just bound to vfio and is idle, there is no effect.
^ permalink raw reply
* Re: [PATCH v2 1/1] netfilter: nf_tables: fib: Drop IPV6 packages if IPv6 is disabled on boot
From: Florian Westphal @ 2019-08-30 15:58 UTC (permalink / raw)
To: Leonardo Bras
Cc: Florian Westphal, Pablo Neira Ayuso, David S. Miller,
netfilter-devel, coreteam, netdev, linux-kernel, Jozsef Kadlecsik,
Alexey Kuznetsov, Hideaki YOSHIFUJI
In-Reply-To: <4b3b52d0f73aeb1437b4b2a46325b36e9c41f92b.camel@linux.ibm.com>
Leonardo Bras <leonardo@linux.ibm.com> wrote:
> On Thu, 2019-08-29 at 22:58 +0200, Florian Westphal wrote:
> [...]
> > 1. add a patch to BREAK in nft_fib_netdev.c for !ipv6_mod_enabled()
> [...]
>
> But this is still needed? I mean, in nft_fib_netdev_eval there are only
> 2 functions being called for IPv6 protocol : nft_fib6_eval and
> nft_fib6_eval_type. Both are already protected by this current patch.
>
> Is your 1st suggestion about this patch, or you think it's better to
> move this change to nft_fib_netdev_eval ?
Ah, it was the latter.
Making bridge netfilter not pass packets up with ipv6 off closes
the problem for fib_ipv6 and inet, so only _netdev.c needs fixing.
^ permalink raw reply
* RE: [PATCH] rtl_nic: add firmware rtl8125a-3
From: Hau @ 2019-08-30 15:56 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Josh Boyer, Linux Firmware, nic_swsd, netdev@vger.kernel.org,
Hayes Wang
In-Reply-To: <b4faccd6-10ff-c6ab-523d-39a1734e1b72@gmail.com>
> On 27.08.2019 14:08, Josh Boyer wrote:
> > On Mon, Aug 26, 2019 at 6:23 PM Heiner Kallweit <hkallweit1@gmail.com>
> wrote:
> >>
> >> This adds firmware rtl8125a-3 for Realtek's 2.5Gbps chip RTL8125.
> >>
> >> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> >> ---
> >> Firmware file was provided by Realtek and they asked me to submit it.
> >
> > Can we get a Signed-off-by from someone at Realtek then?
> >
> Hi Hau,
>
> can you reply and add your Signed-off-by?
> I saw that all the RTL8168 firmware was submitted by Hayes Wang.
>
> > josh
> >
> Heiner
>
Signed-off-by: Chunhao Lin <hau@realtek.com>
> >> The related extension to r8169 driver will be submitted in the next days.
> >> ---
> >> WHENCE | 3 +++
> >> rtl_nic/rtl8125a-3.fw | Bin 0 -> 3456 bytes
> >> 2 files changed, 3 insertions(+)
> >> create mode 100644 rtl_nic/rtl8125a-3.fw
> >>
> >> diff --git a/WHENCE b/WHENCE
> >> index fb12924..dbec18a 100644
> >> --- a/WHENCE
> >> +++ b/WHENCE
> >> @@ -2906,6 +2906,9 @@ Version: 0.0.2
> >> File: rtl_nic/rtl8107e-2.fw
> >> Version: 0.0.2
> >>
> >> +File: rtl_nic/rtl8125a-3.fw
> >> +Version: 0.0.1
> >> +
> >> Licence:
> >> * Copyright © 2011-2013, Realtek Semiconductor Corporation
> >> *
> >> diff --git a/rtl_nic/rtl8125a-3.fw b/rtl_nic/rtl8125a-3.fw new file
> >> mode 100644 index
> >>
> 0000000000000000000000000000000000000000..fac635263f92e8d9734456b75
> 93
> >> 2b2088edd5ef9
> >> GIT binary patch
> >> literal 3456
> >>
> zcmb7G4@{Kj8Gr9M&hw<l39l3>p*MPE#webM6qsqQiuC(hXPi?+wDL#V(Z*4#K%
> FD{
> >>
> zd#PH+tTJbqZG?a`)*5G*m3F2zmN`7hx;2*IKiVu;;~Hwa_E@^5+Z^ooav$qyWa|!|
> >> z{J!V^^FHtMe%~vE5S!~a<<HMqSUGn=c_2HGJ>M6|pO=$6Z+-
> !F`d2|JjuT=?tX!6t
> >> zo1eG1ysol-V@-
> KgU0(T?#@f6Efr9d!!2E*zz=G_mCu@CyK;goi!iD+b1yk6B2%b&6
> >> z7edS;xkzqO0?9-2l9EW0ltM}+rIFG}86+PmljJ95fhB~6Z~~0y3JYX}?Z^&0uqy1t
> >>
> zny?FN!)}}nC*Ym12kkF<@t&E4_=v=ynF9AnDz2DmaE+uRv6r!*@!^m!6NmhMO
> zq8r
> >> zcySgS;n{HZ&ViVjO+Em7C<o$9E{w7~#?6OA6vF-
> CA|!?$MBkPmUNaZNIZ}kPTZ-Wd
> >> z8F2PIf~lcpz}RxchgOhZNnAy~1V!<ssEIFw^W*gx{=)|N&sV@7s=~F-
> YS=QKK)AC8
> >>
> z;l`&BHaB5(q!u4F*5UicX4Dw<xZc@_xQwl|*+!ct+H9u{FeB7V|DE*TO<fCht<>$I
> >> zZZG}Y@U*d?z6a>rPW?gZU!wjH^_^&crVIA-
> hauiRf}*mc@O*L%b>cXFD^8&Io|9br
> >>
> zFS+(#A<NUl=QsF#3U7Megl)!Y%#NIan9+;JM$V!#)QA3t5H6bia7TWJOXlz4ioA=<
> >> z<^?z-1MK-A9Fa>HXt;u_<`7nle1Pws`y;xZ4b$%$RvXt*Vtj-(#xP2a8yGS^#rwu*
> >> z7&RlXNB)8`;|q+Lf8+C)SZDkL{T(+MYZPk@p$0naYDvhUdK;W-
> &~&K<5x2TvCa4ES
> >>
> zJSq_Os=`o`>Ti(hqM4#RkyLfbOj8MwbamOxQ0|CNT`@D2E8<rJ4O!}{IZMSyW~=P
> b
> >> z9LCG0O+ej0lA~sw%T-
> ;^=BaOn@)@g8tu_{^65~O&#t5oXW3d`Ciq!i?u^KfEWsf|f
> >>
> z%8X@d%v{dr6>6QaQuTMNV*C=d)+lAYWhy1Kp7A%(ze4qPRH@`pHTfshkXfVRB
> 2TgY
> >>
> zO=`+Wt(q39Q=W61)m5XOc8&DkO5CPgp(bTNzg>y9p~8jDs$zJj5<R=s;Oi~Q^>M4
> (
> >>
> zG`vTNq`hitUz@`B_Nx)&fWp3Z<>))8?4g&GICDrH_jW38Z<lJiahS3rlpR$<98=@x
> >> z6ix)=-SB%nIOXwTePI%gc_p@upI;Gdo~F;Tmw)5`y%^_39nX1Ki-J6~L1FKz7NSjv
> >> z_`nkPz3?L$w%rohr-(vgBF1<i;qBEnDP75AC6X+Z8dD{_;JbnNV+;3L_)`miW?_eg
> >> z-4-4vre2o#VTHs{P{PCaz|dle45F5=t7KfRt3*ceh=r$#TAy7mkxtwHW#j)EHgmp)
> >> zO)hO_GH>cb5{`=!(@#j)h_-jxgCneiD9Hcd;ix`Q>rX~yy2c{beS3_|m>9m87;BeK
> >> z9^<~->L`kd5sZmZuw?QWNw>vliHU)j7&EQ4-f1m1#+c~6-
> j5U9k9~bn**#pV?$N|-
> >> zq$Nr8T#$I{J?c3t2VJ-F9=Aj_^{tkE`!wz?XF~Vaag5Xw_4`&lQTP1kQQmM$_|B0(
> >>
> zOkxdl@0Tb}k#O<ZNq?P7^BP@o5?P$tDMUYUDdm~Ohjk2MA!9p<P0Z~eCa@+
> uv7NOF
> >> zV)t~$Ac`@GiSytUlb?qfh~`cEKhXXQ`gkQS+oQgJX8gniiK%+szlqBBQMQ+LjIoYA
> >> z7Pea0V&QHJcUss?e1U!-
> enM;`#@W7FhmW$!&b34|Z>oiU3%_IGY6~}8_<=_875$5K
> >> z-p<>elW^0nO-Xb$v)?-<5?*G%4-
> kJO5#)Zu+T&X8&rjZA4DRX1phN*@#Ln3Z5`&x>
> >> zM^Cgz;x5{-ci}0VyQ8FT#^zi&IL{9H?xHU!(>!!e${wT4$GqBa3H>xiG*Va3d7hBl
> >> z$-
> lAV)_T3WsTa}QwwT;{)^yFKtnb^bPxFJExzl=W&oejIewS6dj^AhH>tVh&*5~e`
> >>
> zja9dg7?{KsZ_$^!dgjpQL9gf03g&nvnzMv6vp=S9DYVsnn`y<1qkR|cAF7hLwo&4_
> >> z$0b%#ug_6NWfb*$Il}q#a(!Ob6=ePMXrpB-
> v<#HJEP3C!v!5@<?;Dn1MU0<*f8Qxz
> >>
> zAjU7*@~eyS)8C3a`2}PA^u1Eoi5NfK?_u^^&&MtM&ozI+{=2wFEidM}?R=ite~tg7
> >> zpYGYyoP*`0xugV=o@1RyFwcMDQ>Obe;jicCb=vBh2MhU4<KB$Vk2NcQ<(`-
> qXixrA
> >> z8^49!$+$sGAily`auZvb-$fkYEIElgD0dJaC)$bQXUsw`@urBL?<RiJ1G^-)6L-BT
> >> z@#-RprR2w-
> mqwqPKV$B{bA8MiN1HEyEpap~@gZZ_*el!TTw^JF*(K5a0Q2#@rtsUg
> >> zt6SovowDhaJ<ob6YnhO-UOUgSow9UNkB-
> M#+sN~3dy@Qhi9cEVf73Z`N^D^5uW{WK
> >> zME%~Yvas61t;E=S%Z@SO6V|;&h-
> h!3cbdD!=(z6g@jH#a_vpS&+;={={DQpi2<!K6
> >> DeEY6F
> >>
> >> literal 0
> >> HcmV?d00001
> >>
> >> --
> >> 2.23.0
> >>
> >
>
>
> ------Please consider the environment before printing this e-mail.
^ permalink raw reply
* Re: [PATCH bpf-next v6 00/12] XDP unaligned chunk placement support
From: Jonathan Lemon @ 2019-08-30 15:52 UTC (permalink / raw)
To: Kevin Laatz
Cc: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
saeedm, maximmi, stephen, bruce.richardson, ciara.loftus, bpf,
intel-wired-lan
In-Reply-To: <20190827022531.15060-1-kevin.laatz@intel.com>
On 26 Aug 2019, at 19:25, Kevin Laatz wrote:
> This patch set adds the ability to use unaligned chunks in the XDP umem.
Thanks, Kevin for your hard work and perseverance on this patch set!
--
Jonathan
^ permalink raw reply
* Re: [PATCH bpf-next v6 12/12] doc/af_xdp: include unaligned chunk case
From: Jonathan Lemon @ 2019-08-30 15:51 UTC (permalink / raw)
To: Kevin Laatz
Cc: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
saeedm, maximmi, stephen, bruce.richardson, ciara.loftus, bpf,
intel-wired-lan
In-Reply-To: <20190827022531.15060-13-kevin.laatz@intel.com>
On 26 Aug 2019, at 19:25, Kevin Laatz wrote:
> The addition of unaligned chunks mode, the documentation needs to be
> updated to indicate that the incoming addr to the fill ring will only be
> masked if the user application is run in the aligned chunk mode. This patch
> also adds a line to explicitly indicate that the incoming addr will not be
> masked if running the user application in the unaligned chunk mode.
>
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
^ permalink raw reply
* Re: [PATCH bpf-next v6 11/12] samples/bpf: use hugepages in xdpsock app
From: Jonathan Lemon @ 2019-08-30 15:51 UTC (permalink / raw)
To: Kevin Laatz
Cc: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
saeedm, maximmi, stephen, bruce.richardson, ciara.loftus, bpf,
intel-wired-lan
In-Reply-To: <20190827022531.15060-12-kevin.laatz@intel.com>
On 26 Aug 2019, at 19:25, Kevin Laatz wrote:
> This patch modifies xdpsock to use mmap instead of posix_memalign. With
> this change, we can use hugepages when running the application in unaligned
> chunks mode. Using hugepages makes it more likely that we have physically
> contiguous memory, which supports the unaligned chunk mode better.
>
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
^ permalink raw reply
* Re: [PATCH bpf-next v6 10/12] samples/bpf: add buffer recycling for unaligned chunks to xdpsock
From: Jonathan Lemon @ 2019-08-30 15:49 UTC (permalink / raw)
To: Kevin Laatz
Cc: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
saeedm, maximmi, stephen, bruce.richardson, ciara.loftus, bpf,
intel-wired-lan
In-Reply-To: <20190827022531.15060-11-kevin.laatz@intel.com>
On 26 Aug 2019, at 19:25, Kevin Laatz wrote:
> This patch adds buffer recycling support for unaligned buffers. Since we
> don't mask the addr to 2k at umem_reg in unaligned mode, we need to make
> sure we give back the correct (original) addr to the fill queue. We achieve
> this using the new descriptor format and associated masks. The new format
> uses the upper 16-bits for the offset and the lower 48-bits for the addr.
> Since we have a field for the offset, we no longer need to modify the
> actual address. As such, all we have to do to get back the original address
> is mask for the lower 48 bits (i.e. strip the offset and we get the address
> on it's own).
>
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
^ permalink raw reply
* Re: [PATCH v2 1/1] netfilter: nf_tables: fib: Drop IPV6 packages if IPv6 is disabled on boot
From: Leonardo Bras @ 2019-08-30 15:48 UTC (permalink / raw)
To: Florian Westphal
Cc: Pablo Neira Ayuso, David S. Miller, netfilter-devel, coreteam,
netdev, linux-kernel, Jozsef Kadlecsik, Alexey Kuznetsov,
Hideaki YOSHIFUJI
In-Reply-To: <20190829205832.GM20113@breakpoint.cc>
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
On Thu, 2019-08-29 at 22:58 +0200, Florian Westphal wrote:
[...]
> 1. add a patch to BREAK in nft_fib_netdev.c for !ipv6_mod_enabled()
[...]
But this is still needed? I mean, in nft_fib_netdev_eval there are only
2 functions being called for IPv6 protocol : nft_fib6_eval and
nft_fib6_eval_type. Both are already protected by this current patch.
Is your 1st suggestion about this patch, or you think it's better to
move this change to nft_fib_netdev_eval ?
Best regards,
Leonardo Bras
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH bpf-next v6 09/12] samples/bpf: add unaligned chunks mode support to xdpsock
From: Jonathan Lemon @ 2019-08-30 15:47 UTC (permalink / raw)
To: Kevin Laatz
Cc: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
saeedm, maximmi, stephen, bruce.richardson, ciara.loftus, bpf,
intel-wired-lan
In-Reply-To: <20190827022531.15060-10-kevin.laatz@intel.com>
On 26 Aug 2019, at 19:25, Kevin Laatz wrote:
> This patch adds support for the unaligned chunks mode. The addition of the
> unaligned chunks option will allow users to run the application with more
> relaxed chunk placement in the XDP umem.
>
> Unaligned chunks mode can be used with the '-u' or '--unaligned' command
> line options.
>
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
> Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
^ permalink raw reply
* Re: [PATCH bpf-next v6 08/12] libbpf: add flags to umem config
From: Jonathan Lemon @ 2019-08-30 15:46 UTC (permalink / raw)
To: Kevin Laatz
Cc: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
saeedm, maximmi, stephen, bruce.richardson, ciara.loftus, bpf,
intel-wired-lan
In-Reply-To: <20190827022531.15060-9-kevin.laatz@intel.com>
On 26 Aug 2019, at 19:25, Kevin Laatz wrote:
> This patch adds a 'flags' field to the umem_config and umem_reg structs.
> This will allow for more options to be added for configuring umems.
>
> The first use for the flags field is to add a flag for unaligned chunks
> mode. These flags can either be user-provided or filled with a default.
>
> Since we change the size of the xsk_umem_config struct, we need to version
> the ABI. This patch includes the ABI versioning for xsk_umem__create. The
> Makefile was also updated to handle multiple function versions in
> check-abi.
>
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
> Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
^ permalink raw reply
* RE: [PATCH v2 1/6] mdev: Introduce sha1 based mdev alias
From: Parav Pandit @ 2019-08-30 15:45 UTC (permalink / raw)
To: Cornelia Huck
Cc: alex.williamson@redhat.com, Jiri Pirko, kwankhede@nvidia.com,
davem@davemloft.net, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20190830160223.332fd81f.cohuck@redhat.com>
> -----Original Message-----
> From: Cornelia Huck <cohuck@redhat.com>
> Sent: Friday, August 30, 2019 7:32 PM
> To: Parav Pandit <parav@mellanox.com>
> Cc: alex.williamson@redhat.com; Jiri Pirko <jiri@mellanox.com>;
> kwankhede@nvidia.com; davem@davemloft.net; kvm@vger.kernel.org; linux-
> kernel@vger.kernel.org; netdev@vger.kernel.org
> Subject: Re: [PATCH v2 1/6] mdev: Introduce sha1 based mdev alias
>
> On Fri, 30 Aug 2019 12:58:04 +0000
> Parav Pandit <parav@mellanox.com> wrote:
>
> > > -----Original Message-----
> > > From: Cornelia Huck <cohuck@redhat.com>
> > > Sent: Friday, August 30, 2019 6:09 PM
> > > To: Parav Pandit <parav@mellanox.com>
> > > Cc: alex.williamson@redhat.com; Jiri Pirko <jiri@mellanox.com>;
> > > kwankhede@nvidia.com; davem@davemloft.net; kvm@vger.kernel.org;
> > > linux- kernel@vger.kernel.org; netdev@vger.kernel.org
> > > Subject: Re: [PATCH v2 1/6] mdev: Introduce sha1 based mdev alias
> > >
> > > On Fri, 30 Aug 2019 12:33:22 +0000
> > > Parav Pandit <parav@mellanox.com> wrote:
> > >
> > > > > -----Original Message-----
> > > > > From: Cornelia Huck <cohuck@redhat.com>
> > > > > Sent: Friday, August 30, 2019 2:47 PM
> > > > > To: Parav Pandit <parav@mellanox.com>
> > > > > Cc: alex.williamson@redhat.com; Jiri Pirko <jiri@mellanox.com>;
> > > > > kwankhede@nvidia.com; davem@davemloft.net; kvm@vger.kernel.org;
> > > > > linux- kernel@vger.kernel.org; netdev@vger.kernel.org
> > > > > Subject: Re: [PATCH v2 1/6] mdev: Introduce sha1 based mdev
> > > > > alias
> > > > >
> > > > > On Thu, 29 Aug 2019 06:18:59 -0500 Parav Pandit
> > > > > <parav@mellanox.com> wrote:
> > > > >
> > > > > > Some vendor drivers want an identifier for an mdev device that
> > > > > > is shorter than the UUID, due to length restrictions in the
> > > > > > consumers of that identifier.
> > > > > >
> > > > > > Add a callback that allows a vendor driver to request an alias
> > > > > > of a specified length to be generated for an mdev device. If
> > > > > > generated, that alias is checked for collisions.
> > > > > >
> > > > > > It is an optional attribute.
> > > > > > mdev alias is generated using sha1 from the mdev name.
> > > > > >
> > > > > > Signed-off-by: Parav Pandit <parav@mellanox.com>
> > > > > >
> > > > > > ---
> > > > > > Changelog:
> > > > > > v1->v2:
> > > > > > - Kept mdev_device naturally aligned
> > > > > > - Added error checking for crypt_*() calls
> > > > > > - Corrected a typo from 'and' to 'an'
> > > > > > - Changed return type of generate_alias() from int to char*
> > > > > > v0->v1:
> > > > > > - Moved alias length check outside of the parent lock
> > > > > > - Moved alias and digest allocation from kvzalloc to kzalloc
> > > > > > - &alias[0] changed to alias
> > > > > > - alias_length check is nested under get_alias_length
> > > > > > callback check
> > > > > > - Changed comments to start with an empty line
> > > > > > - Fixed cleaunup of hash if mdev_bus_register() fails
> > > > > > - Added comment where alias memory ownership is handed over
> > > > > > to mdev device
> > > > > > - Updated commit log to indicate motivation for this feature
> > > > > > ---
> > > > > > drivers/vfio/mdev/mdev_core.c | 123
> > > > > ++++++++++++++++++++++++++++++-
> > > > > > drivers/vfio/mdev/mdev_private.h | 5 +-
> > > > > > drivers/vfio/mdev/mdev_sysfs.c | 13 ++--
> > > > > > include/linux/mdev.h | 4 +
> > > > > > 4 files changed, 135 insertions(+), 10 deletions(-)
> > >
> > > > > ...and detached from the local variable here. Who is freeing it?
> > > > > The comment states that it is done by the mdev, but I don't see it?
> > > > >
> > > > mdev_device_free() frees it.
> > >
> > > Ah yes, I overlooked the kfree().
> > >
> > > > once its assigned to mdev, mdev is the owner of it.
> > > >
> > > > > This detour via the local variable looks weird to me. Can you
> > > > > either create the alias directly in the mdev (would need to
> > > > > happen later in the function, but I'm not sure why you generate
> > > > > the alias before checking for duplicates anyway), or do an explicit copy?
> > > > Alias duplicate check is done after generating it, because
> > > > duplicate alias are
> > > not allowed.
> > > > The probability of collision is rare.
> > > > So it is speculatively generated without hold the lock, because
> > > > there is no
> > > need to hold the lock.
> > > > It is compared along with guid while mutex lock is held in single loop.
> > > > And if it is duplicate, there is no need to allocate mdev.
> > > >
> > > > It will be sub optimal to run through the mdev list 2nd time after
> > > > mdev
> > > creation and after generating alias for duplicate check.
> > >
> > > Ok, but what about copying it? I find this "set local variable to
> > > NULL after ownership is transferred" pattern a bit unintuitive.
> > > Copying it to the mdev (and then unconditionally freeing it) looks more
> obvious to me.
> > Its not unconditionally freed.
>
> That's not what I have been saying :(
>
Ah I see. You want to allocate alias memory twice; once inside mdev device and another one in _create() function.
_create() one you want to free unconditionally.
Well, passing pointer is fine.
mdev_register_device() has similar little tricky pattern that makes parent = NULL on __find_parent_device() finds duplicate one.
Ownership transfer is more straight forward code.
It is similar to device_initialize(), device init sequence code, where once device_initialize is done, freeing the device memory will be left to the put_device(), we don't call kfree() on mdev device.
> > Its freed in the error unwinding path.
> > I think its ok along with the comment that describes this error path area.
>
> It is not wrong, but I'm not sure I like it.
Ok.
^ permalink raw reply
* Re: [PATCH bpf-next v6 07/12] net/mlx5e: Allow XSK frames smaller than a page
From: Jonathan Lemon @ 2019-08-30 15:45 UTC (permalink / raw)
To: Kevin Laatz
Cc: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
saeedm, maximmi, stephen, bruce.richardson, ciara.loftus, bpf,
intel-wired-lan
In-Reply-To: <20190827022531.15060-8-kevin.laatz@intel.com>
On 26 Aug 2019, at 19:25, Kevin Laatz wrote:
> From: Maxim Mikityanskiy <maximmi@mellanox.com>
>
> Relax the requirements to the XSK frame size to allow it to be smaller
> than a page and even not a power of two. The current implementation can
> work in this mode, both with Striding RQ and without it.
>
> The code that checks `mtu + headroom <= XSK frame size` is modified
> accordingly. Any frame size between 2048 and PAGE_SIZE is accepted.
>
> Functions that worked with pages only now work with XSK frames, even if
> their size is different from PAGE_SIZE.
>
> With XSK queues, regardless of the frame size, Striding RQ uses the
> stride size of PAGE_SIZE, and UMR MTTs are posted using starting
> addresses of frames, but PAGE_SIZE as page size. MTU guarantees that no
> packet data will overlap with other frames. UMR MTT size is made equal
> to the stride size of the RQ, because UMEM frames may come in random
> order, and we need to handle them one by one. PAGE_SIZE is just a power
> of two that is bigger than any allowed XSK frame size, and also it
> doesn't require making additional changes to the code.
>
> Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
> Reviewed-by: Saeed Mahameed <saeedm@mellanox.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
^ permalink raw reply
* Re: [PATCH bpf-next v6 06/12] mlx5e: modify driver for handling offsets
From: Jonathan Lemon @ 2019-08-30 15:43 UTC (permalink / raw)
To: Kevin Laatz
Cc: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
saeedm, maximmi, stephen, bruce.richardson, ciara.loftus, bpf,
intel-wired-lan
In-Reply-To: <20190827022531.15060-7-kevin.laatz@intel.com>
On 26 Aug 2019, at 19:25, Kevin Laatz wrote:
> With the addition of the unaligned chunks option, we need to make sure we
> handle the offsets accordingly based on the mode we are currently running
> in. This patch modifies the driver to appropriately mask the address for
> each case.
>
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
^ permalink raw reply
* Re: [PATCH bpf-next v6 05/12] ixgbe: modify driver for handling offsets
From: Jonathan Lemon @ 2019-08-30 15:42 UTC (permalink / raw)
To: Kevin Laatz
Cc: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
saeedm, maximmi, stephen, bruce.richardson, ciara.loftus, bpf,
intel-wired-lan
In-Reply-To: <20190827022531.15060-6-kevin.laatz@intel.com>
On 26 Aug 2019, at 19:25, Kevin Laatz wrote:
> With the addition of the unaligned chunks option, we need to make sure we
> handle the offsets accordingly based on the mode we are currently running
> in. This patch modifies the driver to appropriately mask the address for
> each case.
>
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
^ permalink raw reply
* Re: [PATCH bpf-next v6 04/12] i40e: modify driver for handling offsets
From: Jonathan Lemon @ 2019-08-30 15:42 UTC (permalink / raw)
To: Kevin Laatz
Cc: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
saeedm, maximmi, stephen, bruce.richardson, ciara.loftus, bpf,
intel-wired-lan
In-Reply-To: <20190827022531.15060-5-kevin.laatz@intel.com>
On 26 Aug 2019, at 19:25, Kevin Laatz wrote:
> With the addition of the unaligned chunks option, we need to make sure we
> handle the offsets accordingly based on the mode we are currently running
> in. This patch modifies the driver to appropriately mask the address for
> each case.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
^ permalink raw reply
* Re: [PATCH bpf-next v6 03/12] xsk: add support to allow unaligned chunk placement
From: Jonathan Lemon @ 2019-08-30 15:41 UTC (permalink / raw)
To: Kevin Laatz
Cc: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
saeedm, maximmi, stephen, bruce.richardson, ciara.loftus, bpf,
intel-wired-lan
In-Reply-To: <20190827022531.15060-4-kevin.laatz@intel.com>
On 26 Aug 2019, at 19:25, Kevin Laatz wrote:
> Currently, addresses are chunk size aligned. This means, we are very
> restricted in terms of where we can place chunk within the umem. For
> example, if we have a chunk size of 2k, then our chunks can only be placed
> at 0,2k,4k,6k,8k... and so on (ie. every 2k starting from 0).
>
> This patch introduces the ability to use unaligned chunks. With these
> changes, we are no longer bound to having to place chunks at a 2k (or
> whatever your chunk size is) interval. Since we are no longer dealing with
> aligned chunks, they can now cross page boundaries. Checks for page
> contiguity have been added in order to keep track of which pages are
> followed by a physically contiguous page.
>
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
> Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
^ permalink raw reply
* Re: [PATCH bpf-next v6 02/12] ixgbe: simplify Rx buffer recycle
From: Jonathan Lemon @ 2019-08-30 15:39 UTC (permalink / raw)
To: Kevin Laatz
Cc: netdev, ast, daniel, bjorn.topel, magnus.karlsson, jakub.kicinski,
saeedm, maximmi, stephen, bruce.richardson, ciara.loftus, bpf,
intel-wired-lan
In-Reply-To: <20190827022531.15060-3-kevin.laatz@intel.com>
On 26 Aug 2019, at 19:25, Kevin Laatz wrote:
> Currently, the dma, addr and handle are modified when we reuse Rx buffers
> in zero-copy mode. However, this is not required as the inputs to the
> function are copies, not the original values themselves. As we use the
> copies within the function, we can use the original 'obi' values
> directly without having to mask and add the headroom.
>
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
^ 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