[PATCH v2] squashfs: Add posix acl support

[Geliang Tang]

Add posix acl (Access Control Lists) support for squashfs, which is
marked as a todo item in squashfs' documentation.  This patch implements
the squashfs_get_acl function to read file's acl information from its
xattr lists.

Signed-off-by: Geliang Tang 
---
Changes in v2:
 - fix build error, set squashfs_get_acl to NULL when CONFIG_SQUASHFS_POSIX_ACL 
is not selected.
---
 Documentation/filesystems/squashfs.txt |  2 -
 fs/squashfs/Kconfig| 11 ++
 fs/squashfs/Makefile   |  1 +
 fs/squashfs/acl.c  | 69 ++
 fs/squashfs/acl.h  | 31 +++
 fs/squashfs/inode.c|  4 +-
 fs/squashfs/namei.c|  6 ++-
 fs/squashfs/squashfs_fs.h  | 12 +++---
 fs/squashfs/super.c|  3 ++
 fs/squashfs/symlink.c  |  6 ++-
 fs/squashfs/xattr.c| 13 ++-
 fs/squashfs/xattr.h|  8 
 12 files changed, 153 insertions(+), 13 deletions(-)
 create mode 100644 fs/squashfs/acl.c
 create mode 100644 fs/squashfs/acl.h

diff --git a/Documentation/filesystems/squashfs.txt 
b/Documentation/filesystems/squashfs.txt
index e5274f84dc56..539fad6b4db0 100644
--- a/Documentation/filesystems/squashfs.txt
+++ b/Documentation/filesystems/squashfs.txt
@@ -235,8 +235,6 @@ list using a second xattr id lookup table.
 4.1 Todo list
 -
 
-Implement ACL support.
-
 4.2 Squashfs internal cache
 ---
 
diff --git a/fs/squashfs/Kconfig b/fs/squashfs/Kconfig
index 1adb3346b9d6..f9587bcf9dd9 100644
--- a/fs/squashfs/Kconfig
+++ b/fs/squashfs/Kconfig
@@ -107,6 +107,17 @@ config SQUASHFS_XATTR
 
  If unsure, say N.
 
+config SQUASHFS_POSIX_ACL
+   bool "Squashfs POSIX ACL support"
+   depends on SQUASHFS_XATTR
+   select FS_POSIX_ACL
+   help
+ Saying Y here includes support for Access Control Lists (acls).
+ Acls are used to define more fine-grained discretionary access
+ rights for files and directories (see the acl(5) manual page).
+
+ If unsure, say N.
+
 config SQUASHFS_ZLIB
bool "Include support for ZLIB compressed file systems"
depends on SQUASHFS
diff --git a/fs/squashfs/Makefile b/fs/squashfs/Makefile
index 7bd9b8b856d0..73bc1c8a8df6 100644
--- a/fs/squashfs/Makefile
+++ b/fs/squashfs/Makefile
@@ -12,6 +12,7 @@ squashfs-$(CONFIG_SQUASHFS_DECOMP_SINGLE) += 
decompressor_single.o
 squashfs-$(CONFIG_SQUASHFS_DECOMP_MULTI) += decompressor_multi.o
 squashfs-$(CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU) += decompressor_multi_percpu.o
 squashfs-$(CONFIG_SQUASHFS_XATTR) += xattr.o xattr_id.o
+squashfs-$(CONFIG_SQUASHFS_POSIX_ACL) += acl.o
 squashfs-$(CONFIG_SQUASHFS_LZ4) += lz4_wrapper.o
 squashfs-$(CONFIG_SQUASHFS_LZO) += lzo_wrapper.o
 squashfs-$(CONFIG_SQUASHFS_XZ) += xz_wrapper.o
diff --git a/fs/squashfs/acl.c b/fs/squashfs/acl.c
new file mode 100644
index ..1c9eb2d13c2b
--- /dev/null
+++ b/fs/squashfs/acl.c
@@ -0,0 +1,69 @@
+/*
+ * Squashfs - a compressed read only filesystem for Linux
+ *
+ * Copyright (c) 2018
+ * Phillip Lougher 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2,
+ * or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * acl.c
+ */
+
+#include 
+#include 
+#include 
+#include "squashfs_fs.h"
+#include "xattr.h"
+#include "acl.h"
+
+struct posix_acl *squashfs_get_acl(struct inode *inode, int type)
+{
+   int name_index;
+   char *name;
+   struct posix_acl *acl = NULL;
+   char *value = NULL;
+   int retval;
+
+   switch (type) {
+   case ACL_TYPE_ACCESS:
+   name_index = SQUASHFS_XATTR_POSIX_ACL_ACCESS;
+   name = XATTR_POSIX_ACL_ACCESS;
+   break;
+   case ACL_TYPE_DEFAULT:
+   name_index = SQUASHFS_XATTR_POSIX_ACL_DEFAULT;
+   name = XATTR_POSIX_ACL_DEFAULT;
+   break;
+   default:
+   BUG();
+   }
+
+   retval = squashfs_xattr_get(inode, name_index, name, NULL, 0);
+   if (retval > 0) {
+   value = kmalloc(retval, GFP_KERNEL);
+   if (!value)
+   return ERR_PTR(-ENOMEM);
+   retval = squashfs_xattr_get(inode, name_index, name, value, 
retval);
+   }
+  

Re: [RFC bpf-next] bpf: document eBPF helpers and add a script to generate man page

[Alexei Starovoitov]

On Mon, Apr 09, 2018 at 02:25:26PM +0100, Quentin Monnet wrote:
> 
> Anyway, I am fine with keeping just signatures, descriptions and return
> values for now. I will submit a new version with only those items.

Thank you.

Could you also split it into few patches?
 include/uapi/linux/bpf.h   | 2237 
 scripts/bpf_helpers_doc.py |  568 +++
 2 files changed, 2429 insertions(+), 376 deletions(-)

replying back and forth on a single patch of such size will be tedious
for others to follow.
May be document ~10 helpers at a time ? Total of ~7 patches and extra
patch for .py ?

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] perf: riscv: preliminary RISC-V support

[Palmer Dabbelt]

On Mon, 09 Apr 2018 00:07:11 PDT (-0700), alan...@andestech.com wrote:

On Thu, Apr 05, 2018 at 09:47:50AM -0700, Palmer Dabbelt wrote:

On Mon, 26 Mar 2018 00:57:54 PDT (-0700), alan...@andestech.com wrote:
>This patch provide a basic PMU, riscv_base_pmu, which supports two
>general hardware event, instructions and cycles.  Furthermore, this
>PMU serves as a reference implementation to ease the portings in
>the future.
>
>riscv_base_pmu should be able to run on any RISC-V machine that
>conforms to the Priv-Spec.  Note that the latest qemu model hasn't
>fully support a proper behavior of Priv-Spec 1.10 yet, but work
>around should be easy with very small fixes.  Please check
>https://github.com/riscv/riscv-qemu/pull/115 for future updates.
>
>Cc: Nick Hu 
>Cc: Greentime Hu 
>Signed-off-by: Alan Kao 

We should really be able to detect PMU types at runtime (via a device tree
entry) rather than requiring that a single PMU is built in to the kernel.
This will require a handful of modifications to how this patch works, which
I'll try to list below.



>+menu "PMU type"
>+   depends on PERF_EVENTS
>+
>+config RISCV_BASE_PMU
>+   bool "Base Performance Monitoring Unit"
>+   def_bool y
>+   help
>+ A base PMU that serves as a reference implementation and has limited
>+ feature of perf.
>+
>+endmenu
>+

Rather than a menu where a single PMU can be selected, there should be
options to enable or disable support for each PMU type -- this is just like
how all our other drivers work.



I see.  Sure.  The descriptions and implementation will be refined in v3.


>+struct pmu * __weak __init riscv_init_platform_pmu(void)
>+{
>+   riscv_pmu = _base_pmu;
>+   return riscv_pmu->pmu;
>+}

Rather than relying on a weak symbol that gets overridden by other PMU
types, this should look through the device tree for a compatible PMU (in the
case of just the base PMU it could be any RISC-V hart) and install a PMU
handler for it.  There'd probably be some sort of priority scheme here, like
there are for other driver subsystems, where we'd pick the best PMU driver
that's compatible with the PMUs on every hart.

>+
>+int __init init_hw_perf_events(void)
>+{
>+   struct pmu *pmu = riscv_init_platform_pmu();
>+
>+   perf_irq = NULL;
>+   perf_pmu_register(pmu, "cpu", PERF_TYPE_RAW);
>+   return 0;
>+}
>+arch_initcall(init_hw_perf_events);

Since we only have a single PMU type right now this isn't critical to handle
right away, but we will have to refactor this before adding another PMU.


I see.  My rough plan is to do the device tree parsing here, and if no specific
PMU string is found then just register the base PMU proposed in this patch.
How about this idea?


Sounds good.  We know the generic PMU will work on all RISC-V harts, so there's 
no need to add an explicit device tree entry for it.  Then we can figure out 
how to add device tree entries for custom performance monitors later :)

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] squashfs: Add posix acl support

[kbuild test robot]

Hi Geliang,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on v4.16]
[also build test ERROR on next-20180409]
[cannot apply to squashfs/master]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Geliang-Tang/squashfs-Add-posix-acl-support/20180410-013038
config: i386-randconfig-s0-201814 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> ERROR: "squashfs_get_acl" [fs/squashfs/squashfs.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v4 10/10] dt-bindings: gpio: Add bindings for Cadence I3C gpio expander

[Rob Herring]

On Fri, Mar 30, 2018 at 09:47:51AM +0200, Boris Brezillon wrote:
> Document the Cadence I3C gpio expander bindings.
> 
> Signed-off-by: Boris Brezillon 
> ---
> Changes in v4:
> - Use GPIO_ and IRQ_TYPE_ macros instead of raw numbers
> - Fix the unit-address in the example
> ---
>  .../devicetree/bindings/gpio/gpio-cdns-i3c.txt | 39 
> ++
>  1 file changed, 39 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-cdns-i3c.txt

Reviewed-by: Rob Herring 

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 08/10] dt-bindings: i3c: Document Cadence I3C master bindings

[Rob Herring]

On Fri, Mar 30, 2018 at 09:47:49AM +0200, Boris Brezillon wrote:
> Document Cadence I3C master DT bindings.
> 
> Signed-off-by: Boris Brezillon 
> ---
> Changes in v4:
> - Fix example to match the new representation
> ---
>  .../devicetree/bindings/i3c/cdns,i3c-master.txt| 44 
> ++
>  1 file changed, 44 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt

Reviewed-by: Rob Herring 

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 04/10] dt-bindings: i3c: Document core bindings

[Rob Herring]

On Fri, Mar 30, 2018 at 09:47:45AM +0200, Boris Brezillon wrote:
> A new I3C subsystem has been added and a generic description has been
> created to represent the I3C bus and the devices connected on it.
> 
> Document this generic representation.
> 
> Signed-off-by: Boris Brezillon 
> ---
> Changes in v4:
> - Clarify the fact that static address == I3C address and dynamic
>   address == I3C address
> - Use i2c-scl-hz in the example
> 
> Changes in v3:
> - Rename {i2c,i3c}-scl-frequency DT prop into {i2c,i3c}-scl-hz
> - Rework the way we expose the provisional ID and LVR information
> - Rename dynamic-address into assigned-address
> - Enforce the I3C master node name
> 
> Changes in v2:
> - Define how to describe I3C devices in the DT and when it should be
>   used. Note that the parsing of I3C devices is not yet implemented in
>   the framework. Will be added when someone really needs it.
> ---
>  Documentation/devicetree/bindings/i3c/i3c.txt | 140 
> ++
>  1 file changed, 140 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt

Reviewed-by: Rob Herring 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] mm: replace __HAVE_ARCH_PTE_SPECIAL

[David Rientjes]

On Mon, 9 Apr 2018, Christoph Hellwig wrote:

> > -#ifdef __HAVE_ARCH_PTE_SPECIAL
> > +#ifdef CONFIG_ARCH_HAS_PTE_SPECIAL
> >  # define HAVE_PTE_SPECIAL 1
> >  #else
> >  # define HAVE_PTE_SPECIAL 0
> 
> I'd say kill this odd indirection and just use the
> CONFIG_ARCH_HAS_PTE_SPECIAL symbol directly.
> 
> 

Agree, and I think it would be easier to audit/review if patches 1 and 3 
were folded together to see the relationship between the newly added 
selects and what #define's it is replacing.  Otherwise, looks good!
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] mm: replace __HAVE_ARCH_PTE_SPECIAL

[Christoph Hellwig]

> -#ifdef __HAVE_ARCH_PTE_SPECIAL
> +#ifdef CONFIG_ARCH_HAS_PTE_SPECIAL
>  # define HAVE_PTE_SPECIAL 1
>  #else
>  # define HAVE_PTE_SPECIAL 0

I'd say kill this odd indirection and just use the
CONFIG_ARCH_HAS_PTE_SPECIAL symbol directly.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] sched/fair: add support to tune PELT ramp/decay timings

[Patrick Bellasi]

The PELT half-life is the time [ms] required by the PELT signal to build
up a 50% load/utilization, starting from zero. This time is currently
hardcoded to be 32ms, a value which seems to make sense for most of the
workloads.

However, 32ms has been verified to be too long for certain classes of
workloads. For example, in the mobile space many tasks affecting the
user-experience run with a 16ms or 8ms cadence, since they need to match
the common 60Hz or 120Hz refresh rate of the graphics pipeline.
This contributed so fare to the idea that "PELT is too slow" to properly
track the utilization of interactive mobile workloads, especially
compared to alternative load tracking solutions which provides a
better representation of tasks demand in the range of 10-20ms.

A faster PELT ramp-up time could give some advantages to speed-up the
time required for the signal to stabilize and thus to better represent
task demands in the mobile space. As a downside, it also reduces the
decay time, and thus we forget the load/utilization of sleeping tasks
(or idle CPUs) faster.

Fortunately, since the integration of the utilization estimation
support in mainline kernel:

   commit 7f65ea42eb00 ("sched/fair: Add util_est on top of PELT")

a fast decay time is no longer an issue for tasks utilization estimation.
Although estimated utilization does not slow down the decay of blocked
utilization on idle CPUs, for mobile workloads this seems not to be a
major concern compared to the benefits in interactivity responsiveness.

Let's add a compile time option to choose the PELT speed which better
fits for a specific system. By default the current 32ms half-life is
used, but we can also compile a kernel to use a faster ramp-up time of
either 16ms or 8ms. These two configurations have been verified to give
PELT a further improvement in performance, compared to other out-of-tree
load tracking solutions, when it comes to track interactive workloads
thus better supporting both tasks placements and frequencies selections.

Signed-off-by: Patrick Bellasi 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Jonathan Corbet 
Cc: Paul Turner 
Cc: Vincent Guittot 
Cc: Joel Fernandes 
Cc: Morten Rasmussen 
Cc: linux-doc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
 Documentation/scheduler/sched-pelt.c | 45 ++--
 init/Kconfig | 44 +++
 kernel/sched/sched-pelt.h| 39 ++-
 3 files changed, 105 insertions(+), 23 deletions(-)

diff --git a/Documentation/scheduler/sched-pelt.c 
b/Documentation/scheduler/sched-pelt.c
index e4219139386a..e0ae21616188 100644
--- a/Documentation/scheduler/sched-pelt.c
+++ b/Documentation/scheduler/sched-pelt.c
@@ -10,34 +10,35 @@
 #include 
 #include 
 
-#define HALFLIFE 32
+#define HALFLIFE { 32, 16, 8 }
 #define SHIFT 32
 
 double y;
 
-void calc_runnable_avg_yN_inv(void)
+void calc_runnable_avg_yN_inv(const int halflife)
 {
int i;
unsigned int x;
 
printf("static const u32 runnable_avg_yN_inv[] = {");
-   for (i = 0; i < HALFLIFE; i++) {
+   for (i = 0; i < halflife; i++) {
x = ((1UL<<32)-1)*pow(y, i);
 
-   if (i % 6 == 0) printf("\n\t");
-   printf("0x%8x, ", x);
+   if (i % 4 == 0)
+   printf("\n\t");
+   printf("0x%8x,", x);
}
printf("\n};\n\n");
 }
 
 int sum = 1024;
 
-void calc_runnable_avg_yN_sum(void)
+void calc_runnable_avg_yN_sum(const int halflife)
 {
int i;
 
printf("static const u32 runnable_avg_yN_sum[] = {\n\t0,");
-   for (i = 1; i <= HALFLIFE; i++) {
+   for (i = 1; i <= halflife; i++) {
if (i == 1)
sum *= y;
else
@@ -55,7 +56,7 @@ int n = -1;
 /* first period */
 long max = 1024;
 
-void calc_converged_max(void)
+void calc_converged_max(const int halflife)
 {
long last = 0, y_inv = ((1UL<<32)-1)*y;
 
@@ -73,17 +74,17 @@ void calc_converged_max(void)
last = max;
}
n--;
-   printf("#define LOAD_AVG_PERIOD %d\n", HALFLIFE);
+   printf("#define LOAD_AVG_PERIOD %d\n", halflife);
printf("#define LOAD_AVG_MAX %ld\n", max);
-// printf("#define LOAD_AVG_MAX_N %d\n\n", n);
+   /* printf("#define LOAD_AVG_MAX_N %d\n\n", n); */
 }
 
-void calc_accumulated_sum_32(void)
+void calc_accumulated_sum_32(const int halflife)
 {
int i, x = sum;
 
printf("static const u32 __accumulated_sum_N32[] = {\n\t 0,");
-   for (i = 1; i <= n/HALFLIFE+1; i++) {
+   for (i = 1; i <= n / halflife + 1; i++) {
if (i > 1)
x = x/2 + sum;
 
@@ -97,12 +98,22 @@ void calc_accumulated_sum_32(void)
 
 void 

Re: [PATCH 0/3] move __HAVE_ARCH_PTE_SPECIAL in Kconfig

[Laurent Dufour]

On 09/04/2018 18:03, Vineet Gupta wrote:
> On 04/09/2018 06:57 AM, Laurent Dufour wrote:
>> The per architecture __HAVE_ARCH_PTE_SPECIAL is defined statically in the
>> per architecture header files. This doesn't allow to make other
>> configuration dependent on it.
> 
> So I understand this series has more "readability" value and I'm fine with 
> this
> change but I wonder if you really would want to make something depend on it or
> make this de-configurable. PTE special is really a fundamental construct - 
> e.g.
> it is used for anon mapped pages where zero page has been wired up etc...

I don't want it to be de-configurable. This is almost like
ARCH_SUPPORTS_MEMORY_FAILURE, ARCH_USES_HIGH_VMA_FLAGS, ARCH_HAS_HMM...

These values are selected by per architecture Kconfig files and are not exposed
through the configuration menu.

Concerning making something depend on it, I will probably make
CONFIG_SPECULATIVE_PAGE_FAULT introduced by the SPF series dependent on it.
For details, please see https://lkml.org/lkml/2018/3/13/1143

Thanks,
Laurent.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] move __HAVE_ARCH_PTE_SPECIAL in Kconfig

[Vineet Gupta]

On 04/09/2018 06:57 AM, Laurent Dufour wrote:

The per architecture __HAVE_ARCH_PTE_SPECIAL is defined statically in the
per architecture header files. This doesn't allow to make other
configuration dependent on it.


So I understand this series has more "readability" value and I'm fine with this 
change but I wonder if you really would want to make something depend on it or 
make this de-configurable. PTE special is really a fundamental construct - e.g. it 
is used for anon mapped pages where zero page has been wired up etc...


-Vineet


This series is moving the __HAVE_ARCH_PTE_SPECIAL into the Kconfig files,
setting it automatically when architectures was already setting it in
header file.

There is no functional change introduced by this series.


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] move __HAVE_ARCH_PTE_SPECIAL in Kconfig

[Jerome Glisse]

On Mon, Apr 09, 2018 at 04:07:21PM +0200, Michal Hocko wrote:
> On Mon 09-04-18 15:57:06, Laurent Dufour wrote:
> > The per architecture __HAVE_ARCH_PTE_SPECIAL is defined statically in the
> > per architecture header files. This doesn't allow to make other
> > configuration dependent on it.
> > 
> > This series is moving the __HAVE_ARCH_PTE_SPECIAL into the Kconfig files,
> > setting it automatically when architectures was already setting it in
> > header file.
> > 
> > There is no functional change introduced by this series.
> 
> I would just fold all three patches into a single one. It is much easier
> to review that those selects are done properly when you can see that the
> define is set for the same architecture.
> 
> In general, I like the patch. It is always quite painful to track per
> arch defines.

You can also add Reviewed-by: Jérôme Glisse  my grep fu
showed no place that was forgotten.

Cheers,
Jérôme
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 3/9] dt-bindings: Tegra186 tachometer device tree bindings

[Mikko Perttunen]

On 04/09/2018 04:21 PM, Rob Herring wrote:

On Mon, Apr 9, 2018 at 12:38 AM, Mikko Perttunen  wrote:

Rob,


Please don't top post to lists.


this binding is for a specific IP block (for measuring/aggregating input
pulses) on the Tegra186 SoC, so I don't think it fits into any generic
binding.


What is it hooked up to to measure? You only mention "fan" five times
in the doc.


In practice, fans.



You have #pwm-cells too, so this block has PWM output as well? If not,
then where's the PWM for the fan control because there is no point in
having fan tach without some control mechanism.


It doesn't provide a PWM output. The (Linux) PWM framework provides 
functionality in both directions - control and capture. But if the 
device tree #pwm-cells/pwms properties are only for control, we may need 
to introduce a new #capture-pwm-cells/capture-pwms or similar.


The idea is that the generic fan node can then specify two pwms, one for 
control and one for capture, to enable e.g. closed-loop control (I'm not 
personally familiar with the usecase for this but I could imagine 
something like that). The control PWM can be something completely 
different, maybe not a PWM in the first place (e.g. some fixed voltage).




There's only so many ways to control fans and types of fans, so yes,
the interface of control and feedback lines between a fan and its
controller should absolutely be generic.


I'm not quite getting what you mean by this. Clearly we need a custom 
compatibility string for the tachometer as it's a different hardware 
block with different programming than others. Or are you complaining 
about the nvidia,pulse-per-rev/capture-window-len properties?


Thanks,
Mikko



Rob



Thanks,
Mikko


On 03/27/2018 05:52 PM, Rob Herring wrote:


On Wed, Mar 21, 2018 at 10:10:38AM +0530, Rajkumar Rampelli wrote:


Supply Device tree binding documentation for the NVIDIA
Tegra186 SoC's Tachometer Controller

Signed-off-by: Rajkumar Rampelli 
---

V2: Renamed compatible string to "nvidia,tegra186-pwm-tachometer"
  Renamed dt property values of clock-names and reset-names to
"tachometer"
  from "tach"



Read my prior comments on v1.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] move __HAVE_ARCH_PTE_SPECIAL in Kconfig

[Michal Hocko]

On Mon 09-04-18 15:57:06, Laurent Dufour wrote:
> The per architecture __HAVE_ARCH_PTE_SPECIAL is defined statically in the
> per architecture header files. This doesn't allow to make other
> configuration dependent on it.
> 
> This series is moving the __HAVE_ARCH_PTE_SPECIAL into the Kconfig files,
> setting it automatically when architectures was already setting it in
> header file.
> 
> There is no functional change introduced by this series.

I would just fold all three patches into a single one. It is much easier
to review that those selects are done properly when you can see that the
define is set for the same architecture.

In general, I like the patch. It is always quite painful to track per
arch defines.

> Laurent Dufour (3):
>   mm: introduce ARCH_HAS_PTE_SPECIAL
>   mm: replace __HAVE_ARCH_PTE_SPECIAL
>   mm: remove __HAVE_ARCH_PTE_SPECIAL
> 
>  Documentation/features/vm/pte_special/arch-support.txt | 2 +-
>  arch/arc/Kconfig   | 1 +
>  arch/arc/include/asm/pgtable.h | 2 --
>  arch/arm/Kconfig   | 1 +
>  arch/arm/include/asm/pgtable-3level.h  | 1 -
>  arch/arm64/Kconfig | 1 +
>  arch/arm64/include/asm/pgtable.h   | 2 --
>  arch/powerpc/Kconfig   | 1 +
>  arch/powerpc/include/asm/book3s/64/pgtable.h   | 3 ---
>  arch/powerpc/include/asm/pte-common.h  | 3 ---
>  arch/riscv/Kconfig | 1 +
>  arch/s390/Kconfig  | 1 +
>  arch/s390/include/asm/pgtable.h| 1 -
>  arch/sh/Kconfig| 1 +
>  arch/sh/include/asm/pgtable.h  | 2 --
>  arch/sparc/Kconfig | 1 +
>  arch/sparc/include/asm/pgtable_64.h| 3 ---
>  arch/x86/Kconfig   | 1 +
>  arch/x86/include/asm/pgtable_types.h   | 1 -
>  include/linux/pfn_t.h  | 4 ++--
>  mm/Kconfig | 3 +++
>  mm/gup.c   | 4 ++--
>  mm/memory.c| 2 +-
>  23 files changed, 18 insertions(+), 24 deletions(-)
> 
> -- 
> 2.7.4

-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] mm: remove __HAVE_ARCH_PTE_SPECIAL

[Laurent Dufour]

It is now replaced by Kconfig variable CONFIG_ARCH_HAS_PTE_SPECIAL.

Signed-off-by: Laurent Dufour 
---
 arch/arc/include/asm/pgtable.h   | 2 --
 arch/arm/include/asm/pgtable-3level.h| 1 -
 arch/arm64/include/asm/pgtable.h | 2 --
 arch/powerpc/include/asm/book3s/64/pgtable.h | 3 ---
 arch/powerpc/include/asm/pte-common.h| 3 ---
 arch/s390/include/asm/pgtable.h  | 1 -
 arch/sh/include/asm/pgtable.h| 2 --
 arch/sparc/include/asm/pgtable_64.h  | 3 ---
 arch/x86/include/asm/pgtable_types.h | 1 -
 9 files changed, 18 deletions(-)

diff --git a/arch/arc/include/asm/pgtable.h b/arch/arc/include/asm/pgtable.h
index 08fe33830d4b..8ec5599a0957 100644
--- a/arch/arc/include/asm/pgtable.h
+++ b/arch/arc/include/asm/pgtable.h
@@ -320,8 +320,6 @@ PTE_BIT_FUNC(mkexec,|= (_PAGE_EXECUTE));
 PTE_BIT_FUNC(mkspecial,|= (_PAGE_SPECIAL));
 PTE_BIT_FUNC(mkhuge,   |= (_PAGE_HW_SZ));
 
-#define __HAVE_ARCH_PTE_SPECIAL
-
 static inline pte_t pte_modify(pte_t pte, pgprot_t newprot)
 {
return __pte((pte_val(pte) & _PAGE_CHG_MASK) | pgprot_val(newprot));
diff --git a/arch/arm/include/asm/pgtable-3level.h 
b/arch/arm/include/asm/pgtable-3level.h
index 2a4836087358..6d50a11d7793 100644
--- a/arch/arm/include/asm/pgtable-3level.h
+++ b/arch/arm/include/asm/pgtable-3level.h
@@ -219,7 +219,6 @@ static inline pte_t pte_mkspecial(pte_t pte)
pte_val(pte) |= L_PTE_SPECIAL;
return pte;
 }
-#define__HAVE_ARCH_PTE_SPECIAL
 
 #define pmd_write(pmd) (pmd_isclear((pmd), L_PMD_SECT_RDONLY))
 #define pmd_dirty(pmd) (pmd_isset((pmd), L_PMD_SECT_DIRTY))
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 7e2c27e63cd8..b96c8a186908 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -306,8 +306,6 @@ static inline int pte_same(pte_t pte_a, pte_t pte_b)
 #define HPAGE_MASK (~(HPAGE_SIZE - 1))
 #define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
 
-#define __HAVE_ARCH_PTE_SPECIAL
-
 static inline pte_t pgd_pte(pgd_t pgd)
 {
return __pte(pgd_val(pgd));
diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h 
b/arch/powerpc/include/asm/book3s/64/pgtable.h
index a6b9f1d74600..f12d148eccbe 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -338,9 +338,6 @@ extern unsigned long pci_io_base;
 /* Advertise special mapping type for AGP */
 #define HAVE_PAGE_AGP
 
-/* Advertise support for _PAGE_SPECIAL */
-#define __HAVE_ARCH_PTE_SPECIAL
-
 #ifndef __ASSEMBLY__
 
 /*
diff --git a/arch/powerpc/include/asm/pte-common.h 
b/arch/powerpc/include/asm/pte-common.h
index c4a72c7a8c83..03dfddb1f49a 100644
--- a/arch/powerpc/include/asm/pte-common.h
+++ b/arch/powerpc/include/asm/pte-common.h
@@ -216,9 +216,6 @@ static inline bool pte_user(pte_t pte)
 #define PAGE_AGP   (PAGE_KERNEL_NC)
 #define HAVE_PAGE_AGP
 
-/* Advertise support for _PAGE_SPECIAL */
-#define __HAVE_ARCH_PTE_SPECIAL
-
 #ifndef _PAGE_READ
 /* if not defined, we should not find _PAGE_WRITE too */
 #define _PAGE_READ 0
diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
index 2d24d33bf188..9809694e1389 100644
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -171,7 +171,6 @@ static inline int is_module_addr(void *addr)
 #define _PAGE_WRITE0x020   /* SW pte write bit */
 #define _PAGE_SPECIAL  0x040   /* SW associated with special page */
 #define _PAGE_UNUSED   0x080   /* SW bit for pgste usage state */
-#define __HAVE_ARCH_PTE_SPECIAL
 
 #ifdef CONFIG_MEM_SOFT_DIRTY
 #define _PAGE_SOFT_DIRTY 0x002 /* SW pte soft dirty bit */
diff --git a/arch/sh/include/asm/pgtable.h b/arch/sh/include/asm/pgtable.h
index 89c513a982fc..f6abfe2bca93 100644
--- a/arch/sh/include/asm/pgtable.h
+++ b/arch/sh/include/asm/pgtable.h
@@ -156,8 +156,6 @@ extern void page_table_range_init(unsigned long start, 
unsigned long end,
 #define HAVE_ARCH_UNMAPPED_AREA
 #define HAVE_ARCH_UNMAPPED_AREA_TOPDOWN
 
-#define __HAVE_ARCH_PTE_SPECIAL
-
 #include 
 
 #endif /* __ASM_SH_PGTABLE_H */
diff --git a/arch/sparc/include/asm/pgtable_64.h 
b/arch/sparc/include/asm/pgtable_64.h
index 44d6ac47e035..1393a8ac596b 100644
--- a/arch/sparc/include/asm/pgtable_64.h
+++ b/arch/sparc/include/asm/pgtable_64.h
@@ -117,9 +117,6 @@ bool kern_addr_valid(unsigned long addr);
 #define _PAGE_PMD_HUGE_AC(0x0100,UL) /* Huge page*/
 #define _PAGE_PUD_HUGE_PAGE_PMD_HUGE
 
-/* Advertise support for _PAGE_SPECIAL */
-#define __HAVE_ARCH_PTE_SPECIAL
-
 /* SUN4U pte bits... */
 #define _PAGE_SZ4MB_4U   _AC(0x6000,UL) /* 4MB Page */
 #define _PAGE_SZ512K_4U  _AC(0x4000,UL) /* 512K Page   
 */
diff --git a/arch/x86/include/asm/pgtable_types.h 

[PATCH 2/3] mm: replace __HAVE_ARCH_PTE_SPECIAL

[Laurent Dufour]

Replace __HAVE_ARCH_PTE_SPECIAL by the new configuration variable
CONFIG_ARCH_HAS_PTE_SPECIAL.

Signed-off-by: Laurent Dufour 
---
 Documentation/features/vm/pte_special/arch-support.txt | 2 +-
 include/linux/pfn_t.h  | 4 ++--
 mm/gup.c   | 4 ++--
 mm/memory.c| 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/features/vm/pte_special/arch-support.txt 
b/Documentation/features/vm/pte_special/arch-support.txt
index 055004f467d2..cd05924ea875 100644
--- a/Documentation/features/vm/pte_special/arch-support.txt
+++ b/Documentation/features/vm/pte_special/arch-support.txt
@@ -1,6 +1,6 @@
 #
 # Feature name:  pte_special
-# Kconfig:   __HAVE_ARCH_PTE_SPECIAL
+# Kconfig:   ARCH_HAS_PTE_SPECIAL
 # description:   arch supports the pte_special()/pte_mkspecial() VM 
APIs
 #
 ---
diff --git a/include/linux/pfn_t.h b/include/linux/pfn_t.h
index a03c2642a87c..21713dc14ce2 100644
--- a/include/linux/pfn_t.h
+++ b/include/linux/pfn_t.h
@@ -122,7 +122,7 @@ pud_t pud_mkdevmap(pud_t pud);
 #endif
 #endif /* __HAVE_ARCH_PTE_DEVMAP */
 
-#ifdef __HAVE_ARCH_PTE_SPECIAL
+#ifdef CONFIG_ARCH_HAS_PTE_SPECIAL
 static inline bool pfn_t_special(pfn_t pfn)
 {
return (pfn.val & PFN_SPECIAL) == PFN_SPECIAL;
@@ -132,5 +132,5 @@ static inline bool pfn_t_special(pfn_t pfn)
 {
return false;
 }
-#endif /* __HAVE_ARCH_PTE_SPECIAL */
+#endif /* CONFIG_ARCH_HAS_PTE_SPECIAL */
 #endif /* _LINUX_PFN_T_H_ */
diff --git a/mm/gup.c b/mm/gup.c
index 2e2df7f3e92d..9e6a4f70deab 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1354,7 +1354,7 @@ static void undo_dev_pagemap(int *nr, int nr_start, 
struct page **pages)
}
 }
 
-#ifdef __HAVE_ARCH_PTE_SPECIAL
+#ifdef CONFIG_ARCH_HAS_PTE_SPECIAL
 static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
 int write, struct page **pages, int *nr)
 {
@@ -1430,7 +1430,7 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr, 
unsigned long end,
 {
return 0;
 }
-#endif /* __HAVE_ARCH_PTE_SPECIAL */
+#endif /* CONFIG_ARCH_HAS_PTE_SPECIAL */
 
 #if defined(__HAVE_ARCH_PTE_DEVMAP) && defined(CONFIG_TRANSPARENT_HUGEPAGE)
 static int __gup_device_huge(unsigned long pfn, unsigned long addr,
diff --git a/mm/memory.c b/mm/memory.c
index 1bb725631ded..6fc7b9edc18f 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -817,7 +817,7 @@ static void print_bad_pte(struct vm_area_struct *vma, 
unsigned long addr,
  * PFNMAP mappings in order to support COWable mappings.
  *
  */
-#ifdef __HAVE_ARCH_PTE_SPECIAL
+#ifdef CONFIG_ARCH_HAS_PTE_SPECIAL
 # define HAVE_PTE_SPECIAL 1
 #else
 # define HAVE_PTE_SPECIAL 0
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] mm: introduce ARCH_HAS_PTE_SPECIAL

[Laurent Dufour]

Currently the PTE special supports is turned on in per architecture header
files. Most of the time, it is defined in arch/*/include/asm/pgtable.h
depending or not on some other per architecture static definition.

This patch introduce a new configuration variable to manage this directly
in the Kconfig files. It would later replace __HAVE_ARCH_PTE_SPECIAL.

Here notes for some architecture where the definition of
__HAVE_ARCH_PTE_SPECIAL is not obvious:

arm
 __HAVE_ARCH_PTE_SPECIAL which is currently defined in
arch/arm/include/asm/pgtable-3level.h which is included by
arch/arm/include/asm/pgtable.h when CONFIG_ARM_LPAE is set.
So select ARCH_HAS_PTE_SPECIAL if ARM_LPAE.

powerpc
__HAVE_ARCH_PTE_SPECIAL is defined in 2 files:
 - arch/powerpc/include/asm/book3s/64/pgtable.h
 - arch/powerpc/include/asm/pte-common.h
The first one is included if (PPC_BOOK3S & PPC64) while the second is
included in all the other cases.
So select ARCH_HAS_PTE_SPECIAL all the time.

sparc:
__HAVE_ARCH_PTE_SPECIAL is defined if defined(__sparc__) &&
defined(__arch64__) which are defined through the compiler in
sparc/Makefile if !SPARC32 which I assume to be if SPARC64.
So select ARCH_HAS_PTE_SPECIAL if SPARC64

Suggested-by: Jerome Glisse 
Signed-off-by: Laurent Dufour 
---
 arch/arc/Kconfig | 1 +
 arch/arm/Kconfig | 1 +
 arch/arm64/Kconfig   | 1 +
 arch/powerpc/Kconfig | 1 +
 arch/riscv/Kconfig   | 1 +
 arch/s390/Kconfig| 1 +
 arch/sh/Kconfig  | 1 +
 arch/sparc/Kconfig   | 1 +
 arch/x86/Kconfig | 1 +
 mm/Kconfig   | 3 +++
 10 files changed, 12 insertions(+)

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index d76bf4a83740..8516e2b0239a 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -44,6 +44,7 @@ config ARC
select HAVE_GENERIC_DMA_COHERENT
select HAVE_KERNEL_GZIP
select HAVE_KERNEL_LZMA
+   select ARCH_HAS_PTE_SPECIAL
 
 config MIGHT_HAVE_PCI
bool
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1878083771af..a67973cb041c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -7,6 +7,7 @@ config ARM
select ARCH_HAS_DEBUG_VIRTUAL if MMU
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
+   select ARCH_HAS_PTE_SPECIAL if ARM_LPAE
select ARCH_HAS_SET_MEMORY
select ARCH_HAS_PHYS_TO_DMA
select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 276e96ceaf27..7ae3c09921fb 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -17,6 +17,7 @@ config ARM64
select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA
select ARCH_HAS_KCOV
select ARCH_HAS_MEMBARRIER_SYNC_CORE
+   select ARCH_HAS_PTE_SPECIAL
select ARCH_HAS_SET_MEMORY
select ARCH_HAS_SG_CHAIN
select ARCH_HAS_STRICT_KERNEL_RWX
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c32a181a7cbb..f7415fe25c07 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -141,6 +141,7 @@ config PPC
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_HAS_PHYS_TO_DMA
select ARCH_HAS_PMEM_APIif PPC64
+   select ARCH_HAS_PTE_SPECIAL
select ARCH_HAS_MEMBARRIER_CALLBACKS
select ARCH_HAS_SCALED_CPUTIME  if VIRT_CPU_ACCOUNTING_NATIVE
select ARCH_HAS_SG_CHAIN
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 148865de1692..b0a8404bf684 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -34,6 +34,7 @@ config RISCV
select THREAD_INFO_IN_TASK
select RISCV_TIMER
select GENERIC_IRQ_MULTI_HANDLER
+   select ARCH_HAS_PTE_SPECIAL
 
 config MMU
def_bool y
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 32a0d5b958bf..5f1f4997e7e9 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -72,6 +72,7 @@ config S390
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA
select ARCH_HAS_KCOV
+   select ARCH_HAS_PTE_SPECIAL
select ARCH_HAS_SET_MEMORY
select ARCH_HAS_SG_CHAIN
select ARCH_HAS_STRICT_KERNEL_RWX
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 97fe29316476..a6c75b6806d2 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -50,6 +50,7 @@ config SUPERH
select HAVE_ARCH_AUDITSYSCALL
select HAVE_FUTEX_CMPXCHG if FUTEX
select HAVE_NMI
+   select ARCH_HAS_PTE_SPECIAL
help
  The SuperH is a RISC processor targeted for use in embedded systems
  and consumer electronics; it was also used in the Sega Dreamcast
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 8767e45f1b2b..6b5a4f05dcb2 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -86,6 +86,7 @@ config SPARC64
select ARCH_USE_QUEUED_SPINLOCKS
select GENERIC_TIME_VSYSCALL
select 

[PATCH 0/3] move __HAVE_ARCH_PTE_SPECIAL in Kconfig

[Laurent Dufour]

The per architecture __HAVE_ARCH_PTE_SPECIAL is defined statically in the
per architecture header files. This doesn't allow to make other
configuration dependent on it.

This series is moving the __HAVE_ARCH_PTE_SPECIAL into the Kconfig files,
setting it automatically when architectures was already setting it in
header file.

There is no functional change introduced by this series.

Laurent Dufour (3):
  mm: introduce ARCH_HAS_PTE_SPECIAL
  mm: replace __HAVE_ARCH_PTE_SPECIAL
  mm: remove __HAVE_ARCH_PTE_SPECIAL

 Documentation/features/vm/pte_special/arch-support.txt | 2 +-
 arch/arc/Kconfig   | 1 +
 arch/arc/include/asm/pgtable.h | 2 --
 arch/arm/Kconfig   | 1 +
 arch/arm/include/asm/pgtable-3level.h  | 1 -
 arch/arm64/Kconfig | 1 +
 arch/arm64/include/asm/pgtable.h   | 2 --
 arch/powerpc/Kconfig   | 1 +
 arch/powerpc/include/asm/book3s/64/pgtable.h   | 3 ---
 arch/powerpc/include/asm/pte-common.h  | 3 ---
 arch/riscv/Kconfig | 1 +
 arch/s390/Kconfig  | 1 +
 arch/s390/include/asm/pgtable.h| 1 -
 arch/sh/Kconfig| 1 +
 arch/sh/include/asm/pgtable.h  | 2 --
 arch/sparc/Kconfig | 1 +
 arch/sparc/include/asm/pgtable_64.h| 3 ---
 arch/x86/Kconfig   | 1 +
 arch/x86/include/asm/pgtable_types.h   | 1 -
 include/linux/pfn_t.h  | 4 ++--
 mm/Kconfig | 3 +++
 mm/gup.c   | 4 ++--
 mm/memory.c| 2 +-
 23 files changed, 18 insertions(+), 24 deletions(-)

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 7/9] trace_uprobe/sdt: Fix multiple update of same reference counter

[Ravi Bangoria]

On 04/09/2018 07:02 PM, Ravi Bangoria wrote:
> Hi Oleg,
>
> On 04/09/2018 06:47 PM, Oleg Nesterov wrote:
>> I didn't read this version yet, just one question...
>>
>> So now it depends on CONFIG_MMU_NOTIFIER, yes? I do not see any changes in 
>> Kconfig
>> files, this doesn't look right...
> Yes, you are write.

s/write/right.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification

[Dongjiu Geng]

1. Detect whether KVM can set set guest SError syndrome
2. Support to Set VSESR_EL2 and inject SError by user space.
3. Support live migration to keep SError pending state and VSESR_EL2 value.
4. ACPI 6.1 adds support for NOTIFY_SEI as a GHES notification mechanism, so 
support this
   notification in software, KVM or kernel ARCH code call handle_guest_sei() to 
let ACP driver
   to handle this notification.

Change since V10:

Address James's comments, thanks James
1. Merge the helper function with the user.
2. Move the ISS_MASK into pend_guest_serror() to clear top bits
3. Make kvm_vcpu_events struct align to 4 bytes
4. Add something check in the kvm_arm_vcpu_set_events()
5. Check kvm_arm_vcpu_get/set_events()'s return value.
6. Initialise kvm_vcpu_events to 0 so that padding transferred to user-space 
doesn't
contain kernel stack.

Dongjiu Geng (4):
  arm64: KVM: export the capability to set guest SError syndrome
  arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS
  ACPI / APEI: Add SEI notification type support for ARMv8
  arm64: handle NOTIFY_SEI notification by the APEI driver

 Documentation/virtual/kvm/api.txt| 39 --
 arch/arm/include/asm/kvm_host.h  |  6 
 arch/arm/kvm/guest.c | 12 
 arch/arm64/include/asm/kvm_emulate.h |  5 
 arch/arm64/include/asm/kvm_host.h|  7 +
 arch/arm64/include/asm/system_misc.h |  1 +
 arch/arm64/include/uapi/asm/kvm.h| 12 
 arch/arm64/kernel/traps.c|  4 +++
 arch/arm64/kvm/guest.c   | 31 +
 arch/arm64/kvm/inject_fault.c|  7 -
 arch/arm64/kvm/reset.c   |  4 +++
 arch/arm64/mm/fault.c| 10 +++
 drivers/acpi/apei/Kconfig| 15 ++
 drivers/acpi/apei/ghes.c | 53 
 include/acpi/ghes.h  |  1 +
 include/uapi/linux/kvm.h |  1 +
 virt/kvm/arm/arm.c   | 21 ++
 17 files changed, 226 insertions(+), 3 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 4/4] arm64: handle NOTIFY_SEI notification by the APEI driver

[Dongjiu Geng]

Add a helper to handle the NOTIFY_SEI notification, when kernel
gets the NOTIFY_SEI notification, call this helper and let APEI
driver to handle this notification.

Signed-off-by: Dongjiu Geng 
---
 arch/arm64/include/asm/system_misc.h |  1 +
 arch/arm64/kernel/traps.c|  4 
 arch/arm64/mm/fault.c| 10 ++
 3 files changed, 15 insertions(+)

diff --git a/arch/arm64/include/asm/system_misc.h 
b/arch/arm64/include/asm/system_misc.h
index 07aa8e3..9ee13ad 100644
--- a/arch/arm64/include/asm/system_misc.h
+++ b/arch/arm64/include/asm/system_misc.h
@@ -57,6 +57,7 @@ void hook_debug_fault_code(int nr, int (*fn)(unsigned long, 
unsigned int,
 })
 
 int handle_guest_sea(phys_addr_t addr, unsigned int esr);
+int handle_guest_sei(void);
 
 #endif /* __ASSEMBLY__ */
 
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index bbb0fde..d888eb2 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -681,6 +681,10 @@ bool arm64_is_fatal_ras_serror(struct pt_regs *regs, 
unsigned int esr)
 {
u32 aet = arm64_ras_serror_get_severity(esr);
 
+   /* The APEI driver may handle this RAS error. */
+   if (!handle_guest_sei())
+   return false;
+
switch (aet) {
case ESR_ELx_AET_CE:/* corrected error */
case ESR_ELx_AET_UEO:   /* restartable, not yet consumed */
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index f76bb2c..8f29bd8 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -683,6 +683,16 @@ int handle_guest_sea(phys_addr_t addr, unsigned int esr)
return ret;
 }
 
+int handle_guest_sei(void)
+{
+   int ret = -ENOENT;
+
+   if (IS_ENABLED(CONFIG_ACPI_APEI_SEI))
+   ret = ghes_notify_sei();
+
+   return ret;
+}
+
 asmlinkage void __exception do_mem_abort(unsigned long addr, unsigned int esr,
 struct pt_regs *regs)
 {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC bpf-next] bpf: document eBPF helpers and add a script to generate man page

[Quentin Monnet]

2018-04-09 12:52 UTC+0200 ~ Markus Heiser 
> 
>> Am 09.04.2018 um 12:08 schrieb Daniel Borkmann :
> [...]
> 
>>> May I completely misunderstood you, so correct my if I'am wrong:
>>>
>>> - ./scripts/bpf_helpers_doc.py : produces reST markup from C-comments
>>> - ./scripts/kerne-doc  : produces reST markup from C-comments
>>>
>>> IMO: both are doing the same job, so why not using kernel-doc?
>>
>> They are not really doing the same job, in bpf_helpers_doc.py case you don't
>> want the whole header rendered, but just a fraction of it, that is, the
>> single big comment which describes all BPF helper functions that a BPF
>> program developer has available to use in user space - aka the entries in
>> the __BPF_FUNC_MAPPER() macro;
> 
> 
>> I also doubt the latter would actually qualify
>> in kdoc context as some sort of a function description.
> 
> latter .. ah, OK .. thanks for clarifying. 
> 
> -- Markus --

As Daniel explained, kernel-doc does not apply in this case, we do not
have the full function prototype for eBPF helpers in the header file.
But to be honest, I didn't even realise kernel-doc was available and
could do something close to what I was looking for, so thanks for your
feedback! :)

Quentin

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 7/9] trace_uprobe/sdt: Fix multiple update of same reference counter

[Ravi Bangoria]

Hi Oleg,

On 04/09/2018 06:47 PM, Oleg Nesterov wrote:
> On 04/04, Ravi Bangoria wrote:
>> +static void sdt_add_mm_list(struct trace_uprobe *tu, struct mm_struct *mm)
>> +{
>> +struct mmu_notifier *mn;
>> +struct sdt_mm_list *sml = kzalloc(sizeof(*sml), GFP_KERNEL);
>> +
>> +if (!sml)
>> +return;
>> +sml->mm = mm;
>> +list_add(&(sml->list), &(tu->sml.list));
>> +
>> +/* Register mmu_notifier for this mm. */
>> +mn = kzalloc(sizeof(*mn), GFP_KERNEL);
>> +if (!mn)
>> +return;
>> +
>> +mn->ops = _mmu_notifier_ops;
>> +__mmu_notifier_register(mn, mm);
>> +}
> I didn't read this version yet, just one question...
>
> So now it depends on CONFIG_MMU_NOTIFIER, yes? I do not see any changes in 
> Kconfig
> files, this doesn't look right...

Yes, you are write. I'll make CONFIG_UPROBE_EVENTS dependent on
CONFIG_MMU_NOTIFIER.

Thanks,
Ravi

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 2/4] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS

[Dongjiu Geng]

This new IOCTL exports user-invisible states related to SError.
Together with appropriate user space changes, it can inject
SError with specified syndrome to guest by setup kvm_vcpu_events
value. Also it can support live migration.

Signed-off-by: Dongjiu Geng 

Change since V10:

Address James's comments, thanks James
1. Merge the helper function with the user.
2. Move the ISS_MASK into pend_guest_serror() to clear top bits
3. Make kvm_vcpu_events struct align to 4 bytes
4. Add something check in the kvm_arm_vcpu_set_events()
5. Check kvm_arm_vcpu_get/set_events()'s return value.
6. Initialise kvm_vcpu_events to 0 so that padding transferred to user-space 
doesn't
contain kernel stack.
---
 Documentation/virtual/kvm/api.txt| 28 ++--
 arch/arm/include/asm/kvm_host.h  |  6 ++
 arch/arm/kvm/guest.c | 12 
 arch/arm64/include/asm/kvm_emulate.h |  5 +
 arch/arm64/include/asm/kvm_host.h|  7 +++
 arch/arm64/include/uapi/asm/kvm.h| 12 
 arch/arm64/kvm/guest.c   | 31 +++
 arch/arm64/kvm/inject_fault.c|  7 ++-
 arch/arm64/kvm/reset.c   |  1 +
 virt/kvm/arm/arm.c   | 21 +
 10 files changed, 127 insertions(+), 3 deletions(-)

diff --git a/Documentation/virtual/kvm/api.txt 
b/Documentation/virtual/kvm/api.txt
index 8a3d708..45719b4 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -819,11 +819,13 @@ struct kvm_clock_data {
 
 Capability: KVM_CAP_VCPU_EVENTS
 Extended by: KVM_CAP_INTR_SHADOW
-Architectures: x86
+Architectures: x86, arm, arm64
 Type: vm ioctl
 Parameters: struct kvm_vcpu_event (out)
 Returns: 0 on success, -1 on error
 
+X86:
+
 Gets currently pending exceptions, interrupts, and NMIs as well as related
 states of the vcpu.
 
@@ -865,15 +867,31 @@ Only two fields are defined in the flags field:
 - KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that
   smi contains a valid state.
 
+ARM, ARM64:
+
+Gets currently pending SError exceptions as well as related states of the vcpu.
+
+struct kvm_vcpu_events {
+   struct {
+   __u8 serror_pending;
+   __u8 serror_has_esr;
+   /* Align it to 4 bytes */
+   __u8 pad[2];
+   __u64 serror_esr;
+   } exception;
+};
+
 4.32 KVM_SET_VCPU_EVENTS
 
 Capability: KVM_CAP_VCPU_EVENTS
 Extended by: KVM_CAP_INTR_SHADOW
-Architectures: x86
+Architectures: x86, arm, arm64
 Type: vm ioctl
 Parameters: struct kvm_vcpu_event (in)
 Returns: 0 on success, -1 on error
 
+X86:
+
 Set pending exceptions, interrupts, and NMIs as well as related states of the
 vcpu.
 
@@ -894,6 +912,12 @@ shall be written into the VCPU.
 
 KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available.
 
+ARM, ARM64:
+
+Set pending SError exceptions as well as related states of the vcpu.
+
+See KVM_GET_VCPU_EVENTS for the data structure.
+
 
 4.33 KVM_GET_DEBUGREGS
 
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index ef54013..d81621e 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -211,6 +211,12 @@ struct kvm_vcpu_stat {
 int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
 int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
 int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+   struct kvm_vcpu_events *events);
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+   struct kvm_vcpu_events *events);
+
 unsigned long kvm_call_hyp(void *hypfn, ...);
 void force_vm_exit(const cpumask_t *mask);
 
diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
index 1e0784e..39f895d 100644
--- a/arch/arm/kvm/guest.c
+++ b/arch/arm/kvm/guest.c
@@ -248,6 +248,18 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return -EINVAL;
 }
 
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+   struct kvm_vcpu_events *events)
+{
+   return -EINVAL;
+}
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+   struct kvm_vcpu_events *events)
+{
+   return -EINVAL;
+}
+
 int __attribute_const__ kvm_target_cpu(void)
 {
switch (read_cpuid_part()) {
diff --git a/arch/arm64/include/asm/kvm_emulate.h 
b/arch/arm64/include/asm/kvm_emulate.h
index 413dc82..3294885 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -71,6 +71,11 @@ static inline void vcpu_set_hcr(struct kvm_vcpu *vcpu, 
unsigned long hcr)
vcpu->arch.hcr_el2 = hcr;
 }
 
+static inline unsigned long vcpu_get_vsesr(struct kvm_vcpu *vcpu)
+{
+   return vcpu->arch.vsesr_el2;
+}
+
 static inline void vcpu_set_vsesr(struct kvm_vcpu *vcpu, u64 vsesr)
 {

[PATCH v11 3/4] ACPI / APEI: Add SEI notification type support for ARMv8

[Dongjiu Geng]

ACPI 6.x adds support for NOTIFY_SEI as a GHES notification
mechanism, so add new GHES notification handling functions.
Expose API ghes_notify_sei() to arch code, arch code will call
this API when it gets this NOTIFY_SEI.

Signed-off-by: Dongjiu Geng 
---
 drivers/acpi/apei/Kconfig | 15 ++
 drivers/acpi/apei/ghes.c  | 53 +++
 include/acpi/ghes.h   |  1 +
 3 files changed, 69 insertions(+)

diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig
index 52ae543..ff4afc3 100644
--- a/drivers/acpi/apei/Kconfig
+++ b/drivers/acpi/apei/Kconfig
@@ -55,6 +55,21 @@ config ACPI_APEI_SEA
  option allows the OS to look for such hardware error record, and
  take appropriate action.
 
+config ACPI_APEI_SEI
+   bool "APEI SError(System Error) Interrupt logging/recovering support"
+   depends on ARM64 && ACPI_APEI_GHES
+   default y
+   help
+ This option should be enabled if the system supports
+ firmware first handling of SEI (SError interrupt).
+
+ SEI happens with asynchronous external abort for errors on device
+ memory reads on ARMv8 systems. If a system supports firmware first
+ handling of SEI, the platform analyzes and handles hardware error
+ notifications from SEI, and it may then form a hardware error record 
for
+ the OS to parse and handle. This option allows the OS to look for
+ such hardware error record, and take appropriate action.
+
 config ACPI_APEI_MEMORY_FAILURE
bool "APEI memory error recovering support"
depends on ACPI_APEI && MEMORY_FAILURE
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 1efefe9..33f77ae 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -827,6 +827,46 @@ static inline void ghes_sea_add(struct ghes *ghes) { }
 static inline void ghes_sea_remove(struct ghes *ghes) { }
 #endif /* CONFIG_ACPI_APEI_SEA */
 
+#ifdef CONFIG_ACPI_APEI_SEI
+static LIST_HEAD(ghes_sei);
+
+/*
+ * Return 0 only if one of the SEI error sources successfully reported an error
+ * record sent from the firmware.
+ */
+int ghes_notify_sei(void)
+{
+   struct ghes *ghes;
+   int ret = -ENOENT;
+
+   rcu_read_lock();
+   list_for_each_entry_rcu(ghes, _sei, list) {
+   if (!ghes_proc(ghes))
+   ret = 0;
+   }
+   rcu_read_unlock();
+   return ret;
+}
+
+static void ghes_sei_add(struct ghes *ghes)
+{
+   mutex_lock(_list_mutex);
+   list_add_rcu(>list, _sei);
+   mutex_unlock(_list_mutex);
+}
+
+static void ghes_sei_remove(struct ghes *ghes)
+{
+   mutex_lock(_list_mutex);
+   list_del_rcu(>list);
+   mutex_unlock(_list_mutex);
+   synchronize_rcu();
+}
+#else /* CONFIG_ACPI_APEI_SEI */
+static inline void ghes_sei_add(struct ghes *ghes) { }
+static inline void ghes_sei_remove(struct ghes *ghes) { }
+#endif /* CONFIG_ACPI_APEI_SEI */
+
 #ifdef CONFIG_HAVE_ACPI_APEI_NMI
 /*
  * printk is not safe in NMI context.  So in NMI handler, we allocate
@@ -1055,6 +1095,13 @@ static int ghes_probe(struct platform_device *ghes_dev)
goto err;
}
break;
+   case ACPI_HEST_NOTIFY_SEI:
+   if (!IS_ENABLED(CONFIG_ACPI_APEI_SEI)) {
+   pr_warn(GHES_PFX "Generic hardware error source: %d 
notified via SEI is not supported!\n",
+   generic->header.source_id);
+   goto err;
+   }
+   break;
case ACPI_HEST_NOTIFY_NMI:
if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_NMI)) {
pr_warn(GHES_PFX "Generic hardware error source: %d 
notified via NMI interrupt is not supported!\n",
@@ -1126,6 +1173,9 @@ static int ghes_probe(struct platform_device *ghes_dev)
case ACPI_HEST_NOTIFY_SEA:
ghes_sea_add(ghes);
break;
+   case ACPI_HEST_NOTIFY_SEI:
+   ghes_sei_add(ghes);
+   break;
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_add(ghes);
break;
@@ -1179,6 +1229,9 @@ static int ghes_remove(struct platform_device *ghes_dev)
case ACPI_HEST_NOTIFY_SEA:
ghes_sea_remove(ghes);
break;
+   case ACPI_HEST_NOTIFY_SEI:
+   ghes_sei_remove(ghes);
+   break;
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_remove(ghes);
break;
diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h
index 8feb0c8..9ba59e2 100644
--- a/include/acpi/ghes.h
+++ b/include/acpi/ghes.h
@@ -120,5 +120,6 @@ static inline void *acpi_hest_get_next(struct 
acpi_hest_generic_data *gdata)
 section = acpi_hest_get_next(section))
 
 int ghes_notify_sea(void);
+int ghes_notify_sei(void);
 
 #endif /* GHES_H */
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in

[PATCH v11 1/4] arm64: KVM: export the capability to set guest SError syndrome

[Dongjiu Geng]

Before user space injects a SError, it needs to know whether it can
specify the guest Exception Syndrome, so KVM should tell user space
whether it has such capability.

Signed-off-by: Dongjiu Geng 
---
 Documentation/virtual/kvm/api.txt | 11 +++
 arch/arm64/kvm/reset.c|  3 +++
 include/uapi/linux/kvm.h  |  1 +
 3 files changed, 15 insertions(+)

diff --git a/Documentation/virtual/kvm/api.txt 
b/Documentation/virtual/kvm/api.txt
index fc3ae95..8a3d708 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -4415,3 +4415,14 @@ Parameters: none
 This capability indicates if the flic device will be able to get/set the
 AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and allows
 to discover this without having to create a flic device.
+
+8.14 KVM_CAP_ARM_SET_SERROR_ESR
+
+Architectures: arm, arm64
+
+This capability indicates that userspace can specify syndrome value reported to
+guest OS when guest takes a virtual SError interrupt exception.
+If KVM has this capability, userspace can only specify the ISS field for the 
ESR
+syndrome, can not specify the EC field which is not under control by KVM.
+If this virtual SError is taken to EL1 using AArch64, this value will be 
reported
+into ISS filed of ESR_EL1.
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 3256b92..38c8a64 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long 
ext)
case KVM_CAP_ARM_PMU_V3:
r = kvm_arm_support_pmu_v3();
break;
+   case KVM_CAP_ARM_INJECT_SERROR_ESR:
+   r = cpus_have_const_cap(ARM64_HAS_RAS_EXTN);
+   break;
case KVM_CAP_SET_GUEST_DEBUG:
case KVM_CAP_VCPU_ATTRIBUTES:
r = 1;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 8fb90a0..3587b33 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -934,6 +934,7 @@ struct kvm_ppc_resize_hpt {
 #define KVM_CAP_S390_AIS_MIGRATION 150
 #define KVM_CAP_PPC_GET_CPU_CHAR 151
 #define KVM_CAP_S390_BPB 152
+#define KVM_CAP_ARM_INJECT_SERROR_ESR 153
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 7/9] trace_uprobe/sdt: Fix multiple update of same reference counter

[Oleg Nesterov]

On 04/04, Ravi Bangoria wrote:
>
> +static void sdt_add_mm_list(struct trace_uprobe *tu, struct mm_struct *mm)
> +{
> + struct mmu_notifier *mn;
> + struct sdt_mm_list *sml = kzalloc(sizeof(*sml), GFP_KERNEL);
> +
> + if (!sml)
> + return;
> + sml->mm = mm;
> + list_add(&(sml->list), &(tu->sml.list));
> +
> + /* Register mmu_notifier for this mm. */
> + mn = kzalloc(sizeof(*mn), GFP_KERNEL);
> + if (!mn)
> + return;
> +
> + mn->ops = _mmu_notifier_ops;
> + __mmu_notifier_register(mn, mm);
> +}

and what if __mmu_notifier_register() fails simply because signal_pending() == 
T?
see mm_take_all_locks().

at first glance this all look suspicious and sub-optimal, but let me repeat that
I didn't read this version yet.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC bpf-next] bpf: document eBPF helpers and add a script to generate man page

[Quentin Monnet]

2018-04-09 11:01 UTC+0200 ~ Daniel Borkmann 
> On 04/06/2018 01:11 PM, Quentin Monnet wrote:
>> eBPF helper functions can be called from within eBPF programs to perform
>> a variety of tasks that would be otherwise hard or impossible to do with
>> eBPF itself. There is a growing number of such helper functions in the
>> kernel, but documentation is scarce. The main user space header file
>> does contain a short commented description of most helpers, but it is
>> somewhat outdated and not complete. It is more a "cheat sheet" than a
>> real documentation accessible to new eBPF developers.
>>
>> This commit attempts to improve the situation by replacing the existing
>> overview for the helpers with a more developed description. Furthermore,
>> a Python script is added to generate a manual page for eBPF helpers. The
>> workflow is the following, and requires the rst2man utility:
>>
>> $ ./scripts/bpf_helpers_doc.py \
>> --filename include/uapi/linux/bpf.h > /tmp/bpf-helpers.rst
>> $ rst2man /tmp/bpf-helpers.rst > /tmp/bpf-helpers.7
>> $ man /tmp/bpf-helpers.7
>>
>> The objective is to keep all documentation related to the helpers in a
>> single place, and to be able to generate from here a manual page that
>> could be packaged in the man-pages repository and shipped with most
>> distributions [1].
>>
>> Additionally, parsing the prototypes of the helper functions could
>> hopefully be reused, with a different Printer object, to generate
>> header files needed in some eBPF-related projects.
>>
>> Regarding the description of each helper, it comprises several items:
>>
>> - The function prototype.
>> - A description of the function and of its arguments (except for a
>>   couple of cases, when there are no arguments and the return value
>>   makes the function usage really obvious).
>> - A description of return values (if not void).
>> - A listing of eBPF program types (if relevant, map types) compatible
>>   with the helper.
>> - Information about the helper being restricted to GPL programs, or not.
>> - The kernel version in which the helper was introduced.
>> - The commit that introduced the helper (this is mostly to have it in
>>   the source of the man page, as it can be used to track changes and
>>   update the page).
>>
>> For several helpers, descriptions are inspired (at times, nearly copied)
>> from the commit logs introducing them in the kernel--Many thanks to
>> their respective authors! They were completed as much as possible, the
>> objective being to have something easily accessible even for people just
>> starting with eBPF. There is probably a bit more work to do in this
>> direction for some helpers.
>>
>> Some RST formatting is used in the descriptions (not in function
>> prototypes, to keep them readable, but the Python script provided in
>> order to generate the RST for the manual page does add formatting to
>> prototypes, to produce something pretty) to get "bold" and "italics" in
>> manual pages. Hopefully, the descriptions in bpf.h file remains
>> perfectly readable. Note that the few trailing white spaces are
>> intentional, removing them would break paragraphs for rst2man.
>>
>> The descriptions should ideally be updated each time someone adds a new
>> helper, or updates the behaviour (compatibility extended to new program
>> types, new socket option supported...) or the interface (new flags
>> available, ...) of existing ones.
>>
>> [1] I have not contacted people from the man-pages project prior to
>> sending this RFC, so I can offer no guaranty at this time that they
>> would accept to take the generated man page.
>>
>> Cc: linux-doc@vger.kernel.org
>> Cc: linux-...@vger.kernel.org
>> Signed-off-by: Quentin Monnet 
> 
> Great work, thanks a lot for doing this!
> 
> [...]
>> + * int bpf_probe_read(void *dst, u32 size, const void *src)
>> + *  Description
>> + *  For tracing programs, safely attempt to read *size* bytes from
>> + *  address *src* and store the data in *dst*.
>> + *  Return
>> + *  0 on success, or a negative error in case of failure.
>> + *  For
>> + *  *Tracing programs*.
>> + *  GPL only
>> + *  Yes
>> + *  Since
>> + *  Linux 4.1
>> + *
>> + * .. commit 2541517c32be
>>   *
>>   * u64 bpf_ktime_get_ns(void)
>> - * Return: current ktime
>> - *
>> - * int bpf_trace_printk(const char *fmt, int fmt_size, ...)
>> - * Return: length of buffer written or negative error
>> + *  Description
>> + *  Return the time elapsed since system boot, in nanoseconds.
>> + *  Return
>> + *  Current *ktime*.
>> + *  For
>> + *  All program types, except
>> + *  **BPF_PROG_TYPE_CGROUP_DEVICE**.
> 
> I think we should probably always just list the actual program types instead,
> since when new types get added to the kernel not supporting bpf_ktime_get_ns()
> helper in this example, the above statement would be misleading 

Re: [PATCH V2 3/9] dt-bindings: Tegra186 tachometer device tree bindings

[Rob Herring]

On Mon, Apr 9, 2018 at 12:38 AM, Mikko Perttunen  wrote:
> Rob,

Please don't top post to lists.

> this binding is for a specific IP block (for measuring/aggregating input
> pulses) on the Tegra186 SoC, so I don't think it fits into any generic
> binding.

What is it hooked up to to measure? You only mention "fan" five times
in the doc.

You have #pwm-cells too, so this block has PWM output as well? If not,
then where's the PWM for the fan control because there is no point in
having fan tach without some control mechanism.

There's only so many ways to control fans and types of fans, so yes,
the interface of control and feedback lines between a fan and its
controller should absolutely be generic.

Rob

>
> Thanks,
> Mikko
>
>
> On 03/27/2018 05:52 PM, Rob Herring wrote:
>>
>> On Wed, Mar 21, 2018 at 10:10:38AM +0530, Rajkumar Rampelli wrote:
>>>
>>> Supply Device tree binding documentation for the NVIDIA
>>> Tegra186 SoC's Tachometer Controller
>>>
>>> Signed-off-by: Rajkumar Rampelli 
>>> ---
>>>
>>> V2: Renamed compatible string to "nvidia,tegra186-pwm-tachometer"
>>>  Renamed dt property values of clock-names and reset-names to
>>> "tachometer"
>>>  from "tach"
>>
>>
>> Read my prior comments on v1.
>>
>> Rob
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 7/9] trace_uprobe/sdt: Fix multiple update of same reference counter

[Oleg Nesterov]

On 04/04, Ravi Bangoria wrote:
>
> +static void sdt_add_mm_list(struct trace_uprobe *tu, struct mm_struct *mm)
> +{
> + struct mmu_notifier *mn;
> + struct sdt_mm_list *sml = kzalloc(sizeof(*sml), GFP_KERNEL);
> +
> + if (!sml)
> + return;
> + sml->mm = mm;
> + list_add(&(sml->list), &(tu->sml.list));
> +
> + /* Register mmu_notifier for this mm. */
> + mn = kzalloc(sizeof(*mn), GFP_KERNEL);
> + if (!mn)
> + return;
> +
> + mn->ops = _mmu_notifier_ops;
> + __mmu_notifier_register(mn, mm);
> +}

I didn't read this version yet, just one question...

So now it depends on CONFIG_MMU_NOTIFIER, yes? I do not see any changes in 
Kconfig
files, this doesn't look right...

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] squashfs-tools: Add posix acl support

[Geliang Tang]

Add posix acl (Access Control Lists) support for mksquashfs and
unsquashfs tools.

Signed-off-by: Geliang Tang 
---
 squashfs-tools/read_xattrs.c  |  2 ++
 squashfs-tools/squashfs_fs.h  | 12 +++-
 squashfs-tools/unsquashfs_xattr.c |  4 +++-
 3 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/squashfs-tools/read_xattrs.c b/squashfs-tools/read_xattrs.c
index 42106f5..8ef8291 100644
--- a/squashfs-tools/read_xattrs.c
+++ b/squashfs-tools/read_xattrs.c
@@ -64,6 +64,8 @@ static long long xattr_table_start;
  */
 struct prefix prefix_table[] = {
{ "user.", SQUASHFS_XATTR_USER },
+   { "system.", SQUASHFS_XATTR_POSIX_ACL_ACCESS },
+   { "system.", SQUASHFS_XATTR_POSIX_ACL_DEFAULT },
{ "trusted.", SQUASHFS_XATTR_TRUSTED },
{ "security.", SQUASHFS_XATTR_SECURITY },
{ "", -1 }
diff --git a/squashfs-tools/squashfs_fs.h b/squashfs-tools/squashfs_fs.h
index afca918..040035c 100644
--- a/squashfs-tools/squashfs_fs.h
+++ b/squashfs-tools/squashfs_fs.h
@@ -122,11 +122,13 @@
 #define SQUASHFS_LSOCKET_TYPE  14
 
 /* Xattr types */
-#define SQUASHFS_XATTR_USER0
-#define SQUASHFS_XATTR_TRUSTED 1
-#define SQUASHFS_XATTR_SECURITY2
-#define SQUASHFS_XATTR_VALUE_OOL   256
-#define SQUASHFS_XATTR_PREFIX_MASK 0xff
+#define SQUASHFS_XATTR_USER0
+#define SQUASHFS_XATTR_POSIX_ACL_ACCESS1
+#define SQUASHFS_XATTR_POSIX_ACL_DEFAULT   2
+#define SQUASHFS_XATTR_TRUSTED 3
+#define SQUASHFS_XATTR_SECURITY4
+#define SQUASHFS_XATTR_VALUE_OOL   256
+#define SQUASHFS_XATTR_PREFIX_MASK 0xff
 
 /* Flag whether block is compressed or uncompressed, bit is set if block is
  * uncompressed */
diff --git a/squashfs-tools/unsquashfs_xattr.c 
b/squashfs-tools/unsquashfs_xattr.c
index 59f4aae..34aae84 100644
--- a/squashfs-tools/unsquashfs_xattr.c
+++ b/squashfs-tools/unsquashfs_xattr.c
@@ -57,7 +57,9 @@ void write_xattr(char *pathname, unsigned int xattr)
if(user_xattrs && prefix != SQUASHFS_XATTR_USER)
continue;
 
-   if(root_process || prefix == SQUASHFS_XATTR_USER) {
+   if(root_process || prefix == SQUASHFS_XATTR_USER
+   || prefix == SQUASHFS_XATTR_POSIX_ACL_ACCESS
+   || prefix == SQUASHFS_XATTR_POSIX_ACL_DEFAULT) {
int res = lsetxattr(pathname, xattr_list[i].full_name,
xattr_list[i].value, xattr_list[i].vsize, 0);
 
-- 
2.14.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] squashfs: Add posix acl support

[Geliang Tang]

Add posix acl (Access Control Lists) support for squashfs, which is
marked as a todo item in squashfs' documentation.  This patch implements
the squashfs_get_acl function to read file's acl information from its
xattr lists.

Signed-off-by: Geliang Tang 
---
 Documentation/filesystems/squashfs.txt |  2 -
 fs/squashfs/Kconfig| 11 ++
 fs/squashfs/Makefile   |  1 +
 fs/squashfs/acl.c  | 69 ++
 fs/squashfs/acl.h  | 27 +
 fs/squashfs/inode.c|  4 +-
 fs/squashfs/namei.c|  6 ++-
 fs/squashfs/squashfs_fs.h  | 12 +++---
 fs/squashfs/super.c|  3 ++
 fs/squashfs/symlink.c  |  6 ++-
 fs/squashfs/xattr.c| 13 ++-
 fs/squashfs/xattr.h|  8 
 12 files changed, 149 insertions(+), 13 deletions(-)
 create mode 100644 fs/squashfs/acl.c
 create mode 100644 fs/squashfs/acl.h

diff --git a/Documentation/filesystems/squashfs.txt 
b/Documentation/filesystems/squashfs.txt
index e5274f84dc56..539fad6b4db0 100644
--- a/Documentation/filesystems/squashfs.txt
+++ b/Documentation/filesystems/squashfs.txt
@@ -235,8 +235,6 @@ list using a second xattr id lookup table.
 4.1 Todo list
 -
 
-Implement ACL support.
-
 4.2 Squashfs internal cache
 ---
 
diff --git a/fs/squashfs/Kconfig b/fs/squashfs/Kconfig
index 1adb3346b9d6..f9587bcf9dd9 100644
--- a/fs/squashfs/Kconfig
+++ b/fs/squashfs/Kconfig
@@ -107,6 +107,17 @@ config SQUASHFS_XATTR
 
  If unsure, say N.
 
+config SQUASHFS_POSIX_ACL
+   bool "Squashfs POSIX ACL support"
+   depends on SQUASHFS_XATTR
+   select FS_POSIX_ACL
+   help
+ Saying Y here includes support for Access Control Lists (acls).
+ Acls are used to define more fine-grained discretionary access
+ rights for files and directories (see the acl(5) manual page).
+
+ If unsure, say N.
+
 config SQUASHFS_ZLIB
bool "Include support for ZLIB compressed file systems"
depends on SQUASHFS
diff --git a/fs/squashfs/Makefile b/fs/squashfs/Makefile
index 7bd9b8b856d0..73bc1c8a8df6 100644
--- a/fs/squashfs/Makefile
+++ b/fs/squashfs/Makefile
@@ -12,6 +12,7 @@ squashfs-$(CONFIG_SQUASHFS_DECOMP_SINGLE) += 
decompressor_single.o
 squashfs-$(CONFIG_SQUASHFS_DECOMP_MULTI) += decompressor_multi.o
 squashfs-$(CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU) += decompressor_multi_percpu.o
 squashfs-$(CONFIG_SQUASHFS_XATTR) += xattr.o xattr_id.o
+squashfs-$(CONFIG_SQUASHFS_POSIX_ACL) += acl.o
 squashfs-$(CONFIG_SQUASHFS_LZ4) += lz4_wrapper.o
 squashfs-$(CONFIG_SQUASHFS_LZO) += lzo_wrapper.o
 squashfs-$(CONFIG_SQUASHFS_XZ) += xz_wrapper.o
diff --git a/fs/squashfs/acl.c b/fs/squashfs/acl.c
new file mode 100644
index ..1c9eb2d13c2b
--- /dev/null
+++ b/fs/squashfs/acl.c
@@ -0,0 +1,69 @@
+/*
+ * Squashfs - a compressed read only filesystem for Linux
+ *
+ * Copyright (c) 2018
+ * Phillip Lougher 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2,
+ * or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * acl.c
+ */
+
+#include 
+#include 
+#include 
+#include "squashfs_fs.h"
+#include "xattr.h"
+#include "acl.h"
+
+struct posix_acl *squashfs_get_acl(struct inode *inode, int type)
+{
+   int name_index;
+   char *name;
+   struct posix_acl *acl = NULL;
+   char *value = NULL;
+   int retval;
+
+   switch (type) {
+   case ACL_TYPE_ACCESS:
+   name_index = SQUASHFS_XATTR_POSIX_ACL_ACCESS;
+   name = XATTR_POSIX_ACL_ACCESS;
+   break;
+   case ACL_TYPE_DEFAULT:
+   name_index = SQUASHFS_XATTR_POSIX_ACL_DEFAULT;
+   name = XATTR_POSIX_ACL_DEFAULT;
+   break;
+   default:
+   BUG();
+   }
+
+   retval = squashfs_xattr_get(inode, name_index, name, NULL, 0);
+   if (retval > 0) {
+   value = kmalloc(retval, GFP_KERNEL);
+   if (!value)
+   return ERR_PTR(-ENOMEM);
+   retval = squashfs_xattr_get(inode, name_index, name, value, 
retval);
+   }
+   if (retval > 0)
+   acl = posix_acl_from_xattr(_user_ns, value, retval);
+   else if (retval == 

Re: [PATCH] Fixed typo in onewire generic doc

[Jonathan Corbet]

On Mon, 09 Apr 2018 02:56:49 +0300
Evgeniy Polyakov  wrote:

> Hi everyone
> 
> I'm really sorry for that long delay.
> 
> Was this patch accepted or should I push it upstream?
> 
> 20.12.2017, 22:09, "Gergo Huszty" :
> > Onewire devices has 6 byte long unique serial numbers, 1 byte family
> > code and 1 byte CRC. Linux sysfs presents the device folder in the
> > form of familyID-deviceID, so CRC is not shown. The consequence is
> > that the device serial number is always a 12 long hex-string, but
> > doc says 13 in one place. This is corrected by this change.
> > Reference: https://en.wikipedia.org/wiki/1-Wire

Commit d6f44b3bd870ff5946fcd4293b4c07029d8d93c9, merged for 4.16.

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC bpf-next] bpf: document eBPF helpers and add a script to generate man page

[Markus Heiser]

> Am 09.04.2018 um 12:08 schrieb Daniel Borkmann :
[...]

>> May I completely misunderstood you, so correct my if I'am wrong:
>> 
>> - ./scripts/bpf_helpers_doc.py : produces reST markup from C-comments
>> - ./scripts/kerne-doc  : produces reST markup from C-comments
>> 
>> IMO: both are doing the same job, so why not using kernel-doc?
> 
> They are not really doing the same job, in bpf_helpers_doc.py case you don't
> want the whole header rendered, but just a fraction of it, that is, the
> single big comment which describes all BPF helper functions that a BPF
> program developer has available to use in user space - aka the entries in
> the __BPF_FUNC_MAPPER() macro;


> I also doubt the latter would actually qualify
> in kdoc context as some sort of a function description.

latter .. ah, OK .. thanks for clarifying. 

-- Markus --

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC bpf-next] bpf: document eBPF helpers and add a script to generate man page

[Daniel Borkmann]

On 04/09/2018 11:35 AM, Markus Heiser wrote:
> 
>> Am 09.04.2018 um 11:25 schrieb Daniel Borkmann :
>>
>> On 04/09/2018 11:21 AM, Markus Heiser wrote:
>> [...]
>>> Do we really need another kernel-doc parser?
>>>
>>>  ./scripts/kernel-doc include/uapi/linux/bpf.h
>>>
>>> should already do the job (producing .rst). For more infos, take a look at
>>
>> This has absolutely zero to do with kernel-doc, but rather producing
>> a description of BPF helper function that are later assembled into an
>> actual man-page that BPF program developers (user space) can use.
> 
> May I completely misunderstood you, so correct my if I'am wrong:
> 
> - ./scripts/bpf_helpers_doc.py : produces reST markup from C-comments
> - ./scripts/kerne-doc  : produces reST markup from C-comments
> 
> IMO: both are doing the same job, so why not using kernel-doc?

They are not really doing the same job, in bpf_helpers_doc.py case you don't
want the whole header rendered, but just a fraction of it, that is, the
single big comment which describes all BPF helper functions that a BPF
program developer has available to use in user space - aka the entries in
the __BPF_FUNC_MAPPER() macro; I also doubt the latter would actually qualify
in kdoc context as some sort of a function description.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC bpf-next] bpf: document eBPF helpers and add a script to generate man page

[Markus Heiser]

> Am 09.04.2018 um 11:25 schrieb Daniel Borkmann :
> 
> On 04/09/2018 11:21 AM, Markus Heiser wrote:
> [...]
>> Do we really need another kernel-doc parser?
>> 
>>  ./scripts/kernel-doc include/uapi/linux/bpf.h
>> 
>> should already do the job (producing .rst). For more infos, take a look at
> 
> This has absolutely zero to do with kernel-doc, but rather producing
> a description of BPF helper function that are later assembled into an
> actual man-page that BPF program developers (user space) can use.

May I completely misunderstood you, so correct my if I'am wrong:

- ./scripts/bpf_helpers_doc.py : produces reST markup from C-comments
- ./scripts/kerne-doc  : produces reST markup from C-comments

IMO: both are doing the same job, so why not using kernel-doc?

-- Markus --


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC bpf-next] bpf: document eBPF helpers and add a script to generate man page

[Markus Heiser]

On 04/06/2018 01:11 PM, Quentin Monnet wrote:
>> eBPF helper functions can be called from within eBPF programs to perform
>> a variety of tasks that would be otherwise hard or impossible to do with
>> eBPF itself. There is a growing number of such helper functions in the
>> kernel, but documentation is scarce. The main user space header file
>> does contain a short commented description of most helpers, but it is
>> somewhat outdated and not complete. It is more a "cheat sheet" than a
>> real documentation accessible to new eBPF developers.
>> 
>> This commit attempts to improve the situation by replacing the existing
>> overview for the helpers with a more developed description. Furthermore,
>> a Python script is added to generate a manual page for eBPF helpers. The
>> workflow is the following, and requires the rst2man utility:
>> 
>>$ ./scripts/bpf_helpers_doc.py \
>>--filename include/uapi/linux/bpf.h > /tmp/bpf-helpers.rst
>>$ rst2man /tmp/bpf-helpers.rst > /tmp/bpf-helpers.7
>>$ man /tmp/bpf-helpers.7
>> 
>> The objective is to keep all documentation related to the helpers in a
>> single place,

Do we really need another kernel-doc parser?

  ./scripts/kernel-doc include/uapi/linux/bpf.h

should already do the job (producing .rst). For more infos, take a look at

  https://www.kernel.org/doc/html/latest/doc-guide/index.html

-- Markus --

PS: sorry for re-post, first post was HTML which is not accepted by ML :o
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC bpf-next] bpf: document eBPF helpers and add a script to generate man page

[Daniel Borkmann]

On 04/09/2018 11:21 AM, Markus Heiser wrote:
[...]
> Do we really need another kernel-doc parser?
> 
>   ./scripts/kernel-doc include/uapi/linux/bpf.h
> 
> should already do the job (producing .rst). For more infos, take a look at

This has absolutely zero to do with kernel-doc, but rather producing
a description of BPF helper function that are later assembled into an
actual man-page that BPF program developers (user space) can use.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC bpf-next] bpf: document eBPF helpers and add a script to generate man page

[Daniel Borkmann]

On 04/06/2018 01:11 PM, Quentin Monnet wrote:
> eBPF helper functions can be called from within eBPF programs to perform
> a variety of tasks that would be otherwise hard or impossible to do with
> eBPF itself. There is a growing number of such helper functions in the
> kernel, but documentation is scarce. The main user space header file
> does contain a short commented description of most helpers, but it is
> somewhat outdated and not complete. It is more a "cheat sheet" than a
> real documentation accessible to new eBPF developers.
> 
> This commit attempts to improve the situation by replacing the existing
> overview for the helpers with a more developed description. Furthermore,
> a Python script is added to generate a manual page for eBPF helpers. The
> workflow is the following, and requires the rst2man utility:
> 
> $ ./scripts/bpf_helpers_doc.py \
> --filename include/uapi/linux/bpf.h > /tmp/bpf-helpers.rst
> $ rst2man /tmp/bpf-helpers.rst > /tmp/bpf-helpers.7
> $ man /tmp/bpf-helpers.7
> 
> The objective is to keep all documentation related to the helpers in a
> single place, and to be able to generate from here a manual page that
> could be packaged in the man-pages repository and shipped with most
> distributions [1].
> 
> Additionally, parsing the prototypes of the helper functions could
> hopefully be reused, with a different Printer object, to generate
> header files needed in some eBPF-related projects.
> 
> Regarding the description of each helper, it comprises several items:
> 
> - The function prototype.
> - A description of the function and of its arguments (except for a
>   couple of cases, when there are no arguments and the return value
>   makes the function usage really obvious).
> - A description of return values (if not void).
> - A listing of eBPF program types (if relevant, map types) compatible
>   with the helper.
> - Information about the helper being restricted to GPL programs, or not.
> - The kernel version in which the helper was introduced.
> - The commit that introduced the helper (this is mostly to have it in
>   the source of the man page, as it can be used to track changes and
>   update the page).
> 
> For several helpers, descriptions are inspired (at times, nearly copied)
> from the commit logs introducing them in the kernel--Many thanks to
> their respective authors! They were completed as much as possible, the
> objective being to have something easily accessible even for people just
> starting with eBPF. There is probably a bit more work to do in this
> direction for some helpers.
> 
> Some RST formatting is used in the descriptions (not in function
> prototypes, to keep them readable, but the Python script provided in
> order to generate the RST for the manual page does add formatting to
> prototypes, to produce something pretty) to get "bold" and "italics" in
> manual pages. Hopefully, the descriptions in bpf.h file remains
> perfectly readable. Note that the few trailing white spaces are
> intentional, removing them would break paragraphs for rst2man.
> 
> The descriptions should ideally be updated each time someone adds a new
> helper, or updates the behaviour (compatibility extended to new program
> types, new socket option supported...) or the interface (new flags
> available, ...) of existing ones.
> 
> [1] I have not contacted people from the man-pages project prior to
> sending this RFC, so I can offer no guaranty at this time that they
> would accept to take the generated man page.
> 
> Cc: linux-doc@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Quentin Monnet 

Great work, thanks a lot for doing this!

[...]
> + * int bpf_probe_read(void *dst, u32 size, const void *src)
> + *   Description
> + *   For tracing programs, safely attempt to read *size* bytes from
> + *   address *src* and store the data in *dst*.
> + *   Return
> + *   0 on success, or a negative error in case of failure.
> + *   For
> + *   *Tracing programs*.
> + *   GPL only
> + *   Yes
> + *   Since
> + *   Linux 4.1
> + *
> + * .. commit 2541517c32be
>   *
>   * u64 bpf_ktime_get_ns(void)
> - * Return: current ktime
> - *
> - * int bpf_trace_printk(const char *fmt, int fmt_size, ...)
> - * Return: length of buffer written or negative error
> + *   Description
> + *   Return the time elapsed since system boot, in nanoseconds.
> + *   Return
> + *   Current *ktime*.
> + *   For
> + *   All program types, except
> + *   **BPF_PROG_TYPE_CGROUP_DEVICE**.

I think we should probably always just list the actual program types instead,
since when new types get added to the kernel not supporting bpf_ktime_get_ns()
helper in this example, the above statement would be misleading (potentially
more misleading than the other way around when it's not yet mentioned to be
supported).

> + *   GPL only
> + *   Yes
> + *   Since

Re: [PATCH v2 9/9] perf probe: Support SDT markers having reference counter (semaphore)

[Ravi Bangoria]

Hi Masami,

On 04/09/2018 12:58 PM, Masami Hiramatsu wrote:
> Hi Ravi,
>
> On Wed,  4 Apr 2018 14:01:10 +0530
> Ravi Bangoria  wrote:
>
>> @@ -2054,15 +2060,21 @@ char *synthesize_probe_trace_command(struct 
>> probe_trace_event *tev)
>>  }
>>  
>>  /* Use the tp->address for uprobes */
>> -if (tev->uprobes)
>> +if (tev->uprobes) {
>>  err = strbuf_addf(, "%s:0x%lx", tp->module, tp->address);
>> -else if (!strncmp(tp->symbol, "0x", 2))
>> +if (uprobe_ref_ctr_is_supported() &&
>> +tp->ref_ctr_offset &&
>> +err >= 0)
>> +err = strbuf_addf(, "(0x%lx)", tp->ref_ctr_offset);
> If the kernel doesn't support uprobe_ref_ctr but the event requires
> to increment uprobe_ref_ctr, I think we should (at least) warn user here.

pr_debug("A semaphore is associated with %s:%s and seems your kernel doesn't 
support it.\n"
 tev->group, tev->event);

Looks good?

>> @@ -776,14 +784,21 @@ static char *synthesize_sdt_probe_command(struct 
>> sdt_note *note,
>>  {
>>  struct strbuf buf;
>>  char *ret = NULL, **args;
>> -int i, args_count;
>> +int i, args_count, err;
>> +unsigned long long ref_ctr_offset;
>>  
>>  if (strbuf_init(, 32) < 0)
>>  return NULL;
>>  
>> -if (strbuf_addf(, "p:%s/%s %s:0x%llx",
>> -sdtgrp, note->name, pathname,
>> -sdt_note__get_addr(note)) < 0)
>> +err = strbuf_addf(, "p:%s/%s %s:0x%llx",
>> +sdtgrp, note->name, pathname,
>> +sdt_note__get_addr(note));
>> +
>> +ref_ctr_offset = sdt_note__get_ref_ctr_offset(note);
>> +if (uprobe_ref_ctr_is_supported() && ref_ctr_offset && err >= 0)
>> +err = strbuf_addf(, "(0x%llx)", ref_ctr_offset);
> We don't have to care about uprobe_ref_ctr support here, because
> this information will be just cached, not directly written to
> uprobe_events.

Sure, will remove the check.

Thanks for the review :).
Ravi

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 9/9] perf probe: Support SDT markers having reference counter (semaphore)

[Masami Hiramatsu]

Hi Ravi,

On Wed,  4 Apr 2018 14:01:10 +0530
Ravi Bangoria  wrote:

> With this, perf buildid-cache will save SDT markers with reference
> counter in probe cache. Perf probe will be able to probe markers
> having reference counter. Ex,
> 
>   # readelf -n /tmp/tick | grep -A1 loop2
> Name: loop2
> ... Semaphore: 0x10020036
> 
>   # ./perf buildid-cache --add /tmp/tick
>   # ./perf probe sdt_tick:loop2
>   # ./perf stat -e sdt_tick:loop2 /tmp/tick
> hi: 0
> hi: 1
> hi: 2
> ^C
>  Performance counter stats for '/tmp/tick':
>  3  sdt_tick:loop2
>2.561851452 seconds time elapsed
> 
> Signed-off-by: Ravi Bangoria 
> ---
>  tools/perf/util/probe-event.c | 18 ++---
>  tools/perf/util/probe-event.h |  1 +
>  tools/perf/util/probe-file.c  | 34 ++--
>  tools/perf/util/probe-file.h  |  1 +
>  tools/perf/util/symbol-elf.c  | 46 
> ---
>  tools/perf/util/symbol.h  |  7 +++
>  6 files changed, 86 insertions(+), 21 deletions(-)
> 
> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> index e1dbc98..b3a1330 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -1832,6 +1832,12 @@ int parse_probe_trace_command(const char *cmd, struct 
> probe_trace_event *tev)
>   tp->offset = strtoul(fmt2_str, NULL, 10);
>   }
>  
> + if (tev->uprobes) {
> + fmt2_str = strchr(p, '(');
> + if (fmt2_str)
> + tp->ref_ctr_offset = strtoul(fmt2_str + 1, NULL, 0);
> + }
> +
>   tev->nargs = argc - 2;
>   tev->args = zalloc(sizeof(struct probe_trace_arg) * tev->nargs);
>   if (tev->args == NULL) {
> @@ -2054,15 +2060,21 @@ char *synthesize_probe_trace_command(struct 
> probe_trace_event *tev)
>   }
>  
>   /* Use the tp->address for uprobes */
> - if (tev->uprobes)
> + if (tev->uprobes) {
>   err = strbuf_addf(, "%s:0x%lx", tp->module, tp->address);
> - else if (!strncmp(tp->symbol, "0x", 2))
> + if (uprobe_ref_ctr_is_supported() &&
> + tp->ref_ctr_offset &&
> + err >= 0)
> + err = strbuf_addf(, "(0x%lx)", tp->ref_ctr_offset);

If the kernel doesn't support uprobe_ref_ctr but the event requires
to increment uprobe_ref_ctr, I think we should (at least) warn user here.

> + } else if (!strncmp(tp->symbol, "0x", 2)) {
>   /* Absolute address. See try_to_find_absolute_address() */
>   err = strbuf_addf(, "%s%s0x%lx", tp->module ?: "",
> tp->module ? ":" : "", tp->address);
> - else
> + } else {
>   err = strbuf_addf(, "%s%s%s+%lu", tp->module ?: "",
>   tp->module ? ":" : "", tp->symbol, tp->offset);
> + }
> +
>   if (err)
>   goto error;
>  
> diff --git a/tools/perf/util/probe-event.h b/tools/perf/util/probe-event.h
> index 45b14f0..15a98c3 100644
> --- a/tools/perf/util/probe-event.h
> +++ b/tools/perf/util/probe-event.h
> @@ -27,6 +27,7 @@ struct probe_trace_point {
>   char*symbol;/* Base symbol */
>   char*module;/* Module name */
>   unsigned long   offset; /* Offset from symbol */
> + unsigned long   ref_ctr_offset; /* SDT reference counter offset */
>   unsigned long   address;/* Actual address of the trace point */
>   boolretprobe;   /* Return probe flag */
>  };
> diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
> index 4ae1123..ca0e524 100644
> --- a/tools/perf/util/probe-file.c
> +++ b/tools/perf/util/probe-file.c
> @@ -697,8 +697,16 @@ int probe_cache__add_entry(struct probe_cache *pcache,
>  #ifdef HAVE_GELF_GETNOTE_SUPPORT
>  static unsigned long long sdt_note__get_addr(struct sdt_note *note)
>  {
> - return note->bit32 ? (unsigned long long)note->addr.a32[0]
> -  : (unsigned long long)note->addr.a64[0];
> + return note->bit32 ?
> + (unsigned long long)note->addr.a32[SDT_NOTE_IDX_LOC] :
> + (unsigned long long)note->addr.a64[SDT_NOTE_IDX_LOC];
> +}
> +
> +static unsigned long long sdt_note__get_ref_ctr_offset(struct sdt_note *note)
> +{
> + return note->bit32 ?
> + (unsigned long long)note->addr.a32[SDT_NOTE_IDX_REFCTR] :
> + (unsigned long long)note->addr.a64[SDT_NOTE_IDX_REFCTR];
>  }
>  
>  static const char * const type_to_suffix[] = {
> @@ -776,14 +784,21 @@ static char *synthesize_sdt_probe_command(struct 
> sdt_note *note,
>  {
>   struct strbuf buf;
>   char *ret = NULL, **args;
> - int i, args_count;
> + int i, args_count, err;
> + unsigned long long ref_ctr_offset;
>  
>   if (strbuf_init(, 32) < 0)
>   return NULL;
>  

Re: [PATCH 1/2] perf: riscv: preliminary RISC-V support

[Alan Kao]

On Thu, Apr 05, 2018 at 09:47:50AM -0700, Palmer Dabbelt wrote:
> On Mon, 26 Mar 2018 00:57:54 PDT (-0700), alan...@andestech.com wrote:
> >This patch provide a basic PMU, riscv_base_pmu, which supports two
> >general hardware event, instructions and cycles.  Furthermore, this
> >PMU serves as a reference implementation to ease the portings in
> >the future.
> >
> >riscv_base_pmu should be able to run on any RISC-V machine that
> >conforms to the Priv-Spec.  Note that the latest qemu model hasn't
> >fully support a proper behavior of Priv-Spec 1.10 yet, but work
> >around should be easy with very small fixes.  Please check
> >https://github.com/riscv/riscv-qemu/pull/115 for future updates.
> >
> >Cc: Nick Hu 
> >Cc: Greentime Hu 
> >Signed-off-by: Alan Kao 
> 
> We should really be able to detect PMU types at runtime (via a device tree
> entry) rather than requiring that a single PMU is built in to the kernel.
> This will require a handful of modifications to how this patch works, which
> I'll try to list below.

> >+menu "PMU type"
> >+depends on PERF_EVENTS
> >+
> >+config RISCV_BASE_PMU
> >+bool "Base Performance Monitoring Unit"
> >+def_bool y
> >+help
> >+  A base PMU that serves as a reference implementation and has limited
> >+  feature of perf.
> >+
> >+endmenu
> >+
> 
> Rather than a menu where a single PMU can be selected, there should be
> options to enable or disable support for each PMU type -- this is just like
> how all our other drivers work.
> 

I see.  Sure.  The descriptions and implementation will be refined in v3.

> >+struct pmu * __weak __init riscv_init_platform_pmu(void)
> >+{
> >+riscv_pmu = _base_pmu;
> >+return riscv_pmu->pmu;
> >+}
> 
> Rather than relying on a weak symbol that gets overridden by other PMU
> types, this should look through the device tree for a compatible PMU (in the
> case of just the base PMU it could be any RISC-V hart) and install a PMU
> handler for it.  There'd probably be some sort of priority scheme here, like
> there are for other driver subsystems, where we'd pick the best PMU driver
> that's compatible with the PMUs on every hart.
> 
> >+
> >+int __init init_hw_perf_events(void)
> >+{
> >+struct pmu *pmu = riscv_init_platform_pmu();
> >+
> >+perf_irq = NULL;
> >+perf_pmu_register(pmu, "cpu", PERF_TYPE_RAW);
> >+return 0;
> >+}
> >+arch_initcall(init_hw_perf_events);
> 
> Since we only have a single PMU type right now this isn't critical to handle
> right away, but we will have to refactor this before adding another PMU.

I see.  My rough plan is to do the device tree parsing here, and if no specific
PMU string is found then just register the base PMU proposed in this patch.
How about this idea?

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html