* (unknown),
From: mari.kayhko @ 2017-06-02 6:04 UTC (permalink / raw)
To: netdev
[-- Attachment #1: 083544262110.zip --]
[-- Type: application/zip, Size: 3182 bytes --]
^ permalink raw reply
* Re: [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
From: Maxime Ripard @ 2017-06-02 6:37 UTC (permalink / raw)
To: David Miller
Cc: clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wens-jdAy2FN1RRM, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
peppe.cavallaro-qxv4g6HH51o, alexandre.torgue-qxv4g6HH51o,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170601.145819.789604139072328057.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 590 bytes --]
On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller wrote:
> From: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Wed, 31 May 2017 09:18:31 +0200
>
> > This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> > present on Allwinner H3/H5/A83T/A64 SoCs.
>
> Series applied, but wow that's a lot of DT file changes :-(
The DT patches should not go through your tree, but arm-soc, so I
guess this is not an issue for you?
Maximee
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 10/12] apparmorfs: Replace CURRENT_TIME with current_time()
From: John Johansen @ 2017-06-02 7:29 UTC (permalink / raw)
To: Deepa Dinamani, linux-kernel, akpm
Cc: yuchao0, bfields, clm, linux-mtd, dushistov, jlayton, tglx, devel,
linux-cifs, paul, y2038, mingo, jsimmons, arnd, rostedt,
oleg.drokin, john.stultz, viro, dsterba, jaegeuk, ceph-devel,
andreas.dilger, jbacik, gregkh, samba-technical, eparis,
linux-f2fs-devel, linux-security-module, linux-audit, netdev,
linux-fsdevel, davem, linux-btrfs, lustre-devel
In-Reply-To: <1491613030-11599-11-git-send-email-deepa.kernel@gmail.com>
On 04/07/2017 05:57 PM, Deepa Dinamani wrote:
> CURRENT_TIME macro is not y2038 safe on 32 bit systems.
>
> The patch replaces all the uses of CURRENT_TIME by
> current_time().
>
> This is also in preparation for the patch that transitions
> vfs timestamps to use 64 bit time and hence make them
> y2038 safe. current_time() is also planned to be transitioned
> to y2038 safe behavior along with this change.
>
> CURRENT_TIME macro will be deleted before merging the
> aforementioned change.
>
> Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
This is all good, and I have no objections to it being merged for 4.12.
If it isn't this change is already queued up for the apparmor 4.13
merge
Acked-by: John Johansen <john.johansen@canonical.com>
> ---
> security/apparmor/apparmorfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/security/apparmor/apparmorfs.c b/security/apparmor/apparmorfs.c
> index be0b498..4f6ac9d 100644
> --- a/security/apparmor/apparmorfs.c
> +++ b/security/apparmor/apparmorfs.c
> @@ -1357,7 +1357,7 @@ static int aa_mk_null_file(struct dentry *parent)
>
> inode->i_ino = get_next_ino();
> inode->i_mode = S_IFCHR | S_IRUGO | S_IWUGO;
> - inode->i_atime = inode->i_mtime = inode->i_ctime = CURRENT_TIME;
> + inode->i_atime = inode->i_mtime = inode->i_ctime = current_time(inode);
> init_special_inode(inode, S_IFCHR | S_IRUGO | S_IWUGO,
> MKDEV(MEM_MAJOR, 3));
> d_instantiate(dentry, inode);
>
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
* [PATCH v4 0/6] stmmac: pci: Refactor DMI probing
From: Jan Kiszka @ 2017-06-02 7:34 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue, David Miller
Cc: netdev, linux-kernel, Andy Shevchenko
Some cleanups of the way we probe DMI platforms in the driver. Reduces
a bit of open-coding and makes the logic easier reusable for any
potential DMI platform != Quark.
Tested on IOT2000 and Galileo Gen2.
Changes in v4:
- Refactor patch 5 according to feedback
Jan
Jan Kiszka (6):
stmmac: pci: Make stmmac_pci_info structure constant
stmmac: pci: Use stmmac_pci_info for all devices
stmmac: pci: Make stmmac_pci_find_phy_addr truly generic
stmmac: pci: Select quark_pci_dmi_data from quark_default_data
stmmac: pci: Use dmi_system_id table for retrieving PHY addresses
stmmac: pci: Remove setup handler indirection via stmmac_pci_info
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 205 +++++++++++++----------
1 file changed, 119 insertions(+), 86 deletions(-)
--
2.12.3
^ permalink raw reply
* [PATCH v4 1/6] stmmac: pci: Make stmmac_pci_info structure constant
From: Jan Kiszka @ 2017-06-02 7:34 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue, David Miller
Cc: netdev, linux-kernel, Andy Shevchenko
In-Reply-To: <cover.1496388893.git.jan.kiszka@siemens.com>
By removing the PCI device reference from the structure and passing it
as parameters to the interested functions, we can make quark_pci_info
const.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 23 +++++++++++------------
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 22f910795be4..0efe42659a37 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -38,17 +38,17 @@ struct stmmac_pci_dmi_data {
};
struct stmmac_pci_info {
- struct pci_dev *pdev;
- int (*setup)(struct plat_stmmacenet_data *plat,
- struct stmmac_pci_info *info);
+ int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat,
+ const struct stmmac_pci_info *info);
struct stmmac_pci_dmi_data *dmi;
};
-static int stmmac_pci_find_phy_addr(struct stmmac_pci_info *info)
+static int stmmac_pci_find_phy_addr(struct pci_dev *pdev,
+ const struct stmmac_pci_info *info)
{
const char *name = dmi_get_system_info(DMI_BOARD_NAME);
const char *asset_tag = dmi_get_system_info(DMI_BOARD_ASSET_TAG);
- unsigned int func = PCI_FUNC(info->pdev->devfn);
+ unsigned int func = PCI_FUNC(pdev->devfn);
struct stmmac_pci_dmi_data *dmi;
/*
@@ -114,10 +114,10 @@ static void stmmac_default_data(struct plat_stmmacenet_data *plat)
/* TODO: AXI */
}
-static int quark_default_data(struct plat_stmmacenet_data *plat,
- struct stmmac_pci_info *info)
+static int quark_default_data(struct pci_dev *pdev,
+ struct plat_stmmacenet_data *plat,
+ const struct stmmac_pci_info *info)
{
- struct pci_dev *pdev = info->pdev;
int ret;
/* Set common default data first */
@@ -127,7 +127,7 @@ static int quark_default_data(struct plat_stmmacenet_data *plat,
* Refuse to load the driver and register net device if MAC controller
* does not connect to any PHY interface.
*/
- ret = stmmac_pci_find_phy_addr(info);
+ ret = stmmac_pci_find_phy_addr(pdev, info);
if (ret < 0)
return ret;
@@ -175,7 +175,7 @@ static struct stmmac_pci_dmi_data quark_pci_dmi_data[] = {
{}
};
-static struct stmmac_pci_info quark_pci_info = {
+static const struct stmmac_pci_info quark_pci_info = {
.setup = quark_default_data,
.dmi = quark_pci_dmi_data,
};
@@ -237,9 +237,8 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
pci_set_master(pdev);
if (info) {
- info->pdev = pdev;
if (info->setup) {
- ret = info->setup(plat, info);
+ ret = info->setup(pdev, plat, info);
if (ret)
return ret;
}
--
2.12.3
^ permalink raw reply related
* [PATCH v4 2/6] stmmac: pci: Use stmmac_pci_info for all devices
From: Jan Kiszka @ 2017-06-02 7:34 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue, David Miller
Cc: netdev, linux-kernel, Andy Shevchenko
In-Reply-To: <cover.1496388893.git.jan.kiszka@siemens.com>
Make stmmac_default_data compatible with stmmac_pci_info.setup and use
an info structure for all devices. This allows to make the probing more
regular.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 36 +++++++++++++++---------
1 file changed, 23 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 0efe42659a37..d3d74e526e17 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -100,7 +100,9 @@ static void common_default_data(struct plat_stmmacenet_data *plat)
plat->rx_queues_cfg[0].pkt_route = 0x0;
}
-static void stmmac_default_data(struct plat_stmmacenet_data *plat)
+static int stmmac_default_data(struct pci_dev *pdev,
+ struct plat_stmmacenet_data *plat,
+ const struct stmmac_pci_info *info)
{
/* Set common default data first */
common_default_data(plat);
@@ -112,8 +114,14 @@ static void stmmac_default_data(struct plat_stmmacenet_data *plat)
plat->dma_cfg->pbl = 32;
plat->dma_cfg->pblx8 = true;
/* TODO: AXI */
+
+ return 0;
}
+static const struct stmmac_pci_info stmmac_pci_info = {
+ .setup = stmmac_default_data,
+};
+
static int quark_default_data(struct pci_dev *pdev,
struct plat_stmmacenet_data *plat,
const struct stmmac_pci_info *info)
@@ -236,14 +244,9 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
pci_set_master(pdev);
- if (info) {
- if (info->setup) {
- ret = info->setup(pdev, plat, info);
- if (ret)
- return ret;
- }
- } else
- stmmac_default_data(plat);
+ ret = info->setup(pdev, plat, info);
+ if (ret)
+ return ret;
pci_enable_msi(pdev);
@@ -269,14 +272,21 @@ static void stmmac_pci_remove(struct pci_dev *pdev)
static SIMPLE_DEV_PM_OPS(stmmac_pm_ops, stmmac_suspend, stmmac_resume);
-#define STMMAC_VENDOR_ID 0x700
+/* synthetic ID, no official vendor */
+#define PCI_VENDOR_ID_STMMAC 0x700
+
#define STMMAC_QUARK_ID 0x0937
#define STMMAC_DEVICE_ID 0x1108
+#define STMMAC_DEVICE(vendor_id, dev_id, info) { \
+ PCI_VDEVICE(vendor_id, dev_id), \
+ .driver_data = (kernel_ulong_t)&info \
+ }
+
static const struct pci_device_id stmmac_id_table[] = {
- {PCI_DEVICE(STMMAC_VENDOR_ID, STMMAC_DEVICE_ID)},
- {PCI_DEVICE(PCI_VENDOR_ID_STMICRO, PCI_DEVICE_ID_STMICRO_MAC)},
- {PCI_VDEVICE(INTEL, STMMAC_QUARK_ID), (kernel_ulong_t)&quark_pci_info},
+ STMMAC_DEVICE(STMMAC, STMMAC_DEVICE_ID, stmmac_pci_info),
+ STMMAC_DEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_MAC, stmmac_pci_info),
+ STMMAC_DEVICE(INTEL, STMMAC_QUARK_ID, quark_pci_info),
{}
};
--
2.12.3
^ permalink raw reply related
* [PATCH v4 3/6] stmmac: pci: Make stmmac_pci_find_phy_addr truly generic
From: Jan Kiszka @ 2017-06-02 7:34 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue, David Miller
Cc: netdev, linux-kernel, Andy Shevchenko
In-Reply-To: <cover.1496388893.git.jan.kiszka@siemens.com>
Move the special case for the early Galileo firmware into
quark_default_setup. This allows to use stmmac_pci_find_phy_addr for
non-quark cases.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index d3d74e526e17..f44ae49eb11c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -51,12 +51,8 @@ static int stmmac_pci_find_phy_addr(struct pci_dev *pdev,
unsigned int func = PCI_FUNC(pdev->devfn);
struct stmmac_pci_dmi_data *dmi;
- /*
- * Galileo boards with old firmware don't support DMI. We always return
- * 1 here, so at least first found MAC controller would be probed.
- */
if (!name)
- return 1;
+ return -ENODEV;
for (dmi = info->dmi; dmi->name && *dmi->name; dmi++) {
if (!strcmp(dmi->name, name) && dmi->func == func) {
@@ -136,8 +132,18 @@ static int quark_default_data(struct pci_dev *pdev,
* does not connect to any PHY interface.
*/
ret = stmmac_pci_find_phy_addr(pdev, info);
- if (ret < 0)
- return ret;
+ if (ret < 0) {
+ /* Return error to the caller on DMI enabled boards. */
+ if (dmi_get_system_info(DMI_BOARD_NAME))
+ return ret;
+
+ /*
+ * Galileo boards with old firmware don't support DMI. We always
+ * use 1 here as PHY address, so at least the first found MAC
+ * controller would be probed.
+ */
+ ret = 1;
+ }
plat->bus_id = PCI_DEVID(pdev->bus->number, pdev->devfn);
plat->phy_addr = ret;
--
2.12.3
^ permalink raw reply related
* [PATCH v4 4/6] stmmac: pci: Select quark_pci_dmi_data from quark_default_data
From: Jan Kiszka @ 2017-06-02 7:34 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue, David Miller
Cc: netdev, linux-kernel, Andy Shevchenko
In-Reply-To: <cover.1496388893.git.jan.kiszka@siemens.com>
No need to carry this reference in stmmac_pci_info - the Quark-specific
setup handler knows that it needs to use the Quark-specific DMI table.
This also allows to drop the stmmac_pci_info reference from the setup
handler parameter list.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 83 +++++++++++-------------
1 file changed, 39 insertions(+), 44 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index f44ae49eb11c..a6e10d3ced5c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -38,13 +38,11 @@ struct stmmac_pci_dmi_data {
};
struct stmmac_pci_info {
- int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat,
- const struct stmmac_pci_info *info);
- struct stmmac_pci_dmi_data *dmi;
+ int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);
};
static int stmmac_pci_find_phy_addr(struct pci_dev *pdev,
- const struct stmmac_pci_info *info)
+ struct stmmac_pci_dmi_data *dmi_data)
{
const char *name = dmi_get_system_info(DMI_BOARD_NAME);
const char *asset_tag = dmi_get_system_info(DMI_BOARD_ASSET_TAG);
@@ -54,7 +52,7 @@ static int stmmac_pci_find_phy_addr(struct pci_dev *pdev,
if (!name)
return -ENODEV;
- for (dmi = info->dmi; dmi->name && *dmi->name; dmi++) {
+ for (dmi = dmi_data; dmi->name && *dmi->name; dmi++) {
if (!strcmp(dmi->name, name) && dmi->func == func) {
/* If asset tag is provided, match on it as well. */
if (dmi->asset_tag && strcmp(dmi->asset_tag, asset_tag))
@@ -97,8 +95,7 @@ static void common_default_data(struct plat_stmmacenet_data *plat)
}
static int stmmac_default_data(struct pci_dev *pdev,
- struct plat_stmmacenet_data *plat,
- const struct stmmac_pci_info *info)
+ struct plat_stmmacenet_data *plat)
{
/* Set common default data first */
common_default_data(plat);
@@ -118,9 +115,40 @@ static const struct stmmac_pci_info stmmac_pci_info = {
.setup = stmmac_default_data,
};
+static struct stmmac_pci_dmi_data quark_pci_dmi_data[] = {
+ {
+ .name = "Galileo",
+ .func = 6,
+ .phy_addr = 1,
+ },
+ {
+ .name = "GalileoGen2",
+ .func = 6,
+ .phy_addr = 1,
+ },
+ {
+ .name = "SIMATIC IOT2000",
+ .asset_tag = "6ES7647-0AA00-0YA2",
+ .func = 6,
+ .phy_addr = 1,
+ },
+ {
+ .name = "SIMATIC IOT2000",
+ .asset_tag = "6ES7647-0AA00-1YA2",
+ .func = 6,
+ .phy_addr = 1,
+ },
+ {
+ .name = "SIMATIC IOT2000",
+ .asset_tag = "6ES7647-0AA00-1YA2",
+ .func = 7,
+ .phy_addr = 1,
+ },
+ {}
+};
+
static int quark_default_data(struct pci_dev *pdev,
- struct plat_stmmacenet_data *plat,
- const struct stmmac_pci_info *info)
+ struct plat_stmmacenet_data *plat)
{
int ret;
@@ -131,7 +159,7 @@ static int quark_default_data(struct pci_dev *pdev,
* Refuse to load the driver and register net device if MAC controller
* does not connect to any PHY interface.
*/
- ret = stmmac_pci_find_phy_addr(pdev, info);
+ ret = stmmac_pci_find_phy_addr(pdev, quark_pci_dmi_data);
if (ret < 0) {
/* Return error to the caller on DMI enabled boards. */
if (dmi_get_system_info(DMI_BOARD_NAME))
@@ -157,41 +185,8 @@ static int quark_default_data(struct pci_dev *pdev,
return 0;
}
-static struct stmmac_pci_dmi_data quark_pci_dmi_data[] = {
- {
- .name = "Galileo",
- .func = 6,
- .phy_addr = 1,
- },
- {
- .name = "GalileoGen2",
- .func = 6,
- .phy_addr = 1,
- },
- {
- .name = "SIMATIC IOT2000",
- .asset_tag = "6ES7647-0AA00-0YA2",
- .func = 6,
- .phy_addr = 1,
- },
- {
- .name = "SIMATIC IOT2000",
- .asset_tag = "6ES7647-0AA00-1YA2",
- .func = 6,
- .phy_addr = 1,
- },
- {
- .name = "SIMATIC IOT2000",
- .asset_tag = "6ES7647-0AA00-1YA2",
- .func = 7,
- .phy_addr = 1,
- },
- {}
-};
-
static const struct stmmac_pci_info quark_pci_info = {
.setup = quark_default_data,
- .dmi = quark_pci_dmi_data,
};
/**
@@ -250,7 +245,7 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
pci_set_master(pdev);
- ret = info->setup(pdev, plat, info);
+ ret = info->setup(pdev, plat);
if (ret)
return ret;
--
2.12.3
^ permalink raw reply related
* [PATCH v4 5/6] stmmac: pci: Use dmi_system_id table for retrieving PHY addresses
From: Jan Kiszka @ 2017-06-02 7:34 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue, David Miller
Cc: netdev, linux-kernel, Andy Shevchenko
In-Reply-To: <cover.1496388893.git.jan.kiszka@siemens.com>
Avoids reimplementation of DMI matching in stmmac_pci_find_phy_addr.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 99 ++++++++++++++++--------
1 file changed, 66 insertions(+), 33 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index a6e10d3ced5c..2be15a8a9c40 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -30,36 +30,39 @@
* negative value of the address means that MAC controller is not connected
* with PHY.
*/
-struct stmmac_pci_dmi_data {
- const char *name;
- const char *asset_tag;
+struct stmmac_pci_func_data {
unsigned int func;
int phy_addr;
};
+struct stmmac_pci_dmi_data {
+ const struct stmmac_pci_func_data *func;
+ size_t nfuncs;
+};
+
struct stmmac_pci_info {
int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);
};
static int stmmac_pci_find_phy_addr(struct pci_dev *pdev,
- struct stmmac_pci_dmi_data *dmi_data)
+ const struct dmi_system_id *dmi_list)
{
- const char *name = dmi_get_system_info(DMI_BOARD_NAME);
- const char *asset_tag = dmi_get_system_info(DMI_BOARD_ASSET_TAG);
- unsigned int func = PCI_FUNC(pdev->devfn);
- struct stmmac_pci_dmi_data *dmi;
-
- if (!name)
+ const struct stmmac_pci_func_data *func_data;
+ const struct stmmac_pci_dmi_data *dmi_data;
+ const struct dmi_system_id *dmi_id;
+ int func = PCI_FUNC(pdev->devfn);
+ size_t n;
+
+ dmi_id = dmi_first_match(dmi_list);
+ if (!dmi_id)
return -ENODEV;
- for (dmi = dmi_data; dmi->name && *dmi->name; dmi++) {
- if (!strcmp(dmi->name, name) && dmi->func == func) {
- /* If asset tag is provided, match on it as well. */
- if (dmi->asset_tag && strcmp(dmi->asset_tag, asset_tag))
- continue;
- return dmi->phy_addr;
- }
- }
+ dmi_data = dmi_id->driver_data;
+ func_data = dmi_data->func;
+
+ for (n = 0; n < dmi_data->nfuncs; n++, func_data++)
+ if (func_data->func == func)
+ return func_data->phy_addr;
return -ENODEV;
}
@@ -115,34 +118,64 @@ static const struct stmmac_pci_info stmmac_pci_info = {
.setup = stmmac_default_data,
};
-static struct stmmac_pci_dmi_data quark_pci_dmi_data[] = {
+static const struct stmmac_pci_func_data galileo_stmmac_func_data[] = {
{
- .name = "Galileo",
.func = 6,
.phy_addr = 1,
},
+ { },
+};
+
+static const struct stmmac_pci_dmi_data galileo_stmmac_dmi_data = {
+ .func = galileo_stmmac_func_data,
+ .nfuncs = ARRAY_SIZE(galileo_stmmac_func_data),
+};
+
+static const struct stmmac_pci_func_data iot2040_stmmac_func_data[] = {
{
- .name = "GalileoGen2",
.func = 6,
.phy_addr = 1,
},
{
- .name = "SIMATIC IOT2000",
- .asset_tag = "6ES7647-0AA00-0YA2",
- .func = 6,
+ .func = 7,
.phy_addr = 1,
},
+ { },
+};
+
+static const struct stmmac_pci_dmi_data iot2040_stmmac_dmi_data = {
+ .func = iot2040_stmmac_func_data,
+ .nfuncs = ARRAY_SIZE(iot2040_stmmac_func_data),
+};
+
+static const struct dmi_system_id quark_pci_dmi[] = {
{
- .name = "SIMATIC IOT2000",
- .asset_tag = "6ES7647-0AA00-1YA2",
- .func = 6,
- .phy_addr = 1,
+ .matches = {
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "Galileo"),
+ },
+ .driver_data = (void *)&galileo_stmmac_dmi_data,
},
{
- .name = "SIMATIC IOT2000",
- .asset_tag = "6ES7647-0AA00-1YA2",
- .func = 7,
- .phy_addr = 1,
+ .matches = {
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "GalileoGen2"),
+ },
+ .driver_data = (void *)&galileo_stmmac_dmi_data,
+ },
+ {
+ .matches = {
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "SIMATIC IOT2000"),
+ DMI_EXACT_MATCH(DMI_BOARD_ASSET_TAG,
+ "6ES7647-0AA00-0YA2"),
+ },
+ .driver_data = (void *)&galileo_stmmac_dmi_data,
+ },
+ {
+ .matches = {
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "SIMATIC IOT2000"),
+ DMI_EXACT_MATCH(DMI_BOARD_ASSET_TAG,
+ "6ES7647-0AA00-1YA2"),
+ },
+ .driver_data = (void *)&iot2040_stmmac_dmi_data,
},
{}
};
@@ -159,7 +192,7 @@ static int quark_default_data(struct pci_dev *pdev,
* Refuse to load the driver and register net device if MAC controller
* does not connect to any PHY interface.
*/
- ret = stmmac_pci_find_phy_addr(pdev, quark_pci_dmi_data);
+ ret = stmmac_pci_find_phy_addr(pdev, quark_pci_dmi);
if (ret < 0) {
/* Return error to the caller on DMI enabled boards. */
if (dmi_get_system_info(DMI_BOARD_NAME))
--
2.12.3
^ permalink raw reply related
* [PATCH v4 6/6] stmmac: pci: Remove setup handler indirection via stmmac_pci_info
From: Jan Kiszka @ 2017-06-02 7:34 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue, David Miller
Cc: netdev, linux-kernel, Andy Shevchenko
In-Reply-To: <cover.1496388893.git.jan.kiszka@siemens.com>
By now, stmmac_pci_info only contains a single entry. Register this
directly with the PCI device table, removing one indirection.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 34 +++++++++---------------
1 file changed, 12 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 2be15a8a9c40..393710815e4b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -40,9 +40,7 @@ struct stmmac_pci_dmi_data {
size_t nfuncs;
};
-struct stmmac_pci_info {
- int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);
-};
+typedef int (*stmmac_setup)(struct pci_dev *, struct plat_stmmacenet_data *);
static int stmmac_pci_find_phy_addr(struct pci_dev *pdev,
const struct dmi_system_id *dmi_list)
@@ -97,8 +95,8 @@ static void common_default_data(struct plat_stmmacenet_data *plat)
plat->rx_queues_cfg[0].pkt_route = 0x0;
}
-static int stmmac_default_data(struct pci_dev *pdev,
- struct plat_stmmacenet_data *plat)
+static int stmmac_default_setup(struct pci_dev *pdev,
+ struct plat_stmmacenet_data *plat)
{
/* Set common default data first */
common_default_data(plat);
@@ -114,10 +112,6 @@ static int stmmac_default_data(struct pci_dev *pdev,
return 0;
}
-static const struct stmmac_pci_info stmmac_pci_info = {
- .setup = stmmac_default_data,
-};
-
static const struct stmmac_pci_func_data galileo_stmmac_func_data[] = {
{
.func = 6,
@@ -180,8 +174,8 @@ static const struct dmi_system_id quark_pci_dmi[] = {
{}
};
-static int quark_default_data(struct pci_dev *pdev,
- struct plat_stmmacenet_data *plat)
+static int quark_default_setup(struct pci_dev *pdev,
+ struct plat_stmmacenet_data *plat)
{
int ret;
@@ -218,10 +212,6 @@ static int quark_default_data(struct pci_dev *pdev,
return 0;
}
-static const struct stmmac_pci_info quark_pci_info = {
- .setup = quark_default_data,
-};
-
/**
* stmmac_pci_probe
*
@@ -237,7 +227,7 @@ static const struct stmmac_pci_info quark_pci_info = {
static int stmmac_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
- struct stmmac_pci_info *info = (struct stmmac_pci_info *)id->driver_data;
+ stmmac_setup setup = (stmmac_setup)id->driver_data;
struct plat_stmmacenet_data *plat;
struct stmmac_resources res;
int i;
@@ -278,7 +268,7 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
pci_set_master(pdev);
- ret = info->setup(pdev, plat);
+ ret = setup(pdev, plat);
if (ret)
return ret;
@@ -312,15 +302,15 @@ static SIMPLE_DEV_PM_OPS(stmmac_pm_ops, stmmac_suspend, stmmac_resume);
#define STMMAC_QUARK_ID 0x0937
#define STMMAC_DEVICE_ID 0x1108
-#define STMMAC_DEVICE(vendor_id, dev_id, info) { \
+#define STMMAC_DEVICE(vendor_id, dev_id, setup) { \
PCI_VDEVICE(vendor_id, dev_id), \
- .driver_data = (kernel_ulong_t)&info \
+ .driver_data = (kernel_ulong_t)&setup \
}
static const struct pci_device_id stmmac_id_table[] = {
- STMMAC_DEVICE(STMMAC, STMMAC_DEVICE_ID, stmmac_pci_info),
- STMMAC_DEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_MAC, stmmac_pci_info),
- STMMAC_DEVICE(INTEL, STMMAC_QUARK_ID, quark_pci_info),
+ STMMAC_DEVICE(STMMAC, STMMAC_DEVICE_ID, stmmac_default_setup),
+ STMMAC_DEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_MAC, stmmac_default_setup),
+ STMMAC_DEVICE(INTEL, STMMAC_QUARK_ID, quark_default_setup),
{}
};
--
2.12.3
^ permalink raw reply related
* Re: [PATCH v3 net-next 1/3] perf, bpf: Add BPF support to all perf_event types
From: Peter Zijlstra @ 2017-06-02 8:06 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S . Miller, Brendan Gregg, Daniel Borkmann, Teng Qin,
netdev, linux-kernel, kernel-team
In-Reply-To: <20170602020336.1062853-2-ast@fb.com>
On Thu, Jun 01, 2017 at 07:03:34PM -0700, Alexei Starovoitov wrote:
> diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
> index 172dc8ee0e3b..ab93490d1a00 100644
> --- a/kernel/bpf/arraymap.c
> +++ b/kernel/bpf/arraymap.c
> @@ -452,39 +452,18 @@ static void bpf_event_entry_free_rcu(struct bpf_event_entry *ee)
> static void *perf_event_fd_array_get_ptr(struct bpf_map *map,
> struct file *map_file, int fd)
> {
> - const struct perf_event_attr *attr;
> struct bpf_event_entry *ee;
> - struct perf_event *event;
> struct file *perf_file;
>
> perf_file = perf_event_get(fd);
> if (IS_ERR(perf_file))
> return perf_file;
>
> - event = perf_file->private_data;
> - ee = ERR_PTR(-EINVAL);
> -
> - attr = perf_event_attrs(event);
> - if (IS_ERR(attr) || attr->inherit)
> - goto err_out;
> -
> - switch (attr->type) {
> - case PERF_TYPE_SOFTWARE:
> - if (attr->config != PERF_COUNT_SW_BPF_OUTPUT)
> - goto err_out;
> - /* fall-through */
> - case PERF_TYPE_RAW:
> - case PERF_TYPE_HARDWARE:
> - ee = bpf_event_entry_gen(perf_file, map_file);
> - if (ee)
> - return ee;
> - ee = ERR_PTR(-ENOMEM);
> - /* fall-through */
> - default:
> - break;
> - }
Would it make sense to call perf_event_read_local() on the events here
in order to weed out the -EOPNOTSUPP ones?
> + ee = bpf_event_entry_gen(perf_file, map_file);
> + if (ee)
> + return ee;
>
> -err_out:
> + ee = ERR_PTR(-ENOMEM);
> fput(perf_file);
> return ee;
> }
^ permalink raw reply
* Re: [net-next] team: add macro MODULE_ALIAS_TEAM_MODE for team mode alias
From: Jiri Pirko @ 2017-06-02 8:10 UTC (permalink / raw)
To: Zhang Shengju; +Cc: davem, netdev
In-Reply-To: <1496302622-9958-1-git-send-email-zhangshengju@cmss.chinamobile.com>
Thu, Jun 01, 2017 at 09:37:02AM CEST, zhangshengju@cmss.chinamobile.com wrote:
>Add a new macro MODULE_ALIAS_TEAM_MODE to unify and simplify the
>declaration of team mode alias.
>
>Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [patch iproute2 v2 repost 3/3] tc/actions: introduce support for goto chain action
From: Jiri Pirko @ 2017-06-02 8:15 UTC (permalink / raw)
To: Jiri Benc
Cc: netdev, davem, jhs, xiyou.wangcong, dsa, edumazet, stephen,
daniel, alexander.h.duyck, simon.horman, mlxsw
In-Reply-To: <20170531142702.6d0ca6fa@griffin>
Wed, May 31, 2017 at 02:27:02PM CEST, jbenc@redhat.com wrote:
>On Tue, 16 May 2017 19:29:37 +0200, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@mellanox.com>
>>
>> Allow user to set control action "goto" with filter chain index as
>> a parameter.
>>
>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>> ---
>> include/linux/pkt_cls.h | 16 +++++++++++++++-
>> man/man8/tc-ife.8 | 2 +-
>> man/man8/tc-pedit.8 | 2 +-
>> man/man8/tc-police.8 | 2 +-
>> man/man8/tc-vlan.8 | 2 +-
>
>Jiri, this *seriously* needs a proper documentation. I consider myself
>to be well above average in understanding tc filters and actions, and as
>you know I participated at least passively in some chats about the
>chains. Yet I'm still very lost in semantics of chains. I cannot
>imagine how an average user would be able to use this.
>
>Some questions about the semantics:
>
>- What chain(s) are processed by default? If I don't use goto_chain but
> have multiple chains, will only chain 0 be processed, or more? In
> what order, what are the rules? If I don't have a chain 0, what would
> happen?
0 only. I exepcter it makes sense. But you are right, I will put it to
man.
>
>- What is the relation between priorities and chains? I expected that
> chains are under the same priority but that's not the case in your
> example. For a user, it's very unclear why there are priorities and
> chains. They appear to do the same thing, why can't I just jump
> between priorities?
Basically, what we had previously was single chain (0) only. Now we have
multichain, each chain is completely independent list of tps, each tp
having its prio.
I will also add this to man.
>
>Please, in addition to explaining here on the list, add detailed
>explanation to the man pages.
>
>Thanks,
>
> Jiri
^ permalink raw reply
* Re: [patch iproute2 v2 repost 3/3] tc/actions: introduce support for goto chain action
From: Jiri Benc @ 2017-06-02 8:22 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, jhs, xiyou.wangcong, dsa, edumazet, stephen,
daniel, alexander.h.duyck, simon.horman, mlxsw
In-Reply-To: <20170602081512.GB2015@nanopsycho.orion>
On Fri, 2 Jun 2017 10:15:12 +0200, Jiri Pirko wrote:
> 0 only. I exepcter it makes sense. But you are right, I will put it to
> man.
Thanks!
> Basically, what we had previously was single chain (0) only. Now we have
> multichain, each chain is completely independent list of tps, each tp
> having its prio.
Okay, chains are superior to priorities. It was not clear :-)
> I will also add this to man.
Thanks,
Jiri
^ permalink raw reply
* [PATCH][-next] mwifiex: make function mwifiex_ret_pkt_aggr_ctrl static
From: Colin King @ 2017-06-02 8:56 UTC (permalink / raw)
To: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
Kalle Valo, linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
function mwifiex_ret_pkt_aggr_ctrl can be made static as it does not
need to be in global scope.
Cleans up sparse warning: "symbol 'mwifiex_ret_pkt_aggr_ctrl' was not
declared. Should it be static?"
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
index 3348fb3a7514..2945775e83c5 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
@@ -1154,8 +1154,8 @@ static int mwifiex_ret_chan_region_cfg(struct mwifiex_private *priv,
return 0;
}
-int mwifiex_ret_pkt_aggr_ctrl(struct mwifiex_private *priv,
- struct host_cmd_ds_command *resp)
+static int mwifiex_ret_pkt_aggr_ctrl(struct mwifiex_private *priv,
+ struct host_cmd_ds_command *resp)
{
struct host_cmd_ds_pkt_aggr_ctrl *pkt_aggr_ctrl =
&resp->params.pkt_aggr_ctrl;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
From: Maxime Ripard @ 2017-06-02 9:13 UTC (permalink / raw)
To: David Miller
Cc: clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wens-jdAy2FN1RRM, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
peppe.cavallaro-qxv4g6HH51o, alexandre.torgue-qxv4g6HH51o,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170602063752.aqyvwcykvepiyt4y-ZC1Zs529Oq4@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 926 bytes --]
On Fri, Jun 02, 2017 at 08:37:52AM +0200, Maxime Ripard wrote:
> On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller wrote:
> > From: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date: Wed, 31 May 2017 09:18:31 +0200
> >
> > > This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> > > present on Allwinner H3/H5/A83T/A64 SoCs.
> >
> > Series applied, but wow that's a lot of DT file changes :-(
>
> The DT patches should not go through your tree, but arm-soc, so I
> guess this is not an issue for you?
Ok, so I saw that you actually merged them. Can you revert or drop
that merge for the DT part?
This will generate a lot of conflicts with our tree, and I'm not sure
this would be efficient to make you take all the entirely unrelated to
next patches.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH] virtio_net: lower limit on buffer size
From: Sergei Shtylyov @ 2017-06-02 9:34 UTC (permalink / raw)
To: Michael S. Tsirkin, linux-kernel
Cc: J. Bruce Fields, netdev, Mikulas Patocka, virtualization
In-Reply-To: <1496361148-4603-1-git-send-email-mst@redhat.com>
Hello!
On 6/2/2017 2:56 AM, Michael S. Tsirkin wrote:
> commit d85b758f72b0 "virtio_net: fix support for small rings"
Commit d85b758f72b0 ("virtio_net: fix support for small rings")
> was supposed to increase the buffer size for small rings
> but had an unintentional side effect of decreasing
> it for large rings. This seems to break some setups -
> it's not yet clear why, but increasing buffer size
> back to what it was before helps.
>
> Fixes: d85b758f72b0 "virtio_net: fix support for small rings"
Fixes: d85b758f72b0 ("virtio_net: fix support for small rings")
> Reported-by: Mikulas Patocka <mpatocka@redhat.com>
> Reported-by: "J. Bruce Fields" <bfields@fieldses.org>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
[...]
MBR, Sergei
^ permalink raw reply
* RE: [PATCH nf-next] netns: add and use net_ns_barrier
From: David Laight @ 2017-06-02 9:38 UTC (permalink / raw)
To: 'Florian Westphal', netfilter-devel@vger.kernel.org
Cc: netdev@vger.kernel.org, Eric W. Biederman
In-Reply-To: <20170530093812.10712-1-fw@strlen.de>
From: Florian Westphal
> Sent: 30 May 2017 10:38
>
> Quoting Joe Stringer:
> If a user loads nf_conntrack_ftp, sends FTP traffic through a network
> namespace, destroys that namespace then unloads the FTP helper module,
> then the kernel will crash.
>
> Events that lead to the crash:
> 1. conntrack is created with ftp helper in netns x
> 2. This netns is destroyed
> 3. netns destruction is scheduled
> 4. netns destruction wq starts, removes netns from global list
> 5. ftp helper is unloaded, which resets all helpers of the conntracks
> via for_each_net()
>
> but because netns is already gone from list the for_each_net() loop
> doesn't include it, therefore all of these conntracks are unaffected.
>
> 6. helper module unload finishes
> 7. netns wq invokes destructor for rmmod'ed helper
>
...
> void
> nf_ct_iterate_destroy(int (*iter)(struct nf_conn *i, void *data), void *data)
> @@ -1734,6 +1736,13 @@ nf_ct_iterate_destroy(int (*iter)(struct nf_conn *i, void *data), void *data)
> }
> rtnl_unlock();
>
> + /* Need to wait for netns cleanup worker to finish, if its
> + * running -- it might have deleted a net namespace from
> + * the global list, so our __nf_ct_unconfirmed_destroy() might
> + * not have affected all namespaces.
> + */
> + net_ns_barrier();
> +
A problem I see is that nothing obvious guarantees that the cleanup worker
has actually started.
David
^ permalink raw reply
* [PATCH] net-procfs: Use vsnprintf extension %phN
From: Joe Perches @ 2017-06-02 9:40 UTC (permalink / raw)
To: linux-kernel; +Cc: David S. Miller, netdev
Save a bit of code by using the kernel extension.
$ size net/core/net-procfs.o*
text data bss dec hex filename
3701 120 0 3821 eed net/core/net-procfs.o.new
3764 120 0 3884 f2c net/core/net-procfs.o.old
Signed-off-by: Joe Perches <joe@perches.com>
---
net/core/net-procfs.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/net/core/net-procfs.c b/net/core/net-procfs.c
index 14d09345f00d..4847964931df 100644
--- a/net/core/net-procfs.c
+++ b/net/core/net-procfs.c
@@ -363,15 +363,10 @@ static int dev_mc_seq_show(struct seq_file *seq, void *v)
netif_addr_lock_bh(dev);
netdev_for_each_mc_addr(ha, dev) {
- int i;
-
- seq_printf(seq, "%-4d %-15s %-5d %-5d ", dev->ifindex,
- dev->name, ha->refcount, ha->global_use);
-
- for (i = 0; i < dev->addr_len; i++)
- seq_printf(seq, "%02x", ha->addr[i]);
-
- seq_putc(seq, '\n');
+ seq_printf(seq, "%-4d %-15s %-5d %-5d %*phN\n",
+ dev->ifindex, dev->name,
+ ha->refcount, ha->global_use,
+ (int)dev->addr_len, ha->addr);
}
netif_addr_unlock_bh(dev);
return 0;
--
2.10.0.rc2.1.g053435c
^ permalink raw reply related
* Re: [PATCH 04/12] fs: ceph: CURRENT_TIME with ktime_get_real_ts()
From: Arnd Bergmann @ 2017-06-02 9:45 UTC (permalink / raw)
To: Yan, Zheng
Cc: yuchao0-hv44wF8Li93QT0dZR+AlfA, J. Bruce Fields, Chris Mason,
linux-mtd, Deepa Dinamani, Evgeniy Dushistov, Jeff Layton,
ceph-devel, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
linux-cifs-u79uwXL29TY76Z2rM5mHXA, Paul Moore, y2038 Mailman List,
Ingo Molnar, Steven Rostedt, Drokin, Oleg, John Stultz, Al Viro,
David Sterba, Jaegeuk Kim, Thomas Gleixner, Josef Bacik, gregkh,
samba-technical-w/Ol4Ecudpl8XjKLYN78aQ, Linux Kernel Mailing List,
Eric
In-Reply-To: <CAAM7YAkXNo_69tOrw6a5kpyref9nEpEp-2vxBbFVSHGmAVbt+A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Jun 2, 2017 at 4:09 AM, Yan, Zheng <ukernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Fri, Jun 2, 2017 at 8:57 AM, Deepa Dinamani <deepa.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Thu, Jun 1, 2017 at 5:36 PM, John Stultz <john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>> On Thu, Jun 1, 2017 at 5:26 PM, Yan, Zheng <ukernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>> On Thu, Jun 1, 2017 at 6:22 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>>>>> On Thu, Jun 1, 2017 at 11:56 AM, Yan, Zheng <ukernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>>> On Sat, Apr 8, 2017 at 8:57 AM, Deepa Dinamani <deepa.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>>
>>>>>>> diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
>>>>>>> index 517838b..77204da 100644
>>>>>>> --- a/drivers/block/rbd.c
>>>>>>> +++ b/drivers/block/rbd.c
>>>>>>> @@ -1922,7 +1922,7 @@ static void rbd_osd_req_format_write(struct rbd_obj_request *obj_request)
>>>>>>> {
>>>>>>> struct ceph_osd_request *osd_req = obj_request->osd_req;
>>>>>>>
>>>>>>> - osd_req->r_mtime = CURRENT_TIME;
>>>>>>> + ktime_get_real_ts(&osd_req->r_mtime);
>>>>>>> osd_req->r_data_offset = obj_request->offset;
>>>>>>> }
>>>>>>>
>>>>>>> diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c
>>>>>>> index c681762..1d3fa90 100644
>>>>>>> --- a/fs/ceph/mds_client.c
>>>>>>> +++ b/fs/ceph/mds_client.c
>>>>>>> @@ -1666,6 +1666,7 @@ struct ceph_mds_request *
>>>>>>> ceph_mdsc_create_request(struct ceph_mds_client *mdsc, int op, int mode)
>>>>>>> {
>>>>>>> struct ceph_mds_request *req = kzalloc(sizeof(*req), GFP_NOFS);
>>>>>>> + struct timespec ts;
>>>>>>>
>>>>>>> if (!req)
>>>>>>> return ERR_PTR(-ENOMEM);
>>>>>>> @@ -1684,7 +1685,8 @@ ceph_mdsc_create_request(struct ceph_mds_client *mdsc, int op, int mode)
>>>>>>> init_completion(&req->r_safe_completion);
>>>>>>> INIT_LIST_HEAD(&req->r_unsafe_item);
>>>>>>>
>>>>>>> - req->r_stamp = current_fs_time(mdsc->fsc->sb);
>>>>>>> + ktime_get_real_ts(&ts);
>>>>>>> + req->r_stamp = timespec_trunc(ts, mdsc->fsc->sb->s_time_gran);
>>>>>>
>>>>>> This change causes our kernel_untar_tar test case to fail (inode's
>>>>>> ctime goes back). The reason is that there is time drift between the
>>>>>> time stamps got by ktime_get_real_ts() and current_time(). We need to
>>>>>> revert this change until current_time() uses ktime_get_real_ts()
>>>>>> internally.
>>>>>
>>>>> Hmm, the change was not supposed to have a user-visible effect, so
>>>>> something has gone wrong, but I don't immediately see how it
>>>>> relates to what you observe.
>>>>>
>>>>> ktime_get_real_ts() and current_time() use the same time base, there
>>>>> is no drift, but there is a difference in resolution, as the latter uses
>>>>> the time stamp of the last jiffies update, which may be up to one jiffy
>>>>> (10ms) behind the exact time we put in the request stamps here.
>>>>>
>>>>> Do you still see problems if you use current_kernel_time() instead of
>>>>> ktime_get_real_ts()?
>>>>
>>>> The problem disappears after using current_kernel_time().
>>>>
>>>> https://github.com/ceph/ceph-client/commit/2e0f648da23167034a3cf1500bc90ec60aef2417
>>>
>>> From the commit above:
>>> "It seems there is time drift between ktime_get_real_ts() and
>>> current_kernel_time()"
>>>
>>> Its more of a granularity difference. current_kernel_time() returns
>>> the cached time at the last tick, where as ktime_get_real_ts() reads
>>> the clocksource hardware and returns the immediate time.
>>>
>>> Filesystems usually use the cached time (similar to
>>> CLOCK_REALTIME_COARSE), for performance reasons, as touching the
>>> clocksource takes time.
>>
>> Alternatively, it would be best for this code also to use current_time().
>> I had suggested this in one of the previous versions of the patch.
>> The implementation of current_time() will change when we switch vfs to
>> use 64 bit time. This will prevent such errors from happening again.
>> But, this also means there is more code reordering for these modules
>> to get a reference to inode.
>>
>
> I took a look. it's quite inconvenience to use current_time(). I
> prefer to temporarily use current_kernel_time().
I've looked at the code some more and I think there is another angle to it:
In your test case, 'tar' calls into the utimes syscall (or a member of its
family), which sets the i_ctime field in the inode to the curren time
(using current_time()), then calls __ceph_setattr(), which creates
a mds client request, and ceph_mdsc_create_request() takes another
time stamp and stores it in r_stamp.
We then store the first timestamp (only) in the in-memory inode, and the
second time stamp in the request. Depending on the state of the inode,
we may also set the ctime to a third timestamp we again take using
current_time().
The mtime and atime from user space get passed correctly through
union ceph_mds_request_args->setattr and are kept in sync between
the in-memory inode and the persistent inode data, but the ctime
in the inode never makes it to the lower protocol levels and instead
we use the r_stamp field that got set a little earlier or a little later.
I believe the bug you see is the result of the two timestamps
currently being almost guaranteed to be different in the latest
kernels.
Changing r_stamp to use current_kernel_time() will make it the
same value most of the time (as it was before Deepa's patch),
but when the timer interrupt happens between the timestamps,
the two are still different, it's just much harder to hit.
I think the proper solution should be to change __ceph_setattr()
in a way that has req->r_stamp always synchronized with i_ctime.
If we copy i_ctime to r_stamp, that will also take care of the
future issues with the planned changes to current_time().
The part I don't understand is what else r_stamp (i.e. the time
stamp in ceph_msg_data with type==
CEPH_MSG_CLIENT_REQUEST) is used for, other than setting
ctime in CEPH_MDS_OP_SETATTR.
Will this be used to update the stored i_ctime for other operations
too? If so, we would need to synchronize it with the in-memory
i_ctime for all operations that do this.
Semi-related side note: I see that the granularity for ceph_timespec
is 1000 nanoseconds, so the value is always a multiple of 1000.
If the full 32-bit data gets stored, we could use this it to store the
epoch number in the future:
static inline void ceph_decode_timespec(struct timespec64 *ts,
const struct ceph_timespec *tv)
{
u32 ns_epoch = le32_to_cpu(tv->tv_nsec);
u32 epoch = ns_epoch % 1000;
/* tv_sec is traditionally interpreted as unsigned
* with time ranges 1970-2106, we extend
* it to 1970-138069 */
ts->tv_sec = (u64)le32_to_cpu(tv->tv_sec) +
(u64)epoch << 32;
ts->tv_nsec = ns_epoch - epoch;
}
Arnd
^ permalink raw reply
* Re: [PATCH nf-next] netns: add and use net_ns_barrier
From: Florian Westphal @ 2017-06-02 9:53 UTC (permalink / raw)
To: David Laight
Cc: 'Florian Westphal', netfilter-devel@vger.kernel.org,
netdev@vger.kernel.org, Eric W. Biederman
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DD000799C@AcuExch.aculab.com>
David Laight <David.Laight@ACULAB.COM> wrote:
> From: Florian Westphal
> > Sent: 30 May 2017 10:38
> >
> > Quoting Joe Stringer:
> > If a user loads nf_conntrack_ftp, sends FTP traffic through a network
> > namespace, destroys that namespace then unloads the FTP helper module,
> > then the kernel will crash.
> >
> > Events that lead to the crash:
> > 1. conntrack is created with ftp helper in netns x
> > 2. This netns is destroyed
> > 3. netns destruction is scheduled
> > 4. netns destruction wq starts, removes netns from global list
> > 5. ftp helper is unloaded, which resets all helpers of the conntracks
> > via for_each_net()
> >
> > but because netns is already gone from list the for_each_net() loop
> > doesn't include it, therefore all of these conntracks are unaffected.
> >
> > 6. helper module unload finishes
> > 7. netns wq invokes destructor for rmmod'ed helper
> >
> ...
> > void
> > nf_ct_iterate_destroy(int (*iter)(struct nf_conn *i, void *data), void *data)
> > @@ -1734,6 +1736,13 @@ nf_ct_iterate_destroy(int (*iter)(struct nf_conn *i, void *data), void *data)
> > }
> > rtnl_unlock();
> >
> > + /* Need to wait for netns cleanup worker to finish, if its
> > + * running -- it might have deleted a net namespace from
> > + * the global list, so our __nf_ct_unconfirmed_destroy() might
> > + * not have affected all namespaces.
> > + */
> > + net_ns_barrier();
> > +
>
> A problem I see is that nothing obvious guarantees that the cleanup worker
> has actually started.
If it hasn't even started, the earlier for_each_net() has seen all
net namespaces and we managed to clear helper extensions of all conntracks.
Same in case it has finished already: netns cleanup work queue has
free'd all the affected conntracks we might have missed.
We only are in trouble if netns work queue is running concurrently:
netns cleanup first removes net namespaces from the global list,
so nf_ct_iterate_destroy might have missed these.
^ permalink raw reply
* Re: [PATCH 04/12] fs: ceph: CURRENT_TIME with ktime_get_real_ts()
From: Yan, Zheng @ 2017-06-02 10:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Deepa Dinamani, John Stultz, Linux Kernel Mailing List,
Andrew Morton, Thomas Gleixner, Al Viro, gregkh, Dilger, Andreas,
J. Bruce Fields, Chris Mason, David Miller, David Sterba,
Evgeniy Dushistov, Eric Paris, Jaegeuk Kim, Josef Bacik,
Jeff Layton, James Simmons, Ingo Molnar, Drokin, Oleg
In-Reply-To: <CAK8P3a1TwkVRCwDWqgYE8Z3wZT2+v6xayq=dVeW8KaHmO0W4cg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Jun 2, 2017 at 5:45 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Fri, Jun 2, 2017 at 4:09 AM, Yan, Zheng <ukernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Fri, Jun 2, 2017 at 8:57 AM, Deepa Dinamani <deepa.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> On Thu, Jun 1, 2017 at 5:36 PM, John Stultz <john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>>> On Thu, Jun 1, 2017 at 5:26 PM, Yan, Zheng <ukernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>> On Thu, Jun 1, 2017 at 6:22 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>>>>>> On Thu, Jun 1, 2017 at 11:56 AM, Yan, Zheng <ukernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>>>> On Sat, Apr 8, 2017 at 8:57 AM, Deepa Dinamani <deepa.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>>>
>>>>>>>> diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
>>>>>>>> index 517838b..77204da 100644
>>>>>>>> --- a/drivers/block/rbd.c
>>>>>>>> +++ b/drivers/block/rbd.c
>>>>>>>> @@ -1922,7 +1922,7 @@ static void rbd_osd_req_format_write(struct rbd_obj_request *obj_request)
>>>>>>>> {
>>>>>>>> struct ceph_osd_request *osd_req = obj_request->osd_req;
>>>>>>>>
>>>>>>>> - osd_req->r_mtime = CURRENT_TIME;
>>>>>>>> + ktime_get_real_ts(&osd_req->r_mtime);
>>>>>>>> osd_req->r_data_offset = obj_request->offset;
>>>>>>>> }
>>>>>>>>
>>>>>>>> diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c
>>>>>>>> index c681762..1d3fa90 100644
>>>>>>>> --- a/fs/ceph/mds_client.c
>>>>>>>> +++ b/fs/ceph/mds_client.c
>>>>>>>> @@ -1666,6 +1666,7 @@ struct ceph_mds_request *
>>>>>>>> ceph_mdsc_create_request(struct ceph_mds_client *mdsc, int op, int mode)
>>>>>>>> {
>>>>>>>> struct ceph_mds_request *req = kzalloc(sizeof(*req), GFP_NOFS);
>>>>>>>> + struct timespec ts;
>>>>>>>>
>>>>>>>> if (!req)
>>>>>>>> return ERR_PTR(-ENOMEM);
>>>>>>>> @@ -1684,7 +1685,8 @@ ceph_mdsc_create_request(struct ceph_mds_client *mdsc, int op, int mode)
>>>>>>>> init_completion(&req->r_safe_completion);
>>>>>>>> INIT_LIST_HEAD(&req->r_unsafe_item);
>>>>>>>>
>>>>>>>> - req->r_stamp = current_fs_time(mdsc->fsc->sb);
>>>>>>>> + ktime_get_real_ts(&ts);
>>>>>>>> + req->r_stamp = timespec_trunc(ts, mdsc->fsc->sb->s_time_gran);
>>>>>>>
>>>>>>> This change causes our kernel_untar_tar test case to fail (inode's
>>>>>>> ctime goes back). The reason is that there is time drift between the
>>>>>>> time stamps got by ktime_get_real_ts() and current_time(). We need to
>>>>>>> revert this change until current_time() uses ktime_get_real_ts()
>>>>>>> internally.
>>>>>>
>>>>>> Hmm, the change was not supposed to have a user-visible effect, so
>>>>>> something has gone wrong, but I don't immediately see how it
>>>>>> relates to what you observe.
>>>>>>
>>>>>> ktime_get_real_ts() and current_time() use the same time base, there
>>>>>> is no drift, but there is a difference in resolution, as the latter uses
>>>>>> the time stamp of the last jiffies update, which may be up to one jiffy
>>>>>> (10ms) behind the exact time we put in the request stamps here.
>>>>>>
>>>>>> Do you still see problems if you use current_kernel_time() instead of
>>>>>> ktime_get_real_ts()?
>>>>>
>>>>> The problem disappears after using current_kernel_time().
>>>>>
>>>>> https://github.com/ceph/ceph-client/commit/2e0f648da23167034a3cf1500bc90ec60aef2417
>>>>
>>>> From the commit above:
>>>> "It seems there is time drift between ktime_get_real_ts() and
>>>> current_kernel_time()"
>>>>
>>>> Its more of a granularity difference. current_kernel_time() returns
>>>> the cached time at the last tick, where as ktime_get_real_ts() reads
>>>> the clocksource hardware and returns the immediate time.
>>>>
>>>> Filesystems usually use the cached time (similar to
>>>> CLOCK_REALTIME_COARSE), for performance reasons, as touching the
>>>> clocksource takes time.
>>>
>>> Alternatively, it would be best for this code also to use current_time().
>>> I had suggested this in one of the previous versions of the patch.
>>> The implementation of current_time() will change when we switch vfs to
>>> use 64 bit time. This will prevent such errors from happening again.
>>> But, this also means there is more code reordering for these modules
>>> to get a reference to inode.
>>>
>>
>> I took a look. it's quite inconvenience to use current_time(). I
>> prefer to temporarily use current_kernel_time().
>
> I've looked at the code some more and I think there is another angle to it:
> In your test case, 'tar' calls into the utimes syscall (or a member of its
> family), which sets the i_ctime field in the inode to the curren time
> (using current_time()), then calls __ceph_setattr(), which creates
> a mds client request, and ceph_mdsc_create_request() takes another
> time stamp and stores it in r_stamp.
>
> We then store the first timestamp (only) in the in-memory inode, and the
> second time stamp in the request. Depending on the state of the inode,
> we may also set the ctime to a third timestamp we again take using
> current_time().
>
> The mtime and atime from user space get passed correctly through
> union ceph_mds_request_args->setattr and are kept in sync between
> the in-memory inode and the persistent inode data, but the ctime
> in the inode never makes it to the lower protocol levels and instead
> we use the r_stamp field that got set a little earlier or a little later.
>
> I believe the bug you see is the result of the two timestamps
> currently being almost guaranteed to be different in the latest
> kernels.
> Changing r_stamp to use current_kernel_time() will make it the
> same value most of the time (as it was before Deepa's patch),
> but when the timer interrupt happens between the timestamps,
> the two are still different, it's just much harder to hit.
>
> I think the proper solution should be to change __ceph_setattr()
> in a way that has req->r_stamp always synchronized with i_ctime.
> If we copy i_ctime to r_stamp, that will also take care of the
> future issues with the planned changes to current_time().
>
I already have a patch
https://github.com/ceph/ceph-client/commit/24f54cd18e195a002ee3d2ab50dbc952fd9f82af
> The part I don't understand is what else r_stamp (i.e. the time
> stamp in ceph_msg_data with type==
> CEPH_MSG_CLIENT_REQUEST) is used for, other than setting
> ctime in CEPH_MDS_OP_SETATTR.
>
> Will this be used to update the stored i_ctime for other operations
> too? If so, we would need to synchronize it with the in-memory
> i_ctime for all operations that do this.
>
yes, mds uses it to update ctime of modified inodes. For example,
when handling mkdir, mds set ctime of both parent inode and new inode
to r_stamp.
Regards
Yan, Zheng
> Semi-related side note: I see that the granularity for ceph_timespec
> is 1000 nanoseconds, so the value is always a multiple of 1000.
> If the full 32-bit data gets stored, we could use this it to store the
> epoch number in the future:
>
> static inline void ceph_decode_timespec(struct timespec64 *ts,
> const struct ceph_timespec *tv)
> {
> u32 ns_epoch = le32_to_cpu(tv->tv_nsec);
> u32 epoch = ns_epoch % 1000;
>
> /* tv_sec is traditionally interpreted as unsigned
> * with time ranges 1970-2106, we extend
> * it to 1970-138069 */
> ts->tv_sec = (u64)le32_to_cpu(tv->tv_sec) +
> (u64)epoch << 32;
> ts->tv_nsec = ns_epoch - epoch;
> }
>
> Arnd
^ permalink raw reply
* Re: [PATCH v4 5/6] stmmac: pci: Use dmi_system_id table for retrieving PHY addresses
From: Andy Shevchenko @ 2017-06-02 10:43 UTC (permalink / raw)
To: Jan Kiszka
Cc: Giuseppe Cavallaro, Alexandre Torgue, David Miller, netdev,
linux-kernel@vger.kernel.org
In-Reply-To: <33942c3893beaca0f82528386fa3b239a6a02f02.1496388893.git.jan.kiszka@siemens.com>
On Fri, Jun 2, 2017 at 10:34 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> Avoids reimplementation of DMI matching in stmmac_pci_find_phy_addr.
> +static const struct stmmac_pci_func_data galileo_stmmac_func_data[] = {
> {
> .func = 6,
> .phy_addr = 1,
> },
> + { },
Now this is redundant.
> +};
> +static const struct stmmac_pci_dmi_data galileo_stmmac_dmi_data = {
> + .func = galileo_stmmac_func_data,
> + .nfuncs = ARRAY_SIZE(galileo_stmmac_func_data),
It will be 2, when is supposed to be 1, see above.
> +};
> +static const struct stmmac_pci_func_data iot2040_stmmac_func_data[] = {
> + { },
> +};
> + .nfuncs = ARRAY_SIZE(iot2040_stmmac_func_data),
Ditto.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 6/6] stmmac: pci: Remove setup handler indirection via stmmac_pci_info
From: Andy Shevchenko @ 2017-06-02 10:44 UTC (permalink / raw)
To: Jan Kiszka
Cc: Giuseppe Cavallaro, Alexandre Torgue, David Miller, netdev,
linux-kernel@vger.kernel.org
In-Reply-To: <1df4f24d4bb29a37a7b3b45a8ee359658c760878.1496388893.git.jan.kiszka@siemens.com>
On Fri, Jun 2, 2017 at 10:34 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> By now, stmmac_pci_info only contains a single entry. Register this
> directly with the PCI device table, removing one indirection.
Please, drop this patch from the next version.
We can discuss it after the first 5 will be in.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 04/12] fs: ceph: CURRENT_TIME with ktime_get_real_ts()
From: Arnd Bergmann @ 2017-06-02 10:51 UTC (permalink / raw)
To: Yan, Zheng
Cc: yuchao0-hv44wF8Li93QT0dZR+AlfA, J. Bruce Fields, Chris Mason,
linux-mtd, Deepa Dinamani, Evgeniy Dushistov, Jeff Layton,
ceph-devel, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
linux-cifs-u79uwXL29TY76Z2rM5mHXA, Paul Moore, y2038 Mailman List,
Ingo Molnar, Steven Rostedt, Drokin, Oleg, John Stultz, Al Viro,
David Sterba, Jaegeuk Kim, Thomas Gleixner, Josef Bacik, gregkh,
samba-technical-w/Ol4Ecudpl8XjKLYN78aQ, Linux Kernel Mailing List,
Eric
In-Reply-To: <CAAM7YA=BJHFLz_Ud==7L=yCzxj+1sjctc68tvpNogPhiSxxELQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Jun 2, 2017 at 12:10 PM, Yan, Zheng <ukernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Fri, Jun 2, 2017 at 5:45 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>> On Fri, Jun 2, 2017 at 4:09 AM, Yan, Zheng <ukernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> On Fri, Jun 2, 2017 at 8:57 AM, Deepa Dinamani <deepa.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>> On Thu, Jun 1, 2017 at 5:36 PM, John Stultz <john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>>>> On Thu, Jun 1, 2017 at 5:26 PM, Yan, Zheng <ukernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>> I believe the bug you see is the result of the two timestamps
>> currently being almost guaranteed to be different in the latest
>> kernels.
>> Changing r_stamp to use current_kernel_time() will make it the
>> same value most of the time (as it was before Deepa's patch),
>> but when the timer interrupt happens between the timestamps,
>> the two are still different, it's just much harder to hit.
>>
>> I think the proper solution should be to change __ceph_setattr()
>> in a way that has req->r_stamp always synchronized with i_ctime.
>> If we copy i_ctime to r_stamp, that will also take care of the
>> future issues with the planned changes to current_time().
>>
> I already have a patch
> https://github.com/ceph/ceph-client/commit/24f54cd18e195a002ee3d2ab50dbc952fd9f82af
Looks good to me. In case anyone cares:
Acked-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
>> The part I don't understand is what else r_stamp (i.e. the time
>> stamp in ceph_msg_data with type==
>> CEPH_MSG_CLIENT_REQUEST) is used for, other than setting
>> ctime in CEPH_MDS_OP_SETATTR.
>>
>> Will this be used to update the stored i_ctime for other operations
>> too? If so, we would need to synchronize it with the in-memory
>> i_ctime for all operations that do this.
>>
>
> yes, mds uses it to update ctime of modified inodes. For example,
> when handling mkdir, mds set ctime of both parent inode and new inode
> to r_stamp.
I see, so we may have a variation of that problem there as well: From
my reading of the code, the child inode is not in memory yet, so
that seems fine, but I could not find where the parent in-memory inode
i_ctime is updated in ceph, but it is most likely not the same as
req->r_stamp (assuming it gets updated at all).
Would it make sense require all callers of ceph_mdsc_do_request()
to update r_stamp at the same time as i_ctime to keep them in sync?
Arnd
^ 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