* Re: [v8, bpf-next, 4/9] net/wireless/iwlwifi: fix iwlwifi_dev_ucode_error tracepoint
From: Steven Rostedt @ 2018-05-24 23:39 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Johannes Berg, Alexei Starovoitov, davem, daniel, torvalds,
peterz, mathieu.desnoyers, netdev, kernel-team, linux-api,
linux-wireless
In-Reply-To: <20180524232837.24jvdsdiohkpj7fs@ast-mbp>
On Thu, 24 May 2018 16:28:39 -0700
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> Ohh. I didn't realize that networking wireless doesn't fall under netdev.
> I thought wireless folks are silent because they are embarrassed
> by a function with 17 arguments.
Please lets refrain from the demeaning comments.
I agree with your argument, but not the tone.
-- Steve
^ permalink raw reply
* Re: [PATCH v5 20/28] fpga: dfl: add fpga bridge platform driver for FME
From: Wu Hao @ 2018-05-24 23:59 UTC (permalink / raw)
To: Alan Tull
Cc: Moritz Fischer, linux-fpga, linux-kernel, linux-api, Kang, Luwei,
Zhang, Yi Z, Tim Whisonant, Enno Luebbers, Shiva Rao,
Christopher Rauer
In-Reply-To: <CANk1AXRSVsC6uQkQsxzRYAB2U+119W6iP=vwPWA2X1R6xwYTzQ@mail.gmail.com>
On Thu, May 24, 2018 at 12:26:09PM -0500, Alan Tull wrote:
> On Wed, May 23, 2018 at 6:42 PM, Wu Hao <hao.wu@intel.com> wrote:
> > On Wed, May 23, 2018 at 04:06:17PM -0500, Alan Tull wrote:
> >> On Wed, May 23, 2018 at 10:28 AM, Wu Hao <hao.wu@intel.com> wrote:
> >> > On Wed, May 23, 2018 at 10:15:00AM -0500, Alan Tull wrote:
> >> >> On Tue, May 1, 2018 at 9:50 PM, Wu Hao <hao.wu@intel.com> wrote:
> >> >>
> >> >> Hi Hao,
> >> >>
> >> >> > This patch adds fpga bridge platform driver for FPGA Management Engine.
> >> >> > It implements the enable_set callback for fpga bridge.
> >> >> >
> >> >> > Signed-off-by: Tim Whisonant <tim.whisonant@intel.com>
> >> >> > Signed-off-by: Enno Luebbers <enno.luebbers@intel.com>
> >> >> > Signed-off-by: Shiva Rao <shiva.rao@intel.com>
> >> >> > Signed-off-by: Christopher Rauer <christopher.rauer@intel.com>
> >> >> > Signed-off-by: Wu Hao <hao.wu@intel.com>
> >> >> > Acked-by: Alan Tull <atull@kernel.org>
> >> >> > Acked-by: Moritz Fischer <mdf@kernel.org>
> >> >> > ---
> >> >> > v3: rename driver to fpga-dfl-fme-br
> >> >> > remove useless dev_dbg in probe function.
> >> >> > rebased due to fpga api change.
> >> >> > v4: rename to dfl-fme-br and fix SPDX license issue
> >> >> > include dfl-fme-pr.h instead of dfl-fme.h
> >> >> > add Acked-by from Alan and Moritz
> >> >> > v5: rebase due to API changes.
> >> >> > defer port and its ops finding when really need.
> >> >> > ---
> >> >> > drivers/fpga/Kconfig | 6 +++
> >> >> > drivers/fpga/Makefile | 1 +
> >> >> > drivers/fpga/dfl-fme-br.c | 114 ++++++++++++++++++++++++++++++++++++++++++++++
> >> >> > 3 files changed, 121 insertions(+)
> >> >> > create mode 100644 drivers/fpga/dfl-fme-br.c
> >> >> >
> >> >> > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> >> >> > index 89f76e8..a8f939a 100644
> >> >> > --- a/drivers/fpga/Kconfig
> >> >> > +++ b/drivers/fpga/Kconfig
> >> >> > @@ -156,6 +156,12 @@ config FPGA_DFL_FME_MGR
> >> >> > help
> >> >> > Say Y to enable FPGA Manager driver for FPGA Management Engine.
> >> >> >
> >> >> > +config FPGA_DFL_FME_BRIDGE
> >> >> > + tristate "FPGA DFL FME Bridge Driver"
> >> >> > + depends on FPGA_DFL_FME
> >> >> > + help
> >> >> > + Say Y to enable FPGA Bridge driver for FPGA Management Engine.
> >> >> > +
> >> >> > config FPGA_DFL_PCI
> >> >> > tristate "FPGA Device Feature List (DFL) PCIe Device Driver"
> >> >> > depends on PCI && FPGA_DFL
> >> >> > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> >> >> > index f82814a..75096e9 100644
> >> >> > --- a/drivers/fpga/Makefile
> >> >> > +++ b/drivers/fpga/Makefile
> >> >> > @@ -32,6 +32,7 @@ obj-$(CONFIG_OF_FPGA_REGION) += of-fpga-region.o
> >> >> > obj-$(CONFIG_FPGA_DFL) += dfl.o
> >> >> > obj-$(CONFIG_FPGA_DFL_FME) += dfl-fme.o
> >> >> > obj-$(CONFIG_FPGA_DFL_FME_MGR) += dfl-fme-mgr.o
> >> >> > +obj-$(CONFIG_FPGA_DFL_FME_BRIDGE) += dfl-fme-br.o
> >> >> >
> >> >> > dfl-fme-objs := dfl-fme-main.o dfl-fme-pr.o
> >> >> >
> >> >> > diff --git a/drivers/fpga/dfl-fme-br.c b/drivers/fpga/dfl-fme-br.c
> >> >> > new file mode 100644
> >> >> > index 0000000..5c51b08
> >> >> > --- /dev/null
> >> >> > +++ b/drivers/fpga/dfl-fme-br.c
> >> >> > @@ -0,0 +1,114 @@
> >> >> > +// SPDX-License-Identifier: GPL-2.0
> >> >> > +/*
> >> >> > + * FPGA Bridge Driver for FPGA Management Engine (FME)
> >> >> > + *
> >> >> > + * Copyright (C) 2017 Intel Corporation, Inc.
> >> >> > + *
> >> >> > + * Authors:
> >> >> > + * Wu Hao <hao.wu@intel.com>
> >> >> > + * Joseph Grecco <joe.grecco@intel.com>
> >> >> > + * Enno Luebbers <enno.luebbers@intel.com>
> >> >> > + * Tim Whisonant <tim.whisonant@intel.com>
> >> >> > + * Ananda Ravuri <ananda.ravuri@intel.com>
> >> >> > + * Henry Mitchel <henry.mitchel@intel.com>
> >> >> > + */
> >> >> > +
> >> >> > +#include <linux/module.h>
> >> >> > +#include <linux/fpga/fpga-bridge.h>
> >> >> > +
> >> >> > +#include "dfl.h"
> >> >> > +#include "dfl-fme-pr.h"
> >> >> > +
> >> >> > +struct fme_br_priv {
> >> >> > + struct dfl_fme_br_pdata *pdata;
> >> >> > + struct dfl_fpga_port_ops *port_ops;
> >> >> > + struct platform_device *port_pdev;
> >> >> > +};
> >> >> > +
> >> >> > +static int fme_bridge_enable_set(struct fpga_bridge *bridge, bool enable)
> >> >> > +{
> >> >> > + struct fme_br_priv *priv = bridge->priv;
> >> >> > + struct platform_device *port_pdev;
> >> >> > + struct dfl_fpga_port_ops *ops;
> >> >> > +
> >> >> > + if (!priv->port_pdev) {
> >> >> > + port_pdev = dfl_fpga_cdev_find_port(priv->pdata->cdev,
> >> >> > + &priv->pdata->port_id,
> >> >> > + dfl_fpga_check_port_id);
> >> >> > + if (!port_pdev)
> >> >> > + return -ENODEV;
> >> >> > +
> >> >> > + priv->port_pdev = port_pdev;
> >> >> > + }
> >> >> > +
> >> >> > + if (priv->port_pdev && !priv->port_ops) {
> >> >> > + ops = dfl_fpga_get_port_ops(priv->port_pdev);
> >> >> > + if (!ops || !ops->enable_set)
> >> >> > + return -ENOENT;
> >> >> > +
> >> >> > + priv->port_ops = ops;
> >> >> > + }
> >> >>
> >> >> This is saving some pointers. Is it possible that the port_pdev or
> >> >> port_ops could go away?
> >> >
> >> > Hi Alan
> >> >
> >> > Thanks for the comments.
> >> >
> >> > The find_port function will get the port device to prevent that.
> >> > You can see put device in remove function. And it's similar for the
> >> > port ops. In dfl_fpga_get_port_ops function, it will prevent unexpected
> >> > port ops removing by try module get.
> >>
> >> OK, good, and I see the find_port function documents that put_device
> >> is needed, so that's good too.
> >>
> >> When we previously discussed this [1] you described a procedure of
> >> hot-unplugging the VF AFU from the VM and turning it back to PF before
> >> doing the FPGA programming. Some comments on that would be helpful,
> >> maybe located with the port_ops functions.
> >>
> >
> > Hi Alan
> >
> > Actually I plan to add those descriptions about virtualization in the
> > documenation/fpga/dfl.txt, together with the patch which enables the
> > virtualization support for Intel FPGA device (e.g Intel PAC card).
>
> Great
>
> > I
> > think dfl.txt is a better place to have that procedure documented.
> > How do you think?
>
> If it is only in the dff.txt, it may remain unclear (in the code) that
> that is an issue that the code is working around.
No problem, I will add more comments in the code too.
>
> >
> >
> >> [1] https://lkml.org/lkml/2018/4/6/180
> >>
> >> >
> >> >>
> >> >> Also, the port ops routines probably should be named
> >> >> dfl_fpga_port_ops_get/find_port/etc
> >> >>
> >> >
> >> > Hm.. as I see there are functions named as get_device(), put_device(), so
> >> > I just name it as ..._get_port_ops and ..._put_port_ops in similar way. :)
> >> > If you think that could be a better name, it's fine for me to change them.
> >>
> >> Yes, I've seen that too. I think keeping the prefix the same helps to
> >> organize the namespace. Plus :) if I'm grepping through the code, I
> >> can be lazy and not have to use a regex to find the port ops
> >> functions.
> >
> > so we good with current naming?
>
> Recently GregKH give us some guidance about using a common prefix [2].
I see, Thanks.
>
> >
> > some places we find it's get_device() and put_device(), but other functions
> > like device_add(), device_del(). actually it's not a big problem I think, :)
> > currently port_ops has a unified style ..._add/del/get/put_port_ops. I am
> > fine with both kind of naming, if you prefer ...port_ops_add/del/get/put
> > style, please let me know, I can change them in the next version.
>
> Since you have struct dfl_fpga_port_ops, you can just add _{action} to
> the name of the struct and you have dfl_fpga_port_ops_add/del/get/pu
Sure, I will change them in the next version.
Hao
>
> Thanks,
> Alan
>
> [2] https://lkml.org/lkml/2018/3/15/709
>
> >
> > Thanks
> > Hao
> >
> >>
> >> Alan
> >>
> >> >
> >> > Thanks
> >> > Hao
> >> >
> >> >> Alan
> >> >>
> >> >> > +
> >> >> > + return priv->port_ops->enable_set(priv->port_pdev, enable);
> >> >> > +}
> >> >> > +
> >> >> > +static const struct fpga_bridge_ops fme_bridge_ops = {
> >> >> > + .enable_set = fme_bridge_enable_set,
> >> >> > +};
> >> >> > +
> >> >> > +static int fme_br_probe(struct platform_device *pdev)
> >> >> > +{
> >> >> > + struct device *dev = &pdev->dev;
> >> >> > + struct fme_br_priv *priv;
> >> >> > + struct fpga_bridge *br;
> >> >> > + int ret;
> >> >> > +
> >> >> > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> >> >> > + if (!priv)
> >> >> > + return -ENOMEM;
> >> >> > +
> >> >> > + priv->pdata = dev_get_platdata(dev);
> >> >> > +
> >> >> > + br = fpga_bridge_create(dev, "DFL FPGA FME Bridge",
> >> >> > + &fme_bridge_ops, priv);
> >> >> > + if (!br)
> >> >> > + return -ENOMEM;
> >> >> > +
> >> >> > + platform_set_drvdata(pdev, br);
> >> >> > +
> >> >> > + ret = fpga_bridge_register(br);
> >> >> > + if (ret)
> >> >> > + fpga_bridge_free(br);
> >> >> > +
> >> >> > + return ret;
> >> >> > +}
> >> >> > +
> >> >> > +static int fme_br_remove(struct platform_device *pdev)
> >> >> > +{
> >> >> > + struct fpga_bridge *br = platform_get_drvdata(pdev);
> >> >> > + struct fme_br_priv *priv = br->priv;
> >> >> > +
> >> >> > + fpga_bridge_unregister(br);
> >> >> > +
> >> >> > + if (priv->port_pdev)
> >> >> > + put_device(&priv->port_pdev->dev);
> >> >> > + if (priv->port_ops)
> >> >> > + dfl_fpga_put_port_ops(priv->port_ops);
> >> >> > +
> >> >> > + return 0;
> >> >> > +}
> >> >> > +
> >> >> > +static struct platform_driver fme_br_driver = {
> >> >> > + .driver = {
> >> >> > + .name = DFL_FPGA_FME_BRIDGE,
> >> >> > + },
> >> >> > + .probe = fme_br_probe,
> >> >> > + .remove = fme_br_remove,
> >> >> > +};
> >> >> > +
> >> >> > +module_platform_driver(fme_br_driver);
> >> >> > +
> >> >> > +MODULE_DESCRIPTION("FPGA Bridge for DFL FPGA Management Engine");
> >> >> > +MODULE_AUTHOR("Intel Corporation");
> >> >> > +MODULE_LICENSE("GPL v2");
> >> >> > +MODULE_ALIAS("platform:dfl-fme-bridge");
> >> >> > --
> >> >> > 1.8.3.1
> >> >> >
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/6] lib/rhashtable: guarantee initial hashtable allocation
From: Davidlohr Bueso @ 2018-05-25 3:26 UTC (permalink / raw)
To: akpm, torvalds
Cc: tgraf, herbert, manfred, guillaume.knispel, linux-api,
linux-kernel, Davidlohr Bueso
In-Reply-To: <20180524211135.27760-3-dave@stgolabs.net>
On Thu, 24 May 2018, Davidlohr Bueso wrote:
> size = sizeof(*tbl) + nbuckets * sizeof(tbl->buckets[0]);
>+ if (retry) {
>+ gfp |= __GFP_NOFAIL;
>+ tbl = kzalloc(size, gfp);
>+ } /* fall-through */
>+
> if (gfp != GFP_KERNEL)
> tbl = kzalloc(size, gfp | __GFP_NOWARN | __GFP_NORETRY);
This is wrong I'll fix in a v2, it should be _else_ if (gfp != GFP_KERNEL) ...
^ permalink raw reply
* Re: [PATCH -next 0/6] rhashtable: guarantee first allocation
From: Davidlohr Bueso @ 2018-05-25 3:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrew Morton, Thomas Graf, Herbert Xu, Manfred Spraul,
guillaume.knispel, Linux API, Linux Kernel Mailing List
In-Reply-To: <CA+55aFxnrwFniJq6nCFn4pWRHLH-Wac9bVFKieBC-TixTsFg=Q@mail.gmail.com>
On Thu, 24 May 2018, Linus Torvalds wrote:
>On Thu, May 24, 2018 at 2:28 PM Davidlohr Bueso <dave@stgolabs.net> wrote:
>> 10 files changed, 79 insertions(+), 86 deletions(-)
>
>I certainly can't complain about this small code removal, but I think if we
>did the kvmalloc_node() cleanup, we'd be able to get rid of even more.
>
>For example, bucket_table_alloc() does that
>
> if (gfp != GFP_KERNEL)
> tbl = kzalloc(size, gfp | __GFP_NOWARN | __GFP_NORETRY);
> else
> tbl = kvzalloc(size, gfp);
>
>purely due to the kvalloc_node() oddity. Wouldn't it be nice to just write
>it as
>
> tbl = kvzalloc(size, gfp);
>
>knowing that the whole point of all the kv*alloc*() functions is to "just
>do the right thing given size, gpf mask, and ease of allocation".
Yes this makes a lot of sense. I'll see about adding it on top.
Thanks,
Davidlohr
^ permalink raw reply
* Re: [v8, bpf-next, 4/9] net/wireless/iwlwifi: fix iwlwifi_dev_ucode_error tracepoint
From: Kalle Valo @ 2018-05-25 10:48 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Johannes Berg, Alexei Starovoitov, davem, daniel, torvalds,
peterz, rostedt, mathieu.desnoyers, netdev, kernel-team,
linux-api, linux-wireless
In-Reply-To: <20180524232837.24jvdsdiohkpj7fs@ast-mbp>
Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:
> On Wed, May 23, 2018 at 01:03:08PM +0200, Johannes Berg wrote:
>> On Wed, 2018-03-28 at 12:05 -0700, Alexei Starovoitov wrote:
>> > fix iwlwifi_dev_ucode_error tracepoint to pass pointer to a table
>> > instead of all 17 arguments by value.
>> > dvm/main.c and mvm/utils.c have 'struct iwl_error_event_table'
>> > defined with very similar yet subtly different fields and offsets.
>> > tracepoint is still common and using definition of 'struct iwl_error_event_table'
>> > from dvm/commands.h while copying fields.
>> > Long term this tracepoint probably should be split into two.
>>
>> It would've been nice to CC the wireless list for wireless related
>> patches ...
>
> Ohh. I didn't realize that networking wireless doesn't fall under netdev.
> I thought wireless folks are silent because they are embarrassed
> by a function with 17 arguments.
Really, this is the level of discussion now? You don't even bother to CC
the driver maintainers and your first reaction is that they are just too
embarrassed to answer? Oh man...
But if you continue doing these kind of "drive-by cleanups" to a
subsystem you are not familiar with, at least don't assume anything and
instead use get_maintainer script to find the maintainers so that the
patches get reviewed and applied to the correct tree:
$ scripts/get_maintainer.pl --no-rolestats --no-git -f drivers/net/wireless/intel/iwlwifi/dvm/main.c
Johannes Berg <johannes.berg@intel.com>
Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Luca Coelho <luciano.coelho@intel.com>
Intel Linux Wireless <linuxwifi@intel.com>
Kalle Valo <kvalo@codeaurora.org>
"David S. Miller" <davem@davemloft.net>
Daniel Borkmann <daniel@iogearbox.net>
Alexei Starovoitov <ast@kernel.org>
Kees Cook <keescook@chromium.org>
linux-wireless@vger.kernel.org
netdev@vger.kernel.org
linux-kernel@vger.kernel.org
--
Kalle Valo
^ permalink raw reply
* [PATCH 0/6 v1 resend] statfs: handle mount propagation
From: Christian Brauner @ 2018-05-25 12:48 UTC (permalink / raw)
To: linux-fsdevel, linux-kernel
Cc: torvalds, tglx, kstewart, gregkh, pombredanne, linux-api,
ebiederm, seth.forshee, viro, Christian Brauner
From: Christian Brauner <christian.brauner@ubuntu.com>
Hey,
This is v1 of this patchset. All changes from v0 to v1 are non-functional.
Specifically, the commit messages and justification have been extended as
requested by Linus and Al.
This little series does the following:
- unify the definition of constants in statfs.h and fs.h:
The definitions for MS_* flags are currently a mixture between hex values
and bit-shifts. All higher values are already initialized with bit-shifts
for MS_* constants starting with (1<<16). This patch switches the
definitions for MS_* constants over to uniformly use bit-shifts and
alignes the definitions of ST_* flags too.
Initializing them identically let's userspace easily detect when flags
indicate the same property but use a different value in doing so.
- extend statfs to handle mount propagation:
For all cases the only way to do this right now is by parsing
/proc/<pid>/mountinfo. Yes, it is doable but still it is somewhat costly
and annoying as e.g. those mount propagation fields are optional.
1. prevent propagation from happening:
From a userspace perspective we often run into the case where we
simply want to know whether a given mountpoint is MS_SHARED or is
MS_SLAVE. If it is we remount it as MS_PRIVATE to prevent any
propagation from happening. We don't care about the peer
relationship or how the propagation is exactly setup. We only want
to prevent any propagation from happening.
These mountpoints might be known in advance so parsing
/proc/<pid>/mountinfo should not be needed.
2. differentiate between MS_SLAVE and MS_SHARED mountpoints:
Mountpoints that are MS_SLAVE are kept intact and mountpoints that
are MS_SHARED are made MS_PRIVATE. These mountpoint might be known in
advance so parsing /proc/<pid>/mountinfo should not be needed.
3. retrieve propagation properties when procfs is not mounted:
When the set of interesting mountpoints is known and /proc is not
mounted calling statfs() is the only good way to reliably determine
the propagation property of a mountpoint.
4. inspecting file descriptors to mountpoints for propagation
properties:
When file descriptors to mountpoints are passed around between
processes it is useful to have fstatvfs() handle mount propagation
properties too.
To this end the flags:
- ST_UNBINDABLE
- ST_SHARED
- ST_PRIVATE
- ST_SLAVE
are added. They have the same value as their MS_* counterparts.
- Testing:
I verified that now userspace can do e.g.
int ret;
char *s = "/some/path";
struct statvfs sb;
ret = statvfs(s, &sb);
if (ret < 0)
return false;
if (sb.f_flag & ST_SHARED) {
ret = mount("", s, NULL, MS_SLAVE | MS_REC, NULL);
if (ret < 0)
return -1;
}
Thanks!
Christian
Christian Brauner (6):
fs: use << for MS_* flags
statfs: use << to align with fs header
statfs: add ST_UNBINDABLE
statfs: add ST_SHARED
statfs: add ST_SLAVE
statfs: add ST_PRIVATE
fs/statfs.c | 16 +++++++++++++++-
include/linux/statfs.h | 30 +++++++++++++++++-------------
include/uapi/linux/fs.h | 33 +++++++++++++++++----------------
3 files changed, 49 insertions(+), 30 deletions(-)
--
2.17.0
^ permalink raw reply
* [PATCH 1/6 v1 resend] fs: use << for MS_* flags
From: Christian Brauner @ 2018-05-25 12:48 UTC (permalink / raw)
To: linux-fsdevel, linux-kernel
Cc: torvalds, tglx, kstewart, gregkh, pombredanne, linux-api,
ebiederm, seth.forshee, viro, Christian Brauner
In-Reply-To: <20180525124825.23875-1-christian@brauner.io>
The definitions for MS_* flags are currently a mixture between hex values
and bit-shifts. All higher values are already initialized with bit-shifts
for MS_* constants starting with (1<<16).
This patch switches the definitions for MS_* constants over to uniformly
use bit-shifts.
Note that the BIT() macro cannot be used as it is not exported to uapi
files as was pointed out by gregkh.
Signed-off-by: Christian Brauner <christian@brauner.io>
---
v0->v1:
* non-functional changes: extend commit message
---
include/uapi/linux/fs.h | 33 +++++++++++++++++----------------
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index d2a8313fabd7..9662790a657c 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -105,22 +105,23 @@ struct inodes_stat_t {
/*
* These are the fs-independent mount-flags: up to 32 flags are supported
*/
-#define MS_RDONLY 1 /* Mount read-only */
-#define MS_NOSUID 2 /* Ignore suid and sgid bits */
-#define MS_NODEV 4 /* Disallow access to device special files */
-#define MS_NOEXEC 8 /* Disallow program execution */
-#define MS_SYNCHRONOUS 16 /* Writes are synced at once */
-#define MS_REMOUNT 32 /* Alter flags of a mounted FS */
-#define MS_MANDLOCK 64 /* Allow mandatory locks on an FS */
-#define MS_DIRSYNC 128 /* Directory modifications are synchronous */
-#define MS_NOATIME 1024 /* Do not update access times. */
-#define MS_NODIRATIME 2048 /* Do not update directory access times */
-#define MS_BIND 4096
-#define MS_MOVE 8192
-#define MS_REC 16384
-#define MS_VERBOSE 32768 /* War is peace. Verbosity is silence.
- MS_VERBOSE is deprecated. */
-#define MS_SILENT 32768
+#define MS_RDONLY (1<<0) /* Mount read-only */
+#define MS_NOSUID (1<<1) /* Ignore suid and sgid bits */
+#define MS_NODEV (1<<2) /* Disallow access to device special files */
+#define MS_NOEXEC (1<<3) /* Disallow program execution */
+#define MS_SYNCHRONOUS (1<<4) /* Writes are synced at once */
+#define MS_REMOUNT (1<<5) /* Alter flags of a mounted FS */
+#define MS_MANDLOCK (1<<6) /* Allow mandatory locks on an FS */
+#define MS_DIRSYNC (1<<7) /* Directory modifications are synchronous */
+#define MS_NOATIME (1<<10) /* Do not update access times. */
+#define MS_NODIRATIME (1<<11) /* Do not update directory access times */
+#define MS_BIND (1<<12)
+#define MS_MOVE (1<<13)
+#define MS_REC (1<<14)
+#define MS_VERBOSE (1<<15) /* War is peace. Verbosity is silence.
+ * MS_VERBOSE is deprecated.
+ */
+#define MS_SILENT (1<<15)
#define MS_POSIXACL (1<<16) /* VFS does not apply the umask */
#define MS_UNBINDABLE (1<<17) /* change to unbindable */
#define MS_PRIVATE (1<<18) /* change to private */
--
2.17.0
^ permalink raw reply related
* [PATCH 2/6 v1 resend] statfs: use << to align with fs header
From: Christian Brauner @ 2018-05-25 12:48 UTC (permalink / raw)
To: linux-fsdevel, linux-kernel
Cc: torvalds, tglx, kstewart, gregkh, pombredanne, linux-api,
ebiederm, seth.forshee, viro, Christian Brauner
In-Reply-To: <20180525124825.23875-1-christian@brauner.io>
After switching to using bit-shifts to define MS_* flags switch over ST_*
flags too. ST_* and MS_* flags generally have the exact same value.
Initializing them identically let's userspace easily detect when flags
indicate the same property but use a different value in doing so.
Signed-off-by: Christian Brauner <christian@brauner.io>
---
v0->v1:
* non-functional changes: extend commit message
---
include/linux/statfs.h | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/include/linux/statfs.h b/include/linux/statfs.h
index 3142e98546ac..b336c04e793c 100644
--- a/include/linux/statfs.h
+++ b/include/linux/statfs.h
@@ -27,18 +27,18 @@ struct kstatfs {
* ABI. The exception is ST_VALID which has the same value as MS_REMOUNT
* which doesn't make any sense for statfs.
*/
-#define ST_RDONLY 0x0001 /* mount read-only */
-#define ST_NOSUID 0x0002 /* ignore suid and sgid bits */
-#define ST_NODEV 0x0004 /* disallow access to device special files */
-#define ST_NOEXEC 0x0008 /* disallow program execution */
-#define ST_SYNCHRONOUS 0x0010 /* writes are synced at once */
-#define ST_VALID 0x0020 /* f_flags support is implemented */
-#define ST_MANDLOCK 0x0040 /* allow mandatory locks on an FS */
-/* 0x0080 used for ST_WRITE in glibc */
-/* 0x0100 used for ST_APPEND in glibc */
-/* 0x0200 used for ST_IMMUTABLE in glibc */
-#define ST_NOATIME 0x0400 /* do not update access times */
-#define ST_NODIRATIME 0x0800 /* do not update directory access times */
-#define ST_RELATIME 0x1000 /* update atime relative to mtime/ctime */
+#define ST_RDONLY (1<<0) /* mount read-only */
+#define ST_NOSUID (1<<1) /* ignore suid and sgid bits */
+#define ST_NODEV (1<<2) /* disallow access to device special files */
+#define ST_NOEXEC (1<<3) /* disallow program execution */
+#define ST_SYNCHRONOUS (1<<4) /* writes are synced at once */
+#define ST_VALID (1<<5) /* f_flags support is implemented */
+#define ST_MANDLOCK (1<<6) /* allow mandatory locks on an FS */
+/* (1<<7) used for ST_WRITE in glibc */
+/* (1<<8) used for ST_APPEND in glibc */
+/* (1<<9) used for ST_IMMUTABLE in glibc */
+#define ST_NOATIME (1<<10) /* do not update access times */
+#define ST_NODIRATIME (1<<11) /* do not update directory access times */
+#define ST_RELATIME (1<<12) /* update atime relative to mtime/ctime */
#endif
--
2.17.0
^ permalink raw reply related
* [PATCH 3/6 v1 resend] statfs: add ST_UNBINDABLE
From: Christian Brauner @ 2018-05-25 12:48 UTC (permalink / raw)
To: linux-fsdevel, linux-kernel
Cc: torvalds, tglx, kstewart, gregkh, pombredanne, linux-api,
ebiederm, seth.forshee, viro, Christian Brauner
In-Reply-To: <20180525124825.23875-1-christian@brauner.io>
Currently userspace can only determine whether a mountpoint is unbindable
by parsing /proc/<pid>/mountinfo. It would be convenient to simply retrieve
this property with a statvfs() call.
This let's userspace avoid costly parsing, supports cases where /proc is
not mounted, and supports usecases where file descriptors to mountpoints
are passed between processes that are inspected via fstatvfs().
Signed-off-by: Christian Brauner <christian@brauner.io>
---
v0->v1:
* non-functional changes: extend commit message
---
fs/statfs.c | 2 ++
include/linux/statfs.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/fs/statfs.c b/fs/statfs.c
index 5b2a24f0f263..61b3063d3921 100644
--- a/fs/statfs.c
+++ b/fs/statfs.c
@@ -29,6 +29,8 @@ static int flags_by_mnt(int mnt_flags)
flags |= ST_NODIRATIME;
if (mnt_flags & MNT_RELATIME)
flags |= ST_RELATIME;
+ if (mnt_flags & MNT_UNBINDABLE)
+ flags |= ST_UNBINDABLE;
return flags;
}
diff --git a/include/linux/statfs.h b/include/linux/statfs.h
index b336c04e793c..e1b84d0388c1 100644
--- a/include/linux/statfs.h
+++ b/include/linux/statfs.h
@@ -40,5 +40,6 @@ struct kstatfs {
#define ST_NOATIME (1<<10) /* do not update access times */
#define ST_NODIRATIME (1<<11) /* do not update directory access times */
#define ST_RELATIME (1<<12) /* update atime relative to mtime/ctime */
+#define ST_UNBINDABLE (1<<17) /* change to unbindable */
#endif
--
2.17.0
^ permalink raw reply related
* [PATCH 4/6 v1 resend] statfs: add ST_SHARED
From: Christian Brauner @ 2018-05-25 12:48 UTC (permalink / raw)
To: linux-fsdevel, linux-kernel
Cc: torvalds, tglx, kstewart, gregkh, pombredanne, linux-api,
ebiederm, seth.forshee, viro, Christian Brauner
In-Reply-To: <20180525124825.23875-1-christian@brauner.io>
Currently userspace can only determine whether a mountpoint is shared
by parsing /proc/<pid>/mountinfo. It would be convenient to simply retrieve
this property with a statvfs() call.
This let's userspace avoid costly parsing, supports cases where /proc is
not mounted, and supports usecases where file descriptors to mountpoints
are passed between processes that are inspected via fstatvfs().
This is especially helpful in all cases where userspace is not interested
in specific propagation properties but rather just wants to either turn on
or turn off propagation for specific mountpoints.
Signed-off-by: Christian Brauner <christian@brauner.io>
---
v0->v1:
* non-functional changes: extend commit message
---
fs/statfs.c | 2 ++
include/linux/statfs.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/fs/statfs.c b/fs/statfs.c
index 61b3063d3921..2fc6f9c3793c 100644
--- a/fs/statfs.c
+++ b/fs/statfs.c
@@ -31,6 +31,8 @@ static int flags_by_mnt(int mnt_flags)
flags |= ST_RELATIME;
if (mnt_flags & MNT_UNBINDABLE)
flags |= ST_UNBINDABLE;
+ if (mnt_flags & MNT_SHARED)
+ flags |= ST_SHARED;
return flags;
}
diff --git a/include/linux/statfs.h b/include/linux/statfs.h
index e1b84d0388c1..5416b2936dd9 100644
--- a/include/linux/statfs.h
+++ b/include/linux/statfs.h
@@ -41,5 +41,6 @@ struct kstatfs {
#define ST_NODIRATIME (1<<11) /* do not update directory access times */
#define ST_RELATIME (1<<12) /* update atime relative to mtime/ctime */
#define ST_UNBINDABLE (1<<17) /* change to unbindable */
+#define ST_SHARED (1<<20) /* change to shared */
#endif
--
2.17.0
^ permalink raw reply related
* [PATCH 5/6 v1 resend] statfs: add ST_SLAVE
From: Christian Brauner @ 2018-05-25 12:48 UTC (permalink / raw)
To: linux-fsdevel, linux-kernel
Cc: torvalds, tglx, kstewart, gregkh, pombredanne, linux-api,
ebiederm, seth.forshee, viro, Christian Brauner
In-Reply-To: <20180525124825.23875-1-christian@brauner.io>
Currently userspace can only determine whether a mountpoint is slave
by parsing /proc/<pid>/mountinfo. It would be convenient to simply retrieve
this property with a statvfs() call.
This let's userspace avoid costly parsing, supports cases where /proc is
not mounted, and supports usecases where file descriptors to mountpoints
are passed between processes that are inspected via fstatvfs().
This is especially helpful in all cases where userspace is not interested
in specific propagation properties our peer group layouts but rather just
wants to either turn on or turn off propagation for specific mountpoints.
Signed-off-by: Christian Brauner <christian@brauner.io>
---
v0->v1:
* non-functional changes: extend commit message
---
fs/statfs.c | 10 +++++++++-
include/linux/statfs.h | 1 +
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/fs/statfs.c b/fs/statfs.c
index 2fc6f9c3793c..35ad0402c9a3 100644
--- a/fs/statfs.c
+++ b/fs/statfs.c
@@ -10,6 +10,7 @@
#include <linux/uaccess.h>
#include <linux/compat.h>
#include "internal.h"
+#include "pnode.h"
static int flags_by_mnt(int mnt_flags)
{
@@ -50,8 +51,15 @@ static int flags_by_sb(int s_flags)
static int calculate_f_flags(struct vfsmount *mnt)
{
- return ST_VALID | flags_by_mnt(mnt->mnt_flags) |
+ int flags = 0;
+
+ flags = ST_VALID | flags_by_mnt(mnt->mnt_flags) |
flags_by_sb(mnt->mnt_sb->s_flags);
+
+ if (IS_MNT_SLAVE(real_mount(mnt)))
+ flags |= ST_SLAVE;
+
+ return flags;
}
static int statfs_by_dentry(struct dentry *dentry, struct kstatfs *buf)
diff --git a/include/linux/statfs.h b/include/linux/statfs.h
index 5416b2936dd9..048127effaad 100644
--- a/include/linux/statfs.h
+++ b/include/linux/statfs.h
@@ -41,6 +41,7 @@ struct kstatfs {
#define ST_NODIRATIME (1<<11) /* do not update directory access times */
#define ST_RELATIME (1<<12) /* update atime relative to mtime/ctime */
#define ST_UNBINDABLE (1<<17) /* change to unbindable */
+#define ST_SLAVE (1<<19) /* change to slave */
#define ST_SHARED (1<<20) /* change to shared */
#endif
--
2.17.0
^ permalink raw reply related
* [PATCH 6/6 v1 resend] statfs: add ST_PRIVATE
From: Christian Brauner @ 2018-05-25 12:48 UTC (permalink / raw)
To: linux-fsdevel, linux-kernel
Cc: torvalds, tglx, kstewart, gregkh, pombredanne, linux-api,
ebiederm, seth.forshee, viro, Christian Brauner
In-Reply-To: <20180525124825.23875-1-christian@brauner.io>
Currently userspace can only determine whether a mountpoint is private
by parsing /proc/<pid>/mountinfo. It would be convenient to simply retrieve
this property with a statvfs() call.
This let's userspace avoid costly parsing, supports cases where /proc is
not mounted, and supports usecases where file descriptors to mountpoints are
passed between processes that are inspected via fstatvfs().
A mountpoint is considered ST_PRIVATE iff and it is neither ST_SLAVE nor
ST_SHARED.
Signed-off-by: Christian Brauner <christian@brauner.io>
---
v0->v1:
* non-functional changes: extend commit message
---
fs/statfs.c | 2 ++
include/linux/statfs.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/fs/statfs.c b/fs/statfs.c
index 35ad0402c9a3..899e899ee84c 100644
--- a/fs/statfs.c
+++ b/fs/statfs.c
@@ -58,6 +58,8 @@ static int calculate_f_flags(struct vfsmount *mnt)
if (IS_MNT_SLAVE(real_mount(mnt)))
flags |= ST_SLAVE;
+ else if (!(flags & ST_SHARED))
+ flags |= ST_PRIVATE;
return flags;
}
diff --git a/include/linux/statfs.h b/include/linux/statfs.h
index 048127effaad..663fa5498a7d 100644
--- a/include/linux/statfs.h
+++ b/include/linux/statfs.h
@@ -41,6 +41,7 @@ struct kstatfs {
#define ST_NODIRATIME (1<<11) /* do not update directory access times */
#define ST_RELATIME (1<<12) /* update atime relative to mtime/ctime */
#define ST_UNBINDABLE (1<<17) /* change to unbindable */
+#define ST_PRIVATE (1<<18) /* change to private */
#define ST_SLAVE (1<<19) /* change to slave */
#define ST_SHARED (1<<20) /* change to shared */
--
2.17.0
^ permalink raw reply related
* Re: [RFC PATCH 1/5] mm, slab/slub: introduce kmalloc-reclaimable caches
From: Christopher Lameter @ 2018-05-25 15:51 UTC (permalink / raw)
To: Vlastimil Babka
Cc: linux-mm, Roman Gushchin, Michal Hocko, Johannes Weiner,
linux-kernel, linux-api, Pekka Enberg, David Rientjes,
Joonsoo Kim, Mel Gorman, Vijayanand Jitta
In-Reply-To: <20180524110011.1940-2-vbabka@suse.cz>
On Thu, 24 May 2018, Vlastimil Babka wrote:
> diff --git a/include/linux/slab.h b/include/linux/slab.h
> index 9ebe659bd4a5..5bff0571b360 100644
> --- a/include/linux/slab.h
> +++ b/include/linux/slab.h
> @@ -296,11 +296,16 @@ static inline void __check_heap_object(const void *ptr, unsigned long n,
> (KMALLOC_MIN_SIZE) : 16)
>
> #ifndef CONFIG_SLOB
> -extern struct kmem_cache *kmalloc_caches[KMALLOC_SHIFT_HIGH + 1];
> +extern struct kmem_cache *kmalloc_caches[2][KMALLOC_SHIFT_HIGH + 1];
> #ifdef CONFIG_ZONE_DMA
> extern struct kmem_cache *kmalloc_dma_caches[KMALLOC_SHIFT_HIGH + 1];
> #endif
In the existing code we used a different array name for the DMA caches.
This is a similar situation.
I would suggest to use
kmalloc_reclaimable_caches[]
or make it consistent by folding the DMA caches into the array too (but
then note the issues below).
> @@ -536,12 +541,13 @@ static __always_inline void *kmalloc(size_t size, gfp_t flags)
> #ifndef CONFIG_SLOB
> if (!(flags & GFP_DMA)) {
> unsigned int index = kmalloc_index(size);
> + unsigned int recl = kmalloc_reclaimable(flags);
This is a hotpath reserved for regular allocations. The reclaimable slabs
need to be handled like the DMA slabs. So check for GFP_DMA plus the
reclaimable flags.
> @@ -588,12 +594,13 @@ static __always_inline void *kmalloc_node(size_t size, gfp_t flags, int node)
> if (__builtin_constant_p(size) &&
> size <= KMALLOC_MAX_CACHE_SIZE && !(flags & GFP_DMA)) {
> unsigned int i = kmalloc_index(size);
> + unsigned int recl = kmalloc_reclaimable(flags);
>
Same situation here and additional times below.
^ permalink raw reply
* Re: [RFC PATCH 4/5] mm: rename and change semantics of nr_indirectly_reclaimable_bytes
From: Christopher Lameter @ 2018-05-25 15:59 UTC (permalink / raw)
To: Vlastimil Babka
Cc: linux-mm, Roman Gushchin, Michal Hocko, Johannes Weiner,
linux-kernel, linux-api, Pekka Enberg, David Rientjes,
Joonsoo Kim, Mel Gorman, Vijayanand Jitta
In-Reply-To: <20180524110011.1940-5-vbabka@suse.cz>
On Thu, 24 May 2018, Vlastimil Babka wrote:
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 32699b2dc52a..4343948f33e5 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -180,7 +180,7 @@ enum node_stat_item {
> NR_VMSCAN_IMMEDIATE, /* Prioritise for reclaim when writeback ends */
> NR_DIRTIED, /* page dirtyings since bootup */
> NR_WRITTEN, /* page writings since bootup */
> - NR_INDIRECTLY_RECLAIMABLE_BYTES, /* measured in bytes */
> + NR_RECLAIMABLE, /* all reclaimable pages, including slab */
> NR_VM_NODE_STAT_ITEMS
We already have NR_SLAB_RECLAIMABLE and NR_RECLAIMABLE now counts what
NR_SLAB_RECLAIMABLE counts plus something else. THis means updating
two counters in parallel.
Could keep the existing counter and just account
for those non slab things you mentioned? Avoid counting twice and may
provide unique insides into those non slab reclaimable objects. I'd like
to see this.
^ permalink raw reply
* Re: aio poll and a new in-kernel poll API V13
From: Al Viro @ 2018-05-26 0:11 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-api,
linux-kernel
In-Reply-To: <20180523192022.1703-1-hch@lst.de>
On Wed, May 23, 2018 at 09:19:49PM +0200, Christoph Hellwig wrote:
> Hi all,
>
> this series adds support for the IOCB_CMD_POLL operation to poll for the
> readyness of file descriptors using the aio subsystem. The API is based
> on patches that existed in RHAS2.1 and RHEL3, which means it already is
> supported by libaio. To implement the poll support efficiently new
> methods to poll are introduced in struct file_operations: get_poll_head
> and poll_mask. The first one returns a wait_queue_head to wait on
> (lifetime is bound by the file), and the second does a non-blocking
> check for the POLL* events. This allows aio poll to work without
> any additional context switches, unlike epoll.
>
> This series sits on top of the aio-fsync series that also includes
> support for io_pgetevents.
OK, I can live with that, except for one problem - the first patch shouldn't
be sitting on top of arseloads of next window fodder.
Please, rebase the rest of the series on top of merge of vfs.git#fixes
(4faa99965e02) with your aio-fsync.4 and tell me what to pull.
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: aio poll and a new in-kernel poll API V13
From: Al Viro @ 2018-05-26 7:09 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-api,
linux-kernel
In-Reply-To: <20180526001111.GL30522@ZenIV.linux.org.uk>
On Sat, May 26, 2018 at 01:11:11AM +0100, Al Viro wrote:
> On Wed, May 23, 2018 at 09:19:49PM +0200, Christoph Hellwig wrote:
> > Hi all,
> >
> > this series adds support for the IOCB_CMD_POLL operation to poll for the
> > readyness of file descriptors using the aio subsystem. The API is based
> > on patches that existed in RHAS2.1 and RHEL3, which means it already is
> > supported by libaio. To implement the poll support efficiently new
> > methods to poll are introduced in struct file_operations: get_poll_head
> > and poll_mask. The first one returns a wait_queue_head to wait on
> > (lifetime is bound by the file), and the second does a non-blocking
> > check for the POLL* events. This allows aio poll to work without
> > any additional context switches, unlike epoll.
> >
> > This series sits on top of the aio-fsync series that also includes
> > support for io_pgetevents.
>
> OK, I can live with that, except for one problem - the first patch shouldn't
> be sitting on top of arseloads of next window fodder.
>
> Please, rebase the rest of the series on top of merge of vfs.git#fixes
> (4faa99965e02) with your aio-fsync.4 and tell me what to pull.
UGH
You've based it on vfs.git#hch.aio (== your aio-fsync.4) + baf10564fbb6
(== vfs.git#fixes^), *and* started with cherry-pick of vfs.git#fixes
on top of that, followed by your series.
That makes no sense whatsoever. Please, take your aio-fsync.4, merge
vfs.git#fixes (== 4faa99965e02, "fix io_destroy()/aio_complete() race",
same change as your 4e79230e5254) into it and rebase the rest of your
branch on top of that (from "uapi: turn __poll_t sparse checkin
on by default" to "random: convert to ->poll_mask"). BTW, you probably
want s/checkin/checks/ in the first one of those...
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: aio poll and a new in-kernel poll API V13
From: Christoph Hellwig @ 2018-05-26 7:23 UTC (permalink / raw)
To: Al Viro
Cc: Christoph Hellwig, Avi Kivity, linux-aio, linux-fsdevel, netdev,
linux-api, linux-kernel
In-Reply-To: <20180526070937.GA4188@ZenIV.linux.org.uk>
I'm still waking up..
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: aio poll and a new in-kernel poll API V13
From: Al Viro @ 2018-05-27 22:27 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-api,
linux-kernel
In-Reply-To: <20180526072306.GA17313@lst.de>
OK, it's in -next now; there are several cleanups I'd put
into vfs.git#work.aio:
aio: all callers of aio_{read,write,fsync,poll} treat 0 and -EIOCBQUEUED the same way
aio_read_events_ring(): make a bit more readable
aio: shift copyin of iocb into io_submit_one()
aio: fold do_io_submit() into callers
Those are *not* on -next yet and if anybody has objections against
any of those, please yell. Individual patches in followups...
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: [PATCH 07/14] powerpc: Add support for restartable sequences
From: Mathieu Desnoyers @ 2018-05-28 7:00 UTC (permalink / raw)
To: Michael Ellerman, Boqun Feng
Cc: Will Deacon, Peter Zijlstra, Paul E. McKenney, Andy Lutomirski,
Dave Watson, linux-kernel, linux-api, Paul Turner, Andrew Morton,
Russell King, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Andrew Hunter, Andi Kleen, Chris Lameter, Ben Maurer, rostedt,
Josh Triplett, Linus Torvalds, Catalin Marinas <cata>
In-Reply-To: <87o9h5sw4e.fsf@concordia.ellerman.id.au>
----- On May 24, 2018, at 3:03 AM, Michael Ellerman mpe@ellerman.id.au wrote:
> Mathieu Desnoyers <mathieu.desnoyers@efficios.com> writes:
>> ----- On May 23, 2018, at 4:14 PM, Mathieu Desnoyers
>> mathieu.desnoyers@efficios.com wrote:
> ...
>>>
>>> Hi Boqun,
>>>
>>> I tried your patch in a ppc64 le environment, and it does not survive boot
>>> with CONFIG_DEBUG_RSEQ=y. init gets killed right away.
>
>
> Sorry this code is super gross and hard to deal with.
>
>> The following fixup gets ppc64 to work:
>>
>> --- a/arch/powerpc/kernel/entry_64.S
>> +++ b/arch/powerpc/kernel/entry_64.S
>> @@ -208,6 +208,7 @@ system_call_exit:
>> /* Check whether the syscall is issued inside a restartable sequence */
>> addi r3,r1,STACK_FRAME_OVERHEAD
>> bl rseq_syscall
>> + ld r3,RESULT(r1)
>> #endif
>> /*
>> * Disable interrupts so current_thread_info()->flags can't change,
>
> I don't think that's safe.
>
> If you look above that, we have r3, r8 and r12 all live:
>
> .Lsyscall_exit:
> std r3,RESULT(r1)
> CURRENT_THREAD_INFO(r12, r1)
>
> ld r8,_MSR(r1)
> #ifdef CONFIG_PPC_BOOK3S
> /* No MSR:RI on BookE */
> andi. r10,r8,MSR_RI
> beq- .Lunrecov_restore
> #endif
>
>
> They're all volatile across function calls:
>
> http://openpowerfoundation.org/wp-content/uploads/resources/leabi/content/dbdoclet.50655240_68174.html
>
>
> The system_call_exit symbol is actually there for kprobes and cosmetic
> purposes. The actual syscall return flow starts at .Lsyscall_exit.
>
> So I think this would work:
>
> diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
> index db4df061c33a..e19f377a25e0 100644
> --- a/arch/powerpc/kernel/entry_64.S
> +++ b/arch/powerpc/kernel/entry_64.S
> @@ -184,6 +184,14 @@ system_call: /* label this so stack traces look sane */
>
> .Lsyscall_exit:
> std r3,RESULT(r1)
> +
> +#ifdef CONFIG_DEBUG_RSEQ
> + /* Check whether the syscall is issued inside a restartable sequence */
> + addi r3,r1,STACK_FRAME_OVERHEAD
> + bl rseq_syscall
> + ld r3,RESULT(r1)
> +#endif
> +
> CURRENT_THREAD_INFO(r12, r1)
>
> ld r8,_MSR(r1)
>
>
> I'll try and get this series into my test setup at some point, been a
> bit busy lately :)
Yes, this was needed. I had this in my tree already, but there is still
a kernel OOPS when running the rseq selftests on ppc64 with CONFIG_DEBUG_RSEQ=y.
My current dev tree is at: https://github.com/compudj/linux-percpu-dev/tree/rseq/dev-local
So considering we are at rc7 now, should I plan to removing the powerpc bits
for merge window submission, or is there someone planning to spend time on
fixing and testing ppc integration before the merge window opens ?
Thanks,
Mathieu
>
> cheers
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* Re: [RFC PATCH 1/5] mm, slab/slub: introduce kmalloc-reclaimable caches
From: Vlastimil Babka @ 2018-05-28 8:03 UTC (permalink / raw)
To: Christopher Lameter
Cc: linux-mm, Roman Gushchin, Michal Hocko, Johannes Weiner,
linux-kernel, linux-api, Pekka Enberg, David Rientjes,
Joonsoo Kim, Mel Gorman, Vijayanand Jitta
In-Reply-To: <0100016397ffdbf2-dc8a305f-efa8-4771-9f2a-3a7568693db4-000000@email.amazonses.com>
On 05/25/2018 05:51 PM, Christopher Lameter wrote:
> On Thu, 24 May 2018, Vlastimil Babka wrote:
>
>> diff --git a/include/linux/slab.h b/include/linux/slab.h
>> index 9ebe659bd4a5..5bff0571b360 100644
>> --- a/include/linux/slab.h
>> +++ b/include/linux/slab.h
>> @@ -296,11 +296,16 @@ static inline void __check_heap_object(const void *ptr, unsigned long n,
>> (KMALLOC_MIN_SIZE) : 16)
>>
>> #ifndef CONFIG_SLOB
>> -extern struct kmem_cache *kmalloc_caches[KMALLOC_SHIFT_HIGH + 1];
>> +extern struct kmem_cache *kmalloc_caches[2][KMALLOC_SHIFT_HIGH + 1];
>> #ifdef CONFIG_ZONE_DMA
>> extern struct kmem_cache *kmalloc_dma_caches[KMALLOC_SHIFT_HIGH + 1];
>> #endif
>
> In the existing code we used a different array name for the DMA caches.
> This is a similar situation.
>
> I would suggest to use
>
> kmalloc_reclaimable_caches[]
>
> or make it consistent by folding the DMA caches into the array too (but
> then note the issues below).
>
>> @@ -536,12 +541,13 @@ static __always_inline void *kmalloc(size_t size, gfp_t flags)
>> #ifndef CONFIG_SLOB
>> if (!(flags & GFP_DMA)) {
>> unsigned int index = kmalloc_index(size);
>> + unsigned int recl = kmalloc_reclaimable(flags);
>
> This is a hotpath reserved for regular allocations. The reclaimable slabs
> need to be handled like the DMA slabs. So check for GFP_DMA plus the
> reclaimable flags.
Yeah I thought that by doing reclaimable via array index manipulation
and not a branch, there would be no noticeable overhead. And GFP_DMA
should go away eventually. I will see if I can convert GFP_DMA to
another index, and completely remove the branch quoted above.
>> @@ -588,12 +594,13 @@ static __always_inline void *kmalloc_node(size_t size, gfp_t flags, int node)
>> if (__builtin_constant_p(size) &&
>> size <= KMALLOC_MAX_CACHE_SIZE && !(flags & GFP_DMA)) {
>> unsigned int i = kmalloc_index(size);
>> + unsigned int recl = kmalloc_reclaimable(flags);
>>
>
>
> Same situation here and additional times below.
>
^ permalink raw reply
* Re: [RFC PATCH 0/5] kmalloc-reclaimable caches
From: Vlastimil Babka @ 2018-05-28 8:15 UTC (permalink / raw)
To: Johannes Weiner
Cc: linux-mm, Roman Gushchin, Michal Hocko, linux-kernel, linux-api,
Christoph Lameter, Pekka Enberg, David Rientjes, Joonsoo Kim,
Mel Gorman, Vijayanand Jitta
In-Reply-To: <20180524153225.GA7329@cmpxchg.org>
On 05/24/2018 05:32 PM, Johannes Weiner wrote:
> On Thu, May 24, 2018 at 01:00:06PM +0200, Vlastimil Babka wrote:
>> - the vmstat/meminfo counter name is rather general and might suggest it also
>> includes reclaimable page caches, which it doesn't
>>
>> Suggestions welcome for all three points. For the last one, we might also keep
>> the counter separate from nr_slab_reclaimable, not superset. I did a superset
>> as IIRC somebody suggested that in the older threads or at LSF.
>
> Yeah, the "reclaimable" name is too generic. How about KReclaimable?
>
> The counter being a superset sounds good to me. We use this info for
> both load balancing and manual debugging. For load balancing code it's
> nice not having to worry about finding all the counters that hold
> reclaimable memory depending on kernel version; it's always simply
> user cache + user anon + kernel reclaimable. And for debugging, we can
> always add more specific subset counters later on if we need them.
Hm, Christoph in his reply to patch 4/5 expressed a different opinion.
It's true that updating two counters has extra overhead, especially if
there are two separate critical sections:
mod_lruvec_page_state(page, NR_SLAB_RECLAIMABLE, nr_pages);
mod_node_page_state(page_pgdat(page), NR_RECLAIMABLE, nr_pages);
The first disables irq for CONFIG_MEMCG or defers to
mod_node_page_state() otherwise.
mod_node_page_state() is different depending on CONFIG_SMP and
CONFIG_HAVE_CMPXCHG_LOCAL.
I don't see an easy way to make this optimal? Different counter would be
indeed simpler. /proc/vmstat would then print separate counters, but we
could have both separate and summary counter in /proc/meminfo. Would
that be enough?
^ permalink raw reply
* Re: [PATCH 1/6] lib/rhashtable: convert param sanitations to WARN_ON
From: Herbert Xu @ 2018-05-28 9:40 UTC (permalink / raw)
To: Davidlohr Bueso
Cc: akpm, torvalds, tgraf, manfred, guillaume.knispel, linux-api,
linux-kernel, Davidlohr Bueso
In-Reply-To: <20180524211135.27760-2-dave@stgolabs.net>
On Thu, May 24, 2018 at 02:11:30PM -0700, Davidlohr Bueso wrote:
> For the purpose of making rhashtable_init() unable to fail,
> we can replace the returning -EINVAL with WARN_ONs whenever
> the caller passes bogus parameters during initialization.
>
> Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
I don't really see why we need these WARN_ONs. The problem should
be quite obvious when you're writing your code.
If you really want them perhaps add them to the ipc code instead?
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/6] lib/rhashtable: guarantee initial hashtable allocation
From: Herbert Xu @ 2018-05-28 9:49 UTC (permalink / raw)
To: Davidlohr Bueso
Cc: akpm, torvalds, tgraf, manfred, guillaume.knispel, linux-api,
linux-kernel, Davidlohr Bueso
In-Reply-To: <20180524211135.27760-3-dave@stgolabs.net>
On Thu, May 24, 2018 at 02:11:31PM -0700, Davidlohr Bueso wrote:
>
> -static struct bucket_table *bucket_table_alloc(struct rhashtable *ht,
> - size_t nbuckets,
> - gfp_t gfp)
> +static struct bucket_table *__bucket_table_alloc(struct rhashtable *ht,
> + size_t nbuckets,
> + gfp_t gfp, bool retry)
> {
> struct bucket_table *tbl = NULL;
> size_t size, max_locks;
> int i;
>
> size = sizeof(*tbl) + nbuckets * sizeof(tbl->buckets[0]);
> + if (retry) {
> + gfp |= __GFP_NOFAIL;
> + tbl = kzalloc(size, gfp);
> + } /* fall-through */
I'd prefer this logic to be moved to the caller. So just call the
function with GFP_KERNEL | __GFP_NOFAIL.
Of course you need to modify bucket_table_alloc so that it still
treats this as GFP_KERNEL (as opposed to GFP_ATOMIC). That is,
instead of
> if (gfp != GFP_KERNEL)
You will need
if ((gfp & ~__GFP_NOFAIL) != GFP_KERNEL)
> @@ -1067,9 +1086,20 @@ int rhashtable_init(struct rhashtable *ht,
> }
> }
>
> + /*
> + * This is api initialization and thus we need to guarantee the
> + * initial rhashtable allocation. Upon failure, retry with a
> + * smallest possible size, otherwise we exhaust our options with
> + * __GFP_NOFAIL.
> + */
> tbl = bucket_table_alloc(ht, size, GFP_KERNEL);
> - if (tbl == NULL)
> - return -ENOMEM;
> + if (unlikely(tbl == NULL)) {
> + size = HASH_MIN_SIZE;
> +
> + tbl = bucket_table_alloc(ht, size, GFP_KERNEL);
> + if (tbl == NULL)
> + tbl = bucket_table_alloc_retry(ht, size, GFP_KERNEL);
> + }
Perhaps you should also explain here why we don't just try the
minimum size with __GFP_NOFAIL as the second step rather than the
third.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/6] lib/rhashtable: guarantee initial hashtable allocation
From: Herbert Xu @ 2018-05-28 10:02 UTC (permalink / raw)
To: Davidlohr Bueso
Cc: akpm, torvalds, tgraf, manfred, guillaume.knispel, linux-api,
linux-kernel, Davidlohr Bueso
In-Reply-To: <20180524211135.27760-3-dave@stgolabs.net>
On Thu, May 24, 2018 at 02:11:31PM -0700, Davidlohr Bueso wrote:
>
> + /*
> + * This is api initialization and thus we need to guarantee the
> + * initial rhashtable allocation. Upon failure, retry with a
> + * smallest possible size, otherwise we exhaust our options with
> + * __GFP_NOFAIL.
> + */
> tbl = bucket_table_alloc(ht, size, GFP_KERNEL);
> - if (tbl == NULL)
> - return -ENOMEM;
> + if (unlikely(tbl == NULL)) {
> + size = HASH_MIN_SIZE;
You should also take min_size into account. Yes I know the current
code ignores it unless you also set nelem_hint. But that's just a
bug.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [patch v22 0/4] JTAG driver introduction
From: Oleksandr Shamray @ 2018-05-28 10:34 UTC (permalink / raw)
To: gregkh, arnd
Cc: system-sw-low-level, devicetree, jiri, vadimp, linux-api, openbmc,
linux-kernel, openocd-devel-owner, robh+dt, joel, linux-serial,
Oleksandr Shamray, tklauser, mchehab, davem, linux-arm-kernel
When a need raise up to use JTAG interface for system's devices
programming or CPU debugging, usually the user layer
application implements jtag protocol by bit-bang or using a
proprietary connection to vendor hardware.
This method can be slow and not generic.
We propose to implement general JTAG interface and infrastructure
to communicate with user layer application. In such way, we can
have the standard JTAG interface core part and separation from
specific HW implementation.
This allow new capability to debug the CPU or program system's
device via BMC without additional devices nor cost.
This patch purpose is to add JTAG master core infrastructure by
defining new JTAG class and provide generic JTAG interface
to allow hardware specific drivers to connect this interface.
This will enable all JTAG drivers to use the common interface
part and will have separate for hardware implementation.
The JTAG (Joint Test Action Group) core driver provides minimal generic
JTAG interface, which can be used by hardware specific JTAG master
controllers. By providing common interface for the JTAG controllers,
user space device programing is hardware independent.
Modern SoC which in use for embedded system' equipped with
internal JTAG master interface.
This interface is used for programming and debugging system's
hardware components, like CPLD, FPGA, CPU, voltage and
industrial controllers.
Firmware for such devices can be upgraded through JTAG interface during
Runtime. The JTAG standard support for multiple devices programming,
is in case their lines are daisy-chained together.
For example, systems which equipped with host CPU, BMC SoC or/and
number of programmable devices are capable to connect a pin and
select system components dynamically for programming and debugging,
This is using by the BMC which is equipped with internal SoC master
controller.
For example:
BMC JTAG master --> pin selected to CPLDs chain for programming (filed
upgrade, production)
BMC JTAG master --> pin selected to voltage monitors for programming
(field upgrade, production)
BMC JTAG master --> pin selected to host CPU (on-site debugging
and developers debugging)
For example, we can have application in user space which using calls
to JTAG driver executes CPLD programming directly from SVF file
The JTAG standard (IEEE 1149.1) defines the next connector pins:
- TDI (Test Data In);
- TDO (Test Data Out);
- TCK (Test Clock);
- TMS (Test Mode Select);
- TRST (Test Reset) (Optional);
The SoC equipped with JTAG master controller, performs
device programming on command or vector level. For example
a file in a standard SVF (Serial Vector Format) that contains
boundary scan vectors, can be used by sending each vector
to the JTAG interface and the JTAG controller will execute
the programming.
Initial version provides the system calls set for:
- SIR (Scan Instruction Register, IEEE 1149.1 Instruction Register scan);
- SDR (Scan Data Register, IEEE 1149.1 Data Register scan);
- RUNTEST (Forces the IEEE 1149.1 bus to a run state for a specified
number of clocks.
SoC which are not equipped with JTAG master interface, can be built
on top of JTAG core driver infrastructure, by applying bit-banging of
TDI, TDO, TCK and TMS pins within the hardware specific driver.
Oleksandr Shamray (4):
drivers: jtag: Add JTAG core driver
drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master
driver
Documentation: jtag: Add bindings for Aspeed SoC 24xx and 25xx
families JTAG master driver
Documentation: jtag: Add ABI documentation
Documentation/ABI/testing/jtag-dev | 27 +
.../devicetree/bindings/jtag/aspeed-jtag.txt | 22 +
Documentation/ioctl/ioctl-number.txt | 2 +
Documentation/jtag/overview | 28 +
Documentation/jtag/transactions | 109 +++
MAINTAINERS | 10 +
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/jtag/Kconfig | 31 +
drivers/jtag/Makefile | 2 +
drivers/jtag/jtag-aspeed.c | 769 ++++++++++++++++++++
drivers/jtag/jtag.c | 322 ++++++++
include/linux/jtag.h | 43 ++
include/uapi/linux/jtag.h | 102 +++
14 files changed, 1470 insertions(+), 0 deletions(-)
create mode 100644 Documentation/ABI/testing/jtag-dev
create mode 100644 Documentation/devicetree/bindings/jtag/aspeed-jtag.txt
create mode 100644 Documentation/jtag/overview
create mode 100644 Documentation/jtag/transactions
create mode 100644 drivers/jtag/Kconfig
create mode 100644 drivers/jtag/Makefile
create mode 100644 drivers/jtag/jtag-aspeed.c
create mode 100644 drivers/jtag/jtag.c
create mode 100644 include/linux/jtag.h
create mode 100644 include/uapi/linux/jtag.h
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).