* Re: [PATCH v3 00/15] soc: octeontx2: Add RVU admin function driver
From: Sunil Kovvuri @ 2018-09-11 16:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: LKML, olof, LAKML, linux-soc, Andrew Lunn, David S. Miller,
Linux Netdev List, Sunil Goutham
In-Reply-To: <CAK8P3a32gpNX42NuzmbW1PbsHpq7v7LoQ6WDeKtt=QiYbuyM7w@mail.gmail.com>
On Tue, Sep 11, 2018 at 7:07 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Sep 11, 2018 at 2:37 PM Sunil Kovvuri <sunil.kovvuri@gmail.com> wrote:
> >
> > Didn't receive any feedback for the v3 patch series over a week's time.
> > Can you please pick up these patches to merge into arm-soc ?
>
> I would still prefer to see the whole thing as part of drivers/net/
> instead of drivers/soc,
> and reviewed in full on the netdev side, including the parts that are
> not ethernet specific.
>
> Arnd
Hmm.. I agree that there are many networking terms used in the driver
but it's not a
networking driver, it's just a HW configuration driver which includes
how HW should
parse the packet. This driver doesn't fit into drivers/net.
Let's say if netdev driver in drivers/net/ethernet doesn't make use of
crypto feature
then i guess netdev maintainers would reject any patches which configure crypto
block. Also as i have been saying there are other scenarios as well.
Future silicons may add support for other features into this resource
virtualization unit's domain.
An example would be compression. Any patches which do compression
related HW configuration
might be rejected by netdev maintainers, cause they are no way related
to networking.
I will keep netdev mailing list in all the patch submissions but
moving this driver into drivers/net
doesn't sound right, from it's functionality perspective.
Thanks,
Sunil.
^ permalink raw reply
* Re: [PATCH net-next 0/8] bnxt_en: devlink param updates
From: Jakub Kicinski @ 2018-09-11 11:33 UTC (permalink / raw)
To: Vasundhara Volam; +Cc: davem, michael.chan, netdev, Alexander Duyck
In-Reply-To: <1536655505-14387-1-git-send-email-vasundhara-v.volam@broadcom.com>
On Tue, 11 Sep 2018 14:14:57 +0530, Vasundhara Volam wrote:
> This patchset adds support for 4 generic and 1 driver-specific devlink
> parameters.
>
> Also, this patchset adds support to return proper error code if
> HWRM_NVM_GET/SET_VARIABLE commands return error code
> HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED.
>
> Vasundhara Volam (8):
> devlink: Add generic parameter hw_tc_offload
Much like Jiri, I can't help but wonder why do you need this?
> devlink: Add generic parameter ignore_ari
> devlink: Add generic parameter msix_vec_per_pf_max
> devlink: Add generic parameter msix_vec_per_pf_min
IMHO more structured API would be preferable if possible. The string
keys won't scale if you want to set the parameters per PF, and
creating more structured API for PCIe which is a relatively slow
moving HW spec seems tractable.
Not to mention the question Alex posed before about where this knobs
should actually live. I'm personally fine with devlink.
> bnxt_en: Use hw_tc_offload and ignore_ari devlink parameters
> bnxt_en: return proper error when FW returns
> HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED
> bnxt_en: Use msix_vec_per_pf_max and msix_vec_per_pf_min devlink
> params.
> bnxt_en: Add a driver specific devlink parameter.
The details about the device specific devlink parameter are very much
lacking. Why does the patch subject not mention any specifics? What's
GRE in the first place?
You really need to provide more details and docs for all these
parameters.
^ permalink raw reply
* [PATCH net-next] qlcnic: Remove set but not used variables 'fw_mbx' and 'hdr_size'
From: YueHaibing @ 2018-09-11 11:51 UTC (permalink / raw)
To: Harish Patil, Manish Chopra, David S. Miller
Cc: Yue Haibing, Dept-GELinuxNICDev, netdev, kernel-janitors
From: Yue Haibing <yuehaibing@huawei.com>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c: In function 'qlcnic_sriov_pull_bc_msg':
drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c:907:6: warning:
variable 'fw_mbx' set but not used [-Wunused-but-set-variable]
drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c: In function 'qlcnic_sriov_issue_bc_post':
drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c:939:16: warning:
variable 'hdr_size' set but not used [-Wunused-but-set-variable]
Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c
index 77e386e..f7c2f32 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c
@@ -904,13 +904,11 @@ static void qlcnic_sriov_pull_bc_msg(struct qlcnic_adapter *adapter,
u32 *hdr, u32 *pay, u32 size)
{
struct qlcnic_hardware_context *ahw = adapter->ahw;
- u32 fw_mbx;
u8 i, max = 2, hdr_size, j;
hdr_size = (sizeof(struct qlcnic_bc_hdr) / sizeof(u32));
max = (size / sizeof(u32)) + hdr_size;
- fw_mbx = readl(QLCNIC_MBX_FW(ahw, 0));
for (i = 2, j = 0; j < hdr_size; i++, j++)
*(hdr++) = readl(QLCNIC_MBX_FW(ahw, i));
for (; j < max; i++, j++)
@@ -936,7 +934,7 @@ static int __qlcnic_sriov_issue_bc_post(struct qlcnic_vf_info *vf)
static int qlcnic_sriov_issue_bc_post(struct qlcnic_bc_trans *trans, u8 type)
{
struct qlcnic_vf_info *vf = trans->vf;
- u32 pay_size, hdr_size;
+ u32 pay_size;
u32 *hdr, *pay;
int ret;
u8 pci_func = trans->func_id;
@@ -947,14 +945,12 @@ static int qlcnic_sriov_issue_bc_post(struct qlcnic_bc_trans *trans, u8 type)
if (type == QLC_BC_COMMAND) {
hdr = (u32 *)(trans->req_hdr + trans->curr_req_frag);
pay = (u32 *)(trans->req_pay + trans->curr_req_frag);
- hdr_size = (sizeof(struct qlcnic_bc_hdr) / sizeof(u32));
pay_size = qlcnic_sriov_get_bc_paysize(trans->req_pay_size,
trans->curr_req_frag);
pay_size = (pay_size / sizeof(u32));
} else {
hdr = (u32 *)(trans->rsp_hdr + trans->curr_rsp_frag);
pay = (u32 *)(trans->rsp_pay + trans->curr_rsp_frag);
- hdr_size = (sizeof(struct qlcnic_bc_hdr) / sizeof(u32));
pay_size = qlcnic_sriov_get_bc_paysize(trans->rsp_pay_size,
trans->curr_rsp_frag);
pay_size = (pay_size / sizeof(u32));
^ permalink raw reply related
* Re: unexpected GRO/veth behavior
From: Paolo Abeni @ 2018-09-11 11:44 UTC (permalink / raw)
To: Eric Dumazet, netdev; +Cc: Toshiaki Makita
In-Reply-To: <ecb079cc-033d-0726-75ce-00eada2ae765@gmail.com>
On Tue, 2018-09-11 at 03:27 -0700, Eric Dumazet wrote:
> On 09/10/2018 11:54 PM, Paolo Abeni wrote:
> > I *think* we can hit a similar condition with a tun device in IFF_NAPI
> > mode.
>
> Why ?
>
> tun_get_user() does not attach skb to a socket, that would be quite useless since skb
>
I think we can hit this code path:
tun_get_user() -> tun_alloc_skb() -> sock_alloc_send_pskb() ->
skb_set_owner_w()
Than later napi and GRO.
Cheers,
Paolo
^ permalink raw reply
* Re: [Intel-wired-lan] e1000e driver stuck at 10Mbps after reconnection
From: Camille Bordignon @ 2018-09-11 11:46 UTC (permalink / raw)
To: Benjamin Poirier
Cc: Neftin, Sasha, Alexander Duyck, Netdev, intel-wired-lan,
David S. Miller, linux-kernel
In-Reply-To: <20180911083147.GA31642@f2>
Le mardi 11 sept. 2018 à 17:31:47 (+0900), Benjamin Poirier a écrit :
> On 2018/09/07 08:28, Camille Bordignon wrote:
> > Le mercredi 08 août 2018 à 18:00:28 (+0300), Neftin, Sasha a écrit :
> > > On 8/8/2018 17:24, Neftin, Sasha wrote:
> > > > On 8/7/2018 09:42, Camille Bordignon wrote:
> > > > > Le lundi 06 août 2018 à 15:45:29 (-0700), Alexander Duyck a écrit :
> > > > > > On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon
> > > > > > <camille.bordignon@easymile.com> wrote:
> > > > > > > Hello,
> > > > > > >
> > > > > > > Recently we experienced some issues with intel NIC (I219-LM
> > > > > > > and I219-V).
> > > > > > > It seems that after a wire reconnection, auto-negotation "fails" and
> > > > > > > link speed drips to 10 Mbps.
> > > > > > >
> [...]
> >
> > I recently figured out that neither the previous patch nor commit
> > 0b76aae741abb9d16d2c0e67f8b1e766576f897d fix this issue.
> >
> > In these cases, after reproducing the issue, when ethernet wire is connected
> > kernel logs mention full speed (1000 Mbps) but actually it seems it is not.
> > The problem persists.
> >
>
> Hmm, so the newer (post 4110e02eb45e) kernels are actually "better", in
> that they accurately report that link speed is 10Mb/s.
>
Exactly.
> In the end, do you know of a kernel version that doesn't exhibit the
> problem of slower actual link speed?
>
No. I've tried older version but at some point API has changed and
it fails to compile.
> I had a look at the code and I tried to reproduce the problem on the
> hardware that I have (I217) but could not.
>
> Also, out of curiosity, have you tried playing with the speed, autoneg
> and advertise settings via ethtool -s to force the link to 1000Mb/s?
Forcing the speed fixes the issue in any case (I mean even when speed is
wronly reported to 1000Mb/s).
Done this way:
#ethtool -s enp0s31f6 speed 1000 duplex full autoneg off
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/8] bnxt_en: devlink param updates
From: Jiri Pirko @ 2018-09-11 11:51 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Vasundhara Volam, davem, michael.chan, netdev, Alexander Duyck
In-Reply-To: <20180911133215.5798ed2a@cakuba>
Tue, Sep 11, 2018 at 01:33:51PM CEST, jakub.kicinski@netronome.com wrote:
>On Tue, 11 Sep 2018 14:14:57 +0530, Vasundhara Volam wrote:
>> This patchset adds support for 4 generic and 1 driver-specific devlink
>> parameters.
>>
>> Also, this patchset adds support to return proper error code if
>> HWRM_NVM_GET/SET_VARIABLE commands return error code
>> HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED.
>>
>> Vasundhara Volam (8):
>> devlink: Add generic parameter hw_tc_offload
>
>Much like Jiri, I can't help but wonder why do you need this?
>
>> devlink: Add generic parameter ignore_ari
>> devlink: Add generic parameter msix_vec_per_pf_max
>> devlink: Add generic parameter msix_vec_per_pf_min
>
>IMHO more structured API would be preferable if possible. The string
>keys won't scale if you want to set the parameters per PF, and
>creating more structured API for PCIe which is a relatively slow
>moving HW spec seems tractable.
>
>Not to mention the question Alex posed before about where this knobs
>should actually live. I'm personally fine with devlink.
>
>> bnxt_en: Use hw_tc_offload and ignore_ari devlink parameters
>> bnxt_en: return proper error when FW returns
>> HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED
>> bnxt_en: Use msix_vec_per_pf_max and msix_vec_per_pf_min devlink
>> params.
>> bnxt_en: Add a driver specific devlink parameter.
>
>The details about the device specific devlink parameter are very much
>lacking. Why does the patch subject not mention any specifics? What's
>GRE in the first place?
>
>You really need to provide more details and docs for all these
>parameters.
We really need Documentation/networking/devlink-params.txt to describe
these.
^ permalink raw reply
* [PATCH] qtnfmac: remove set but not used variable 'vif'
From: YueHaibing @ 2018-09-11 12:28 UTC (permalink / raw)
To: Igor Mitsyanko, Avinash Patil, Sergey Matyukevich, Kalle Valo,
Sergei Maksimenko, Vasily Ulyanov, Andrey Shevchenko
Cc: YueHaibing, linux-wireless, netdev, kernel-janitors
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c: In function 'qtnf_dump_survey':
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c:694:19: warning:
variable 'vif' set but not used [-Wunused-but-set-variable]
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
index 4aa332f..452d4b7 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
@@ -691,11 +691,8 @@ static int qtnf_set_default_key(struct wiphy *wiphy, struct net_device *dev,
const struct cfg80211_chan_def *chandef = &wdev->chandef;
struct ieee80211_channel *chan;
struct qtnf_chan_stats stats;
- struct qtnf_vif *vif;
int ret;
- vif = qtnf_netdev_get_priv(dev);
-
sband = wiphy->bands[NL80211_BAND_2GHZ];
if (sband && idx >= sband->n_channels) {
idx -= sband->n_channels;
^ permalink raw reply related
* [PATCH] wil6210: remove set but not used variable 'start'
From: YueHaibing @ 2018-09-11 12:32 UTC (permalink / raw)
To: Maya Erez, Kalle Valo
Cc: YueHaibing, linux-wireless, wil6210, netdev, kernel-janitors
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/ath/wil6210/pm.c: In function 'wil_suspend_keep_radio_on':
drivers/net/wireless/ath/wil6210/pm.c:193:16: warning:
variable 'start' set but not used [-Wunused-but-set-variable]
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/ath/wil6210/pm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/pm.c b/drivers/net/wireless/ath/wil6210/pm.c
index 3a41947..75fe932 100644
--- a/drivers/net/wireless/ath/wil6210/pm.c
+++ b/drivers/net/wireless/ath/wil6210/pm.c
@@ -190,7 +190,7 @@ static int wil_resume_keep_radio_on(struct wil6210_priv *wil)
static int wil_suspend_keep_radio_on(struct wil6210_priv *wil)
{
int rc = 0;
- unsigned long start, data_comp_to;
+ unsigned long data_comp_to;
wil_dbg_pm(wil, "suspend keep radio on\n");
@@ -232,7 +232,6 @@ static int wil_suspend_keep_radio_on(struct wil6210_priv *wil)
}
/* Wait for completion of the pending RX packets */
- start = jiffies;
data_comp_to = jiffies + msecs_to_jiffies(WIL_DATA_COMPLETION_TO_MS);
if (test_bit(wil_status_napi_en, wil->status)) {
while (!wil->txrx_ops.is_rx_idle(wil)) {
^ permalink raw reply related
* [PATCH][net-dsa-next] net: dsa: b53: ensure variable pause is initialized
From: Colin King @ 2018-09-11 17:53 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn, Vivien Didelot, David S . Miller,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Currenly integer pause is not initialized and may be left an
uninitialized state if flow control on BCM5301x's CPU port
is not enabled. This will potentially feed garbage into
the TX or RX pause bits that are or'd into pause. Fix this
by ensuring pause is initialized to zero.
Detected by static analysis with smatch:
"error: uninitialized symbol 'pause'."
Fixes: 5e004460f874 ("net: dsa: b53: Add helper to set link parameters")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/dsa/b53/b53_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index ea4256cd628b..dbf5b86a07fe 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1025,7 +1025,7 @@ static void b53_adjust_link(struct dsa_switch *ds, int port,
struct b53_device *dev = ds->priv;
struct ethtool_eee *p = &dev->ports[port].eee;
u8 rgmii_ctrl = 0, reg = 0, off;
- int pause;
+ int pause = 0;
if (!phy_is_pseudo_fixed_link(phydev))
return;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] qtnfmac: remove set but not used variable 'vif'
From: Sergey Matyukevich @ 2018-09-11 12:58 UTC (permalink / raw)
To: YueHaibing
Cc: Igor Mitsyanko, Avinash Patil, Sergey Matyukevich, Kalle Valo,
Sergei Maksimenko, Vasily Ulyanov, Andrey Shevchenko,
linux-wireless, netdev, kernel-janitors
In-Reply-To: <1536668904-13110-1-git-send-email-yuehaibing@huawei.com>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/quantenna/qtnfmac/cfg80211.c: In function 'qtnf_dump_survey':
> drivers/net/wireless/quantenna/qtnfmac/cfg80211.c:694:19: warning:
> variable 'vif' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Thanks !
Reviewed-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Regards,
Sergey
^ permalink raw reply
* [PATCH v2] neighbour: confirm neigh entries when ARP packet is received
From: Vasily Khoruzhick @ 2018-09-11 18:04 UTC (permalink / raw)
To: David S. Miller, Roopa Prabhu, Alexey Dobriyan, Eric Dumazet,
Stephen Hemminger, Jim Westfall, Wolfgang Bumiller,
Vasily Khoruzhick, Kees Cook, Ihar Hrachyshka, netdev,
linux-kernel
Cc: Vasily Khoruzhick
Update 'confirmed' timestamp when ARP packet is received. It shouldn't
affect locktime logic and anyway entry can be confirmed by any higher-layer
protocol. Thus it makes to sense not to confirm it when ARP packet is
received.
Fixes: 77d7123342 ("neighbour: update neigh timestamps iff update is
effective")
Signed-off-by: Vasily Khoruzhick <vasilykh@arista.com>
---
v2: - update comment to match new code.
net/core/neighbour.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index aa19d86937af..56a554597db5 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1180,6 +1180,12 @@ int neigh_update(struct neighbour *neigh, const u8 *lladdr, u8 new,
lladdr = neigh->ha;
}
+ /* Update confirmed timestamp for neighbour entry after we
+ * received ARP packet even if it doesn't change IP to MAC binding.
+ */
+ if (new & NUD_CONNECTED)
+ neigh->confirmed = jiffies;
+
/* If entry was valid and address is not changed,
do not change entry state, if new one is STALE.
*/
@@ -1201,15 +1207,12 @@ int neigh_update(struct neighbour *neigh, const u8 *lladdr, u8 new,
}
}
- /* Update timestamps only once we know we will make a change to the
+ /* Update timestamp only once we know we will make a change to the
* neighbour entry. Otherwise we risk to move the locktime window with
* noop updates and ignore relevant ARP updates.
*/
- if (new != old || lladdr != neigh->ha) {
- if (new & NUD_CONNECTED)
- neigh->confirmed = jiffies;
+ if (new != old || lladdr != neigh->ha)
neigh->updated = jiffies;
- }
if (new != old) {
neigh_del_timer(neigh);
--
2.18.0
^ permalink raw reply related
* Re: [PATCH v2 net-next 10/12] net: ethernet: Add helper for set_pauseparam for Asym Pause
From: kbuild test robot @ 2018-09-11 13:04 UTC (permalink / raw)
To: Andrew Lunn
Cc: kbuild-all, David Miller, netdev, Florian Fainelli, Andrew Lunn
In-Reply-To: <1536616350-15442-11-git-send-email-andrew@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 2121 bytes --]
Hi Andrew,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Andrew-Lunn/Preparing-for-phylib-limkmodes/20180911-204149
config: x86_64-randconfig-x011-201836 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/net/phy/phy_device.c: In function 'phy_set_asym_pause':
>> drivers/net/phy/phy_device.c:1838:11: warning: 'return' with a value, in function returning void
return phy_start_aneg(phydev);
^~~~~~~~~~~~~~~~~~~~~~
drivers/net/phy/phy_device.c:1824:6: note: declared here
void phy_set_asym_pause(struct phy_device *phydev, bool rx, bool tx)
^~~~~~~~~~~~~~~~~~
vim +/return +1838 drivers/net/phy/phy_device.c
1812
1813 /**
1814 * phy_set_asym_pause - Configure Pause and Asym Pause
1815 * @phydev: target phy_device struct
1816 * @rx: Receiver Pause is supported
1817 * @tx: Transmit Pause is supported
1818 *
1819 * Description: Configure advertised Pause support depending on if
1820 * transmit and receiver pause is supported. If there has been a
1821 * change in adverting, trigger a new autoneg. Generally called from
1822 * the set_pauseparam .ndo.
1823 */
1824 void phy_set_asym_pause(struct phy_device *phydev, bool rx, bool tx)
1825 {
1826 u16 oldadv = phydev->advertising;
1827 u16 newadv = oldadv &= ~(SUPPORTED_Pause | SUPPORTED_Asym_Pause);
1828
1829 if (rx)
1830 newadv |= SUPPORTED_Pause | SUPPORTED_Asym_Pause;
1831 if (tx)
1832 newadv ^= SUPPORTED_Asym_Pause;
1833
1834 if (oldadv != newadv) {
1835 phydev->advertising = newadv;
1836
1837 if (phydev->autoneg)
> 1838 return phy_start_aneg(phydev);
1839 }
1840 }
1841 EXPORT_SYMBOL(phy_set_asym_pause);
1842
---
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: 33600 bytes --]
^ permalink raw reply
* Re: [PATCH v3 net-next 5/6] dt-bindings: net: dsa: Add lantiq,xrx200-gswip DT bindings
From: Rob Herring @ 2018-09-11 13:06 UTC (permalink / raw)
To: Andrew Lunn
Cc: Hauke Mehrtens, David Miller, netdev, Vivien Didelot,
Florian Fainelli, John Crispin, Linux-MIPS, dev, hauke.mehrtens,
devicetree
In-Reply-To: <20180910220516.GA16024@lunn.ch>
On Mon, Sep 10, 2018 at 5:05 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > > +See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of
> > > +additional required and optional properties.
> > > +
> > > +
>
> snip
>
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + compatible = "lantiq,xrx200-gswip";
> > > + reg = < 0xE108000 0x3000 /* switch */
> > > + 0xE10B100 0x70 /* mdio */
> > > + 0xE10B1D8 0x30 /* mii */
> > > + >;
> > > + dsa,member = <0 0>;
> >
> > Not documented.
>
> Hi Rob
>
> It is documented in Documentation/devicetree/bindings/net/dsa/dsa.txt
> referenced above.
Hum, okay. Not something I recall reviewing. Not that I tend to
remember, but 'dsa' is not a vendor and the property should be
'dsa-member'.
Rob
^ permalink raw reply
* Re: [PATCH v2] neighbour: confirm neigh entries when ARP packet is received
From: Stephen Hemminger @ 2018-09-11 18:12 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: David S. Miller, Roopa Prabhu, Alexey Dobriyan, Eric Dumazet,
Jim Westfall, Wolfgang Bumiller, Vasily Khoruzhick, Kees Cook,
Ihar Hrachyshka, netdev, linux-kernel
In-Reply-To: <20180911180406.31283-1-vasilykh@arista.com>
On Tue, 11 Sep 2018 11:04:06 -0700
Vasily Khoruzhick <vasilykh@arista.com> wrote:
> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
> index aa19d86937af..56a554597db5 100644
> --- a/net/core/neighbour.c
> +++ b/net/core/neighbour.c
> @@ -1180,6 +1180,12 @@ int neigh_update(struct neighbour *neigh, const u8 *lladdr, u8 new,
> lladdr = neigh->ha;
> }
>
> + /* Update confirmed timestamp for neighbour entry after we
> + * received ARP packet even if it doesn't change IP to MAC binding.
> + */
> + if (new & NUD_CONNECTED)
> + neigh->confirmed = jiffies;
You might want to do:
if ((new & NUD_CONNECTED) && neigh->confirmed != jiffies)
neigh->confirmed = jiffies;
This avoid poisoning the cacheline with unnecessary write.
^ permalink raw reply
* Re: [PATCH net-next v3 17/17] net: WireGuard secure network tunnel
From: kbuild test robot @ 2018-09-11 13:17 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: kbuild-all, linux-kernel, netdev, davem, gregkh,
Jason A. Donenfeld
In-Reply-To: <20180911010838.8818-19-Jason@zx2c4.com>
[-- Attachment #1: Type: text/plain, Size: 5539 bytes --]
Hi Jason,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Jason-A-Donenfeld/WireGuard-Secure-Network-Tunnel/20180911-185037
config: arm-at91_dt_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
All errors (new ones prefixed by >>):
arch/arm/vfp/vfphw.S: Assembler messages:
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c0' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c1' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c2' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c3' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c4' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c5' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c6' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c7' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c8' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c9' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c10' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c11' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c12' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c13' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c14' in ARM mode
>> arch/arm/vfp/vfphw.S:299: Error: selected processor does not support `mrrc p11,3,r0,r1,c15' in ARM mode
>> arch/arm/vfp/vfphw.S:321: Error: selected processor does not support `mcrr p11,3,r0,r1,c0' in ARM mode
>> arch/arm/vfp/vfphw.S:321: Error: selected processor does not support `mcrr p11,3,r0,r1,c1' in ARM mode
>> arch/arm/vfp/vfphw.S:321: Error: selected processor does not support `mcrr p11,3,r0,r1,c2' in ARM mode
>> arch/arm/vfp/vfphw.S:321: Error: selected processor does not support `mcrr p11,3,r0,r1,c3' in ARM mode
vim +299 arch/arm/vfp/vfphw.S
^1da177e Linus Torvalds 2005-04-16 285
93ed3970 Catalin Marinas 2008-08-28 286 ENTRY(vfp_get_double)
07f33a03 Catalin Marinas 2009-07-24 287 tbl_branch r0, r3, #3
^1da177e Linus Torvalds 2005-04-16 288 .irp dr,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
07f33a03 Catalin Marinas 2009-07-24 289 1: fmrrd r0, r1, d\dr
6ebbf2ce Russell King 2014-06-30 290 ret lr
07f33a03 Catalin Marinas 2009-07-24 291 .org 1b + 8
^1da177e Linus Torvalds 2005-04-16 292 .endr
25ebee02 Catalin Marinas 2007-09-25 293 #ifdef CONFIG_VFPv3
25ebee02 Catalin Marinas 2007-09-25 294 @ d16 - d31 registers
25ebee02 Catalin Marinas 2007-09-25 295 .irp dr,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
07f33a03 Catalin Marinas 2009-07-24 296 1: mrrc p11, 3, r0, r1, c\dr @ fmrrd r0, r1, d\dr
6ebbf2ce Russell King 2014-06-30 297 ret lr
07f33a03 Catalin Marinas 2009-07-24 298 .org 1b + 8
25ebee02 Catalin Marinas 2007-09-25 @299 .endr
25ebee02 Catalin Marinas 2007-09-25 300 #endif
^1da177e Linus Torvalds 2005-04-16 301
25ebee02 Catalin Marinas 2007-09-25 302 @ virtual register 16 (or 32 if VFPv3) for compare with zero
^1da177e Linus Torvalds 2005-04-16 303 mov r0, #0
^1da177e Linus Torvalds 2005-04-16 304 mov r1, #0
6ebbf2ce Russell King 2014-06-30 305 ret lr
93ed3970 Catalin Marinas 2008-08-28 306 ENDPROC(vfp_get_double)
^1da177e Linus Torvalds 2005-04-16 307
93ed3970 Catalin Marinas 2008-08-28 308 ENTRY(vfp_put_double)
07f33a03 Catalin Marinas 2009-07-24 309 tbl_branch r2, r3, #3
^1da177e Linus Torvalds 2005-04-16 310 .irp dr,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
07f33a03 Catalin Marinas 2009-07-24 311 1: fmdrr d\dr, r0, r1
6ebbf2ce Russell King 2014-06-30 312 ret lr
07f33a03 Catalin Marinas 2009-07-24 313 .org 1b + 8
^1da177e Linus Torvalds 2005-04-16 314 .endr
25ebee02 Catalin Marinas 2007-09-25 315 #ifdef CONFIG_VFPv3
25ebee02 Catalin Marinas 2007-09-25 316 @ d16 - d31 registers
25ebee02 Catalin Marinas 2007-09-25 317 .irp dr,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
138de1c4 Russell King 2010-05-27 318 1: mcrr p11, 3, r0, r1, c\dr @ fmdrr r0, r1, d\dr
6ebbf2ce Russell King 2014-06-30 319 ret lr
07f33a03 Catalin Marinas 2009-07-24 320 .org 1b + 8
25ebee02 Catalin Marinas 2007-09-25 @321 .endr
:::::: The code at line 299 was first introduced by commit
:::::: 25ebee020bd34d1f4c5678538204f0b10bf9f6d5 [ARM] 4583/1: ARMv7: Add VFPv3 support
:::::: TO: Catalin Marinas <catalin.marinas@arm.com>
:::::: CC: Russell King <rmk+kernel@arm.linux.org.uk>
---
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: 23776 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3][can-next] can: rcar_can: Fix erroneous registration
From: Simon Horman @ 2018-09-11 13:31 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Wolfgang Grandegger, Marc Kleine-Budde, David S. Miller,
Sergei Shtylyov, Chris Paterson, linux-can, netdev,
Geert Uytterhoeven, Biju Das, linux-renesas-soc
In-Reply-To: <1536576195-11520-2-git-send-email-fabrizio.castro@bp.renesas.com>
On Mon, Sep 10, 2018 at 11:43:13AM +0100, Fabrizio Castro wrote:
> Assigning 2 to "renesas,can-clock-select" tricks the driver into
> registering the CAN interface, even though we don't want that.
> This patch improves one of the checks to prevent that from happening.
>
> Fixes: 862e2b6af9413b43 ("can: rcar_can: support all input clocks")
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Signed-off-by: Chris Paterson <Chris.Paterson2@renesas.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: can: rcar_can: Add r8a774a1 support
From: Simon Horman @ 2018-09-11 13:31 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Wolfgang Grandegger, Marc Kleine-Budde, Rob Herring, Mark Rutland,
David S. Miller, Sergei Shtylyov, linux-can, linux-kernel, netdev,
devicetree, Geert Uytterhoeven, Chris Paterson, Biju Das,
linux-renesas-soc
In-Reply-To: <1536576195-11520-3-git-send-email-fabrizio.castro@bp.renesas.com>
On Mon, Sep 10, 2018 at 11:43:14AM +0100, Fabrizio Castro wrote:
> Document RZ/G2M (r8a774a1) SoC specific bindings.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Signed-off-by: Chris Paterson <Chris.Paterson2@renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> ---
> v1->v2:
> * dropped "renesas,rzg-gen2-can" and fixed "clocks" property description
> as per Geert's comments.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* [PATCH net 0/2] nfp: flower: fixes for flower offload
From: Jakub Kicinski @ 2018-09-11 13:38 UTC (permalink / raw)
To: davem; +Cc: netdev, oss-drivers, Jakub Kicinski
Hi!
Two fixes for flower matching and tunnel encap. Pieter fixes
VLAN matching if the entire VLAN id is masked out and match
is only performed on the PCP field. Louis adds validation of
tunnel flags for encap, most importantly we should not offload
actions on IPv6 tunnels if it's not supported.
Louis Peens (1):
nfp: flower: reject tunnel encap with ipv6 outer headers for
offloading
Pieter Jansen van Vuuren (1):
nfp: flower: fix vlan match by checking both vlan id and vlan pcp
drivers/net/ethernet/netronome/nfp/flower/action.c | 6 ++++++
drivers/net/ethernet/netronome/nfp/flower/main.h | 1 +
drivers/net/ethernet/netronome/nfp/flower/match.c | 2 +-
drivers/net/ethernet/netronome/nfp/flower/offload.c | 11 +++++++++++
4 files changed, 19 insertions(+), 1 deletion(-)
--
2.17.1
^ permalink raw reply
* [PATCH net 1/2] nfp: flower: fix vlan match by checking both vlan id and vlan pcp
From: Jakub Kicinski @ 2018-09-11 13:38 UTC (permalink / raw)
To: davem; +Cc: netdev, oss-drivers, Pieter Jansen van Vuuren
In-Reply-To: <20180911133845.14214-1-jakub.kicinski@netronome.com>
From: Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
Previously we only checked if the vlan id field is present when trying
to match a vlan tag. The vlan id and vlan pcp field should be treated
independently.
Fixes: 5571e8c9f241 ("nfp: extend flower matching capabilities")
Signed-off-by: Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
drivers/net/ethernet/netronome/nfp/flower/main.h | 1 +
drivers/net/ethernet/netronome/nfp/flower/match.c | 2 +-
drivers/net/ethernet/netronome/nfp/flower/offload.c | 11 +++++++++++
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/netronome/nfp/flower/main.h b/drivers/net/ethernet/netronome/nfp/flower/main.h
index 85f8209bf007..81d941ab895c 100644
--- a/drivers/net/ethernet/netronome/nfp/flower/main.h
+++ b/drivers/net/ethernet/netronome/nfp/flower/main.h
@@ -70,6 +70,7 @@ struct nfp_app;
#define NFP_FL_FEATS_GENEVE BIT(0)
#define NFP_FL_NBI_MTU_SETTING BIT(1)
#define NFP_FL_FEATS_GENEVE_OPT BIT(2)
+#define NFP_FL_FEATS_VLAN_PCP BIT(3)
#define NFP_FL_FEATS_LAG BIT(31)
struct nfp_fl_mask_id {
diff --git a/drivers/net/ethernet/netronome/nfp/flower/match.c b/drivers/net/ethernet/netronome/nfp/flower/match.c
index a0c72f277faa..17acb8cc6044 100644
--- a/drivers/net/ethernet/netronome/nfp/flower/match.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/match.c
@@ -56,7 +56,7 @@ nfp_flower_compile_meta_tci(struct nfp_flower_meta_tci *frame,
FLOW_DISSECTOR_KEY_VLAN,
target);
/* Populate the tci field. */
- if (flow_vlan->vlan_id) {
+ if (flow_vlan->vlan_id || flow_vlan->vlan_priority) {
tmp_tci = FIELD_PREP(NFP_FLOWER_MASK_VLAN_PRIO,
flow_vlan->vlan_priority) |
FIELD_PREP(NFP_FLOWER_MASK_VLAN_VID,
diff --git a/drivers/net/ethernet/netronome/nfp/flower/offload.c b/drivers/net/ethernet/netronome/nfp/flower/offload.c
index 2edab01c3beb..bd19624f10cf 100644
--- a/drivers/net/ethernet/netronome/nfp/flower/offload.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/offload.c
@@ -192,6 +192,17 @@ nfp_flower_calculate_key_layers(struct nfp_app *app,
key_size += sizeof(struct nfp_flower_mac_mpls);
}
+ if (dissector_uses_key(flow->dissector, FLOW_DISSECTOR_KEY_VLAN)) {
+ struct flow_dissector_key_vlan *flow_vlan;
+
+ flow_vlan = skb_flow_dissector_target(flow->dissector,
+ FLOW_DISSECTOR_KEY_VLAN,
+ flow->mask);
+ if (!(priv->flower_ext_feats & NFP_FL_FEATS_VLAN_PCP) &&
+ flow_vlan->vlan_priority)
+ return -EOPNOTSUPP;
+ }
+
if (dissector_uses_key(flow->dissector,
FLOW_DISSECTOR_KEY_ENC_CONTROL)) {
struct flow_dissector_key_ipv4_addrs *mask_ipv4 = NULL;
--
2.17.1
^ permalink raw reply related
* [PATCH net 2/2] nfp: flower: reject tunnel encap with ipv6 outer headers for offloading
From: Jakub Kicinski @ 2018-09-11 13:38 UTC (permalink / raw)
To: davem; +Cc: netdev, oss-drivers, Louis Peens
In-Reply-To: <20180911133845.14214-1-jakub.kicinski@netronome.com>
From: Louis Peens <louis.peens@netronome.com>
This fixes a bug where ipv6 tunnels would report that it is
getting offloaded to hardware but would actually be rejected
by hardware.
Fixes: b27d6a95a70d ("nfp: compile flower vxlan tunnel set actions")
Signed-off-by: Louis Peens <louis.peens@netronome.com>
Reviewed-by: John Hurley <john.hurley@netronome.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
drivers/net/ethernet/netronome/nfp/flower/action.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/netronome/nfp/flower/action.c b/drivers/net/ethernet/netronome/nfp/flower/action.c
index 9044496803e6..46ba0cf257c6 100644
--- a/drivers/net/ethernet/netronome/nfp/flower/action.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/action.c
@@ -52,6 +52,7 @@
#define NFP_FL_TUNNEL_CSUM cpu_to_be16(0x01)
#define NFP_FL_TUNNEL_KEY cpu_to_be16(0x04)
#define NFP_FL_TUNNEL_GENEVE_OPT cpu_to_be16(0x0800)
+#define NFP_FL_SUPPORTED_TUNNEL_INFO_FLAGS IP_TUNNEL_INFO_TX
#define NFP_FL_SUPPORTED_IPV4_UDP_TUN_FLAGS (NFP_FL_TUNNEL_CSUM | \
NFP_FL_TUNNEL_KEY | \
NFP_FL_TUNNEL_GENEVE_OPT)
@@ -741,11 +742,16 @@ nfp_flower_loop_action(struct nfp_app *app, const struct tc_action *a,
nfp_fl_push_vlan(psh_v, a);
*a_len += sizeof(struct nfp_fl_push_vlan);
} else if (is_tcf_tunnel_set(a)) {
+ struct ip_tunnel_info *ip_tun = tcf_tunnel_info(a);
struct nfp_repr *repr = netdev_priv(netdev);
+
*tun_type = nfp_fl_get_tun_from_act_l4_port(repr->app, a);
if (*tun_type == NFP_FL_TUNNEL_NONE)
return -EOPNOTSUPP;
+ if (ip_tun->mode & ~NFP_FL_SUPPORTED_TUNNEL_INFO_FLAGS)
+ return -EOPNOTSUPP;
+
/* Pre-tunnel action is required for tunnel encap.
* This checks for next hop entries on NFP.
* If none, the packet falls back before applying other actions.
--
2.17.1
^ permalink raw reply related
* [PATCH net-next] nfp: report FW vNIC stats in interface stats
From: Jakub Kicinski @ 2018-09-11 13:44 UTC (permalink / raw)
To: davem; +Cc: netdev, oss-drivers, Jakub Kicinski
Report in standard netdev stats drops and errors as well as
RX multicast from the FW vNIC counters.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
---
drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
index 17a4785e8f4c..1aac55d66404 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
@@ -3167,6 +3167,7 @@ static void nfp_net_stat64(struct net_device *netdev,
struct nfp_net *nn = netdev_priv(netdev);
int r;
+ /* Collect software stats */
for (r = 0; r < nn->max_r_vecs; r++) {
struct nfp_net_r_vector *r_vec = &nn->r_vecs[r];
u64 data[3];
@@ -3192,6 +3193,14 @@ static void nfp_net_stat64(struct net_device *netdev,
stats->tx_bytes += data[1];
stats->tx_errors += data[2];
}
+
+ /* Add in device stats */
+ stats->multicast += nn_readq(nn, NFP_NET_CFG_STATS_RX_MC_FRAMES);
+ stats->rx_dropped += nn_readq(nn, NFP_NET_CFG_STATS_RX_DISCARDS);
+ stats->rx_errors += nn_readq(nn, NFP_NET_CFG_STATS_RX_ERRORS);
+
+ stats->tx_dropped += nn_readq(nn, NFP_NET_CFG_STATS_TX_DISCARDS);
+ stats->tx_errors += nn_readq(nn, NFP_NET_CFG_STATS_TX_ERRORS);
}
static int nfp_net_set_features(struct net_device *netdev,
--
2.17.1
^ permalink raw reply related
* Re: Overlayfs @ Containers and checkpoint/restart micro-conference at LPC2018
From: Vivek Goyal @ 2018-09-11 13:52 UTC (permalink / raw)
To: Christian Brauner
Cc: Amir Goldstein, Stephane Graber, containers, Miklos Szeredi,
Netdev, overlayfs, lxc-users, LSM List, lxc-devel, linux-fsdevel,
zhangyi (F)
In-Reply-To: <20180909091549.yekfuds633afhrgw@mailbox.org>
On Sun, Sep 09, 2018 at 11:18:54AM +0200, Christian Brauner wrote:
[..]
> My team hast just started to be more involved with shifts development a
> few months back. Overlayfs is definitely an inspiration and we even once
> thought about making shifts an extension of overlayfs.
> Seth Forshee on my team is currently actively working on shifts and
> getting a POC ready.
> When he has a POC based on James' patchset there will be an RFC that
> will go to fsdevel and all parties of interest.
> There will also be an update on shifts development during the microconf.
> So even more reason for developers from overlayfs to stop by.
So we need both shiftfs and overlayfs in container deployments, right?
shiftfs to make sure each container can run in its own user namespace
and uid/gid mappings can be setup on the fly and overlayfs to provide
union of multiple layers and copy on write filesystem. I am assuming that
shiftfs is working on top of overlayfs here?
Doing shifting at VFS level using mount API was another idea discussed
at last plumbers. I saw David Howells was pushing all the new mount
API patches. Not sure if he ever got time to pursue shifting at VFS
level.
BTW, now we have metadata only copy up patches in overlayfs as
well(4.19-rc). That speeds up chown operation with overlayfs,
needed for changing ownership of files in images for making sure
they work fine with user namespaces. In my simple testing in a VM,
a fedora image was taking around 30 seconds to chown. With metadata
only copy up that time drops to around 2-3 seconds. So till shiftfs
or shiting at VFS level gets merged, it can be used as a stop gap
solution.
Thanks
Vivek
^ permalink raw reply
* Re: [PATCH] wil6210: remove set but not used variable 'start'
From: merez-sgV2jX0FEOL9JmXXK+q4OQ @ 2018-09-11 19:04 UTC (permalink / raw)
To: YueHaibing
Cc: Kalle Valo, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
wil6210-Rm6X0d1/PG5y9aJCnZT0Uw, netdev-u79uwXL29TY76Z2rM5mHXA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-owner-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1536669139-14848-1-git-send-email-yuehaibing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
On 2018-09-11 15:32, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/ath/wil6210/pm.c: In function
> 'wil_suspend_keep_radio_on':
> drivers/net/wireless/ath/wil6210/pm.c:193:16: warning:
> variable 'start' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: YueHaibing <yuehaibing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Reviewed-by: Maya Erez <merez-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
--
Maya Erez
Qualcomm Israel, Inc. on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCHv3 iproute2] bridge/mdb: fix missing new line when show bridge mdb
From: Hangbin Liu @ 2018-09-11 14:04 UTC (permalink / raw)
To: netdev; +Cc: Phil Sutter, Stephen Hemminger, David Ahern, Hangbin Liu
In-Reply-To: <1536118423-20604-1-git-send-email-liuhangbin@gmail.com>
The bridge mdb show is broken on current iproute2. e.g.
]# bridge mdb show
34: br0 veth0_br 224.1.1.2 temp 34: br0 veth0_br 224.1.1.1 temp
After fix:
]# bridge mdb show
34: br0 veth0_br 224.1.1.2 temp
34: br0 veth0_br 224.1.1.1 temp
v2: Use json print lib as Stephen suggested.
v3: No need to use is_json_context() as Phil pointed out.
Reported-by: Ying Xu <yinxu@redhat.com>
Fixes: c7c1a1ef51aea ("bridge: colorize output and use JSON print library")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
bridge/mdb.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/bridge/mdb.c b/bridge/mdb.c
index f38dc67..2f24b01 100644
--- a/bridge/mdb.c
+++ b/bridge/mdb.c
@@ -107,6 +107,10 @@ static void br_print_router_ports(FILE *f, struct rtattr *attr,
fprintf(f, "%s ", port_ifname);
}
}
+
+ if (!show_stats)
+ print_string(PRINT_FP, NULL, "\n", NULL);
+
close_json_array(PRINT_JSON, NULL);
}
@@ -164,6 +168,8 @@ static void print_mdb_entry(FILE *f, int ifindex, const struct br_mdb_entry *e,
print_string(PRINT_ANY, "timer", " %s",
format_timer(timer));
}
+
+ print_string(PRINT_FP, NULL, "\n", NULL);
close_json_object();
}
--
2.5.5
^ permalink raw reply related
* Inquiry 11-09-2018
From: Invictus Group @ 2018-09-11 12:28 UTC (permalink / raw)
To: netdev
Hello,
This is Ms Julian Smith and i am from Invictus Group Co.,LTD in United Kingdom.
We are glad to know about your company from the web and we are interested in your products.
Could you kindly send us your Latest catalog and price list for our trial order.
Best Regards,
Julian Smith
Purchasing Manager
^ 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