* Re: [PATCH net-next 2/5] r8152: replace array with linking list for rx information
From: Jakub Kicinski @ 2019-08-06 21:40 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <20190806125342.4620a94f@cakuba.netronome.com>
On Tue, 6 Aug 2019 12:53:42 -0700, Jakub Kicinski wrote:
> > @@ -744,6 +745,8 @@ struct r8152 {
> > void (*autosuspend_en)(struct r8152 *tp, bool enable);
> > } rtl_ops;
> >
> > + atomic_t rx_count;
>
> I wonder what the advantage of rx_count being atomic is, perhpas it
> could be protected by the same lock as the list head?
Okay, I see you're using it to test the queue length without the lock in
a later patch.
^ permalink raw reply
* Re: [PATCH net-next v2] openvswitch: Print error when ovs_execute_actions() fails
From: David Miller @ 2019-08-06 21:38 UTC (permalink / raw)
To: pkusunyifeng; +Cc: netdev, pshelar, gvrose8192
In-Reply-To: <1564973771-22542-1-git-send-email-pkusunyifeng@gmail.com>
From: Yifeng Sun <pkusunyifeng@gmail.com>
Date: Sun, 4 Aug 2019 19:56:11 -0700
> Currently in function ovs_dp_process_packet(), return values of
> ovs_execute_actions() are silently discarded. This patch prints out
> an debug message when error happens so as to provide helpful hints
> for debugging.
> ---
> v1->v2: Fixed according to Pravin's review.
Applied.
^ permalink raw reply
* Re: [PATCH net 0/5] Fixes for SJA1105 DSA: FDBs, Learning and PTP
From: David Miller @ 2019-08-06 21:38 UTC (permalink / raw)
To: olteanv; +Cc: f.fainelli, vivien.didelot, andrew, netdev
In-Reply-To: <20190804223848.31676-1-olteanv@gmail.com>
From: Vladimir Oltean <olteanv@gmail.com>
Date: Mon, 5 Aug 2019 01:38:43 +0300
> This is an assortment of functional fixes for the sja1105 switch driver
> targeted for the "net" tree (although they apply on net-next just as
> well).
>
> Patch 1/5 ("net: dsa: sja1105: Fix broken learning with vlan_filtering
> disabled") repairs a breakage introduced in the early development stages
> of the driver: support for traffic from the CPU has broken "normal"
> frame forwarding (based on DMAC) - there is connectivity through the
> switch only because all frames are flooded.
> I debated whether this patch qualifies as a fix, since it puts the
> switch into a mode it has never operated in before (aka SVL). But
> "normal" forwarding did use to work before the "Traffic support for
> SJA1105 DSA driver" patchset, and arguably this patch should have been
> part of that.
> Also, it would be strange for this feature to be broken in the 5.2 LTS.
>
> Patch 2/5 ("net: dsa: sja1105: Use the LOCKEDS bit for SJA1105 E/T as
> well") is a simplification of a previous FDB-related patch that is
> currently in the 5.3 rc's.
>
> Patches 3/5 - 5/5 fix various crashes found while running linuxptp over the
> switch ports for extended periods of time, or in conjunction with other
> error conditions. The fixed-up commits were all introduced in 5.2.
Series applied.
^ permalink raw reply
* Re: [PATCH v2] net/mlx5e: Use refcount_t for refcount
From: Saeed Mahameed @ 2019-08-06 21:25 UTC (permalink / raw)
To: davem@davemloft.net
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
hslester96@gmail.com, linux-rdma@vger.kernel.org, leon@kernel.org
In-Reply-To: <20190806.134848.2232719643712591918.davem@davemloft.net>
On Tue, 2019-08-06 at 13:48 -0700, David Miller wrote:
> From: Saeed Mahameed <saeedm@mellanox.com>
> Date: Tue, 6 Aug 2019 20:42:56 +0000
>
> > On Sat, 2019-08-03 at 00:48 +0800, Chuhong Yuan wrote:
> > > refcount_t is better for reference counters since its
> > > implementation can prevent overflows.
> > > So convert atomic_t ref counters to refcount_t.
> > >
> > > Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
> > > ---
> > > Changes in v2:
> > > - Add #include.
> > >
> >
> > Acked-by: Saeed Mahameed <saeedm@mellanox.com>
> >
> > Dave, up to you take it, or leave it to me :).
>
> Please take it, thank you.
Ok, running some build tests will apply shortly to net-next-mlx5.
Thanks everyone!
^ permalink raw reply
* Re: [PATCH net-next 00/10] Support tunnels over VLAN in NFP
From: David Miller @ 2019-08-06 21:24 UTC (permalink / raw)
To: john.hurley; +Cc: netdev, simon.horman, jakub.kicinski, oss-drivers
In-Reply-To: <1564931351-1036-1-git-send-email-john.hurley@netronome.com>
From: John Hurley <john.hurley@netronome.com>
Date: Sun, 4 Aug 2019 16:09:02 +0100
> This patchset deals with tunnel encap and decap when the end-point IP
> address is on an internal port (for example and OvS VLAN port). Tunnel
> encap without VLAN is already supported in the NFP driver. This patchset
> extends that to include a push VLAN along with tunnel header push.
>
> Patches 1-4 extend the flow_offload IR API to include actions that use
> skbedit to set the ptype of an SKB and that send a packet to port ingress
> from the act_mirred module. Such actions are used in flower rules that
> forward tunnel packets to internal ports where they can be decapsulated.
> OvS and its TC API is an example of a user-space app that produces such
> rules.
>
> Patch 5 modifies the encap offload code to allow the pushing of a VLAN
> header after a tunnel header push.
>
> Patches 6-10 deal with tunnel decap when the end-point is on an internal
> port. They detect 'pre-tunnel rules' which do not deal with tunnels
> themselves but, rather, forward packets to internal ports where they
> can be decapped if required. Such rules are offloaded to a table in HW
> along with an indication of whether packets need to be passed to this
> table of not (based on their destination MAC address). Matching against
> this table prior to decapsulation in HW allows the correct parsing and
> handling of outer VLANs on tunnelled packets and the correct updating of
> stats for said 'pre-tunnel' rules.
Series applied, thanks John.
^ permalink raw reply
* linux-next: Fixes tag needs some work in the net tree
From: Stephen Rothwell @ 2019-08-06 21:22 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Roman Mashak
[-- Attachment #1: Type: text/plain, Size: 418 bytes --]
Hi all,
In commit
b35475c5491a ("net sched: update vlan action for batched events operations")
Fixes tag
Fixes: c7e2b9689 ("sched: introduce vlan action")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [net-next 0/8][pull request] 100GbE Intel Wired LAN Driver Updates 2019-08-04
From: David Miller @ 2019-08-06 21:21 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann
In-Reply-To: <20190804115926.31944-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sun, 4 Aug 2019 04:59:18 -0700
> This series contains more updates to fm10k from Jake Keller.
>
> Jake removes the unnecessary initialization of some variables to help
> resolve static code checker warnings. Explicitly return success during
> resume, since the value of 'err' is always success. Fixed a issue with
> incrementing a void pointer, which can produce undefined behavior. Used
> the __always_unused macro for function templates that are passed as
> parameters in functions, but are not used. Simplified the code by
> removing an unnecessary macro in determining the value of NON_Q_VECTORS.
> Fixed an issue, using bitwise operations to prevent the low address
> overwriting the high portion of the address.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH net-next] r8169: sync PCIe PHY init with vendor driver 8.047.01
From: David Miller @ 2019-08-06 21:20 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <52b6804e-b2d4-0724-9b71-45ec46f4b1b4@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sun, 4 Aug 2019 09:52:33 +0200
> Synchronize PCIe PHY initialization with vendor driver version 8.047.01.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] r8169: add helper r8168_mac_ocp_modify
From: David Miller @ 2019-08-06 21:20 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <dc905b86-2852-86c2-be14-22164bd4a06d@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sun, 4 Aug 2019 09:47:51 +0200
> Add a helper for MAC OCP read-modify-write operations.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] r8169: remove access to legacy register MultiIntr
From: David Miller @ 2019-08-06 21:20 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <d550e704-3854-d91e-22fd-253ede944c3e@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sun, 4 Aug 2019 09:42:57 +0200
> This code piece was inherited from RTL8139 code, the register at
> address 0x5c however has a different meaning on RTL8169 and is unused.
> So we can remove this.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/2] Two small fq_codel optimizations
From: David Miller @ 2019-08-06 21:18 UTC (permalink / raw)
To: dave.taht; +Cc: netdev
In-Reply-To: <1564875449-12122-1-git-send-email-dave.taht@gmail.com>
From: Dave Taht <dave.taht@gmail.com>
Date: Sat, 3 Aug 2019 16:37:27 -0700
> These two patches improve fq_codel performance
> under extreme network loads. The first patch
> more rapidly escalates the codel count under
> overload, the second just kills a totally useless
> statistic.
>
> (sent together because they'd otherwise conflict)
>
> Signed-off-by: Dave Taht <dave.taht@gmail.com>
Series applied.
^ permalink raw reply
* Re: [PATCH net 0/2] action fixes for flow_offload infra compatibility
From: David Miller @ 2019-08-06 21:15 UTC (permalink / raw)
To: vladbu; +Cc: netdev, pieter.jansenvanvuuren, jhs, xiyou.wangcong, jiri
In-Reply-To: <20190803133619.10574-1-vladbu@mellanox.com>
From: Vlad Buslov <vladbu@mellanox.com>
Date: Sat, 3 Aug 2019 16:36:17 +0300
> Fix rcu warnings due to usage of action helpers that expect rcu read lock
> protection from rtnl-protected context of flow_offload infra.
Series applied.
^ permalink raw reply
* Re: [PATCH v1 0/3] net: hisilicon: Fix a few problems with hip04_eth
From: David Miller @ 2019-08-06 21:15 UTC (permalink / raw)
To: xiaojiangfeng
Cc: yisen.zhuang, salil.mehta, netdev, linux-kernel, leeyou.li,
xiaowei774, nixiaoming
In-Reply-To: <1564835501-90257-1-git-send-email-xiaojiangfeng@huawei.com>
From: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
Date: Sat, 3 Aug 2019 20:31:38 +0800
> During the use of the hip04_eth driver,
> several problems were found,
> which solved the hip04_tx_reclaim reentry problem,
> fixed the problem that hip04_mac_start_xmit never
> returns NETDEV_TX_BUSY
> and the dma_map_single failed on the arm64 platform.
Series applied.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: modify assignment to OR for dev_flags in phy_attach_direct
From: Andrew Lunn @ 2019-08-06 21:11 UTC (permalink / raw)
To: Tao Ren
Cc: Florian Fainelli, Heiner Kallweit, David S . Miller,
Vladimir Oltean, Arun Parameswaran, Justin Chen, netdev,
linux-kernel, openbmc
In-Reply-To: <20190805185551.3140564-1-taoren@fb.com>
On Mon, Aug 05, 2019 at 11:55:51AM -0700, Tao Ren wrote:
> Modify the assignment to OR when dealing with phydev->dev_flags in
> phy_attach_direct function, and this is to make sure dev_flags set in
> driver's probe callback won't be lost.
>
> Suggested-by: Andrew Lunn <andrew@lunn.ch>
> CC: Heiner Kallweit <hkallweit1@gmail.com>
> CC: Vladimir Oltean <olteanv@gmail.com>
> Signed-off-by: Tao Ren <taoren@fb.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v2] net: mdio-octeon: Fix Kconfig warnings and build errors
From: David Miller @ 2019-08-06 21:11 UTC (permalink / raw)
To: natechancellor
Cc: andrew, broonie, devel, f.fainelli, gregkh, hkallweit1,
kernel-build-reports, linux-arm-kernel, linux-next, lkp, netdev,
rdunlap, willy
In-Reply-To: <20190803060155.89548-1-natechancellor@gmail.com>
From: Nathan Chancellor <natechancellor@gmail.com>
Date: Fri, 2 Aug 2019 23:01:56 -0700
> After commit 171a9bae68c7 ("staging/octeon: Allow test build on
> !MIPS"), the following combination of configs cause a few Kconfig
> warnings and build errors (distilled from arm allyesconfig and Randy's
> randconfig builds):
>
> CONFIG_NETDEVICES=y
> CONFIG_STAGING=y
> CONFIG_COMPILE_TEST=y
>
> and CONFIG_OCTEON_ETHERNET as either a module or built-in.
>
> WARNING: unmet direct dependencies detected for MDIO_OCTEON
> Depends on [n]: NETDEVICES [=y] && MDIO_DEVICE [=y] && MDIO_BUS [=y]
> && 64BIT [=n] && HAS_IOMEM [=y] && OF_MDIO [=n]
> Selected by [y]:
> - OCTEON_ETHERNET [=y] && STAGING [=y] && (CAVIUM_OCTEON_SOC ||
> COMPILE_TEST [=y]) && NETDEVICES [=y]
>
> In file included from ../drivers/net/phy/mdio-octeon.c:14:
> ../drivers/net/phy/mdio-cavium.h:111:36: error: implicit declaration of
> function ‘writeq’; did you mean ‘writel’?
> [-Werror=implicit-function-declaration]
> 111 | #define oct_mdio_writeq(val, addr) writeq(val, (void *)addr)
> | ^~~~~~
>
> CONFIG_64BIT is not strictly necessary if the proper readq/writeq
> definitions are included from io-64-nonatomic-lo-hi.h.
>
> CONFIG_OF_MDIO is not needed when CONFIG_COMPILE_TEST is enabled because
> of commit f9dc9ac51610 ("of/mdio: Add dummy functions in of_mdio.h.").
>
> Fixes: 171a9bae68c7 ("staging/octeon: Allow test build on !MIPS")
> Reported-by: kbuild test robot <lkp@intel.com>
> Reported-by: Mark Brown <broonie@kernel.org>
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Applied to net-next.
Please make it clear what tree your changes are targetting in the future,
thank you.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: dump CPU port regs through master
From: David Miller @ 2019-08-06 21:08 UTC (permalink / raw)
To: vivien.didelot; +Cc: netdev, f.fainelli, andrew, linville, cphealy
In-Reply-To: <20190802193455.17126-2-vivien.didelot@gmail.com>
From: Vivien Didelot <vivien.didelot@gmail.com>
Date: Fri, 2 Aug 2019 15:34:55 -0400
> Merge the CPU port registers dump into the master interface registers
> dump through ethtool, by nesting the ethtool_drvinfo and ethtool_regs
> structures of the CPU port into the dump.
>
> drvinfo->regdump_len will contain the full data length, while regs->len
> will contain only the master interface registers dump length.
>
> This allows for example to dump the CPU port registers on a ZII Dev
> C board like this:
...
> Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com>
Applied, thanks Vivien.
^ permalink raw reply
* Re: [PATCH net 0/2] Fix batched event generation for vlan action
From: David Miller @ 2019-08-06 21:06 UTC (permalink / raw)
To: mrv; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri
In-Reply-To: <1564773407-26209-1-git-send-email-mrv@mojatatu.com>
From: Roman Mashak <mrv@mojatatu.com>
Date: Fri, 2 Aug 2019 15:16:45 -0400
> When adding or deleting a batch of entries, the kernel sends up to
> TCA_ACT_MAX_PRIO (defined to 32 in kernel) entries in an event to user
> space. However it does not consider that the action sizes may vary and
> require different skb sizes.
>
> For example, consider the following script adding 32 entries with all
> supported vlan parameters (in order to maximize netlink messages size):
>
> % cat tc-batch.sh
> TC="sudo /mnt/iproute2.git/tc/tc"
>
> $TC actions flush action vlan
> for i in `seq 1 $1`;
> do
> cmd="action vlan push protocol 802.1q id 4094 priority 7 pipe \
> index $i cookie aabbccddeeff112233445566778800a1 "
> args=$args$cmd
> done
> $TC actions add $args
> %
> % ./tc-batch.sh 32
> Error: Failed to fill netlink attributes while adding TC action.
> We have an error talking to the kernel
> %
>
> patch 1 adds callback in tc_action_ops of vlan action, which calculates
> the action size, and passes size to tcf_add_notify()/tcf_del_notify().
>
> patch 2 updates the TDC test suite with relevant vlan test cases.
Series applied and patch #1 queued up for -stable.
^ permalink raw reply
* Re: [PATCH][net-next][V2] net/mlx5: remove self-assignment on esw->dev
From: Saeed Mahameed @ 2019-08-06 21:01 UTC (permalink / raw)
To: linux-rdma@vger.kernel.org, colin.king@canonical.com,
davem@davemloft.net, leon@kernel.org, netdev@vger.kernel.org
Cc: kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20190802151316.16011-1-colin.king@canonical.com>
On Fri, 2019-08-02 at 16:13 +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> There is a self assignment of esw->dev to itself, clean this up by
> removing it. Also make dev a const pointer.
>
> Addresses-Coverity: ("Self assignment")
> Fixes: 6cedde451399 ("net/mlx5: E-Switch, Verify support QoS element
> type")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
>
> V2: make dev const
>
Applied to mlx5-next.
Thanks,
Saeed.
^ permalink raw reply
* Re: [PATCH net] inet: frags: re-introduce skb coalescing for local delivery
From: David Miller @ 2019-08-06 20:57 UTC (permalink / raw)
To: gnault; +Cc: netdev, fw, edumazet, posk, alex.aring
In-Reply-To: <22d8da10c97214edd0677e6478093ad9376180ef.1564758715.git.gnault@redhat.com>
From: Guillaume Nault <gnault@redhat.com>
Date: Fri, 2 Aug 2019 17:15:03 +0200
> Before commit d4289fcc9b16 ("net: IP6 defrag: use rbtrees for IPv6
> defrag"), a netperf UDP_STREAM test[0] using big IPv6 datagrams (thus
> generating many fragments) and running over an IPsec tunnel, reported
> more than 6Gbps throughput. After that patch, the same test gets only
> 9Mbps when receiving on a be2net nic (driver can make a big difference
> here, for example, ixgbe doesn't seem to be affected).
>
> By reusing the IPv4 defragmentation code, IPv6 lost fragment coalescing
> (IPv4 fragment coalescing was dropped by commit 14fe22e33462 ("Revert
> "ipv4: use skb coalescing in defragmentation"")).
...
> Re-introducing fragment coalescing is enough to get the initial
> performances again (6.6Gbps with be2net): driver doesn't drop frames
> anymore (no more rx_drops_no_frags errors) and the reassembly engine
> works at full speed.
>
> This patch is quite conservative and only coalesces skbs for local
> IPv4 and IPv6 delivery (in order to avoid changing skb geometry when
> forwarding). Coalescing could be extended in the future if need be, as
> more scenarios would probably benefit from it.
Eric and Florian, please review.
^ permalink raw reply
* Re: [PATCH v2] net/mlx5e: Use refcount_t for refcount
From: David Miller @ 2019-08-06 20:48 UTC (permalink / raw)
To: saeedm; +Cc: hslester96, linux-rdma, netdev, leon, linux-kernel
In-Reply-To: <aaf9680afe5c62d0cf71ff4382b66b3e4d735008.camel@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Tue, 6 Aug 2019 20:42:56 +0000
> On Sat, 2019-08-03 at 00:48 +0800, Chuhong Yuan wrote:
>> refcount_t is better for reference counters since its
>> implementation can prevent overflows.
>> So convert atomic_t ref counters to refcount_t.
>>
>> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
>> ---
>> Changes in v2:
>> - Add #include.
>>
>
> Acked-by: Saeed Mahameed <saeedm@mellanox.com>
>
> Dave, up to you take it, or leave it to me :).
Please take it, thank you.
^ permalink raw reply
* Re: [PATCH v6 1/3] mm/gup: add make_dirty arg to put_user_pages_dirty_lock()
From: John Hubbard @ 2019-08-06 20:43 UTC (permalink / raw)
To: Ira Weiny, john.hubbard
Cc: Andrew Morton, Alexander Viro, Björn Töpel,
Boaz Harrosh, Christoph Hellwig, Daniel Vetter, Dan Williams,
Dave Chinner, David Airlie, David S . Miller, Ilya Dryomov,
Jan Kara, Jason Gunthorpe, Jens Axboe, Jérôme Glisse,
Johannes Thumshirn, Magnus Karlsson, Matthew Wilcox,
Miklos Szeredi, Ming Lei, Sage Weil, Santosh Shilimkar, Yan Zheng,
netdev, dri-devel, linux-mm, linux-rdma, bpf, LKML
In-Reply-To: <20190806174017.GB4748@iweiny-DESK2.sc.intel.com>
On 8/6/19 10:40 AM, Ira Weiny wrote:
> On Sun, Aug 04, 2019 at 02:40:40PM -0700, john.hubbard@gmail.com wrote:
>> From: John Hubbard <jhubbard@nvidia.com>
>>
>> Provide a more capable variation of put_user_pages_dirty_lock(),
>> and delete put_user_pages_dirty(). This is based on the
>> following:
>>
>> 1. Lots of call sites become simpler if a bool is passed
>> into put_user_page*(), instead of making the call site
>> choose which put_user_page*() variant to call.
>>
>> 2. Christoph Hellwig's observation that set_page_dirty_lock()
>> is usually correct, and set_page_dirty() is usually a
>> bug, or at least questionable, within a put_user_page*()
>> calling chain.
>>
>> This leads to the following API choices:
>>
>> * put_user_pages_dirty_lock(page, npages, make_dirty)
>>
>> * There is no put_user_pages_dirty(). You have to
>> hand code that, in the rare case that it's
>> required.
>>
>> Reviewed-by: Christoph Hellwig <hch@lst.de>
>> Cc: Matthew Wilcox <willy@infradead.org>
>> Cc: Jan Kara <jack@suse.cz>
>> Cc: Ira Weiny <ira.weiny@intel.com>
>> Cc: Jason Gunthorpe <jgg@ziepe.ca>
>> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
>
> I assume this is superseded by the patch in the large series?
>
Actually, it's the other way around (there is a note that that effect
in the admittedly wall-of-text cover letter [1] in the 34-patch series.
However, I'm trying hard to ensure that it doesn't actually matter:
* Patch 1 in the latest of each patch series, is identical
* I'm reposting the two series together.
...and yes, it might have been better to merge the two patchsets, but
the smaller one is more reviewable. And as a result, Andrew has already
merged it into the akpm tree.
[1] https://lore.kernel.org/r/20190804224915.28669-1-jhubbard@nvidia.com
thanks,
--
John Hubbard
NVIDIA
^ permalink raw reply
* Re: [PATCH v2] net/mlx5e: Use refcount_t for refcount
From: Saeed Mahameed @ 2019-08-06 20:42 UTC (permalink / raw)
To: hslester96@gmail.com
Cc: linux-rdma@vger.kernel.org, davem@davemloft.net,
netdev@vger.kernel.org, leon@kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190802164828.20243-1-hslester96@gmail.com>
On Sat, 2019-08-03 at 00:48 +0800, Chuhong Yuan wrote:
> refcount_t is better for reference counters since its
> implementation can prevent overflows.
> So convert atomic_t ref counters to refcount_t.
>
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
> ---
> Changes in v2:
> - Add #include.
>
Acked-by: Saeed Mahameed <saeedm@mellanox.com>
Dave, up to you take it, or leave it to me :).
^ permalink raw reply
* Re: [PATCH v3] mlx5: Use refcount_t for refcount
From: Saeed Mahameed @ 2019-08-06 20:40 UTC (permalink / raw)
To: hslester96@gmail.com
Cc: linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, davem@davemloft.net, jgg@ziepe.ca,
leon@kernel.org, dledford@redhat.com
In-Reply-To: <20190806015950.18167-1-hslester96@gmail.com>
On Tue, 2019-08-06 at 09:59 +0800, Chuhong Yuan wrote:
> Reference counters are preferred to use refcount_t instead of
> atomic_t.
> This is because the implementation of refcount_t can prevent
> overflows and detect possible use-after-free.
> So convert atomic_t ref counters to refcount_t.
>
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
> ---
> Changes in v3:
> - Merge v2 patches together.
>
> drivers/infiniband/hw/mlx5/srq_cmd.c | 6 +++---
> drivers/net/ethernet/mellanox/mlx5/core/qp.c | 6 +++---
> include/linux/mlx5/driver.h | 3 ++-
> 3 files changed, 8 insertions(+), 7 deletions(-)
>
LGTM, Leon, let me know if you are happy with this version,
this should go to mlx5-next.
^ permalink raw reply
* Re: [PATCH v2 01/34] mm/gup: add make_dirty arg to put_user_pages_dirty_lock()
From: John Hubbard @ 2019-08-06 20:39 UTC (permalink / raw)
To: Ira Weiny, john.hubbard
Cc: Andrew Morton, Christoph Hellwig, Dan Williams, Dave Chinner,
Dave Hansen, Jan Kara, Jason Gunthorpe, Jérôme Glisse,
LKML, amd-gfx, ceph-devel, devel, devel, dri-devel, intel-gfx,
kvm, linux-arm-kernel, linux-block, linux-crypto, linux-fbdev,
linux-fsdevel, linux-media, linux-mm, linux-nfs, linux-rdma,
linux-rpi-kernel, linux-xfs, netdev, rds-devel, sparclinux, x86,
xen-devel, Christoph Hellwig, Matthew Wilcox
In-Reply-To: <20190806173945.GA4748@iweiny-DESK2.sc.intel.com>
On 8/6/19 10:39 AM, Ira Weiny wrote:
> On Sun, Aug 04, 2019 at 03:48:42PM -0700, john.hubbard@gmail.com wrote:
>> From: John Hubbard <jhubbard@nvidia.com>
...
>> -
>> /**
>> - * put_user_pages_dirty() - release and dirty an array of gup-pinned pages
>> - * @pages: array of pages to be marked dirty and released.
>> + * put_user_pages_dirty_lock() - release and optionally dirty gup-pinned pages
>> + * @pages: array of pages to be maybe marked dirty, and definitely released.
>
> Better would be.
>
> @pages: array of pages to be put
OK, I'll change to that wording.
>
>> * @npages: number of pages in the @pages array.
>> + * @make_dirty: whether to mark the pages dirty
>> *
>> * "gup-pinned page" refers to a page that has had one of the get_user_pages()
>> * variants called on that page.
>> *
>> * For each page in the @pages array, make that page (or its head page, if a
>> - * compound page) dirty, if it was previously listed as clean. Then, release
>> - * the page using put_user_page().
>> + * compound page) dirty, if @make_dirty is true, and if the page was previously
>> + * listed as clean. In any case, releases all pages using put_user_page(),
>> + * possibly via put_user_pages(), for the non-dirty case.
>
> I don't think users of this interface need this level of detail. I think
> something like.
>
> * For each page in the @pages array, release the page. If @make_dirty is
> * true, mark the page dirty prior to release.
Yes, it is too wordy, I'll change to that.
>
...
>> -void put_user_pages_dirty_lock(struct page **pages, unsigned long npages)
>> -{
>> - __put_user_pages_dirty(pages, npages, set_page_dirty_lock);
>> + /*
>> + * TODO: this can be optimized for huge pages: if a series of pages is
>> + * physically contiguous and part of the same compound page, then a
>> + * single operation to the head page should suffice.
>> + */
>
> I think this comment belongs to the for loop below... or just something about
> how to make this and put_user_pages() more efficient. It is odd, that this is
> the same comment as in put_user_pages()...
Actually I think I'll just delete the comment entirely, it's just noise really.
>
> The code is good. So... Other than the comments.
>
> Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Thanks for the review!
thanks,
--
John Hubbard
NVIDIA
^ permalink raw reply
* Re: [PATCH 03/17] mlx5: no need to check return value of debugfs_create functions
From: Saeed Mahameed @ 2019-08-06 20:37 UTC (permalink / raw)
To: gregkh@linuxfoundation.org, netdev@vger.kernel.org; +Cc: leon@kernel.org
In-Reply-To: <20190806161128.31232-4-gregkh@linuxfoundation.org>
On Tue, 2019-08-06 at 18:11 +0200, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic
> should
> never do something different based on this.
>
> This cleans up a lot of unneeded code and logic around the debugfs
> files, making all of this much simpler and easier to understand as we
> don't need to keep the dentries saved anymore.
>
> Cc: Saeed Mahameed <saeedm@mellanox.com>
> Cc: Leon Romanovsky <leon@kernel.org>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Saeed Mahameed <saeedm@mellanox.com>
Some unexpected/undefined driver behavior might occur if some of the
debug_fs_* calls should fail in this driver, I will follow up with a
patch to address this.
Thanks,
Saeed.
^ 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;
as well as URLs for NNTP newsgroup(s).