Re: [PATCH 0/1] man/set_mempolicy.2,mbind.2: add MPOL_LOCAL NUMA memory policy documentation

[Christoph Lameter]

Well the difference between MPOL_DEFAULT and MPOL_LOCAL may be confusing.
Mention somewhere in the MPOL_LOCAL description that the policy with
MPOL_DEFAULT reverts to the policy of the process and MPOL_LOCAL to try to
allocate local? Note that MPOL_LOCAL also will not be local if it just
happens that the local node is overallocated. This is usually confusing
for newcomers. The node/zone reclaim must be activated in order to allow
node local reclaim that results in a node local allocation.



--
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 2/4] drm: Add API for capturing frame CRCs

[Jon Hunter]

gt; *connector)
>   connector->debugfs_entry = NULL;
>  }
>  
> -#endif /* CONFIG_DEBUG_FS */
> +int drm_debugfs_crtc_add(struct drm_crtc *crtc)
> +{
> + struct drm_minor *minor = crtc->dev->primary;

After this patch was applied Tegra boards started crashing here when
dereferencing crtc pointer above ...

[6.789318] Unable to handle kernel paging request at virtual address 
fff8
[6.796537] pgd = c0004000
[6.799270] [fff8] *pgd=afffd861, *pte=, *ppte=
[6.805572] Internal error: Oops: 37 [#1] PREEMPT SMP ARM
[6.810969] Modules linked in:
[6.814038] CPU: 2 PID: 72 Comm: kworker/2:1 Not tainted 
4.8.0-next-20161004-126151-gc7d3b91 #1
[6.822728] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
[6.829000] Workqueue: events deferred_probe_work_func
[6.834150] task: ee00f880 task.stack: ee01
[6.838682] PC is at drm_debugfs_crtc_add+0x8/0x70
[6.843481] LR is at drm_minor_register+0xa4/0x1b0
[6.848267] pc : []lr : []psr: a113
[6.848267] sp : ee011d20  ip : ee2f4914  fp : c0d02100
[6.859732] r10: 0001  r9 :   r8 : 
[6.864949] r7 : ee2f3800  r6 : ee2f3a4c  r5 : ee2f4900  r4 : fff8
[6.871472] r3 : 0001  r2 :   r1 : ee011c70  r0 : fff8
[6.877992] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[6.885123] Control: 10c5387d  Table: 8000406a  DAC: 0051
[6.890871] Process kworker/2:1 (pid: 72, stack limit = 0xee010210)
[6.897129] Stack: (0xee011d20 to 0xee012000)
[6.901491] 1d20: fff8 ee2f4900 ee2f3a4c c0428a60 ee00f880 ee2f3800 
 
[6.909670] 1d40: c0d34794 001e  c0428be8 ee2f3800 eebae800 
c0d3467c c0442008
[6.917839] 1d60: eebae818  c0d34794 001e eebae810 c0dabfec 
 c0407578
[6.926014] 1d80: c040755c c045ac3c  ee011db8 c045af10 0001 
c0dabfc8 c045922c
[6.934190] 1da0: eeaaa370 eebac0b8 eebae810 eebae844 c0d33fa0 c045a9c4 
eebae810 0001
[6.942366] 1dc0: c0d02100 eebae810 eebae810 c0d33fa0 ee9b6e10 c045a0b4 
eebae810 
[6.950544] 1de0: eebae818 c0458624 c0d6404c 6113 c0d02100 c0817664 
eebae800 ee2f3c10
[6.958713] 1e00: ee034ec0 eebae9d8 eebae9b0 eefa5580 eebae810 c0407744 
eefbf974 eebaeb94
[6.966887] 1e20: c0d3400c c0d33f68 ee2f3c10 eebaea10  c0408058 
ee2f3c10 ee9b6810
[6.975064] 1e40:  ee9b6800  c044bb4c  ee9b4940 
ee2f3c10 
[6.983241] 1e60: ffed ee9b6810 fdfb c0d348f8 001e c045c20c 
c045c1bc ee9b6810
[6.991417] 1e80: c0dabfec  c0d348f8 c045ac3c  ee011ec0 
c045af10 0001
[6.999595] 1ea0:  c045922c ee8a3d70 eebacfb8 ee9b6810 ee9b6844 
c0d34de8 c045a9c4
[7.007763] 1ec0: ee9b6810 0001 c0d02100 ee9b6810 ee9b6810 c0d34de8 
eefa8800 c045a0b4
[7.015938] 1ee0: ee9b6810 c0d34d70 c0d34d90 c045a4e8 eeb78f00 c0d34d98 
eefa5580 c0134890
[7.024115] 1f00: ee171484 eefa5580 eeb78f00 eeb78f18 0001 eefa5580 
eeb78f18 eefa5580
[7.032292] 1f20: 0008 c0134ab4 eefa88f5 eeb78f00 eefa5598 c0134cc8 
 eeaf6fc0
[7.040469] 1f40:  eeaf6fc0  eeb78f00 c0134ac4  
 
[7.048637] 1f60:  c0139d68 fffc  ffef eeb78f00 
 
[7.056812] 1f80: ee011f80 ee011f80   ee011f90 ee011f90 
ee011fac eeaf6fc0
[7.064988] 1fa0: c0139c90   c0107938   
 
[7.073165] 1fc0:       
 
[7.081342] 1fe0:     0013  
fff3 efbf
[7.089538] [] (drm_debugfs_crtc_add) from [] 
(drm_minor_register+0xa4/0x1b0)
[7.098405] [] (drm_minor_register) from [] 
(drm_dev_register+0x7c/0xd0)
[7.106856] [] (drm_dev_register) from [] 
(host1x_drm_probe+0x38/0x90)
[7.115135] [] (host1x_drm_probe) from [] 
(host1x_device_probe+0x1c/0x28)
[7.123672] [] (host1x_device_probe) from [] 
(driver_probe_device+0x1f0/0x2a8)
[7.132642] [] (driver_probe_device) from [] 
(bus_for_each_drv+0x44/0x8c)
[7.141178] [] (bus_for_each_drv) from [] 
(__device_attach+0x9c/0x100)
[7.149454] [] (__device_attach) from [] 
(bus_probe_device+0x84/0x8c)
[7.157624] [] (bus_probe_device) from [] 
(device_add+0x380/0x528)
[7.165551] [] (device_add) from [] 
(host1x_subdev_register+0xb0/0xd4)
[7.173827] [] (host1x_subdev_register) from [] 
(host1x_client_register+0xf4/0x11c)
[7.183231] [] (host1x_client_register) from [] 
(tegra_hdmi_probe+0x1c8/0x2c8)
[7.192201] [] (tegra_hdmi_probe) from [] 
(platform_drv_probe+0x50/0xb0)
[7.200653] [] (platform_drv_probe) from [] 
(driver_probe_device+0x1f0/0x2a8)
[7.209536] [] (driver_probe_device) from [] 
(bus_for_each_drv+0x44/0x8c)
[7.218053] [] (bus_for_each_drv) from [] 
(__device

Re: [PATCH v8 2/4] drm: Add API for capturing frame CRCs

[Daniel Vetter]

On Tue, Oct 4, 2016 at 12:10 PM, Jon Hunter  wrote:
> Looks like crtc is a errno in the above case. I see this function is
> called by looping through all the crtc and we never check to see if
> they are valid. Should we?

Tegra is still using the load/unload hooks. That didn't mesh well with
Tomeu's patches (and Tomeu's patches have been thrown out meanwhile
because of that). Still would be neat if tegra could be demidlayered
and loose it's load/unload hooks. See the kerneldoc in drm_drv.c
(especially the DOC: section).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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 2/4] drm: Add API for capturing frame CRCs

[Lukas Wunner]

On Tue, Oct 04, 2016 at 01:25:23PM +0200, Daniel Vetter wrote:
> On Tue, Oct 4, 2016 at 12:10 PM, Jon Hunter  wrote:
> > Looks like crtc is a errno in the above case. I see this function is
> > called by looping through all the crtc and we never check to see if
> > they are valid. Should we?

nouveau is exploding as well on driver load!


> Tegra is still using the load/unload hooks. That didn't mesh well with
> Tomeu's patches (and Tomeu's patches have been thrown out meanwhile
> because of that).

They're still on drm-intel-nightly, please revert if they're broken.

Thanks,

Lukas
--
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 2/4] drm: Add API for capturing frame CRCs

[Jon Hunter]

On 04/10/16 12:25, Daniel Vetter wrote:
> On Tue, Oct 4, 2016 at 12:10 PM, Jon Hunter  wrote:
>> Looks like crtc is a errno in the above case. I see this function is
>> called by looping through all the crtc and we never check to see if
>> they are valid. Should we?
> 
> Tegra is still using the load/unload hooks. That didn't mesh well with
> Tomeu's patches (and Tomeu's patches have been thrown out meanwhile
> because of that). Still would be neat if tegra could be demidlayered
> and loose it's load/unload hooks. See the kerneldoc in drm_drv.c
> (especially the DOC: section).

Adding Thierry and Alex as this is more their domain and CC'ing linux-tegra.

Cheers
Jon

-- 
nvpublic
--
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 2/4] drm: Add API for capturing frame CRCs

[Lukas Wunner]

On Tue, Oct 04, 2016 at 02:23:13PM +0200, Lukas Wunner wrote:
> On Tue, Oct 04, 2016 at 01:25:23PM +0200, Daniel Vetter wrote:
> > On Tue, Oct 4, 2016 at 12:10 PM, Jon Hunter  wrote:
> > > Looks like crtc is a errno in the above case. I see this function is
> > > called by looping through all the crtc and we never check to see if
> > > they are valid. Should we?
> 
> nouveau is exploding as well on driver load!
> 
> > Tegra is still using the load/unload hooks. That didn't mesh well with
> > Tomeu's patches (and Tomeu's patches have been thrown out meanwhile
> > because of that).
> 
> They're still on drm-intel-nightly, please revert if they're broken.

Never mind, I hadn't rebased on today's drm-intel-nightly yet,
I see it's gone now.

Thanks,

Lukas
--
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] x86/pkeys: Update documentation

[Dave Hansen]

From: Dave Hansen 

There are a few items that have gotten stale in the protection
keys documentation.  The config option description only applied
to the execute-only support and is not accurate for the current
code.  There was also a typo with the number of system calls.  I
also wanted to call out that pkey_set() is not a kernel-provided
facility, and where to find an implementation.

Signed-off-by: Dave Hansen 
Cc: x...@kernel.org
Cc: Jonathan Corbet 
Cc: linux-doc@vger.kernel.org
---

 b/Documentation/x86/protection-keys.txt |   14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff -puN Documentation/x86/protection-keys.txt~pkeys-docfix 
Documentation/x86/protection-keys.txt
--- a/Documentation/x86/protection-keys.txt~pkeys-docfix2016-10-04 
09:31:01.361928429 -0700
+++ b/Documentation/x86/protection-keys.txt 2016-10-04 09:32:39.142383585 
-0700
@@ -20,7 +20,7 @@ instruction fetches.
 
 === Syscalls ===
 
-There are 2 system calls which directly interact with pkeys:
+There are 3 system calls which directly interact with pkeys:
 
int pkey_alloc(unsigned long flags, unsigned long init_access_rights)
int pkey_free(int pkey);
@@ -52,6 +52,10 @@ is no longer in use:
munmap(ptr, PAGE_SIZE);
pkey_free(pkey);
 
+(Note: pkey_set() is a wrapper for the RDPKRU and WRPKRU instructions.
+ An example implementation can be found in
+ tools/testing/selftests/x86/protection_keys.c)
+
 === Behavior ===
 
 The kernel attempts to make protection keys consistent with the
@@ -79,11 +83,3 @@ with a read():
 The kernel will send a SIGSEGV in both cases, but si_code will be set
 to SEGV_PKERR when violating protection keys versus SEGV_ACCERR when
 the plain mprotect() permissions are violated.
-
-=== Config Option ===
-
-This config option adds approximately 1.5kb of text. and 50 bytes of
-data to the executable.  A workload which does large O_DIRECT reads
-of holes in XFS files was run to exercise get_user_pages_fast().  No
-performance delta was observed with the config option
-enabled or disabled.
_
--
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: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller

[Parav Pandit]

Hi Doug,

I am still waiting for Leon to provide his comments if any on rdma cgroup.
>From other email context, he was on vacation last week.
While we wait for his comments, I wanted to know your view of this
patchset in 4.9 merge window.

To summarize the discussion that happened in two threads.

[1] Ack by Tejun, asking for review from rdma list
[2] quick review by Christoph on patch-v11 (patch 12 has only typo corrections)
[3] Christoph's ack on architecture of rdma cgroup and fitting it with ABI
[4] My response on Matan's query on RSS indirection table
[5] Response from Intel on their driver support for Matan's query
[6] Christoph's point on architecture, which we are following in new
ABI and current ABI

I have reviewed recent patch [7] from Matan where I see IB verbs
objects are still handled through common path as suggested by
Christoph.

I do not see any issues with rdma cgroup patchset other than it requires rebase.
Am I missing something?
Can you please help me - What would be required to merge it to 4.9?

[1] https://lkml.org/lkml/2016/8/31/494
[2] https://lkml.org/lkml/2016/8/25/146
[3] https://lkml.org/lkml/2016/9/10/175
[4] https://lkml.org/lkml/2016/9/14/221
[5] https://lkml.org/lkml/2016/9/19/571
[6] http://www.spinics.net/lists/linux-rdma/msg40337.html
[7] email subject: [RFC ABI V4 0/7] SG-based RDMA ABI Proposal

Regards,
Parav Pandit

On Wed, Sep 21, 2016 at 9:32 PM, Parav Pandit  wrote:
> Hi Tejun,
>
> On Wed, Sep 21, 2016 at 7:56 PM, Tejun Heo  wrote:
>> Hello, Parav.
>>
>> On Wed, Sep 21, 2016 at 10:13:38AM +0530, Parav Pandit wrote:
>>> We have completed review from Tejun, Christoph.
>>> HFI driver folks also provided feedback for Intel drivers.
>>> Matan's also doesn't have any more comments.
>>>
>>> If possible, if you can also review, it will be helpful.
>>>
>>> I have some more changes unrelated to cgroup in same files in both the git 
>>> tree.
>>> Pushing them now either results into merge conflict later on for
>>> Doug/Tejun, or requires rebase and resending patch.
>>> If you can review, we can avoid such rework.
>>
>> My impression of the thread was that there doesn't seem to be enough
>> of consensus around how rdma resources should be defined.  Is that
>> part agreed upon now?
>>
>
> We ended up discussing few points on different thread [1].
>
> There was confusion on how some non-rdma/non-IB drivers would work
> with rdma cgroup from Matan.
> Christoph explained how they don't fit in the rdma subsystem and
> therefore its not prime target to addess.
> Intel driver maintainer Denny also acknowledged same on [2].
> IB compliant drivers of Intel support rdma cgroup as explained in [2].
> With that usnic and Intel psm drivers falls out of rdma cgroup support
> as they don't fit very well in the verbs definition.
>
> [1] https://www.spinics.net/lists/linux-rdma/msg40340.html
> [2] http://www.spinics.net/lists/linux-rdma/msg40717.html
>
> I will wait for Leon's review comments if he has different view on 
> architecture.
> Back in April when I met face-to-face to Leon and Haggai, Leon was in
> support to have kernel defined the rdma resources as suggested by
> Christoph and Tejun instead of IB/RDMA subsystem.
> I will wait for his comments if his views have changed with new uAPI
> taking shape.
--
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

make pdfdocs errors with v4.8

[Jim Davis]

Running make pdfdocs in a 4.8 tree ran into a number of errors; this
is on a Ubuntu 16.04 system with
the python-sphinx and rst2pdf packages installed from the Ubuntu
repositories.  Any ideas on what I'm doing wrong?

-- 
Jim
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/docproc
  HOSTCC  scripts/check-lc_ctype
  SPHINX  pdfdocs
Running Sphinx v1.3.1
making output directory...
loading pickled environment... not yet created
building [mo]: targets for 0 po files that are out of date
building [pdf]: targets for 493 source files that are out of date
updating environment: 493 added, 0 changed, 0 removed
reading sources... [  0%] gpu/drm-internals
reading sources... [  0%] gpu/drm-kms
reading sources... [  0%] gpu/drm-kms-helpers
reading sources... [  0%] gpu/drm-mm
reading sources... [  1%] gpu/drm-uapi
reading sources... [  1%] gpu/i915
./drivers/gpu/drm/i915/i915_vgpu.c:102: warning: No description found for parameter 'dev_priv'
./drivers/gpu/drm/i915/i915_vgpu.c:181: warning: No description found for parameter 'dev_priv'
./drivers/gpu/drm/i915/i915_vgpu.c:181: warning: Excess function parameter 'dev' description in 'intel_vgt_balloon'
./drivers/gpu/drm/i915/i915_vgpu.c:103: warning: No description found for parameter 'dev_priv'
./drivers/gpu/drm/i915/i915_vgpu.c:182: warning: No description found for parameter 'dev_priv'
./drivers/gpu/drm/i915/i915_vgpu.c:182: warning: Excess function parameter 'dev' description in 'intel_vgt_balloon'
./drivers/gpu/drm/i915/i915_gem.c:932: warning: No description found for parameter 'i915'
./drivers/gpu/drm/i915/i915_gem.c:932: warning: Excess function parameter 'dev' description in 'i915_gem_gtt_pwrite_fast'
./drivers/gpu/drm/i915/intel_hotplug.c:543: warning: Excess function parameter 'enabled' description in 'intel_hpd_poll_init'
./drivers/gpu/drm/i915/intel_hotplug.c:544: warning: Excess function parameter 'enabled' description in 'intel_hpd_poll_init'
./drivers/gpu/drm/i915/intel_fbc.c:1087: warning: No description found for parameter 'crtc_state'
./drivers/gpu/drm/i915/intel_fbc.c:1087: warning: No description found for parameter 'plane_state'
./drivers/gpu/drm/i915/intel_fbc.c:1088: warning: No description found for parameter 'crtc_state'
./drivers/gpu/drm/i915/intel_fbc.c:1088: warning: No description found for parameter 'plane_state'
reading sources... [  1%] gpu/index
reading sources... [  1%] gpu/introduction
reading sources... [  1%] gpu/vga-switcheroo
reading sources... [  2%] index
reading sources... [  2%] kernel-documentation
reading sources... [  2%] media/dvb-drivers/avermedia
reading sources... [  2%] media/dvb-drivers/bt8xx
reading sources... [  2%] media/dvb-drivers/cards
reading sources... [  3%] media/dvb-drivers/ci
reading sources... [  3%] media/dvb-drivers/contributors
reading sources... [  3%] media/dvb-drivers/dvb-usb
reading sources... [  3%] media/dvb-drivers/faq
reading sources... [  3%] media/dvb-drivers/index
reading sources... [  4%] media/dvb-drivers/intro
reading sources... [  4%] media/dvb-drivers/lmedm04
reading sources... [  4%] media/dvb-drivers/opera-firmware
reading sources... [  4%] media/dvb-drivers/technisat
reading sources... [  4%] media/dvb-drivers/ttusb-dec
reading sources... [  5%] media/dvb-drivers/udev
reading sources... [  5%] media/intro
reading sources... [  5%] media/kapi/dtv-core
reading sources... [  5%] media/kapi/mc-core
reading sources... [  5%] media/kapi/rc-core
reading sources... [  6%] media/kapi/v4l2-clocks
reading sources... [  6%] media/kapi/v4l2-common
reading sources... [  6%] media/kapi/v4l2-controls
reading sources... [  6%] media/kapi/v4l2-core
reading sources... [  6%] media/kapi/v4l2-dev
reading sources... [  7%] media/kapi/v4l2-device
reading sources... [  7%] media/kapi/v4l2-dv-timings
reading sources... [  7%] media/kapi/v4l2-event
reading sources... [  7%] media/kapi/v4l2-fh
reading sources... [  7%] media/kapi/v4l2-flash-led-class
reading sources... [  8%] media/kapi/v4l2-intro
reading sources... [  8%] media/kapi/v4l2-mc
reading sources... [  8%] media/kapi/v4l2-mediabus
reading sources... [  8%] media/kapi/v4l2-mem2mem
reading sources... [  8%] media/kapi/v4l2-of
reading sources... [  9%] media/kapi/v4l2-rect
reading sources... [  9%] media/kapi/v4l2-subdev
reading sources... [  9%] media/kapi/v4l2-tuner
reading sources... [  9%] media/kapi/v4l2-tveeprom
reading sources... [  9%] media/kapi/v4l2-videobuf
reading sources... [ 10%] media/kapi/v4l2-videobuf2
reading sources... [ 10%] media/media_kapi
reading sources... [ 10%] media/media_uapi
reading sources... [ 10%] media/uapi/cec/cec-api
reading sources... [ 10%] media/uapi/cec/cec-func-close
reading sources... [ 11%] media/uapi/cec/cec-func-ioctl
reading sources... [ 11%] media/uapi/cec/cec-func-open
reading sources... [ 11%] media/uapi/cec/cec-func-poll
reading sources... [ 11%] media/uapi/cec/cec-funcs
reading sources... [ 11%] media/uapi/cec/cec-header
reading sources... [ 12%] media/uapi/cec/cec-intro
reading sources... [ 12%] media/uap

Re: [RFC PATCH-tip v4 01/10] locking/osq: Make lock/unlock proper acquire/release barrier

[Davidlohr Bueso]

On Thu, 18 Aug 2016, Waiman Long wrote:


The osq_lock() and osq_unlock() function may not provide the necessary
acquire and release barrier in some cases. This patch makes sure
that the proper barriers are provided when osq_lock() is successful
or when osq_unlock() is called.


But why do we need these guarantees given that osq is only used internally
for lock owner spinning situations? Leaking out of the critical region will
obviously be bad if using it as a full lock, but, as is, this can only hurt
performance of two of the most popular locks in the kernel -- although yes,
using smp_acquire__after_ctrl_dep is nicer for polling.

If you need tighter osq for rwsems, could it be refactored such that mutexes
do not take a hit?



Suggested-by: Peter Zijlstra (Intel) 
Signed-off-by: Waiman Long 
---
kernel/locking/osq_lock.c |   24 ++--
1 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c
index 05a3785..3da0b97 100644
--- a/kernel/locking/osq_lock.c
+++ b/kernel/locking/osq_lock.c
@@ -124,6 +124,11 @@ bool osq_lock(struct optimistic_spin_queue *lock)

cpu_relax_lowlatency();
}
+   /*
+* Add an acquire memory barrier for pairing with the release barrier
+* in unlock.
+*/
+   smp_acquire__after_ctrl_dep();
return true;

unqueue:
@@ -198,13 +203,20 @@ void osq_unlock(struct optimistic_spin_queue *lock)
 * Second most likely case.
 */
node = this_cpu_ptr(&osq_node);
-   next = xchg(&node->next, NULL);
-   if (next) {
-   WRITE_ONCE(next->locked, 1);
+   next = xchg_relaxed(&node->next, NULL);
+   if (next)
+   goto unlock;
+
+   next = osq_wait_next(lock, node, NULL);
+   if (unlikely(!next)) {
+   /*
+* In the unlikely event that the OSQ is empty, we need to
+* provide a proper release barrier.
+*/
+   smp_mb();
return;
}

-   next = osq_wait_next(lock, node, NULL);
-   if (next)
-   WRITE_ONCE(next->locked, 1);
+unlock:
+   smp_store_release(&next->locked, 1);
}


As well as for the smp_acquire__after_ctrl_dep comment you have above, this also
obviously pairs with the osq_lock's smp_load_acquire while backing out 
(unqueueing,
step A). Given the above, for this case we might also just rely on 
READ_ONCE(node->locked),
if we get the conditional wrong and miss the node becoming locked, all we do is 
another
iteration, and while there is a cmpxchg() there, it is mitigated with the ccas 
thingy.

Thanks,
Davidlohr
--
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 05/17] README: convert it to ReST markup

[Diego Viola]

On Wed, Sep 21, 2016 at 4:09 PM, Mauro Carvalho Chehab
 wrote:
> Adjust the readme file for it to use the ReST markup:
>
> - add chapter/section markups;
> - use ``foo`` for commands;
> - use :: for verbatim and script blocks;
> - replace unsupported markup _foo_ by **foo**;
> - add cross-references to other ReST files;
> - use lower case on the section titles, to match other ReST files.
>
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  README | 105 
> -
>  1 file changed, 58 insertions(+), 47 deletions(-)
>
> diff --git a/README b/README
> index 09f34f78f2bb..3335b3b2973a 100644
> --- a/README
> +++ b/README
> @@ -1,10 +1,12 @@
> -Linux kernel release 4.x 
> +Linux kernel release 4.x 
> +=
>
>  These are the release notes for Linux version 4.  Read them carefully,
>  as they tell you what this is all about, explain how to install the
>  kernel, and what to do if something goes wrong.
>
> -WHAT IS LINUX?
> +What is Linux?
> +--
>
>Linux is a clone of the operating system Unix, written from scratch by
>Linus Torvalds with assistance from a loosely-knit team of hackers across
> @@ -18,7 +20,8 @@ WHAT IS LINUX?
>It is distributed under the GNU General Public License - see the
>accompanying COPYING file for more details.
>
> -ON WHAT HARDWARE DOES IT RUN?
> +On what hardware does it run?
> +-
>
>Although originally developed first for 32-bit x86-based PCs (386 or 
> higher),
>today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC and
> @@ -34,7 +37,8 @@ ON WHAT HARDWARE DOES IT RUN?
>Linux has also been ported to itself. You can now run the kernel as a
>userspace application - this is called UserMode Linux (UML).
>
> -DOCUMENTATION:
> +Documentation
> +-
>
>   - There is a lot of documentation available both in electronic form on
> the Internet and in books, both Linux-specific and pertaining to
> @@ -53,14 +57,15 @@ DOCUMENTATION:
>   - The Documentation/DocBook/ subdirectory contains several guides for
> kernel developers and users.  These guides can be rendered in a
> number of formats:  PostScript (.ps), PDF, HTML, & man-pages, among 
> others.
> -   After installation, "make psdocs", "make pdfdocs", "make htmldocs",
> -   or "make mandocs" will render the documentation in the requested format.
> +   After installation, ``make psdocs``, ``make pdfdocs``, ``make htmldocs``,
> +   or ``make mandocs`` will render the documentation in the requested format.
>
> -INSTALLING the kernel source:
> +Installing the kernel source
> +
>
>   - If you install the full sources, put the kernel tarball in a
> directory where you have permissions (e.g. your home directory) and
> -   unpack it:
> +   unpack it::
>
>   xz -cd linux-4.X.tar.xz | tar xvf -
>
> @@ -74,12 +79,12 @@ INSTALLING the kernel source:
>   - You can also upgrade between 4.x releases by patching.  Patches are
> distributed in the xz format.  To install by patching, get all the
> newer patch files, enter the top level directory of the kernel source
> -   (linux-4.X) and execute:
> +   (linux-4.X) and execute::
>
>   xz -cd ../patch-4.x.xz | patch -p1
>
> Replace "x" for all versions bigger than the version "X" of your current
> -   source tree, _in_order_, and you should be ok.  You may want to remove
> +   source tree, **in_order**, and you should be ok.  You may want to remove
> the backup files (some-file-name~ or some-file-name.orig), and make sure
> that there are no failed patches (some-file-name# or some-file-name.rej).
> If there are, either you or I have made a mistake.
> @@ -90,12 +95,12 @@ INSTALLING the kernel source:
> and you want to apply the 4.0.3 patch, you must not first apply the 4.0.1
> and 4.0.2 patches. Similarly, if you are running kernel version 4.0.2 and
> want to jump to 4.0.3, you must first reverse the 4.0.2 patch (that is,
> -   patch -R) _before_ applying the 4.0.3 patch. You can read more on this in
> -   Documentation/applying-patches.txt
> +   patch -R) **before** applying the 4.0.3 patch. You can read more on this 
> in
> +   :ref:`Documentation/applying-patches.txt `.
>
> Alternatively, the script patch-kernel can be used to automate this
> process.  It determines the current kernel version and applies any
> -   patches found.
> +   patches found::
>
>   linux/scripts/patch-kernel linux
>
> @@ -103,55 +108,58 @@ INSTALLING the kernel source:
> kernel source.  Patches are applied from the current directory, but
> an alternative directory can be specified as the second argument.
>
> - - Make sure you have no stale .o files and dependencies lying around:
> + - Make sure you have no stale .o files and dependencies lying around::
>
>   cd linux
>   make mrproper
>

Re: [PATCH 05/17] README: convert it to ReST markup

[Diego Viola]

On Tue, Oct 4, 2016 at 4:42 PM, Diego Viola  wrote:
> On Wed, Sep 21, 2016 at 4:09 PM, Mauro Carvalho Chehab
>  wrote:
>> Adjust the readme file for it to use the ReST markup:
>>
>> - add chapter/section markups;
>> - use ``foo`` for commands;
>> - use :: for verbatim and script blocks;
>> - replace unsupported markup _foo_ by **foo**;
>> - add cross-references to other ReST files;
>> - use lower case on the section titles, to match other ReST files.
>>
>> Signed-off-by: Mauro Carvalho Chehab 
>> ---
>>  README | 105 
>> -
>>  1 file changed, 58 insertions(+), 47 deletions(-)
>>
>> diff --git a/README b/README
>> index 09f34f78f2bb..3335b3b2973a 100644
>> --- a/README
>> +++ b/README
>> @@ -1,10 +1,12 @@
>> -Linux kernel release 4.x 
>> +Linux kernel release 4.x 
>> +=
>>
>>  These are the release notes for Linux version 4.  Read them carefully,
>>  as they tell you what this is all about, explain how to install the
>>  kernel, and what to do if something goes wrong.
>>
>> -WHAT IS LINUX?
>> +What is Linux?
>> +--
>>
>>Linux is a clone of the operating system Unix, written from scratch by
>>Linus Torvalds with assistance from a loosely-knit team of hackers across
>> @@ -18,7 +20,8 @@ WHAT IS LINUX?
>>It is distributed under the GNU General Public License - see the
>>accompanying COPYING file for more details.
>>
>> -ON WHAT HARDWARE DOES IT RUN?
>> +On what hardware does it run?
>> +-
>>
>>Although originally developed first for 32-bit x86-based PCs (386 or 
>> higher),
>>today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC and
>> @@ -34,7 +37,8 @@ ON WHAT HARDWARE DOES IT RUN?
>>Linux has also been ported to itself. You can now run the kernel as a
>>userspace application - this is called UserMode Linux (UML).
>>
>> -DOCUMENTATION:
>> +Documentation
>> +-
>>
>>   - There is a lot of documentation available both in electronic form on
>> the Internet and in books, both Linux-specific and pertaining to
>> @@ -53,14 +57,15 @@ DOCUMENTATION:
>>   - The Documentation/DocBook/ subdirectory contains several guides for
>> kernel developers and users.  These guides can be rendered in a
>> number of formats:  PostScript (.ps), PDF, HTML, & man-pages, among 
>> others.
>> -   After installation, "make psdocs", "make pdfdocs", "make htmldocs",
>> -   or "make mandocs" will render the documentation in the requested format.
>> +   After installation, ``make psdocs``, ``make pdfdocs``, ``make htmldocs``,
>> +   or ``make mandocs`` will render the documentation in the requested 
>> format.
>>
>> -INSTALLING the kernel source:
>> +Installing the kernel source
>> +
>>
>>   - If you install the full sources, put the kernel tarball in a
>> directory where you have permissions (e.g. your home directory) and
>> -   unpack it:
>> +   unpack it::
>>
>>   xz -cd linux-4.X.tar.xz | tar xvf -
>>
>> @@ -74,12 +79,12 @@ INSTALLING the kernel source:
>>   - You can also upgrade between 4.x releases by patching.  Patches are
>> distributed in the xz format.  To install by patching, get all the
>> newer patch files, enter the top level directory of the kernel source
>> -   (linux-4.X) and execute:
>> +   (linux-4.X) and execute::
>>
>>   xz -cd ../patch-4.x.xz | patch -p1
>>
>> Replace "x" for all versions bigger than the version "X" of your current
>> -   source tree, _in_order_, and you should be ok.  You may want to remove
>> +   source tree, **in_order**, and you should be ok.  You may want to remove
>> the backup files (some-file-name~ or some-file-name.orig), and make sure
>> that there are no failed patches (some-file-name# or some-file-name.rej).
>> If there are, either you or I have made a mistake.
>> @@ -90,12 +95,12 @@ INSTALLING the kernel source:
>> and you want to apply the 4.0.3 patch, you must not first apply the 4.0.1
>> and 4.0.2 patches. Similarly, if you are running kernel version 4.0.2 and
>> want to jump to 4.0.3, you must first reverse the 4.0.2 patch (that is,
>> -   patch -R) _before_ applying the 4.0.3 patch. You can read more on this in
>> -   Documentation/applying-patches.txt
>> +   patch -R) **before** applying the 4.0.3 patch. You can read more on this 
>> in
>> +   :ref:`Documentation/applying-patches.txt `.
>>
>> Alternatively, the script patch-kernel can be used to automate this
>> process.  It determines the current kernel version and applies any
>> -   patches found.
>> +   patches found::
>>
>>   linux/scripts/patch-kernel linux
>>
>> @@ -103,55 +108,58 @@ INSTALLING the kernel source:
>> kernel source.  Patches are applied from the current directory, but
>> an alternative directory can be specified as the second argument.
>>
>> - - Make sure you

Re: [PATCH v3 4/5] powerpc/mm: restore top-down allocation when using movable_node

[Reza Arbab]

On Tue, Oct 04, 2016 at 11:48:30AM +1100, Balbir Singh wrote:

On 27/09/16 10:14, Reza Arbab wrote:
Right. To be clear, the background info I put in the commit log 
refers to x86, where the SRAT can describe movable nodes which exist 
at boot.  They're trying to avoid allocations from those nodes before 
they've been identified.


On power, movable nodes can only exist via hotplug, so that scenario 
can't happen. We can immediately go back to top-down allocation. That 
is the missing call being added in the patch.


Can we fix cmdline_parse_movable_node() to do the right thing? I 
suspect that code is heavily x86 only in the sense that no other arch 
needs it.


Good idea. We could change it so things only go bottom-up on x86 in the 
first place.


A nice consequence is that CONFIG_MOVABLE_NODE would then basically be 
usable on any platform with memory hotplug, not just PPC64 and X86_64.


I'll see if I can move the relevant code into an arch_*() call or 
otherwise factor it out.


--
Reza Arbab

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

Re: [RFC PATCH-tip v4 01/10] locking/osq: Make lock/unlock proper acquire/release barrier

[Jason Low]

On Tue, Oct 4, 2016 at 12:06 PM, Davidlohr Bueso  wrote:
> On Thu, 18 Aug 2016, Waiman Long wrote:
>
>> The osq_lock() and osq_unlock() function may not provide the necessary
>> acquire and release barrier in some cases. This patch makes sure
>> that the proper barriers are provided when osq_lock() is successful
>> or when osq_unlock() is called.
>
>
> But why do we need these guarantees given that osq is only used internally
> for lock owner spinning situations? Leaking out of the critical region will
> obviously be bad if using it as a full lock, but, as is, this can only hurt
> performance of two of the most popular locks in the kernel -- although yes,
> using smp_acquire__after_ctrl_dep is nicer for polling.
>
> If you need tighter osq for rwsems, could it be refactored such that mutexes
> do not take a hit?

I agree with David, the OSQ is meant to be used internally as a
queuing mechanism than as something for protecting critical regions,
and so these guarantees of preventing critical section leaks don't
seem to be necessary for the OSQ. If that is the case, then it would
be better to avoid the performance hit to mutexes and rwsems.

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: [RFC] fs: add userspace critical mounts event support

[Luis R. Rodriguez]

On Sat, Sep 24, 2016 at 10:41:46AM -0700, Dmitry Torokhov wrote:
> On Fri, Sep 23, 2016 at 6:37 PM, Herbert, Marc  wrote:
> > On 03/09/2016 11:10, Dmitry Torokhov wrote:
> >> I was thinking if we kernel could post
> >> "conditions" (maybe simple stings) that it waits for, and userspace
> >> could unlock these "conditions". One of them might be "firmware
> >> available".
> >
> > On idea offered by Josh Triplett that seems to overlap with this one
> > is to have something similar to the (deprecated) userhelper with
> > *per-blob* requests and notifications except for one major difference:
> > userspace would not anymore be in charge of *providing* the blob but
> > would instead only *signal* when a given blob becomes available and is
> > either found or found missing. Then the kernel loads the blob _by
> > itself_; unlike the userhelper. No new “critical filesystem” concept
> > and a *per-blob basis*, allowing any variation of blob locations
> > across any number of initramfs and filesystems.
> >
> 
> Really, I do not quite understand why people have issues with usermode
> helper/uevents.

One reason is you'd have to implement your own cache for suspend/resume.

> It used to work reasonably well (if you were using
> request_firmware_nowait()), as the kernel would post the request and
> then, when userspace was ready[^Hier], uevents would be processed and
> firmware would be loaded. We had a timeout of 60(?) seconds by
> default, but that would be adjusted as systems needed.

The issue with the timeout was kernel developers *assumed* module init
and probe were detached, and saying 'thou shall not load firmware on
probe' seems actually like a more radical change than just saying
'thou shall load firmware on init'. I'll note that as it stands
its the right thing to complain about these users only because we
lack the semantics to ensure correctness if used on init or probe.
The timeout incurred huge latencies for optional firmwares, and
while we had a new API added to avoid the wait on optional firmware,
that obviously still leaved the races as possible. We now have async
probe which *does* enable some original misconceptions by kernel
developers, but by now other issues have also been found on the
usermode helper, the cache was one, another one was a recent discusion
over the user of the UMH lock with the assumption this was providing
a sort of safeguard on early boot use -- it does not, for the same
exact reasons why a UMH lock does not suffice to avoid all possible
rootfs races. For this later issue refer to a recent discussion in
review with Daniel Wagner's patches.

> Unfortunately it all broke when udev started insisting [1] on
> servicing some uevents in strict sequence, which resulted in boot
> stalls.

That was not the only issue... another implicit issue was that
you are reducing the number of possible supported number of
devices Linux supports per module by the timeout, it would
depend on the combine time it takes to both init and probe.
Some drivers are super complex and even if you *don't* have
firmware requirements and say burn the firmware onto a device
we found that *probe* alone was taking a long long time on some
device drivers -- check out cxgb4 driver, where one device actually
ends up loading about 4 subdevices underneath it. Yes that's a mess
and the driver needs a major rewrite to address this in a clean way
but that takes time. Its no trivial pursuit. The umh timeout then
would not be implicated anymore *but* since systemd implemented the
timeout in general for kmod loading it did mean system was limiting
them Linux drivers and how much devices a driver can support
depending on this timeout value. At SUSE we solved this by lifting
this timeout for kmod workers for now. A long term goal here, which
could help, is also to just detach init and probes, so we give to
system what it originally thought. Summary of this all is here:

http://www.do-not-panic.com/2015/12/linux-asynchronous-probe.html

I have some code that starts to enable some of this on systemd/kmod
but it still needs some more testing before I post.

> Maybe the ultimate answer is to write a firmware loading
> daemon that would also listen to netlink events and do properly what
> udev refused to be doing?

Meh, in the wireless subsystem we devised our own file loader,
check CRDA. That worked for us since we needed to optionally
enable digital RSA signed file checking, but long term our
experience is that this is pointless. So we're going to phase
that out in favor of using the firmware API for the file loading
of this file, and support then digital signatures on the firmware.

I am not sure how/why a firmware loading daemon would be a better
idea now. What Marc describes that Josh proposed with signals for
userspcae seems more aligned with what we likely need -- but note
that since we now use a shared common API for kernel reads from a
path via kernel_read_file_from_path() we'd probably want something
like a notifier for any ker

Re: [RFC] fs: add userspace critical mounts event support

[Linus Torvalds]

On Tue, Oct 4, 2016 at 5:00 PM, Luis R. Rodriguez  wrote:
>
> I am not sure how/why a firmware loading daemon would be a better
> idea now. What Marc describes that Josh proposed with signals for
> userspcae seems more aligned with what we likely need

Quite frankly, I doubt you want a signal.

You will want to have some way to specify where the firmware files
are. Right now we have "fw_path[]" which is hardcoded except for the
first entry that can be set as a module parameter. But you'd probably
want to expand on that, which implies some /sys or /proc interface.

And once you do that, wouldn't it make more sense to just make the
"update the firmware path /proc/sys/kernel/fw_path file" make things
re-search for firmware?

In other words, the interface has to be something *sensible*. Not some
idiotic ad-hoc "send a signal" (of which that stupid original patch
was just a very odd example).

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

Re: [RFC] fs: add userspace critical mounts event support

[Luis R. Rodriguez]

On Tue, Oct 4, 2016 at 5:12 PM, Linus Torvalds
 wrote:
> On Tue, Oct 4, 2016 at 5:00 PM, Luis R. Rodriguez  wrote:
>>
>> I am not sure how/why a firmware loading daemon would be a better
>> idea now. What Marc describes that Josh proposed with signals for
>> userspcae seems more aligned with what we likely need
>
> Quite frankly, I doubt you want a signal.
>
> You will want to have some way to specify where the firmware files
> are. Right now we have "fw_path[]" which is hardcoded except for the
> first entry that can be set as a module parameter. But you'd probably
> want to expand on that, which implies some /sys or /proc interface.
>
> And once you do that, wouldn't it make more sense to just make the
> "update the firmware path /proc/sys/kernel/fw_path file" make things
> re-search for firmware?

We can, but re-searching for firmware assumes we cache pending
firmware, we currently don't, we just either process sync or async
firmware requests.

> In other words, the interface has to be something *sensible*. Not some
> idiotic ad-hoc "send a signal" (of which that stupid original patch
> was just a very odd example).

Note that the races are beyond firmware, so all
kernel_read_file_from_path() users, as such re-using such old /sys/
interafeces for firmware will not suffice to cover all ground now for
the same race for other possible users.

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

Re: [RFC] fs: add userspace critical mounts event support

[Linus Torvalds]

On Tue, Oct 4, 2016 at 5:24 PM, Luis R. Rodriguez  wrote:
>
> Note that the races are beyond firmware, so all
> kernel_read_file_from_path() users, as such re-using such old /sys/
> interafeces for firmware will not suffice to cover all ground now for
> the same race for other possible users.

Blah blah blah.

The reason I've hated this whole discussion is that it's full of
"let's re-architect everything", and then it has these horribly warty
interfaces. It's classic second-system syndrome.

Just do *one* thing, and do it well. Don't change anything else. Don't
force existign drivers to use new interfaces. Don't over-architect,
and don't do stupid interfaces.

If user-space mounts a new filesystem (or just unpacks files from a
tar-file that has firmware images in it, for chissake), that is not
some magical "critical mount event". The whole concept is just stupid.
Is it a "mount event" when the user downloads a new firmware image
from the internet?

HELL NO.

But what is equally stupid is to then dismiss simple models because
some totally unrelated "beyond firmware" issue.

Anything that is "beyond firmware" shouldn't even be discussed, for
chrissake! It has nothing what-so-ever to do with firmware loading. If
there ends up being some common helper functions, and shared code,
that *still* doesn't make it so.

Basic rules of thumb:

 (a) don't over-design

 (b) don't have stupid illogical interfaces

 (c) don't conflate different issues just because you think they may
have shared code.

 (4) be consistent. Don't make up new interfaces, and most certainly
do *NOT* dismiss something just because it's what we have done before.

That's it.

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

Re: [RFC] fs: add userspace critical mounts event support

[Josh Triplett]

On Tue, Oct 04, 2016 at 05:12:58PM -0700, Linus Torvalds wrote:
> On Tue, Oct 4, 2016 at 5:00 PM, Luis R. Rodriguez  wrote:
> > I am not sure how/why a firmware loading daemon would be a better
> > idea now. What Marc describes that Josh proposed with signals for
> > userspcae seems more aligned with what we likely need
> 
> Quite frankly, I doubt you want a signal.
> 
> You will want to have some way to specify where the firmware files
> are. Right now we have "fw_path[]" which is hardcoded except for the
> first entry that can be set as a module parameter. But you'd probably
> want to expand on that, which implies some /sys or /proc interface.
> 
> And once you do that, wouldn't it make more sense to just make the
> "update the firmware path /proc/sys/kernel/fw_path file" make things
> re-search for firmware?

That could work, but it seems like overkill to allow changing the path,
rather than the simpler interface of just telling the one driver "go
ahead and direct-load your firmware now".  I definitely don't think it
should be a system-wide "mount event"; it should be a per-device "go
direct-load your firmware" poke from userspace.  That would solve the
"build-in the driver so it can start waking up slow monitors, but wait
to load the firmware until you have a filesystem" problem.  (And it
would avoid creating some unusual driver-specific late-firmware-load
mechanism.)

That said, the Chrome OS folks apparently have some mechanism where they
mount a tmpfs over /lib/firmware to let userspace choose firmware at
runtime, so perhaps the path-changing mechanism would help there.  Kees?
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] fs: add userspace critical mounts event support

[Linus Torvalds]

On Tue, Oct 4, 2016 at 6:48 PM, Josh Triplett  wrote:
>
>I definitely don't think it
> should be a system-wide "mount event"; it should be a per-device "go
> direct-load your firmware" poke from userspace.

I don't disagree with that kind of interface. We already have things
like "rescan" for PCI bus devices to force a bus rescan. Iit's a
simple device attribute. Having a similar thing to trigger firmware
reload for a driver sounds entirely sane.

  Linus
--
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: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller

[Christoph Hellwig]

FYI, the patches look fine to me:

Acked-by: Christoph Hellwig 

but we're past the merge window for 4.9 now unfortunately.
--
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