Re: [PATCH] capabilities: add capability cgroup controller

[Andy Lutomirski]

On Thu, Jun 23, 2016 at 6:14 PM, Topi Miettinen  wrote:
> On 06/23/16 23:46, Andrew Morton wrote:
>> On Thu, 23 Jun 2016 18:07:10 +0300 Topi Miettinen  wrote:
>>
>>> There are many basic ways to control processes, including capabilities,
>>> cgroups and resource limits. However, there are far fewer ways to find
>>> out useful values for the limits, except blind trial and error.
>>>
>>> Currently, there is no way to know which capabilities are actually used.
>>> Even the source code is only implicit, in-depth knowledge of each
>>> capability must be used when analyzing a program to judge which
>>> capabilities the program will exercise.
>>>
>>> Add a new cgroup controller for monitoring of capabilities
>>> in the cgroup.
>>
>> I'm having trouble understanding how valuable this feature is to our
>> users, and that's a rather important thing!
>>
>> Perhaps it would help if you were to explain your motivation:
>> particular use cases which benefited from this, for example.
>>
>
> It's easy to control with for example systemd or many other tools, which
> capabilities a service should have at the start. But how should a system
> administrator, application developer or distro maintaner ever determine
> a suitable value for this? Currently the only way seems to be to become
> an expert on capabilities, make an educated guess how the set of
> programs in question happen to work in this context and especially how
> they could exercise the capabilites in all possible use cases. Even
> then, the outcome is to just try something to see if that happens to
> work. Reading the source code (if available) does not help very much,
> because the use of capabilities is anything but explicit there.
>
> This is way too difficult, there must be some easier way. The
> information which capabilities actually were used in a trial run gives a
> much better starting point. The users can just use the list of used
> capabilities with configuring the service or when developing or
> maintaining the application. Of course, even that could still fail
> eventually, but then you simply copy the new value of used capabilities
> to the configuration, whereas currently you have to reconsider your
> understanding of the capabilities and the programs in light of the
> failure, which by itself might give no new useful information.
>
> One way to solve this for good would be to make the use of capabilities
> explicit in the ABI. For example, there could be a system call
> dac_override() which would be the only possible way ever to use the
> capability CAP_DAC_OVERRIDE and so forth. Then reading source code,
> tracing and many other approaches would be useful. But the OS with that
> kind of ABI (not Linux) would not be Unix-like at all for any
> (potentially) capability using programs, like find(1) or cat(1).

The problem is that most of the capabilities are so powerful on their
own that limiting services to just a few may be all but useless.

--Andy
--
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] arm64:swiotlb:Enable only when Input size through command line

[Jisheng Zhang]

Dear Konrad,

On Thu, 23 Jun 2016 12:06:10 -0400 Konrad Rzeszutek Wilk wrote:

> On June 23, 2016 10:30:34 AM EDT, Catalin Marinas  
> wrote:
> >On Thu, Jun 23, 2016 at 05:43:40PM +0530, Manjeet Pawar wrote:  
> >> From: Rohit Thapliyal 
> >> 
> >> swiotlb default size of 64M is too big as
> >> default value therefore it is made configurable
> >> through command line through swiotlb_size parameter.
> >> swiotlb allocation shall be done only when the
> >> swiotlb size is given through command line.
> >> Otherwise no swiotlb is allocated.  
> >
> >I already queued this patch:
> >
> >http://lkml.kernel.org/g/1465372426-4077-1-git-send-email-jszh...@marvell.com
> >
> >If you have any objections to it, please reply there.  
> 
> 
> I do (sorry about duplicate email, the other got rejected by mailing lists).
> 
> Why not expand the swiotlb= parameter instead of introducing a new one?

Do you mean pass "swiotlb=" for those platforms(most probably, arm64 with less
than 4GB DDR) which don't need swiotlb? I'm afraid this is not convenient, and
users even don't notice swiotlb parameter. From another side, pass "swiotlb=0"
will make the swiotlb reserve 64MB instead, so how can we achieve zero reserved
memory for swiotlb through "swiotlb=" parameter?

PS: my patch didn't introduce new boot parameter.

I'm not sure I got your meaning, so could you please comment my patch
directly?

Thanks,
Jisheng

> 
> Also, why not use the swiotlb by itself? That does the job as well?
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
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 0/2] cgroup: pids: extend pids.events

[Aleksa Sarai]

While reading the patchset by Kenny Yu, I realised that not having a
field for the "recent" number of failed forks means that userspace would
have trouble accurately deciding whether or not it should increase the
limits.

In addition, by having hits_since, we get to maintain the
on-reset-we-log-failures-again semantics that Tejun said he liked.

Aleksa Sarai (2):
  cgroup: pids: show number of failed forks since limit reset
  docs: cgroup/pids: update documentation to include pids.events

 Documentation/cgroup-v1/pids.txt | 18 ++
 kernel/cgroup_pids.c | 31 ++-
 2 files changed, 40 insertions(+), 9 deletions(-)

-- 
2.8.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/2] cgroup: pids: show number of failed forks since limit reset

[Aleksa Sarai]

This allows users to dynamically adjust their limits based on how many
failed forks happened since they last reset their limits, otherwise they
would have to track (in a racy way) how many limit failures there were
since the last limit change manually. In addition, we log the first
failure since the limit was reset (which was the original semantics of
the patchset).

In addition, I clarified the licensing for this file.

Signed-off-by: Aleksa Sarai 
---
 kernel/cgroup_pids.c | 31 ++-
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/kernel/cgroup_pids.c b/kernel/cgroup_pids.c
index 2bd673783f1a..54ec3e4f3b71 100644
--- a/kernel/cgroup_pids.c
+++ b/kernel/cgroup_pids.c
@@ -26,9 +26,10 @@
  *
  * Copyright (C) 2015 Aleksa Sarai 
  *
- * This file is subject to the terms and conditions of version 2 of the GNU
- * General Public License.  See the file COPYING in the main directory of the
- * Linux distribution for more details.
+ * 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 of the License, or (at your option)
+ * any later version.
  */
 
 #include 
@@ -53,8 +54,11 @@ struct pids_cgroup {
/* Handle for "pids.events" */
struct cgroup_file  events_file;
 
-   /* Number of times fork failed because limit was hit. */
-   atomic64_t  events_limit;
+   /* Total number of times fork failed because limit was hit. */
+   atomic64_t  hits_total;
+
+   /* Number of times fork failed since limit was last set. */
+   atomic64_t  hits_since;
 };
 
 static struct pids_cgroup *css_pids(struct cgroup_subsys_state *css)
@@ -78,7 +82,8 @@ pids_css_alloc(struct cgroup_subsys_state *parent)
 
pids->limit = PIDS_MAX;
atomic64_set(>counter, 0);
-   atomic64_set(>events_limit, 0);
+   atomic64_set(>hits_total, 0);
+   atomic64_set(>hits_since, 0);
return >css;
 }
 
@@ -226,8 +231,12 @@ static int pids_can_fork(struct task_struct *task)
pids = css_pids(css);
err = pids_try_charge(pids, 1);
if (err) {
-   /* Only log the first time events_limit is incremented. */
-   if (atomic64_inc_return(>events_limit) == 1) {
+   /*
+* We only log the first time a fork fails after a limit has
+* been set. Resetting the limit will cause us to log again.
+*/
+   atomic64_inc(>hits_total);
+   if (atomic64_inc_return(>hits_since) == 1) {
pr_info("cgroup: fork rejected by pids controller in ");
pr_cont_cgroup_path(task_cgroup(current, pids_cgrp_id));
pr_cont("\n");
@@ -281,6 +290,9 @@ set_limit:
 * critical that any racing fork()s follow the new limit.
 */
pids->limit = limit;
+   /* Reset the since counter and notify userspace. */
+   atomic64_set(>hits_since, 0);
+   cgroup_file_notify(>events_file);
return nbytes;
 }
 
@@ -310,7 +322,8 @@ static int pids_events_show(struct seq_file *sf, void *v)
 {
struct pids_cgroup *pids = css_pids(seq_css(sf));
 
-   seq_printf(sf, "max %lld\n", (s64)atomic64_read(>events_limit));
+   seq_printf(sf, "since\t%lld\n", (s64)atomic64_read(>hits_since));
+   seq_printf(sf, "total\t%lld\n", (s64)atomic64_read(>hits_total));
return 0;
 }
 
-- 
2.8.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 2/2] docs: cgroup/pids: update documentation to include pids.events

[Aleksa Sarai]

So that users know what the interface and meaning of the keyed values
are. In addition, mention that the only time that since=0 is when the
limit was changed.

Signed-off-by: Aleksa Sarai 
---
 Documentation/cgroup-v1/pids.txt | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/cgroup-v1/pids.txt b/Documentation/cgroup-v1/pids.txt
index 1a078b5d281a..a9bb7b964c6f 100644
--- a/Documentation/cgroup-v1/pids.txt
+++ b/Documentation/cgroup-v1/pids.txt
@@ -33,6 +33,11 @@ limit in the hierarchy is followed).
 pids.current tracks all child cgroup hierarchies, so parent/pids.current is a
 superset of parent/child/pids.current.
 
+pids.events shows information about the number of failed forks in a particular
+cgroup, both overall (since the cgroup was created) and recently (since the
+last limit reset). Userspace is notified of each time a process failed to fork
+in a cgroup.
+
 Example
 ---
 
@@ -83,3 +88,16 @@ sh: fork: Resource temporary unavailable
 # /bin/echo "We can't even spawn a single process now."
 sh: fork: Resource temporary unavailable
 #
+
+We can also see how many times a particular cgroup has failed to fork. For an
+example cgroup:
+
+# cat /sys/fs/cgroup/pids/some_cgroup/pids.events
+since  1
+total  12
+#
+
+This cgroup has had 12 associated process fail to fork throughout its lifetime,
+and has had 1 process fail to fork since the limit was last set. On setting the
+limit, the since counter becomes 0 and userspace is notified (this is the only
+case where since will be 0 and userspace will get a notification).
-- 
2.8.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] capabilities: add capability cgroup controller

[Topi Miettinen]

On 06/23/16 23:46, Andrew Morton wrote:
> On Thu, 23 Jun 2016 18:07:10 +0300 Topi Miettinen  wrote:
> 
>> There are many basic ways to control processes, including capabilities,
>> cgroups and resource limits. However, there are far fewer ways to find
>> out useful values for the limits, except blind trial and error.
>>
>> Currently, there is no way to know which capabilities are actually used.
>> Even the source code is only implicit, in-depth knowledge of each
>> capability must be used when analyzing a program to judge which
>> capabilities the program will exercise.
>>
>> Add a new cgroup controller for monitoring of capabilities
>> in the cgroup.
> 
> I'm having trouble understanding how valuable this feature is to our
> users, and that's a rather important thing!
> 
> Perhaps it would help if you were to explain your motivation:
> particular use cases which benefited from this, for example.
> 

It's easy to control with for example systemd or many other tools, which
capabilities a service should have at the start. But how should a system
administrator, application developer or distro maintaner ever determine
a suitable value for this? Currently the only way seems to be to become
an expert on capabilities, make an educated guess how the set of
programs in question happen to work in this context and especially how
they could exercise the capabilites in all possible use cases. Even
then, the outcome is to just try something to see if that happens to
work. Reading the source code (if available) does not help very much,
because the use of capabilities is anything but explicit there.

This is way too difficult, there must be some easier way. The
information which capabilities actually were used in a trial run gives a
much better starting point. The users can just use the list of used
capabilities with configuring the service or when developing or
maintaining the application. Of course, even that could still fail
eventually, but then you simply copy the new value of used capabilities
to the configuration, whereas currently you have to reconsider your
understanding of the capabilities and the programs in light of the
failure, which by itself might give no new useful information.

One way to solve this for good would be to make the use of capabilities
explicit in the ABI. For example, there could be a system call
dac_override() which would be the only possible way ever to use the
capability CAP_DAC_OVERRIDE and so forth. Then reading source code,
tracing and many other approaches would be useful. But the OS with that
kind of ABI (not Linux) would not be Unix-like at all for any
(potentially) capability using programs, like find(1) or cat(1).

-Topi

--
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: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Jason Cooper]

Hi Ard,

On Thu, Jun 23, 2016 at 10:05:53PM +0200, Ard Biesheuvel wrote:
> On 23 June 2016 at 21:58, Kees Cook  wrote:
> > On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper  wrote:
> >> On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote:
> >>> On Wed, Jun 22, 2016 at 8:59 AM, Thomas Garnier  
> >>> wrote:
> >>> > On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper  
> >>> > wrote:
> >>> >> Hey Kees,
> >>> >>
> >>> >> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote:
> >>> >>> Notable problems that needed solving:
> >>> >> ...
> >>> >>>  - Reasonable entropy is needed early at boot before 
> >>> >>> get_random_bytes()
> >>> >>>is available.
> >>> >>
> >>> >> This series is targetting x86, which typically has RDRAND/RDSEED
> >>> >> instructions.  Are you referring to other arches?  Older x86?  Also,
> >>> >> isn't this the same requirement for base address KASLR?
> >>> >>
> >>> >> Don't get me wrong, I want more diverse entropy sources available
> >>> >> earlier in the boot process as well. :-)  I'm just wondering what's
> >>> >> different about this series vs base address KASLR wrt early entropy
> >>> >> sources.
> >>> >>
> >>> >
> >>> > I think Kees was referring to the refactor I did to get the similar
> >>> > entropy generation than KASLR module randomization. Our approach was
> >>> > to provide best entropy possible even if you have an older processor
> >>> > or under virtualization without support for these instructions.
> >>> > Unfortunately common on companies with a large number of older
> >>> > machines.
> >>>
> >>> Right, the memory offset KASLR uses the same routines as the kernel
> >>> base KASLR. The issue is with older x86 systems, which continue to be
> >>> very common.
> >>
> >> We have the same issue in embedded. :-(  Compounded by the fact that
> >> there is no rand instruction (at least not on ARM).  So, even if there's
> >> a HW-RNG, you can't access it until the driver is loaded.
> >>
> >> This is compounded by the fact that most systems deployed today have
> >> bootloaders a) without hw-rng drivers, b) without dtb editing, and c)
> >> without dtb support at all.
> >>
> >> My current thinking is to add a devicetree property
> >> "userspace,random-seed" .  This way, existing, deployed
> >> boards can append a dtb to a modern kernel with the property set.
> >> The factory bootloader then only needs to amend its boot scripts to read
> >> random-seed from the fs to the given address.
> >
> > The arm64 KASLR implementation has defined a way for boot loaders to
> > pass in an seed similar to this. It might be nice to have a fall-back
> > to a DT entry, though, then the bootloaders don't need to changed.
> >
> > Ard might have some thoughts on why DT wasn't used for KASLR (I assume
> > the early parsing overhead, but I don't remember the discussion any
> > more).
> >
> 
> On arm64, only DT is used for KASLR (even when booting via ACPI). My
> first draft used register x1, but this turned out to be too much of a
> hassle, since parsing the DT is also necessary to discover whether
> there is a 'nokaslr' argument on the kernel command line. So the
> current implementation only supports a single method, which is the
> /chosen/kaslr-seed uint64 property.

Ok, just to clarify (after a short offline chat), my goal is to set a
userspace,random-seed  property in the device tree once.
The bootloader scripts would also only need to be altered once.

Then, at each boot, the bootloader reads the entirety of
/var/lib/misc/random-seed (512 bytes) into the configured address.
random-seed could be in /boot, or on a flash partition.

The decompressor would consume a small portion of that seed for kaslr
and such.  After that, the rest would be consumed by random.c to
initialize the entropy pools.

thx,

Jason.
--
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] capabilities: add capability cgroup controller

[Topi Miettinen]

On 06/23/16 21:38, Tejun Heo wrote:
> Hello,
> 
> On Thu, Jun 23, 2016 at 06:07:10PM +0300, Topi Miettinen wrote:
>> There are many basic ways to control processes, including capabilities,
>> cgroups and resource limits. However, there are far fewer ways to find
>> out useful values for the limits, except blind trial and error.
>>
>> Currently, there is no way to know which capabilities are actually used.
>> Even the source code is only implicit, in-depth knowledge of each
>> capability must be used when analyzing a program to judge which
>> capabilities the program will exercise.
>>
>> Add a new cgroup controller for monitoring of capabilities
>> in the cgroup.
>>
>> Test case demonstrating basic capability monitoring and how the
>> capabilities are combined at next level (boot to rdshell):
> 
> This doesn't have anything to do with resource control and I don't
> think it's a good idea to add arbitrary monitoring mechanisms to
> cgroup just because it's easy to add interface there.  Given that
> capabilities are inherited and modified through the process hierarchy,
> shouldn't this be part of that?

With per process tracking, it's easy to miss if a short-lived process
exercised capabilities. Especially with ambient capabilities, the parent
process could be a shell script which might not use capabilities at all,
but its children do the heavy lifting.

Per process tracking (like in the version I sent earlier) could still be
added on top of this to complement cgroup level tracking, but I think
cgroup approach is more flexible as it can cover anything from a single
task to a collection of processes.

-Topi

> 
> 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

Re: [PATCH] capabilities: add capability cgroup controller

[Andrew Morton]

On Thu, 23 Jun 2016 18:07:10 +0300 Topi Miettinen  wrote:

> There are many basic ways to control processes, including capabilities,
> cgroups and resource limits. However, there are far fewer ways to find
> out useful values for the limits, except blind trial and error.
> 
> Currently, there is no way to know which capabilities are actually used.
> Even the source code is only implicit, in-depth knowledge of each
> capability must be used when analyzing a program to judge which
> capabilities the program will exercise.
> 
> Add a new cgroup controller for monitoring of capabilities
> in the cgroup.

I'm having trouble understanding how valuable this feature is to our
users, and that's a rather important thing!

Perhaps it would help if you were to explain your motivation:
particular use cases which benefited from this, for example.

--
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 v8 4/4] Input: synaptics-rmi4 - add SMBus support

[Dmitry Torokhov]

Hi Benjamin,

On Thu, Jun 09, 2016 at 04:53:50PM +0200, Benjamin Tissoires wrote:
> +
> +struct mapping_table_entry {
> + u16 rmiaddr;

Should be __le16 rmiaddr, otherwise:

  CHECK   drivers/input/rmi4/rmi_smbus.c
drivers/input/rmi4/rmi_smbus.c:116:33: warning: incorrect type in assignment 
(different base types)
drivers/input/rmi4/rmi_smbus.c:116:33:expected unsigned short [unsigned] 
[usertype] rmiaddr
drivers/input/rmi4/rmi_smbus.c:116:33:got restricted __le16 [usertype] 


> +
> +static struct i2c_driver rmi_smb_driver;
> +

I do not think this forward declaration is needed.

> +
> +#ifdef CONFIG_PM_SLEEP
> +static int rmi_smb_suspend(struct device *dev)

__maybe_unused instead of #ifdef.

> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
> + int ret;
> +
> + ret = rmi_driver_suspend(rmi_smb->xport.rmi_dev);
> + if (ret)
> + dev_warn(dev, "Failed to suspend device: %d\n", ret);
> +
> + return ret;
> +}
> +#endif
> +
> +#ifdef CONFIG_PM
> +static int rmi_smb_runtime_suspend(struct device *dev)

Same here?

> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
> + int ret;
> +
> + ret = rmi_driver_suspend(rmi_smb->xport.rmi_dev);
> + if (ret)
> + dev_warn(dev, "Failed to suspend device: %d\n", ret);
> +
> + return 0;
> +}
> +
> +static int rmi_smb_runtime_resume(struct device *dev)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
> + int ret;
> +
> + ret = rmi_driver_resume(rmi_smb->xport.rmi_dev);
> + if (ret)
> + dev_warn(dev, "Failed to resume device: %d\n", ret);
> +
> + return 0;
> +}
> +#endif
> +
> +static const struct dev_pm_ops rmi_smb_pm = {
> + SET_SYSTEM_SLEEP_PM_OPS(rmi_smb_suspend, NULL)
> + SET_RUNTIME_PM_OPS(rmi_smb_runtime_suspend, rmi_smb_runtime_resume,
> +NULL)
> +};
> +
> +static int rmi_smb_resume(struct device *dev)
> +{
> + struct i2c_client *client = container_of(dev, struct i2c_client, dev);
> + struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
> + struct rmi_device *rmi_dev = rmi_smb->xport.rmi_dev;
> + int ret;
> +
> + rmi_smb_reset(_smb->xport, 0);
> +
> + rmi_reset(rmi_dev);
> +
> + ret = rmi_driver_resume(rmi_smb->xport.rmi_dev);
> + if (ret)
> + dev_warn(dev, "Failed to resume device: %d\n", ret);
> +
> + return 0;
> +}
> +
> +static const struct i2c_device_id rmi_id[] = {
> + { "rmi4_smbus", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, rmi_id);
> +
> +static struct i2c_driver rmi_smb_driver = {
> + .driver = {
> + .owner  = THIS_MODULE,
> + .name   = "rmi4_smbus",
> + .pm = _smb_pm,
> + .resume = rmi_smb_resume,

Why rmi_smb_resume is not part of rmi_smb_pm?

Thanks.

-- 
Dmitry
--
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 v8 3/4] i2c: i801: add support of Host Notify

[Dmitry Torokhov]

On Thu, Jun 23, 2016 at 11:46:55PM +0200, Wolfram Sang wrote:
> On Thu, Jun 23, 2016 at 01:55:52PM -0700, Dmitry Torokhov wrote:
> > On Thu, Jun 16, 2016 at 08:09:42AM +0200, Wolfram Sang wrote:
> > > > > - removed the .resume hook as upstream changed suspend/resume hooks 
> > > > > and there
> > > > >   is no need in the end to re-enable host notify on resume (tested on 
> > > > > Lenovo
> > > > >   t440 and t450).
> > > > 
> > > > Actually, this hook seemed to be required on the Lenovo T440 (Haswell)
> > > > but not on the T450 (Broadwell) laptop I have now here.
> > > > 
> > > > Wolfram, I can resend the whole series or a follow-up patch to re-enable
> > > > after resume Host Notify. How do you prefer I deal with that?
> > > 
> > > That depends a little how we want to handle patch 4. I am going to apply
> > > patches 1+2 today to my tree. Then you can just resend patch 3 which I
> > > hope will get some review soon, but I will pick it up for 4.8 later
> > > nonetheless. If it is not causing too much dependency hassle, I'd prefer
> > > that patch 4 goes via Dmitry's input tree.
> > 
> > Any chance I could get a stable branch with these 2 patches based on 4.6
> > so that I can pull it and merge the #4? This way we do not need to wait
> > for 2 releases to merge everything...
> 
> Sure.
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/host-notify

Thanks!

-- 
Dmitry
--
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 v8 3/4] i2c: i801: add support of Host Notify

[Wolfram Sang]

On Thu, Jun 23, 2016 at 01:55:52PM -0700, Dmitry Torokhov wrote:
> On Thu, Jun 16, 2016 at 08:09:42AM +0200, Wolfram Sang wrote:
> > > > - removed the .resume hook as upstream changed suspend/resume hooks and 
> > > > there
> > > >   is no need in the end to re-enable host notify on resume (tested on 
> > > > Lenovo
> > > >   t440 and t450).
> > > 
> > > Actually, this hook seemed to be required on the Lenovo T440 (Haswell)
> > > but not on the T450 (Broadwell) laptop I have now here.
> > > 
> > > Wolfram, I can resend the whole series or a follow-up patch to re-enable
> > > after resume Host Notify. How do you prefer I deal with that?
> > 
> > That depends a little how we want to handle patch 4. I am going to apply
> > patches 1+2 today to my tree. Then you can just resend patch 3 which I
> > hope will get some review soon, but I will pick it up for 4.8 later
> > nonetheless. If it is not causing too much dependency hassle, I'd prefer
> > that patch 4 goes via Dmitry's input tree.
> 
> Any chance I could get a stable branch with these 2 patches based on 4.6
> so that I can pull it and merge the #4? This way we do not need to wait
> for 2 releases to merge everything...

Sure.

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/host-notify

Thanks,

   Wolfram



signature.asc
Description: PGP signature

Re: [PATCH] capabilities: add capability cgroup controller

[Tejun Heo]

Hello,

On Thu, Jun 23, 2016 at 06:07:10PM +0300, Topi Miettinen wrote:
> There are many basic ways to control processes, including capabilities,
> cgroups and resource limits. However, there are far fewer ways to find
> out useful values for the limits, except blind trial and error.
> 
> Currently, there is no way to know which capabilities are actually used.
> Even the source code is only implicit, in-depth knowledge of each
> capability must be used when analyzing a program to judge which
> capabilities the program will exercise.
> 
> Add a new cgroup controller for monitoring of capabilities
> in the cgroup.
> 
> Test case demonstrating basic capability monitoring and how the
> capabilities are combined at next level (boot to rdshell):

This doesn't have anything to do with resource control and I don't
think it's a good idea to add arbitrary monitoring mechanisms to
cgroup just because it's easy to add interface there.  Given that
capabilities are inherited and modified through the process hierarchy,
shouldn't this be part of that?

Thanks.

-- 
tejun
--
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] capabilities: add capability cgroup controller

[Kees Cook]

On Thu, Jun 23, 2016 at 8:07 AM, Topi Miettinen  wrote:
> There are many basic ways to control processes, including capabilities,
> cgroups and resource limits. However, there are far fewer ways to find
> out useful values for the limits, except blind trial and error.
>
> Currently, there is no way to know which capabilities are actually used.
> Even the source code is only implicit, in-depth knowledge of each
> capability must be used when analyzing a program to judge which
> capabilities the program will exercise.
>
> Add a new cgroup controller for monitoring of capabilities
> in the cgroup.
>
> Test case demonstrating basic capability monitoring and how the
> capabilities are combined at next level (boot to rdshell):
>
> (initramfs) cd /sys/fs
> (initramfs) mount -t cgroup2 cgroup cgroup
> (initramfs) cd cgroup
> (initramfs) echo +capability > cgroup.subtree_control
> (initramfs) mkdir test; cd test
> (initramfs) echo +capability > cgroup.subtree_control
> (initramfs) ls
> capability.used cgroup.events   cgroup.subtree_control
> cgroup.controllers  cgroup.procs
> (initramfs) mkdir first second
> (initramfs) sh
>
> BusyBox v1.22.1 (Debian 1:1.22.0-19) built-in shell (ash)
> Enter 'help' for a list of built-in commands.
>
> (initramfs) cd first
> (initramfs) echo $$ >cgroup.procs
> (initramfs) cat capability.used
>  # nothing so far
> (initramfs) mknod /dev/z_$$ c 1 2
> (initramfs) cat capability.used
> 0800 # CAP_MKNOD
> (initramfs) cat ../capability.used
> 0800 # also seen at next higher level
> (initramfs) exit
> (initramfs) sh
>
> BusyBox v1.22.1 (Debian 1:1.22.0-19) built-in shell (ash)
> Enter 'help' for a list of built-in commands.
>
> (initramfs) cd second
> (initramfs) echo $$ >cgroup.procs
> (initramfs) cat capability.used
>  # nothing so far
> (initramfs) chown 1234 /dev/z_*
> (initramfs) cat capability.used
> 0001 # CAP_CHROOT

nitpick: this is CAP_CHOWN, not CAP_CHROOT

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security
--
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 v8 3/4] i2c: i801: add support of Host Notify

[Dmitry Torokhov]

On Thu, Jun 16, 2016 at 08:09:42AM +0200, Wolfram Sang wrote:
> > > - removed the .resume hook as upstream changed suspend/resume hooks and 
> > > there
> > >   is no need in the end to re-enable host notify on resume (tested on 
> > > Lenovo
> > >   t440 and t450).
> > 
> > Actually, this hook seemed to be required on the Lenovo T440 (Haswell)
> > but not on the T450 (Broadwell) laptop I have now here.
> > 
> > Wolfram, I can resend the whole series or a follow-up patch to re-enable
> > after resume Host Notify. How do you prefer I deal with that?
> 
> That depends a little how we want to handle patch 4. I am going to apply
> patches 1+2 today to my tree. Then you can just resend patch 3 which I
> hope will get some review soon, but I will pick it up for 4.8 later
> nonetheless. If it is not causing too much dependency hassle, I'd prefer
> that patch 4 goes via Dmitry's input tree.

Any chance I could get a stable branch with these 2 patches based on 4.6
so that I can pull it and merge the #4? This way we do not need to wait
for 2 releases to merge everything...

Thanks.

-- 
Dmitry
--
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: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Jason Cooper]

Hey Sandy,

On Thu, Jun 23, 2016 at 03:45:54PM -0400, Sandy Harris wrote:
> Jason Cooper  wrote:
> 
> > Modern systems that receive a seed from the bootloader via the
> > random-seed property (typically from the hw-rng) can mix both sources
> > for increased resilience.
> >
> > Unfortunately, I'm not very familiar with the internals of x86
> > bootstrapping.  Could GRUB be scripted to do a similar task?  How would
> > the address and size of the seed be passed to the kernel?  command line?
> 
> One suggestion is at:
> http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image

Yes, this is very similar to the latent_entropy series that I think Kees
just merged.  Well, at a high level, it is.  'store a seed in the
kernel, use it at reboot'.

These approaches are good in that they provide yet another source of
entropy to the kernel.  However, both suffer from the kernel binary
being very static in time and across distro installs.  Particularly with
embedded systems.  It almost becomes a long term secret.  Which, the
longer it lives, the less chance there is of it being secret.

I'm not really comfortable with what John suggests, here:

"""
Next step: It should be straightforward to write a tool that efficiently
updates the stored seed within the boot image. Updating MUST occur
during provisioning, before the device gets booted for the first time
... and also from time to time thereafter. Updating the boot image isn’t
be quite as simple as dd of=/var/lib/urandom/random-seed but neither is
it rocket surgery. The cost is utterly negligible compared to the cost
of a security breach, which is the relevant comparison.
"""

Editing the installed kernel binary to add the seed is exposing the
system to unnecessary risk of bricking the system (e.g. powerfail
 halfway through) [0].  Yes, this can be mitigated by following a similar
process to kernel updates, but why?  The bootloader already knows how to
read a file into RAM.  We just need to put it in the right place and
tell it to do so.  And userspace already writes a new random-seed during
system init and clean shutdown.

We just need to connect the dots so deployed systems can use the seed
earlier without having to hack the kernel or update the bootloader.
Which, while possible, a lot of folks are skittish to do.

thx,

Jason.

[0] I imagine it also borks code-signing...
--
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: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Jason Cooper]

On Thu, Jun 23, 2016 at 12:59:07PM -0700, Kees Cook wrote:
> On Thu, Jun 23, 2016 at 12:45 PM, Sandy Harris  wrote:
> > Jason Cooper  wrote:
> >
> >> Modern systems that receive a seed from the bootloader via the
> >> random-seed property (typically from the hw-rng) can mix both sources
> >> for increased resilience.
> >>
> >> Unfortunately, I'm not very familiar with the internals of x86
> >> bootstrapping.  Could GRUB be scripted to do a similar task?  How would
> >> the address and size of the seed be passed to the kernel?  command line?
> >
> > One suggestion is at:
> > http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image
> 
> Interesting! This might pose a problem for signed images, though.
> (Actually, for signed arm kernels is the DT signed too? If so, it
> would be a similar problem.)

That's the reason for userspace,random-seed = .  Once
set, the dtb never has to change.  The bootloader loads the file to the
same address at each boot.  Userspace is responsible, as it is already,
for updating the random-seed file while up.

thx,

Jason.
--
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: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Ard Biesheuvel]

On 23 June 2016 at 21:58, Kees Cook  wrote:
> On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper  wrote:
>> Hey Kees, Thomas,
>>
>> On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote:
>>> On Wed, Jun 22, 2016 at 8:59 AM, Thomas Garnier  wrote:
>>> > On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper  
>>> > wrote:
>>> >> Hey Kees,
>>> >>
>>> >> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote:
>>> >>> Notable problems that needed solving:
>>> >> ...
>>> >>>  - Reasonable entropy is needed early at boot before get_random_bytes()
>>> >>>is available.
>>> >>
>>> >> This series is targetting x86, which typically has RDRAND/RDSEED
>>> >> instructions.  Are you referring to other arches?  Older x86?  Also,
>>> >> isn't this the same requirement for base address KASLR?
>>> >>
>>> >> Don't get me wrong, I want more diverse entropy sources available
>>> >> earlier in the boot process as well. :-)  I'm just wondering what's
>>> >> different about this series vs base address KASLR wrt early entropy
>>> >> sources.
>>> >>
>>> >
>>> > I think Kees was referring to the refactor I did to get the similar
>>> > entropy generation than KASLR module randomization. Our approach was
>>> > to provide best entropy possible even if you have an older processor
>>> > or under virtualization without support for these instructions.
>>> > Unfortunately common on companies with a large number of older
>>> > machines.
>>>
>>> Right, the memory offset KASLR uses the same routines as the kernel
>>> base KASLR. The issue is with older x86 systems, which continue to be
>>> very common.
>>
>> We have the same issue in embedded. :-(  Compounded by the fact that
>> there is no rand instruction (at least not on ARM).  So, even if there's
>> a HW-RNG, you can't access it until the driver is loaded.
>>
>> This is compounded by the fact that most systems deployed today have
>> bootloaders a) without hw-rng drivers, b) without dtb editing, and c)
>> without dtb support at all.
>>
>> My current thinking is to add a devicetree property
>> "userspace,random-seed" .  This way, existing, deployed
>> boards can append a dtb to a modern kernel with the property set.
>> The factory bootloader then only needs to amend its boot scripts to read
>> random-seed from the fs to the given address.
>
> The arm64 KASLR implementation has defined a way for boot loaders to
> pass in an seed similar to this. It might be nice to have a fall-back
> to a DT entry, though, then the bootloaders don't need to changed.
>
> Ard might have some thoughts on why DT wasn't used for KASLR (I assume
> the early parsing overhead, but I don't remember the discussion any
> more).
>

On arm64, only DT is used for KASLR (even when booting via ACPI). My
first draft used register x1, but this turned out to be too much of a
hassle, since parsing the DT is also necessary to discover whether
there is a 'nokaslr' argument on the kernel command line. So the
current implementation only supports a single method, which is the
/chosen/kaslr-seed uint64 property.

>> Modern systems that receive a seed from the bootloader via the
>> random-seed property (typically from the hw-rng) can mix both sources
>> for increased resilience.
>
> Yeah, that could work.
>
>> Unfortunately, I'm not very familiar with the internals of x86
>> bootstrapping.  Could GRUB be scripted to do a similar task?  How would
>> the address and size of the seed be passed to the kernel?  command line?
>
> Command line could work (though it would need scrubbing to avoid it
> leaking into /proc/cmdine), but there's also the "zero-page" used by
> bootloaders to pass details to the kernel (see
> Documentation/x86/boot.txt). Right now, x86 has sufficient entropy
> (though rdrand is best).
>
> -Kees
>
> --
> Kees Cook
> Chrome OS & Brillo Security
--
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: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Kees Cook]

On Thu, Jun 23, 2016 at 12:45 PM, Sandy Harris  wrote:
> Jason Cooper  wrote:
>
>> Modern systems that receive a seed from the bootloader via the
>> random-seed property (typically from the hw-rng) can mix both sources
>> for increased resilience.
>>
>> Unfortunately, I'm not very familiar with the internals of x86
>> bootstrapping.  Could GRUB be scripted to do a similar task?  How would
>> the address and size of the seed be passed to the kernel?  command line?
>
> One suggestion is at:
> http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image

Interesting! This might pose a problem for signed images, though.
(Actually, for signed arm kernels is the DT signed too? If so, it
would be a similar problem.)

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security
--
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: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Kees Cook]

On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper  wrote:
> Hey Kees, Thomas,
>
> On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote:
>> On Wed, Jun 22, 2016 at 8:59 AM, Thomas Garnier  wrote:
>> > On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper  wrote:
>> >> Hey Kees,
>> >>
>> >> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote:
>> >>> Notable problems that needed solving:
>> >> ...
>> >>>  - Reasonable entropy is needed early at boot before get_random_bytes()
>> >>>is available.
>> >>
>> >> This series is targetting x86, which typically has RDRAND/RDSEED
>> >> instructions.  Are you referring to other arches?  Older x86?  Also,
>> >> isn't this the same requirement for base address KASLR?
>> >>
>> >> Don't get me wrong, I want more diverse entropy sources available
>> >> earlier in the boot process as well. :-)  I'm just wondering what's
>> >> different about this series vs base address KASLR wrt early entropy
>> >> sources.
>> >>
>> >
>> > I think Kees was referring to the refactor I did to get the similar
>> > entropy generation than KASLR module randomization. Our approach was
>> > to provide best entropy possible even if you have an older processor
>> > or under virtualization without support for these instructions.
>> > Unfortunately common on companies with a large number of older
>> > machines.
>>
>> Right, the memory offset KASLR uses the same routines as the kernel
>> base KASLR. The issue is with older x86 systems, which continue to be
>> very common.
>
> We have the same issue in embedded. :-(  Compounded by the fact that
> there is no rand instruction (at least not on ARM).  So, even if there's
> a HW-RNG, you can't access it until the driver is loaded.
>
> This is compounded by the fact that most systems deployed today have
> bootloaders a) without hw-rng drivers, b) without dtb editing, and c)
> without dtb support at all.
>
> My current thinking is to add a devicetree property
> "userspace,random-seed" .  This way, existing, deployed
> boards can append a dtb to a modern kernel with the property set.
> The factory bootloader then only needs to amend its boot scripts to read
> random-seed from the fs to the given address.

The arm64 KASLR implementation has defined a way for boot loaders to
pass in an seed similar to this. It might be nice to have a fall-back
to a DT entry, though, then the bootloaders don't need to changed.

Ard might have some thoughts on why DT wasn't used for KASLR (I assume
the early parsing overhead, but I don't remember the discussion any
more).

> Modern systems that receive a seed from the bootloader via the
> random-seed property (typically from the hw-rng) can mix both sources
> for increased resilience.

Yeah, that could work.

> Unfortunately, I'm not very familiar with the internals of x86
> bootstrapping.  Could GRUB be scripted to do a similar task?  How would
> the address and size of the seed be passed to the kernel?  command line?

Command line could work (though it would need scrubbing to avoid it
leaking into /proc/cmdine), but there's also the "zero-page" used by
bootloaders to pass details to the kernel (see
Documentation/x86/boot.txt). Right now, x86 has sufficient entropy
(though rdrand is best).

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security
--
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: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Jason Cooper]

Hey Kees, Thomas,

On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote:
> On Wed, Jun 22, 2016 at 8:59 AM, Thomas Garnier  wrote:
> > On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper  wrote:
> >> Hey Kees,
> >>
> >> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote:
> >>> Notable problems that needed solving:
> >> ...
> >>>  - Reasonable entropy is needed early at boot before get_random_bytes()
> >>>is available.
> >>
> >> This series is targetting x86, which typically has RDRAND/RDSEED
> >> instructions.  Are you referring to other arches?  Older x86?  Also,
> >> isn't this the same requirement for base address KASLR?
> >>
> >> Don't get me wrong, I want more diverse entropy sources available
> >> earlier in the boot process as well. :-)  I'm just wondering what's
> >> different about this series vs base address KASLR wrt early entropy
> >> sources.
> >>
> >
> > I think Kees was referring to the refactor I did to get the similar
> > entropy generation than KASLR module randomization. Our approach was
> > to provide best entropy possible even if you have an older processor
> > or under virtualization without support for these instructions.
> > Unfortunately common on companies with a large number of older
> > machines.
> 
> Right, the memory offset KASLR uses the same routines as the kernel
> base KASLR. The issue is with older x86 systems, which continue to be
> very common.

We have the same issue in embedded. :-(  Compounded by the fact that
there is no rand instruction (at least not on ARM).  So, even if there's
a HW-RNG, you can't access it until the driver is loaded.

This is compounded by the fact that most systems deployed today have
bootloaders a) without hw-rng drivers, b) without dtb editing, and c)
without dtb support at all.

My current thinking is to add a devicetree property
"userspace,random-seed" .  This way, existing, deployed
boards can append a dtb to a modern kernel with the property set.
The factory bootloader then only needs to amend its boot scripts to read
random-seed from the fs to the given address.

Modern systems that receive a seed from the bootloader via the
random-seed property (typically from the hw-rng) can mix both sources
for increased resilience.

Unfortunately, I'm not very familiar with the internals of x86
bootstrapping.  Could GRUB be scripted to do a similar task?  How would
the address and size of the seed be passed to the kernel?  command line?

thx,

Jason.
--
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: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Sandy Harris]

Jason Cooper  wrote:

> Modern systems that receive a seed from the bootloader via the
> random-seed property (typically from the hw-rng) can mix both sources
> for increased resilience.
>
> Unfortunately, I'm not very familiar with the internals of x86
> bootstrapping.  Could GRUB be scripted to do a similar task?  How would
> the address and size of the seed be passed to the kernel?  command line?

One suggestion is at:
http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image
--
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 v5] leds: documentation: 'ide-disk' to 'disk-activity'

[Stephan Linz]

Cc: Joseph Jezak 
Cc: Jörg Sommer 
Cc: Mark Rutland 
Signed-off-by: Stephan Linz 
Acked-by: Rob Herring 
Signed-off-by: Jacek Anaszewski 
---
Changes in v5:
  - Keep documentation for the old 'ide-disk' device tree
binding, but mark as deprecated and refer to the new
trigger 'disk-activity'.

Changes in v4:
  - Keep the 'ide-disk' trigger and add a second one
for 'disk-activity'.

Changes in v3:
  - Port to kernel 4.x
  - Split into platform independent and dependent parts.

v2: https://patchwork.ozlabs.org/patch/117485/
v1: http://dev.gentoo.org/~josejx/ata.patch
---
 Documentation/devicetree/bindings/leds/common.txt| 5 -
 Documentation/devicetree/bindings/leds/leds-gpio.txt | 4 ++--
 Documentation/laptops/asus-laptop.txt| 2 +-
 Documentation/leds/leds-class.txt| 2 +-
 4 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/leds/common.txt 
b/Documentation/devicetree/bindings/leds/common.txt
index af10678..1c32e31 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -25,8 +25,11 @@ Optional properties for child nodes:
   system
  "default-on" - LED will turn on (but for leds-gpio see "default-state"
property in Documentation/devicetree/bindings/gpio/led.txt)
+ "disk-activity" - LED indicates disk activity, the old name "ide-disk" is
+   still valid for backward compatibility
  "heartbeat" - LED "double" flashes at a load average based rate
- "ide-disk" - LED indicates disk activity
+ "ide-disk" - LED indicates IDE disk activity (deprecated), do not use for
+  new implementation, use the new "disk-activity" name instead
  "timer" - LED flashes at a fixed, configurable rate
 
 - led-max-microamp : Maximum LED supply current in microamperes. This property
diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.txt 
b/Documentation/devicetree/bindings/leds/leds-gpio.txt
index cbbeb18..5b1b43a 100644
--- a/Documentation/devicetree/bindings/leds/leds-gpio.txt
+++ b/Documentation/devicetree/bindings/leds/leds-gpio.txt
@@ -33,9 +33,9 @@ Examples:
 leds {
compatible = "gpio-leds";
hdd {
-   label = "IDE Activity";
+   label = "Disk Activity";
gpios = <_pio 0 GPIO_ACTIVE_LOW>;
-   linux,default-trigger = "ide-disk";
+   linux,default-trigger = "disk-activity";
};
 
fault {
diff --git a/Documentation/laptops/asus-laptop.txt 
b/Documentation/laptops/asus-laptop.txt
index 79a1bc6..5f28587 100644
--- a/Documentation/laptops/asus-laptop.txt
+++ b/Documentation/laptops/asus-laptop.txt
@@ -72,7 +72,7 @@ LEDs
 echo 1 >  /sys/class/leds/asus::mail/brightness
   will switch the mail LED on.
   You can also know if they are on/off by reading their content and use
-  kernel triggers like ide-disk or heartbeat.
+  kernel triggers like disk-activity or heartbeat.
 
 Backlight
 -
diff --git a/Documentation/leds/leds-class.txt 
b/Documentation/leds/leds-class.txt
index 44f5e6b..f1f7ec9 100644
--- a/Documentation/leds/leds-class.txt
+++ b/Documentation/leds/leds-class.txt
@@ -11,7 +11,7 @@ brightness support so will just be turned on for non-zero 
brightness settings.
 The class also introduces the optional concept of an LED trigger. A trigger
 is a kernel based source of led events. Triggers can either be simple or
 complex. A simple trigger isn't configurable and is designed to slot into
-existing subsystems with minimal additional code. Examples are the ide-disk,
+existing subsystems with minimal additional code. Examples are the 
disk-activity,
 nand-disk and sharpsl-charge triggers. With led triggers disabled, the code
 optimises away.
 
-- 
2.9.0

--
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/3] Documentation: dtb: xgene: Add hwmon dts binding documentation

[Hoan Tran]

On Tue, Jun 7, 2016 at 11:05 AM, Hoan Tran  wrote:
> Hi Jassi,
>
> Thanks for your reply !
>
> On Tue, Jun 7, 2016 at 10:20 AM, Jassi Brar  wrote:
>> On Tue, May 24, 2016 at 6:31 AM, Hoan Tran  wrote:
>>> Hi Rob,
>>>
>>> Thanks for your review !
>>>
>>> On Mon, May 23, 2016 at 1:30 PM, Rob Herring  wrote:

 On Mon, May 16, 2016 at 09:17:25AM -0700, Hoan Tran wrote:
 > This patch adds the APM X-Gene hwmon device tree node documentation.
 >
 > Signed-off-by: Hoan Tran 
 > ---
 >  .../devicetree/bindings/hwmon/apm-xgene-hwmon.txt  | 14 
 > ++
 >  1 file changed, 14 insertions(+)
 >  create mode 100644 
 > Documentation/devicetree/bindings/hwmon/apm-xgene-hwmon.txt
 >
 > diff --git a/Documentation/devicetree/bindings/hwmon/apm-xgene-hwmon.txt 
 > b/Documentation/devicetree/bindings/hwmon/apm-xgene-hwmon.txt
 > new file mode 100644
 > index 000..49a482e
 > --- /dev/null
 > +++ b/Documentation/devicetree/bindings/hwmon/apm-xgene-hwmon.txt
 > @@ -0,0 +1,14 @@
 > +APM X-Gene hwmon driver
 > +
 > +Hwmon driver accesses sensors over the "SLIMpro" mailbox.

 DT bindings describe h/w, not driver data.
>>> How about this description: "APM X-Gene SOC sensors are accessed over
>>> the "SLIMpro" mailbox" ?
 I'm not sure this belongs in
 DT and perhaps the devices for the mailbox should be created by the
 mailbox driver.
>>> I don't think the current mailbox supports it.

 > +
 > +Required properties :
 > + - compatible : should be "apm,xgene-slimpro-hwmon"
 > + - mboxes : use the label reference for the mailbox as the first 
 > parameter.
 > + The second parameter is the channel number.

 When do you expect this to be different mailbox numbers?
>>> No, this number is not changed. This "mboxes" property is used and
>>> required by mailbox.c when hwmon driver requests a mailbox channel
>>>
>> I think that's inaccurate.
>>
>> The h/w and the firmware combined is the "platform" from Linux POV.
>> Channels are physical resources provided by a mailbox controller.
>> Currently the firmware listens on Channel-7 but some future revision
>> might switch to, say, Channel-9.  Or say the same firmware on next
>> revision of h/w may have to switch to Channel-3 because it has only 4
>> channels. So I see the mailbox channel number as a hardware property
>> just like an IRQ (which very often change with SoC iterations).
>
> Agree about that. I suppose this number is not changed. But as you
> said, the mailbox channel number can be changed based on SoC or
> Firmware. It would be better if this channel number is specified
> inside a DT node.
>
> Hi Rob, do you have any comments ?
>
> Thanks
> Hoan
>
>>
>> Cheers.

Hi Rob,

Do you have any comments on Jassi's reply ?
If not, I'll send another version which included the binding document
and DT node.

Thanks
Hoan
--
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] arm64:swiotlb:Enable only when Input size through command line

[Konrad Rzeszutek Wilk]

On June 23, 2016 10:30:34 AM EDT, Catalin Marinas  
wrote:
>On Thu, Jun 23, 2016 at 05:43:40PM +0530, Manjeet Pawar wrote:
>> From: Rohit Thapliyal 
>> 
>> swiotlb default size of 64M is too big as
>> default value therefore it is made configurable
>> through command line through swiotlb_size parameter.
>> swiotlb allocation shall be done only when the
>> swiotlb size is given through command line.
>> Otherwise no swiotlb is allocated.
>
>I already queued this patch:
>
>http://lkml.kernel.org/g/1465372426-4077-1-git-send-email-jszh...@marvell.com
>
>If you have any objections to it, please reply there.


I do (sorry about duplicate email, the other got rejected by mailing lists).

Why not expand the swiotlb= parameter instead of introducing a new one?

Also, why not use the swiotlb by itself? That does the job as well?

--
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 v3] Add kernel parameter to blacklist modules

[Prarit Bhargava]

Blacklisting a module in linux has long been a problem.  The current
procedure is to use rd.blacklist=module_name, however, that doesn't
cover the case after the initramfs and before a boot prompt (where one
is supposed to use /etc/modprobe.d/blacklist.conf to blacklist
runtime loading). Using rd.shell to get an early prompt is hit-or-miss,
and doesn't cover all situations AFAICT.

This patch adds this functionality of permanently blacklisting a module
by its name via the kernel parameter module_blacklist=module_name.

[v2]: Rusty, use core_param() instead of __setup() which simplifies
things.

[v3]: Rusty, undo wreckage from strsep()

Signed-off-by: Prarit Bhargava 
Cc: Jonathan Corbet 
Cc: Rusty Russell 
Cc: linux-doc@vger.kernel.org
---
 Documentation/kernel-parameters.txt |3 +++
 kernel/module.c |   29 +
 2 files changed, 32 insertions(+)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 82b42c958d1c..c720b96f2efc 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2295,6 +2295,9 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
Note that if CONFIG_MODULE_SIG_FORCE is set, that
is always true, so this option does nothing.
 
+   module_blacklist=  [KNL] Do not load a comma-separated list of
+   modules.  Useful for debugging problem modules.
+
mousedev.tap_time=
[MOUSE] Maximum time between finger touching and
leaving touchpad surface for touch to be considered
diff --git a/kernel/module.c b/kernel/module.c
index 5f71aa63ed2a..5240da88af79 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3155,6 +3155,32 @@ int __weak module_frob_arch_sections(Elf_Ehdr *hdr,
return 0;
 }
 
+/* module_blacklist is a comma-separated list of module names */
+static char *module_blacklist;
+static bool blacklisted(char *module_name)
+{
+   char *str, *entry;
+
+   if (!module_blacklist)
+   return false;
+
+   str = module_blacklist;
+   do {
+   if (str != module_blacklist)
+   module_blacklist[strlen(str) - 1] = ',';
+   entry = strsep(, ",");
+   if (!strcmp(module_name, entry)) {
+   pr_info("module %s is blacklisted\n", module_name);
+   if (str != module_blacklist)
+   module_blacklist[strlen(str) - 1] = ',';
+   return true;
+   }
+   } while (str);
+
+   return false;
+}
+core_param(module_blacklist, module_blacklist, charp, 0400);
+
 static struct module *layout_and_allocate(struct load_info *info, int flags)
 {
/* Module within temporary copy. */
@@ -3165,6 +3191,9 @@ static struct module *layout_and_allocate(struct 
load_info *info, int flags)
if (IS_ERR(mod))
return mod;
 
+   if (blacklisted(mod->name))
+   return ERR_PTR(-EPERM);
+
err = check_modinfo(mod, info, flags);
if (err)
return ERR_PTR(err);
-- 
1.7.9.3

--
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] capabilities: add capability cgroup controller

[Topi Miettinen]

There are many basic ways to control processes, including capabilities,
cgroups and resource limits. However, there are far fewer ways to find
out useful values for the limits, except blind trial and error.

Currently, there is no way to know which capabilities are actually used.
Even the source code is only implicit, in-depth knowledge of each
capability must be used when analyzing a program to judge which
capabilities the program will exercise.

Add a new cgroup controller for monitoring of capabilities
in the cgroup.

Test case demonstrating basic capability monitoring and how the
capabilities are combined at next level (boot to rdshell):

(initramfs) cd /sys/fs
(initramfs) mount -t cgroup2 cgroup cgroup
(initramfs) cd cgroup
(initramfs) echo +capability > cgroup.subtree_control
(initramfs) mkdir test; cd test
(initramfs) echo +capability > cgroup.subtree_control
(initramfs) ls
capability.used cgroup.events   cgroup.subtree_control
cgroup.controllers  cgroup.procs
(initramfs) mkdir first second
(initramfs) sh

BusyBox v1.22.1 (Debian 1:1.22.0-19) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs) cd first
(initramfs) echo $$ >cgroup.procs
(initramfs) cat capability.used
 # nothing so far
(initramfs) mknod /dev/z_$$ c 1 2
(initramfs) cat capability.used
0800 # CAP_MKNOD
(initramfs) cat ../capability.used
0800 # also seen at next higher level
(initramfs) exit
(initramfs) sh

BusyBox v1.22.1 (Debian 1:1.22.0-19) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs) cd second
(initramfs) echo $$ >cgroup.procs
(initramfs) cat capability.used
 # nothing so far
(initramfs) chown 1234 /dev/z_*
(initramfs) cat capability.used
0001 # CAP_CHROOT
(initramfs) cat ../capability.used
0801 # combined at next higher level
(initramfs) exit

Signed-off-by: Topi Miettinen 
---
 Documentation/cgroup-v2.txt   | 17 +++
 include/linux/capability_cgroup.h |  7 +++
 include/linux/cgroup_subsys.h |  4 ++
 init/Kconfig  |  6 +++
 kernel/capability.c   |  2 +
 security/Makefile |  1 +
 security/capability_cgroup.c  | 99 +++
 7 files changed, 136 insertions(+)
 create mode 100644 include/linux/capability_cgroup.h
 create mode 100644 security/capability_cgroup.c

diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
index 4cc07ce..2b3d277 100644
--- a/Documentation/cgroup-v2.txt
+++ b/Documentation/cgroup-v2.txt
@@ -1118,6 +1118,23 @@ writeback as follows.
total available memory and applied the same way as
vm.dirty[_background]_ratio.
 
+5-4. Capabilities
+
+The "capability" controller is used to monitor capability use in the
+cgroup. This can be used to discover a starting point for capability
+bounding sets, even when running a shell script under ambient
+capabilities, with only short-lived helper processes exercising the
+capabilities.
+
+
+5-4-1. Capability Interface Files
+
+  capability.used
+
+   A read-only file which exists on all cgroups.
+
+   This reports the combined value of capability use in the
+   current cgroup and all its children.
 
 6. Namespace
 
diff --git a/include/linux/capability_cgroup.h 
b/include/linux/capability_cgroup.h
new file mode 100644
index 000..c03b58d
--- /dev/null
+++ b/include/linux/capability_cgroup.h
@@ -0,0 +1,7 @@
+#ifdef CONFIG_CGROUP_CAPABILITY
+void capability_cgroup_update_used(int cap);
+#else
+static inline void capability_cgroup_update_used(int cap)
+{
+}
+#endif
diff --git a/include/linux/cgroup_subsys.h b/include/linux/cgroup_subsys.h
index 0df0336a..a5161d0 100644
--- a/include/linux/cgroup_subsys.h
+++ b/include/linux/cgroup_subsys.h
@@ -56,6 +56,10 @@ SUBSYS(hugetlb)
 SUBSYS(pids)
 #endif
 
+#if IS_ENABLED(CONFIG_CGROUP_CAPABILITY)
+SUBSYS(capability)
+#endif
+
 /*
  * The following subsystems are not supported on the default hierarchy.
  */
diff --git a/init/Kconfig b/init/Kconfig
index f755a60..25d17ef 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1141,6 +1141,12 @@ config CGROUP_PERF
 
  Say N if unsure.
 
+config CGROUP_CAPABILITY
+   bool "Capability controller"
+   help
+ Provides a simple controller for monitoring of capabilities in the
+ cgroup.
+
 config CGROUP_DEBUG
bool "Example controller"
default n
diff --git a/kernel/capability.c b/kernel/capability.c
index 45432b5..b57d7f9 100644
--- a/kernel/capability.c
+++ b/kernel/capability.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -380,6 +381,7 @@ bool ns_capable(struct user_namespace *ns, int cap)
}
 
if (security_capable(current_cred(), ns, cap) == 0) {
+   capability_cgroup_update_used(cap);
current->flags |= PF_SUPERPRIV;
return true;
}
diff 

Re: [PATCH] arm64:swiotlb:Enable only when Input size through command line

[kbuild test robot]

Hi,

[auto build test WARNING on v4.7-rc4]
[cannot apply to arm64/for-next/core next-20160623]
[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/Manjeet-Pawar/arm64-swiotlb-Enable-only-when-Input-size-through-command-line/20160623-205508
config: x86_64-randconfig-i0-201625 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   lib/swiotlb.c: In function 'setup_io_tlb_size':
>> lib/swiotlb.c:131:30: warning: passing argument 2 of 'kstrtoul' makes 
>> integer from pointer without a cast [-Wint-conversion]
  swiotlb_sz = kstrtoul(str, , 0);
 ^
   In file included from include/linux/list.h:8:0,
from include/linux/kobject.h:20,
from include/linux/device.h:17,
from include/linux/dma-mapping.h:6,
from lib/swiotlb.c:21:
   include/linux/kernel.h:298:32: note: expected 'unsigned int' but argument is 
of type 'char **'
static inline int __must_check kstrtoul(const char *s, unsigned int base, 
unsigned long *res)
   ^~~~

vim +/kstrtoul +131 lib/swiotlb.c

   115  
   116  return 0;
   117  }
   118  early_param("swiotlb", setup_io_tlb_npages);
   119  
   120  static int __init
   121  setup_io_tlb_size(char *str)
   122  {
   123  int len = strlen(str);
   124  
   125  if (str[len-1] == 'M')
   126  swiotlb_sz_shift = 20;
   127  else if (str[len-1] == 'K')
   128  swiotlb_sz_shift = 10;
   129  str[len-1] = '\0';
   130  if (isdigit(*str))
 > 131  swiotlb_sz = kstrtoul(str, , 0);
   132  
   133  swiotlb_enabled = 1;
   134  return 0;
   135  }
   136  early_param("swiotlb_sz", setup_io_tlb_size);
   137  /* make io_tlb_overflow tunable too? */
   138  
   139  unsigned long swiotlb_nr_tbl(void)

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


.config.gz
Description: Binary data

Re: [PATCH] arm64:swiotlb:Enable only when Input size through command line

[Catalin Marinas]

On Thu, Jun 23, 2016 at 05:43:40PM +0530, Manjeet Pawar wrote:
> From: Rohit Thapliyal 
> 
> swiotlb default size of 64M is too big as
> default value therefore it is made configurable
> through command line through swiotlb_size parameter.
> swiotlb allocation shall be done only when the
> swiotlb size is given through command line.
> Otherwise no swiotlb is allocated.

I already queued this patch:

http://lkml.kernel.org/g/1465372426-4077-1-git-send-email-jszh...@marvell.com

If you have any objections to it, please reply there.

-- 
Catalin
--
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] Documentation: tiny typo fix in usb/gadget_multi.txt

[Jonathan Corbet]

On Sat, 11 Jun 2016 02:56:37 +0200
Michal Nazarewicz  wrote:

> -For the gadget two work under Windows two conditions have to be met:
> +For the gadget to work under Windows two conditions have to be met:

Applied to the docs tree, thanks.

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: [PATCH] Documentation: fix wrong value in md.txt

[Jonathan Corbet]

On Fri, 17 Jun 2016 09:40:02 +0800 (CST)
"Tiezhu Yang"  wrote:

> I read drivers/md/raid5.c and find the following related code:
> 1) in function 'raid5_set_cache_size':
> if (size <= 16 || size > 32768)
>   return -EINVAL;
> 2) #define NR_STRIPES 256
> 
> So the lower limit value of stripe_cache_size should be 17 and
> the default value should be 256.

Applied to the docs tree, thanks.

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: [docs-next PATCH v2 00/11] Documentation/sphinx follow-up, again

[Jonathan Corbet]

On Thu, 23 Jun 2016 15:28:00 +0300
Jani Nikula  wrote:

> The first 9 patches are just a resend of [1], there's two patches on top
> here.

OK, these all look good to me.  Applied to the docs tree, sorry for the
delay.

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

[docs-next PATCH v2 01/11] kernel-doc: remove old debug cruft from dump_section()

[Jani Nikula]

No functional changes.

Signed-off-by: Jani Nikula 
---
 scripts/kernel-doc | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 27757c21551a..ac18eb5ed776 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -529,21 +529,18 @@ sub dump_section {
 my $contents = join "\n", @_;
 
 if ($name =~ m/$type_param/) {
-#  print STDERR "parameter def '$1' = '$contents'\n";
$name = $1;
$parameterdescs{$name} = $contents;
$sectcheck = $sectcheck . $name . " ";
 $parameterdesc_start_lines{$name} = $new_start_line;
 $new_start_line = 0;
 } elsif ($name eq "@\.\.\.") {
-#  print STDERR "parameter def '...' = '$contents'\n";
$name = "...";
$parameterdescs{$name} = $contents;
$sectcheck = $sectcheck . $name . " ";
 $parameterdesc_start_lines{$name} = $new_start_line;
 $new_start_line = 0;
 } else {
-#  print STDERR "other section '$name' = '$contents'\n";
if (defined($sections{$name}) && ($sections{$name} ne "")) {
print STDERR "${file}:$.: warning: duplicate section name 
'$name'\n";
++$warnings;
-- 
2.1.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

[docs-next PATCH v2 03/11] kernel-doc: add missing semi-colons in option parsing

[Jani Nikula]

Signed-off-by: Jani Nikula 
---
 scripts/kernel-doc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 710615f3a4ff..a6f82c812c15 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -484,10 +484,10 @@ while ($ARGV[0] =~ m/^-(.*)/) {
$function_table{$function} = 1;
 } elsif ($cmd eq "-export") { # only exported symbols
$output_selection = OUTPUT_EXPORTED;
-   %function_table = ()
+   %function_table = ();
 } elsif ($cmd eq "-internal") { # only non-exported symbols
$output_selection = OUTPUT_INTERNAL;
-   %function_table = ()
+   %function_table = ();
 } elsif ($cmd eq "-v") {
$verbose = 1;
 } elsif (($cmd eq "-h") || ($cmd eq "--help")) {
-- 
2.1.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

[docs-next PATCH v2 04/11] kernel-doc: abstract filename mapping

[Jani Nikula]

Reduce duplication in follow-up work. No functional changes.

Signed-off-by: Jani Nikula 
---
 scripts/kernel-doc | 27 ++-
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index a6f82c812c15..516d95fcefb7 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -2730,26 +2730,35 @@ sub local_unescape($) {
return $text;
 }
 
-sub process_file($) {
+sub map_filename($) {
 my $file;
-my $identifier;
-my $func;
-my $descr;
-my $in_purpose = 0;
-my $initial_section_counter = $section_counter;
 my ($orig_file) = @_;
-my $leading_space;
 
 if (defined($ENV{'SRCTREE'})) {
$file = "$ENV{'SRCTREE'}" . "/" . $orig_file;
-}
-else {
+} else {
$file = $orig_file;
 }
+
 if (defined($source_map{$file})) {
$file = $source_map{$file};
 }
 
+return $file;
+}
+
+sub process_file($) {
+my $file;
+my $identifier;
+my $func;
+my $descr;
+my $in_purpose = 0;
+my $initial_section_counter = $section_counter;
+my ($orig_file) = @_;
+my $leading_space;
+
+$file = map_filename($orig_file);
+
 if (!open(IN,"<$file")) {
print STDERR "Error: Cannot open file $file\n";
++$errors;
-- 
2.1.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

[docs-next PATCH v2 06/11] kernel-doc: unify all EXPORT_SYMBOL scanning to one place

[Jani Nikula]

Scan all input files for EXPORT_SYMBOLs along with the explicitly
specified export files before actually parsing anything.

Signed-off-by: Jani Nikula 
---
 scripts/kernel-doc | 18 +-
 1 file changed, 5 insertions(+), 13 deletions(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 9708a87c7069..932b3f34ff06 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -61,10 +61,10 @@ Output format selection (mutually exclusive):
 Output selection (mutually exclusive):
   -export  Only output documentation for symbols that have been
exported using EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL()
-in the same FILE or any -export-file FILE.
+in any input FILE or -export-file FILE.
   -internalOnly output documentation for symbols that have NOT been
exported using EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL()
-in the same FILE or any -export-file FILE.
+in any input FILE or -export-file FILE.
   -function NAME   Only output documentation for the given function(s)
or DOC: section title(s). All other functions and DOC:
sections are ignored. May be specified multiple times.
@@ -2792,17 +2792,6 @@ sub process_file($) {
return;
 }
 
-# two passes for -export and -internal
-if ($output_selection == OUTPUT_EXPORTED ||
-   $output_selection == OUTPUT_INTERNAL) {
-   while () {
-   if (/$export_symbol/o) {
-   $function_table{$2} = 1;
-   }
-   }
-   seek(IN, 0, 0);
-}
-
 $. = 1;
 
 $section_counter = 0;
@@ -3110,6 +3099,9 @@ if (open(SOURCE_MAP, "<.tmp_filelist.txt")) {
 
 if ($output_selection == OUTPUT_EXPORTED ||
 $output_selection == OUTPUT_INTERNAL) {
+
+push(@export_file_list, @ARGV);
+
 foreach (@export_file_list) {
chomp;
process_export_file($_);
-- 
2.1.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] arm64:swiotlb:Enable only when Input size through command line

[Robin Murphy]

On 23/06/16 13:13, Manjeet Pawar wrote:

From: Rohit Thapliyal 

swiotlb default size of 64M is too big as
default value therefore it is made configurable
through command line through swiotlb_size parameter.
swiotlb allocation shall be done only when the
swiotlb size is given through command line.
Otherwise no swiotlb is allocated.


So all platforms with most memory physically above 4GB (which is quite a 
lot of them) are suddenly broken unless they go and muck about with 
their bootloader?


If anyone's got to muck about with their bootloader, why can't it be the 
memory-constrained platforms just passing "swiotlb=1" instead?


Robin.


Signed-off-by: Rohit Thapliyal 
Signed-off-by: Manjeet Pawar 
Reviewed-by: Akhilesh Kumar 
Reviewed-by: Ajeet Kumar Yadav 
---
  Documentation/kernel-parameters.txt |3 +++
  arch/arm64/mm/init.c|3 ++-
  include/linux/swiotlb.h |1 +
  lib/swiotlb.c   |   33 +
  4 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 82b42c9..12b680f 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3875,6 +3875,9 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
force -- force using of bounce buffers even if they
 wouldn't be automatically used by the kernel

+   swiotlb_sz= [KNL] enter swiotlb size.
+   Sets the swiotlb size for eg. swiotlb_sz=64M
+
switches=   [HW,M68k]

sysfs.deprecated=0|1 [KNL]
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index d45f862..89c6b39 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -403,7 +403,8 @@ static void __init free_unused_memmap(void)
   */
  void __init mem_init(void)
  {
-   swiotlb_init(1);
+   if (swiotlb_enabled)
+   swiotlb_init(1);

set_max_mapnr(pfn_to_page(max_pfn) - mem_map);

diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 017fced..c7eb146 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -11,6 +11,7 @@ struct page;
  struct scatterlist;

  extern int swiotlb_force;
+extern int swiotlb_enabled;

  /*
   * Maximum allowable number of contiguous slabs to map,
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 76f29ec..e89296a 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -54,6 +54,7 @@
  #define IO_TLB_MIN_SLABS ((1<<20) >> IO_TLB_SHIFT)

  int swiotlb_force;
+int swiotlb_enabled;

  /*
   * Used to do a quick range check in swiotlb_tbl_unmap_single and
@@ -96,6 +97,9 @@ static DEFINE_SPINLOCK(io_tlb_lock);

  static int late_alloc;

+unsigned long swiotlb_sz;
+unsigned int swiotlb_sz_shift;
+
  static int __init
  setup_io_tlb_npages(char *str)
  {
@@ -112,6 +116,24 @@ setup_io_tlb_npages(char *str)
return 0;
  }
  early_param("swiotlb", setup_io_tlb_npages);
+
+static int __init
+setup_io_tlb_size(char *str)
+{
+   int len = strlen(str);
+
+   if (str[len-1] == 'M')
+   swiotlb_sz_shift = 20;
+   else if (str[len-1] == 'K')
+   swiotlb_sz_shift = 10;
+   str[len-1] = '\0';
+   if (isdigit(*str))
+   swiotlb_sz = kstrtoul(str, , 0);
+
+   swiotlb_enabled = 1;
+   return 0;
+}
+early_param("swiotlb_sz", setup_io_tlb_size);
  /* make io_tlb_overflow tunable too? */

  unsigned long swiotlb_nr_tbl(void)
@@ -120,8 +142,9 @@ unsigned long swiotlb_nr_tbl(void)
  }
  EXPORT_SYMBOL_GPL(swiotlb_nr_tbl);

-/* default to 64MB */
-#define IO_TLB_DEFAULT_SIZE (64UL<<20)
+/* Pass from command line as swiotlb_sz=64M (for eg.)*/
+#define IO_TLB_DEFAULT_SIZE (swiotlb_sz<> 20, vstart, vend - 1);
+   bytes >> swiotlb_sz_shift,
+   swiotlb_sz_shift == 20 ? 'M' : 'K',
+   vstart, vend - 1);
  }

  int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)



--
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

[docs-next PATCH v2 02/11] kernel-doc: do not warn about duplicate default section names

[Jani Nikula]

Since

commit 32217761ee9db0215350dfe1ca4e66f312fb8c54
Author: Jani Nikula 
Date:   Sun May 29 09:40:44 2016 +0300

kernel-doc: concatenate contents of colliding sections

we started getting (more) errors on duplicate section names, especially
on the default section name "Description":

include/net/mac80211.h:3174: warning: duplicate section name 'Description'

This is usually caused by a slightly unorthodox placement of parameter
descriptions, like in the above case, and kernel-doc resetting back to
the default section more than once within a kernel-doc comment.

Ignore warnings on the duplicate section name automatically assigned by
kernel-doc, and only consider explicitly user assigned duplicate section
names an issue.

Signed-off-by: Jani Nikula 
---
 scripts/kernel-doc | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index ac18eb5ed776..710615f3a4ff 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -542,8 +542,11 @@ sub dump_section {
 $new_start_line = 0;
 } else {
if (defined($sections{$name}) && ($sections{$name} ne "")) {
-   print STDERR "${file}:$.: warning: duplicate section name 
'$name'\n";
-   ++$warnings;
+   # Only warn on user specified duplicate section names.
+   if ($name ne $section_default) {
+   print STDERR "${file}:$.: warning: duplicate section name 
'$name'\n";
+   ++$warnings;
+   }
$sections{$name} .= $contents;
} else {
$sections{$name} = $contents;
-- 
2.1.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

[docs-next PATCH v2 05/11] kernel-doc: add support for specifying extra files for EXPORT_SYMBOLs

[Jani Nikula]

If the kernel-doc comments for functions are not in the same file as the
EXPORT_SYMBOL statements, the -export and -internal output selections do
not work as expected. This is typically the case when the kernel-doc
comments are in header files next to the function declarations and the
EXPORT_SYMBOL statements are next to the function definitions in the
source files.

Let the user specify additional source files in which to look for the
EXPORT_SYMBOLs using the new -export-file FILE option, which may be
given multiple times.

The pathological example for this is include/net/mac80211.h, which has
all the kernel-doc documentation for the exported functions defined in a
plethora of source files net/mac80211/*.c.

Signed-off-by: Jani Nikula 
---
 scripts/kernel-doc | 39 +--
 1 file changed, 37 insertions(+), 2 deletions(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 516d95fcefb7..9708a87c7069 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -61,10 +61,10 @@ Output format selection (mutually exclusive):
 Output selection (mutually exclusive):
   -export  Only output documentation for symbols that have been
exported using EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL()
-   in the same FILE.
+in the same FILE or any -export-file FILE.
   -internalOnly output documentation for symbols that have NOT been
exported using EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL()
-   in the same FILE.
+in the same FILE or any -export-file FILE.
   -function NAME   Only output documentation for the given function(s)
or DOC: section title(s). All other functions and DOC:
sections are ignored. May be specified multiple times.
@@ -76,6 +76,9 @@ Output selection modifiers:
   -no-doc-sections Do not output DOC: sections.
   -enable-linenoEnable output of #define LINENO lines. Only works with
 reStructuredText format.
+  -export-file FILE Specify an additional FILE in which to look for
+EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL(). To be used 
with
+-export or -internal. May be specified multiple times.
 
 Other parameters:
   -v   Verbose output, more warnings and other information.
@@ -336,6 +339,8 @@ use constant {
 my $output_selection = OUTPUT_ALL;
 my $show_not_found = 0;
 
+my @export_file_list;
+
 my @build_time;
 if (defined($ENV{'KBUILD_BUILD_TIMESTAMP'}) &&
 (my $seconds = `date -d"${ENV{'KBUILD_BUILD_TIMESTAMP'}}" +%s`) ne '') {
@@ -488,6 +493,9 @@ while ($ARGV[0] =~ m/^-(.*)/) {
 } elsif ($cmd eq "-internal") { # only non-exported symbols
$output_selection = OUTPUT_INTERNAL;
%function_table = ();
+} elsif ($cmd eq "-export-file") {
+   my $file = shift @ARGV;
+   push(@export_file_list, $file);
 } elsif ($cmd eq "-v") {
$verbose = 1;
 } elsif (($cmd eq "-h") || ($cmd eq "--help")) {
@@ -2747,6 +2755,25 @@ sub map_filename($) {
 return $file;
 }
 
+sub process_export_file($) {
+my ($orig_file) = @_;
+my $file = map_filename($orig_file);
+
+if (!open(IN,"<$file")) {
+   print STDERR "Error: Cannot open file $file\n";
+   ++$errors;
+   return;
+}
+
+while () {
+   if (/$export_symbol/) {
+   $function_table{$2} = 1;
+   }
+}
+
+close(IN);
+}
+
 sub process_file($) {
 my $file;
 my $identifier;
@@ -3081,6 +3108,14 @@ if (open(SOURCE_MAP, "<.tmp_filelist.txt")) {
close(SOURCE_MAP);
 }
 
+if ($output_selection == OUTPUT_EXPORTED ||
+$output_selection == OUTPUT_INTERNAL) {
+foreach (@export_file_list) {
+   chomp;
+   process_export_file($_);
+}
+}
+
 foreach (@ARGV) {
 chomp;
 process_file($_);
-- 
2.1.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

[docs-next PATCH v2 10/11] Documentation/sphinx: drop modindex, we don't have python modules

[Jani Nikula]

The modindex is for python modules.

Signed-off-by: Jani Nikula 
---
 Documentation/index.rst | 2 --
 1 file changed, 2 deletions(-)

diff --git a/Documentation/index.rst b/Documentation/index.rst
index 71a276f34c7f..1139a7ea39ec 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -18,6 +18,4 @@ Indices and tables
 ==
 
 * :ref:`genindex`
-* :ref:`modindex`
 * :ref:`search`
-
-- 
2.1.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

[docs-next PATCH v2 11/11] Documentation: add top level 'make help' output for Sphinx

[Jani Nikula]

While there's slight overlap with the DocBook help now, this can stay
intact when the DocBook help goes away.

Signed-off-by: Jani Nikula 
---
 Documentation/DocBook/Makefile | 4 ++--
 Documentation/Makefile.sphinx  | 8 
 Makefile   | 2 ++
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index e0c7e1e0590b..496d4295ec38 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -218,7 +218,7 @@ silent_gen_xml = :
 ###
 # Help targets as used by the top-level makefile
 dochelp:
-   @echo  ' Linux kernel internal documentation in different formats:'
+   @echo  ' Linux kernel internal documentation in different formats 
(DocBook):'
@echo  '  htmldocs- HTML'
@echo  '  pdfdocs - PDF'
@echo  '  psdocs  - Postscript'
@@ -227,7 +227,7 @@ dochelp:
@echo  '  installmandocs  - install man pages generated by mandocs'
@echo  '  cleandocs   - clean all generated DocBook files'
@echo
-   @echo  'make DOCBOOKS="s1.xml s2.xml" [target] Generate only docs 
s1.xml s2.xml'
+   @echo  '  make DOCBOOKS="s1.xml s2.xml" [target] Generate only docs 
s1.xml s2.xml'
@echo  '  valid values for DOCBOOKS are: $(DOCBOOKS)'
 
 
diff --git a/Documentation/Makefile.sphinx b/Documentation/Makefile.sphinx
index addf32309bc3..810c11f0d37f 100644
--- a/Documentation/Makefile.sphinx
+++ b/Documentation/Makefile.sphinx
@@ -60,4 +60,12 @@ installmandocs:
 cleandocs:
$(Q)rm -rf $(BUILDDIR)
 
+dochelp:
+   @echo  ' Linux kernel internal documentation in different formats 
(Sphinx):'
+   @echo  '  htmldocs- HTML'
+   @echo  '  pdfdocs - PDF'
+   @echo  '  epubdocs- EPUB'
+   @echo  '  xmldocs - XML'
+   @echo  '  cleandocs   - clean all generated files'
+
 endif # HAVE_SPHINX
diff --git a/Makefile b/Makefile
index 8908a51b895a..f7f393c40886 100644
--- a/Makefile
+++ b/Makefile
@@ -1364,6 +1364,8 @@ help:
@$(MAKE) $(build)=$(package-dir) help
@echo  ''
@echo  'Documentation targets:'
+   @$(MAKE) -f $(srctree)/Documentation/Makefile.sphinx dochelp
+   @echo  ''
@$(MAKE) -f $(srctree)/Documentation/DocBook/Makefile dochelp
@echo  ''
@echo  'Architecture specific targets ($(SRCARCH)):'
-- 
2.1.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

[docs-next PATCH v2 08/11] Documentation/sphinx: use a more sensible string split in kernel-doc extension

[Jani Nikula]

Using the default str.split doesn't return empty strings like the
current version does.

Signed-off-by: Jani Nikula 
---
 Documentation/sphinx/kernel-doc.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/sphinx/kernel-doc.py 
b/Documentation/sphinx/kernel-doc.py
index 2856376cc62c..d6a76f9a0ba5 100644
--- a/Documentation/sphinx/kernel-doc.py
+++ b/Documentation/sphinx/kernel-doc.py
@@ -68,7 +68,7 @@ class KernelDocDirective(Directive):
 elif 'doc' in self.options:
 cmd += ['-function', str(self.options.get('doc'))]
 elif 'functions' in self.options:
-for f in str(self.options.get('functions')).split(' '):
+for f in str(self.options.get('functions')).split():
 cmd += ['-function', f]
 
 cmd += [filename]
-- 
2.1.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

[docs-next PATCH v2 07/11] Documentation/sphinx: remove unnecessary temporary variable

[Jani Nikula]

Leftover cruft. No functional changes.

Signed-off-by: Jani Nikula 
---
 Documentation/sphinx/kernel-doc.py | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Documentation/sphinx/kernel-doc.py 
b/Documentation/sphinx/kernel-doc.py
index 4adfb0e91ecc..2856376cc62c 100644
--- a/Documentation/sphinx/kernel-doc.py
+++ b/Documentation/sphinx/kernel-doc.py
@@ -59,7 +59,6 @@ class KernelDocDirective(Directive):
 env.note_dependency(os.path.abspath(filename))
 
 tab_width = self.options.get('tab-width', 
self.state.document.settings.tab_width)
-source = filename
 
 # FIXME: make this nicer and more robust against errors
 if 'export' in self.options:
@@ -105,7 +104,7 @@ class KernelDocDirective(Directive):
 lineoffset = int(match.group(1)) - 1
 # we must eat our comments since the upset the markup
 else:
-result.append(line, source, lineoffset)
+result.append(line, filename, lineoffset)
 lineoffset += 1
 
 node = nodes.section()
-- 
2.1.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

[docs-next PATCH v2 09/11] Documentation/sphinx: add support for specifying extra export files

[Jani Nikula]

Let the user specify file patterns where to look for the EXPORT_SYMBOLs
in addition to the file with kernel-doc comments. This is directly based
on the -export-file FILE option added to kernel-doc in "kernel-doc: add
support for specifying extra files for EXPORT_SYMBOLs", but we extend
that with globbing patterns in the Sphinx extension.

The file patterns are added as options to the :export: and :internal:
arguments of the kernel-doc directive. For example, to extract the
documentation of exported functions from include/net/mac80211.h:

.. kernel-doc:: include/net/mac80211.h
   :export: net/mac80211/*.c

Without the file pattern, no exported functions would be found, as the
EXPORT_SYMBOLs are placed in the various source files under
net/mac80211.

The matched files are also added as dependencies on the document in
Sphinx, as they may affect the output. This is one of the reasons to do
the globbing in the Sphinx extension instead of in scripts/kernel-doc.

The file pattern remains optional, and is not needed if the kernel-doc
comments and EXPORT_SYMBOLs are placed in the source file passed in as
the main argument to the kernel-doc directive. This is the most common
case across the kernel source tree.

Signed-off-by: Jani Nikula 
---
 Documentation/sphinx/kernel-doc.py | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/Documentation/sphinx/kernel-doc.py 
b/Documentation/sphinx/kernel-doc.py
index d6a76f9a0ba5..dedb24e3bb7a 100644
--- a/Documentation/sphinx/kernel-doc.py
+++ b/Documentation/sphinx/kernel-doc.py
@@ -31,6 +31,7 @@ import os
 import subprocess
 import sys
 import re
+import glob
 
 from docutils import nodes, statemachine
 from docutils.statemachine import ViewList
@@ -44,8 +45,8 @@ class KernelDocDirective(Directive):
 option_spec = {
 'doc': directives.unchanged_required,
 'functions': directives.unchanged_required,
-'export': directives.flag,
-'internal': directives.flag,
+'export': directives.unchanged,
+'internal': directives.unchanged,
 }
 has_content = False
 
@@ -54,6 +55,7 @@ class KernelDocDirective(Directive):
 cmd = [env.config.kerneldoc_bin, '-rst', '-enable-lineno']
 
 filename = env.config.kerneldoc_srctree + '/' + self.arguments[0]
+export_file_patterns = []
 
 # Tell sphinx of the dependency
 env.note_dependency(os.path.abspath(filename))
@@ -63,14 +65,21 @@ class KernelDocDirective(Directive):
 # FIXME: make this nicer and more robust against errors
 if 'export' in self.options:
 cmd += ['-export']
+export_file_patterns = str(self.options.get('export')).split()
 elif 'internal' in self.options:
 cmd += ['-internal']
+export_file_patterns = str(self.options.get('internal')).split()
 elif 'doc' in self.options:
 cmd += ['-function', str(self.options.get('doc'))]
 elif 'functions' in self.options:
 for f in str(self.options.get('functions')).split():
 cmd += ['-function', f]
 
+for pattern in export_file_patterns:
+for f in glob.glob(env.config.kerneldoc_srctree + '/' + pattern):
+env.note_dependency(os.path.abspath(f))
+cmd += ['-export-file', f]
+
 cmd += [filename]
 
 try:
-- 
2.1.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

[docs-next PATCH v2 00/11] Documentation/sphinx follow-up, again

[Jani Nikula]

The first 9 patches are just a resend of [1], there's two patches on top
here.

Pull details below.

BR,
Jani.

[1] http://mid.gmane.org/cover.1465567017.git.jani.nik...@intel.com


The following changes since commit 8569de68e79e94cce6709831edd94accb6942ade:

  docs: kernel-doc: Add "example" and "note" to the magic section types 
(2016-06-09 13:35:05 -0600)

are available in the git repository at:

  git://people.freedesktop.org/~jani/drm sphinx-for-docs-next

for you to fetch changes up to ebc88ef05c825024a5d95285459b8c842c095c0f:

  Documentation: add top level 'make help' output for Sphinx (2016-06-23 
15:11:51 +0300)


Jani Nikula (11):
  kernel-doc: remove old debug cruft from dump_section()
  kernel-doc: do not warn about duplicate default section names
  kernel-doc: add missing semi-colons in option parsing
  kernel-doc: abstract filename mapping
  kernel-doc: add support for specifying extra files for EXPORT_SYMBOLs
  kernel-doc: unify all EXPORT_SYMBOL scanning to one place
  Documentation/sphinx: remove unnecessary temporary variable
  Documentation/sphinx: use a more sensible string split in kernel-doc 
extension
  Documentation/sphinx: add support for specifying extra export files
  Documentation/sphinx: drop modindex, we don't have python modules
  Documentation: add top level 'make help' output for Sphinx

 Documentation/DocBook/Makefile |  4 +-
 Documentation/Makefile.sphinx  |  8 
 Documentation/index.rst|  2 -
 Documentation/sphinx/kernel-doc.py | 18 +---
 Makefile   |  2 +
 scripts/kernel-doc | 88 +++---
 6 files changed, 87 insertions(+), 35 deletions(-)


-- 
2.1.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] arm64:swiotlb:Enable only when Input size through command line

[Manjeet Pawar]

From: Rohit Thapliyal 

swiotlb default size of 64M is too big as
default value therefore it is made configurable
through command line through swiotlb_size parameter.
swiotlb allocation shall be done only when the
swiotlb size is given through command line.
Otherwise no swiotlb is allocated.

Signed-off-by: Rohit Thapliyal 
Signed-off-by: Manjeet Pawar 
Reviewed-by: Akhilesh Kumar 
Reviewed-by: Ajeet Kumar Yadav 
---
 Documentation/kernel-parameters.txt |3 +++
 arch/arm64/mm/init.c|3 ++-
 include/linux/swiotlb.h |1 +
 lib/swiotlb.c   |   33 +
 4 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 82b42c9..12b680f 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3875,6 +3875,9 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
force -- force using of bounce buffers even if they
 wouldn't be automatically used by the kernel
 
+   swiotlb_sz= [KNL] enter swiotlb size.
+   Sets the swiotlb size for eg. swiotlb_sz=64M
+
switches=   [HW,M68k]
 
sysfs.deprecated=0|1 [KNL]
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index d45f862..89c6b39 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -403,7 +403,8 @@ static void __init free_unused_memmap(void)
  */
 void __init mem_init(void)
 {
-   swiotlb_init(1);
+   if (swiotlb_enabled)
+   swiotlb_init(1);
 
set_max_mapnr(pfn_to_page(max_pfn) - mem_map);
 
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 017fced..c7eb146 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -11,6 +11,7 @@ struct page;
 struct scatterlist;
 
 extern int swiotlb_force;
+extern int swiotlb_enabled;
 
 /*
  * Maximum allowable number of contiguous slabs to map,
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 76f29ec..e89296a 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -54,6 +54,7 @@
 #define IO_TLB_MIN_SLABS ((1<<20) >> IO_TLB_SHIFT)
 
 int swiotlb_force;
+int swiotlb_enabled;
 
 /*
  * Used to do a quick range check in swiotlb_tbl_unmap_single and
@@ -96,6 +97,9 @@ static DEFINE_SPINLOCK(io_tlb_lock);
 
 static int late_alloc;
 
+unsigned long swiotlb_sz;
+unsigned int swiotlb_sz_shift;
+
 static int __init
 setup_io_tlb_npages(char *str)
 {
@@ -112,6 +116,24 @@ setup_io_tlb_npages(char *str)
return 0;
 }
 early_param("swiotlb", setup_io_tlb_npages);
+
+static int __init
+setup_io_tlb_size(char *str)
+{
+   int len = strlen(str);
+
+   if (str[len-1] == 'M')
+   swiotlb_sz_shift = 20;
+   else if (str[len-1] == 'K')
+   swiotlb_sz_shift = 10;
+   str[len-1] = '\0';
+   if (isdigit(*str))
+   swiotlb_sz = kstrtoul(str, , 0);
+
+   swiotlb_enabled = 1;
+   return 0;
+}
+early_param("swiotlb_sz", setup_io_tlb_size);
 /* make io_tlb_overflow tunable too? */
 
 unsigned long swiotlb_nr_tbl(void)
@@ -120,8 +142,9 @@ unsigned long swiotlb_nr_tbl(void)
 }
 EXPORT_SYMBOL_GPL(swiotlb_nr_tbl);
 
-/* default to 64MB */
-#define IO_TLB_DEFAULT_SIZE (64UL<<20)
+/* Pass from command line as swiotlb_sz=64M (for eg.)*/
+#define IO_TLB_DEFAULT_SIZE (swiotlb_sz<> 20, vstart, vend - 1);
+   bytes >> swiotlb_sz_shift,
+   swiotlb_sz_shift == 20 ? 'M' : 'K',
+   vstart, vend - 1);
 }
 
 int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)
-- 
1.7.9.5

--
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 v3 2/7] leds: documentation: 'ide-disk' to 'disk-activity'

[Jacek Anaszewski]

On 06/22/2016 06:05 PM, Stephan Linz wrote:

Hi Jacek,

Am 22.06.2016 um 09:55 schrieb Jacek Anaszewski:

On 06/21/2016 05:05 PM, Mark Rutland wrote:

On Thu, Jun 09, 2016 at 12:29:37AM +0200, Stephan Linz wrote:

Cc: Joseph Jezak 
Cc: Nico Macrionitis 
Cc: Jörg Sommer 
Signed-off-by: Stephan Linz 
---
   Documentation/devicetree/bindings/leds/common.txt| 2 +-
   Documentation/devicetree/bindings/leds/leds-gpio.txt | 2 +-
   Documentation/laptops/asus-laptop.txt| 2 +-
   Documentation/leds/leds-class.txt| 2 +-
   4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/leds/common.txt
b/Documentation/devicetree/bindings/leds/common.txt
index af10678..1e97169 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -26,7 +26,7 @@ Optional properties for child nodes:
"default-on" - LED will turn on (but for leds-gpio see
"default-state"
   property in
Documentation/devicetree/bindings/gpio/led.txt)
"heartbeat" - LED "double" flashes at a load average based rate
- "ide-disk" - LED indicates disk activity
+ "disk-activity" - LED indicates disk activity
"timer" - LED flashes at a fixed, configurable rate


We should not break the binding.

Code must continue to support "ide-disk", though we can mark it
deprecated in the binding documentation, and update the in-kernel dts
files to use "disk-activity".


The code in the version 4 of the patchset supports also "ide-disk".

Stephan, could you send a new version of this patch, with preserved
"ide-disk" property, marked as deprecated?


Yes, I can. I'll submit a new v5 patch set. You can pick out then the
right patch for the LED for-next branch, okay?


You don't need to submit whole patch set, only the affected patch.

--
Best regards,
Jacek Anaszewski
--
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