Mail System Error - Returned Mail

[MAILER-DAEMON]

šõ?îLK¶H7$™~Á}4Ú¥(À׆¡Åcž
HîeŒg»Í-·`•G%æÐÒfƒ(L4xD™˜û"ò#Tý"Ÿª«Ë`þ¯°#bÐd7àj›øë¾øÀ(D.Åé<”Œ…õž…
žX«©Ò¾%ëÎc¥ÃH¶ÈúÀóþü:áÎj7¿ÁŸïͬ³âœH#|ëQ‘jßø ±¡T6QT„¢UÀR1x´R¸(>ª8ƒàQ0XB 
`Úõ•²”d×U/ÅÂàZõuQáw¨¢šôI6nåPc7À¨:oœPbHlø?¹5ëÌs›DçlÆTƒCE%ì‹<ò_Pbèv|ñ‘5¿äwQKvV1hu\8ñ×ä.â¦Mï²·/q3‘í
 
ß´ÈVD½\è¯r’µÂè"|û䑯–¹²üc³NT!;vü3NLío§‘Ø~„¯pʏs¿ðëYN'ŒFCËVm³Âúû’`MÛ{œ›¹©x{²K(‹hâõq¢Z?ƒw—ùNÖï*¥ëŽ`$ÔM¡÷¯ß©.-’“~†{¼$§Nd
…OšV‰þ¡¦å³%˜j¶ Èꌆ˜'ívM·ÛòCG] 
kn†³âfS™Ù¸V’DüÄÒDv…ŠeÛCÁR0W3¼•à᲎~s%:°Ð:#
â~¢ÜþFîJ]×(]þcN©5uåRãYÙñ¼ÚHÐ,¶¾Gôq·»Y®IÙ:KZÁݤ,éÛvMu][¸¨Rø_~Åyî®Ôn"›œY#듺³LËÄ»©á醱½îb˜¢Âc;ﮟы*ó‰ÞÖ¯iþAeÚþÛÁ‚˜”úïg¶¬®cè¹
¡tf4|ø~åHCü„C`aÖAHz'#gê0`ח¤Eãâ:PlŸ{¦2v¬8»ê}8Æwp|ÖØ:ºuœ
î(…q‘ìÉ$üB¿óÑÈR;ØÂþޏiÖqla
ËD^]ƒM¿QBFò^¿)ÔBOsQãù:‰:;äêr°{zÞé£9ÙƳ–½ÄPXR©>¨”ýWãÁ‡ÇÈ>µ±/Ô<½eÑÊÕùG$
_Aè˜èU¥}—²¹c¢Š«êT”ä°Pz^‹SS“\³çi~šYr/M¯o†Òc9Ò2_Tþƪ4Öà²Ó!¯‘úY[ùþ£:ûq8Û¸OT‘À"H{dGâe'Ó8œÁRqýÊ>Äô“ö8ûE;ˁ‚—m"ÃZiiüôdM¬ëҖÎetK3qç8ȃ2Mr¤ŠÕÌïé7•¨
 ¾vÙÏ:ŒË
ó${ß½r·²bvT*9*ÙR÷Í?ϖ‚­DÖ
O˜àX³™Óù|4%–±>C‰SÎêÆt¯#%TÈÚåmYYÍeß
æ·JG25ar9ÝÄÃ/iþŽC"ýfé’îjÏGɜ‘ËÎ6¼«›nßSiåÖ6[ßóB½4D8ë¼]ýã®ÜH³¢¨6©U¼·;­s±â$±!ö©X¥.õ#Ú£7º
 Ì³†«Ž”wˁfD¿Våwúh^4¶w[ø*kR!Šì-î¶fWç<083Ž[˜šÚEê;Blå˜FYed;
A!?ÃËïL«°L,35«?¸oÛ"Qã± xÏêJ¢’*[6
á¡ N%ŸëƒêöàË
à(

___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH v8 15/18] mm, fs, dax: handle layout changes to pinned dax mappings

[Dan Williams]

On Thu, Apr 19, 2018 at 3:44 AM, Jan Kara  wrote:
> On Fri 13-04-18 15:03:51, Dan Williams wrote:
>> On Mon, Apr 9, 2018 at 9:51 AM, Dan Williams  
>> wrote:
>> > On Mon, Apr 9, 2018 at 9:49 AM, Jan Kara  wrote:
>> >> On Sat 07-04-18 12:38:24, Dan Williams wrote:
>> > [..]
>> >>> I wonder if this can be trivially solved by using srcu. I.e. we don't
>> >>> need to wait for a global quiescent state, just a
>> >>> get_user_pages_fast() quiescent state. ...or is that an abuse of the
>> >>> srcu api?
>> >>
>> >> Well, I'd rather use the percpu rwsemaphore (linux/percpu-rwsem.h) than
>> >> SRCU. It is a more-or-less standard locking mechanism rather than relying
>> >> on implementation properties of SRCU which is a data structure protection
>> >> method. And the overhead of percpu rwsemaphore for your use case should be
>> >> about the same as that of SRCU.
>> >
>> > I was just about to ask that. Yes, it seems they would share similar
>> > properties and it would be better to use the explicit implementation
>> > rather than a side effect of srcu.
>>
>> ...unfortunately:
>>
>>  BUG: sleeping function called from invalid context at
>> ./include/linux/percpu-rwsem.h:34
>>  [..]
>>  Call Trace:
>>   dump_stack+0x85/0xcb
>>   ___might_sleep+0x15b/0x240
>>   dax_layout_lock+0x18/0x80
>>   get_user_pages_fast+0xf8/0x140
>>
>> ...and thinking about it more srcu is a better fit. We don't need the
>> 100% exclusion provided by an rwsem we only need the guarantee that
>> all cpus that might have been running get_user_pages_fast() have
>> finished it at least once.
>>
>> In my tests synchronize_srcu is a bit slower than unpatched for the
>> trivial 100 truncate test, but certainly not the 200x latency you were
>> seeing with syncrhonize_rcu.
>>
>> Elapsed time:
>> 0.006149178 unpatched
>> 0.009426360 srcu
>
> Hum, right. Yesterday I was looking into KSM for a different reason and
> I've noticed it also does writeprotect pages and deals with races with GUP.
> And what KSM relies on is:
>
> write_protect_page()
>   ...
>   entry = ptep_clear_flush(vma, pvmw.address, pvmw.pte);
>   /*
>* Check that no O_DIRECT or similar I/O is in progress on the
>* page
>*/
>   if (page_mapcount(page) + 1 + swapped != page_count(page)) {
> page used -> bail

Slick.

>   }
>
> And this really works because gup_pte_range() does:
>
>   page = pte_page(pte);
>   head = compound_head(page);
>
>   if (!page_cache_get_speculative(head))
> goto pte_unmap;
>
>   if (unlikely(pte_val(pte) != pte_val(*ptep))) {
> bail

Need to add a similar check to __gup_device_huge_pmd.

>   }
>
> So either write_protect_page() page sees the elevated reference or
> gup_pte_range() bails because it will see the pte changed.
>
> In the truncate path things are a bit different but in principle the same
> should work - once truncate blocks page faults and unmaps pages from page
> tables, we can be sure GUP will not grab the page anymore or we'll see
> elevated page count. So IMO there's no need for any additional locking
> against the GUP path (but a comment explaining this is highly desirable I
> guess).

Yes, those "pte_val(pte) != pte_val(*ptep)" checks should be
documented for the same reason we require comments on rmb/wmb pairs.
I'll take a look, thanks Jan.
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Write through caching on NVDIMM

[Brian Stark]

I was comparing different caching techniques using MTRR entries and I
found something strange.  Note the output is from a basic utility that
uses mmap.

NV Memory:

Write-back

Writes took 2075.993408 Megabytes per second
Reads took 2130.842529 Megabytes per second No Errors Found

Write-Through

Writes took 55.332256 Megabytes per second
Reads took 92.310310 Megabytes per second No Errors Found  !!!I was
expecting this number to be the same as Write-back

Uncached

Writes took 55.331089 Megabytes per second
Reads took 92.315132 Megabytes per second No Errors Found

Regular memory:

Write-back

Writes took 1875.560791 Megabytes per second
Reads took 2070.452637 Megabytes per second No Errors Found

Write-Through

Writes took 54.903713 Megabytes per second
Reads took 2106.244629 Megabytes per second No Errors Found  !!!This
is what I expected to see for NV Memory

Uncached

Writes took 54.903923 Megabytes per second
Reads took 90.150986 Megabytes per second No Errors Found

I am using the same driver (which adds MTRR entries to change caching
type) there is no physical reason why write through should behave
differently when using NV Memory.  Does anybody on this mailing list
who may be more familiar with caching techniques know why this might
me the case?

Brian

-- 
CONFIDENTIALITY
This e-mail message and any attachments thereto, is 
intended only for use by the addressee(s) named herein and may contain 
legally privileged and/or confidential information. If you are not the 
intended recipient of this e-mail message, you are hereby notified that any 
dissemination, distribution or copying of this e-mail message, and any 
attachments thereto, is strictly prohibited.  If you have received this 
e-mail message in error, please immediately notify the sender and 
permanently delete the original and any copies of this email and any prints 
thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS 
E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING.  Notwithstanding the 
Uniform Electronic Transactions Act or the applicability of any other law 
of similar substance and effect, absent an express statement to the 
contrary hereinabove, this e-mail message its contents, and any attachments 
hereto are not intended to represent an offer or acceptance to enter into a 
contract and are not otherwise intended to bind the sender, Sanmina 
Corporation (or any of its subsidiaries), or any other person or entity.
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH v2] dax: allow MAP_SYNC for device-dax mmap() to succeed

[Dan Williams]

On Thu, Apr 19, 2018 at 1:39 PM, Dave Jiang  wrote:
> MAP_SYNC is a nop for device-dax. Allow MAP_SYNC to succeed on device-dax
> to eliminate special casing between device-dax and fs-dax as to when the
> flag can be specified. Device-dax users already implicitly assume that they do
> not need to call fsync(), and this enables them to explicitly check for this
> capability.
>
> Signed-off-by: Dave Jiang 
> ---
>
> v2: update commit message with suggestion from Dan.

Looks good,

Reviewed-by: Dan Williams 
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

[PATCH v2] dax: allow MAP_SYNC for device-dax mmap() to succeed

[Dave Jiang]

MAP_SYNC is a nop for device-dax. Allow MAP_SYNC to succeed on device-dax
to eliminate special casing between device-dax and fs-dax as to when the
flag can be specified. Device-dax users already implicitly assume that they do
not need to call fsync(), and this enables them to explicitly check for this
capability.

Signed-off-by: Dave Jiang 
---

v2: update commit message with suggestion from Dan.

 drivers/dax/device.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/dax/device.c b/drivers/dax/device.c
index 37be5a306c8f..374b6718f6c5 100644
--- a/drivers/dax/device.c
+++ b/drivers/dax/device.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "dax-private.h"
 #include "dax.h"
 
@@ -530,6 +531,7 @@ static const struct file_operations dax_fops = {
.release = dax_release,
.get_unmapped_area = dax_get_unmapped_area,
.mmap = dax_mmap,
+   .mmap_supported_flags = MAP_SYNC,
 };
 
 static void dev_dax_release(struct device *dev)

___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH] dax: allowing MAP_SYNC for device-dax mmap() to succeed

[Dan Williams]

I'll change the "allowing" to "allow" in the subject so we don't have
a gerund phrase.

On Thu, Apr 19, 2018 at 11:22 AM, Dave Jiang  wrote:
> MAP_SYNC is basically a nop for device-dax. However allowing the MAP_SYNC

Not "bascially", it *is* a nop for device-dax. I'll change this second
sentence to start "Allow MAP_SYNC to succeed on device-dax to
eliminate special casing between device-dax and fs-dax as to when the
flag can be specified."

> flag to succeed on device-dax would make it consistent with fs-dax and
> reduces confusion for the application writer. This allows the application to
> assume that it does not need to call fsync() after writes to device-dax
> mappings.

I'll change this last sentence to say "Device-dax users already
implicitly assume that they do not need to call fsync(), enable them
to explicitly check for this capability".
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

[PATCH] dax: allowing MAP_SYNC for device-dax mmap() to succeed

[Dave Jiang]

MAP_SYNC is basically a nop for device-dax. However allowing the MAP_SYNC
flag to succeed on device-dax would make it consistent with fs-dax and
reduces confusion for the application writer. This allows the application to
assume that it does not need to call fsync() after writes to device-dax
mappings.

Signed-off-by: Dave Jiang 
---
 drivers/dax/device.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/dax/device.c b/drivers/dax/device.c
index 37be5a306c8f..374b6718f6c5 100644
--- a/drivers/dax/device.c
+++ b/drivers/dax/device.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "dax-private.h"
 #include "dax.h"
 
@@ -530,6 +531,7 @@ static const struct file_operations dax_fops = {
.release = dax_release,
.get_unmapped_area = dax_get_unmapped_area,
.mmap = dax_mmap,
+   .mmap_supported_flags = MAP_SYNC,
 };
 
 static void dev_dax_release(struct device *dev)

___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH ndctl v2 0/3] Documentation: add asciidoctor support

[Takashi Iwai]

On Thu, 19 Apr 2018 17:11:17 +0200,
Takashi Iwai wrote:
> 
> Hi,
> 
> this is a revised patchset to add the support for asciidoctor to
> generate documents.  The reason for adding this feature is that the
> future of asciidoc isn't clear as it's written in python2, which is
> now hated by all people out of sudden :)
> 
> The asciidoctor support is enabled via configure option, the default
> is still asciidoc for now.
> 
> thanks,
> 
> Takashi
> 
> 
> v1->v2:
>  * more marker fixes to ndctl man pages
>  * skip superfluous xmlto processing for asciidoctor
>  * add .gitignore entries

... and of course, rebased to shiny v60.


Takashi
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

[PATCH ndctl v2 2/3] Documentation: Add the support for asciidoctor

[Takashi Iwai]

This patch adds the support for asciidoctor to be used for generating
documents instead of asciidoc.  It's enabled via --enable-asciidoctor
configure option while asciidoc is used still as default.

In addition to the configure option, a few other changes were needed:
* some asciidoc.conf python stuff has to be replaced with asciidoctor
  ruby extension; copied mostly from git
* asciidoctor requires slightly different options
* the man pages are generated directly via asciidoctor without xmlto
  processing; less package dependency

Signed-off-by: Takashi Iwai 
---
 Documentation/asciidoctor-extensions.rb.in | 28 
 Documentation/daxctl/Makefile.am   | 28 ++--
 Documentation/ndctl/Makefile.am| 28 ++--
 configure.ac   | 17 +++--
 4 files changed, 95 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/asciidoctor-extensions.rb.in

diff --git a/Documentation/asciidoctor-extensions.rb.in 
b/Documentation/asciidoctor-extensions.rb.in
new file mode 100644
index ..ebdd665f1fb9
--- /dev/null
+++ b/Documentation/asciidoctor-extensions.rb.in
@@ -0,0 +1,28 @@
+require 'asciidoctor'
+require 'asciidoctor/extensions'
+
+module @Utility@
+  module Documentation
+class Link@Utility@Processor < 
Asciidoctor::Extensions::InlineMacroProcessor
+  use_dsl
+
+  named :chrome
+
+  def process(parent, target, attrs)
+if parent.document.basebackend? 'html'
+  prefix = parent.document.attr('@utility@-relative-html-prefix')
+  %(#{target}(#{attrs[1]})\n)
+elsif parent.document.basebackend? 'docbook'
+  "\n" \
+"#{target}" \
+"#{attrs[1]}\n" \
+  "\n"
+end
+  end
+end
+  end
+end
+
+Asciidoctor::Extensions.register do
+  inline_macro @Utility@::Documentation::Link@Utility@Processor, :link@utility@
+end
diff --git a/Documentation/daxctl/Makefile.am b/Documentation/daxctl/Makefile.am
index 259dafd18e5e..7b753095d7a7 100644
--- a/Documentation/daxctl/Makefile.am
+++ b/Documentation/daxctl/Makefile.am
@@ -9,11 +9,22 @@
 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 # General Public License for more details.
 
-do_subst = sed -e 's,UTILITY,daxctl,g'
+if USE_ASCIIDOCTOR
+
+do_subst = sed -e 's,@Utility@,Daxctl,g' -e's,@utility@,daxctl,g'
+CONFFILE = asciidoctor-extensions.rb
+asciidoctor-extensions.rb: ../asciidoctor-extensions.rb.in
+   $(AM_V_GEN) $(do_subst) < $< > $@
 
+else
+
+do_subst = sed -e 's,UTILITY,daxctl,g'
+CONFFILE = asciidoc.conf
 asciidoc.conf: ../asciidoc.conf.in
$(AM_V_GEN) $(do_subst) < $< > $@
 
+endif
+
 man1_MANS = \
daxctl.1 \
daxctl-list.1
@@ -24,10 +35,21 @@ XML_DEPS = \
../../version.m4 \
../copyright.txt \
Makefile \
-   asciidoc.conf
+   $(CONFFILE)
 
 RM ?= rm -f
 
+if USE_ASCIIDOCTOR
+
+%.1: %.txt $(XML_DEPS)
+   $(AM_V_GEN)$(RM) $@+ $@ && \
+   $(ASCIIDOC) -b manpage -d manpage -acompat-mode \
+   -amansource=daxctl -amanmanual="daxctl Manual" \
+   -andctl_version=$(VERSION) -o $@+ $< && \
+   mv $@+ $@
+
+else
+
 %.xml: %.txt $(XML_DEPS)
$(AM_V_GEN)$(RM) $@+ $@ && \
$(ASCIIDOC) -b docbook -d manpage -f asciidoc.conf \
@@ -37,3 +59,5 @@ RM ?= rm -f
 %.1: %.xml $(XML_DEPS)
$(AM_V_GEN)$(RM) $@ && \
$(XMLTO) -o . -m ../manpage-normal.xsl man $<
+
+endif
diff --git a/Documentation/ndctl/Makefile.am b/Documentation/ndctl/Makefile.am
index 4f04087598b5..70ec4597bd06 100644
--- a/Documentation/ndctl/Makefile.am
+++ b/Documentation/ndctl/Makefile.am
@@ -9,11 +9,22 @@
 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 # General Public License for more details.
 
-do_subst = sed -e 's,UTILITY,ndctl,g'
+if USE_ASCIIDOCTOR
+
+do_subst = sed -e 's,@Utility@,Ndctl,g' -e's,@utility@,ndctl,g'
+CONFFILE = asciidoctor-extensions.rb
+asciidoctor-extensions.rb: ../asciidoctor-extensions.rb.in
+   $(AM_V_GEN) $(do_subst) < $< > $@
 
+else
+
+do_subst = sed -e 's,UTILITY,ndctl,g'
+CONFFILE = asciidoc.conf
 asciidoc.conf: ../asciidoc.conf.in
$(AM_V_GEN) $(do_subst) < $< > $@
 
+endif
+
 man1_MANS = \
ndctl.1 \
ndctl-wait-scrub.1 \
@@ -41,7 +52,7 @@ CLEANFILES = $(man1_MANS)
 XML_DEPS = \
../../version.m4 \
Makefile \
-   asciidoc.conf \
+   $(CONFFILE) \
../copyright.txt \
region-description.txt \
xable-region-options.txt \
@@ -54,6 +65,17 @@ XML_DEPS = \
 
 RM ?= rm -f
 
+if USE_ASCIIDOCTOR
+
+%.1: %.txt $(XML_DEPS)
+   $(AM_V_GEN)$(RM) $@+ $@ && \
+   $(ASCIIDOC) -b manpage -d manpage -acompat-mode \
+   -amansource=ndctl -amanmanual="ndctl Manual" \
+   -andctl_version=$(VERSION) -o $@+ $< && \
+   mv $@+ $@
+
+else
+
 %.xml: 

[PATCH ndctl v2 1/3] Documentation: fix title and section markers

[Takashi Iwai]

The length of the title and section marker has to be aligned with the
previous line.  This was caught when running asciidoctor, which is
more strict than asciidoc.

Also since asciidoctor doesn't like the verse block in some cases,
replace the code examples with simpler markers.

Signed-off-by: Takashi Iwai 
---
 Documentation/daxctl/daxctl-list.txt| 13 +++--
 Documentation/ndctl/ndctl-disable-dimm.txt  |  2 +-
 Documentation/ndctl/ndctl-enable-region.txt |  2 +-
 Documentation/ndctl/ndctl-init-labels.txt   | 15 ++-
 Documentation/ndctl/ndctl-list.txt  | 13 -
 Documentation/ndctl/ndctl-start-scrub.txt   |  6 --
 Documentation/ndctl/ndctl-wait-scrub.txt|  6 --
 7 files changed, 35 insertions(+), 22 deletions(-)

diff --git a/Documentation/daxctl/daxctl-list.txt 
b/Documentation/daxctl/daxctl-list.txt
index 99ca4a1b4f28..cb82c3cc6fb2 100644
--- a/Documentation/daxctl/daxctl-list.txt
+++ b/Documentation/daxctl/daxctl-list.txt
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 
 daxctl-list(1)
-=
+==
 
 NAME
 
@@ -24,10 +24,9 @@ daxctl list --devices
 
 EXAMPLE
 ---
-[verse]
+
 # daxctl list --regions --devices
 
-["literal"]
 {
   "id":1,
   "devices":[
@@ -37,6 +36,7 @@ EXAMPLE
 }
   ]
 }
+
 
 OPTIONS
 ---
@@ -54,14 +54,14 @@ OPTIONS
tuple, or keyword 'all' to filter the listing. For
example to list the first device instance in region1:
 
-[verse]
+
 # daxctl list --dev=1.0
 
-["literal"]
 {
   "chardev":"dax1.0",
   "size":3233808384
 }
+
 
 -D::
 --devices::
@@ -82,7 +82,7 @@ OPTIONS
will be formatted as human readable strings with units, other
fields are converted to hexadecimal strings.  Example:
 
-[verse]
+
 # daxctl list
 {
   "chardev":"dax1.0",
@@ -94,5 +94,6 @@ OPTIONS
   "chardev":"dax1.0",
   "size":"30.57 GiB (32.83 GB)"
 }
+
 
 include::../copyright.txt[]
diff --git a/Documentation/ndctl/ndctl-disable-dimm.txt 
b/Documentation/ndctl/ndctl-disable-dimm.txt
index d5a8d19966cf..7706ac351abc 100644
--- a/Documentation/ndctl/ndctl-disable-dimm.txt
+++ b/Documentation/ndctl/ndctl-disable-dimm.txt
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 
 ndctl-disable-dimm(1)
-===
+=
 
 NAME
 
diff --git a/Documentation/ndctl/ndctl-enable-region.txt 
b/Documentation/ndctl/ndctl-enable-region.txt
index 6c4ad9fefb0a..e5cbddbe6cf7 100644
--- a/Documentation/ndctl/ndctl-enable-region.txt
+++ b/Documentation/ndctl/ndctl-enable-region.txt
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 
 ndctl-enable-region(1)
-
+==
 
 NAME
 
diff --git a/Documentation/ndctl/ndctl-init-labels.txt 
b/Documentation/ndctl/ndctl-init-labels.txt
index 580d82aa99cf..736d52d03cab 100644
--- a/Documentation/ndctl/ndctl-init-labels.txt
+++ b/Documentation/ndctl/ndctl-init-labels.txt
@@ -26,7 +26,7 @@ the DIMM.
 EXAMPLE
 ---
 Find the DIMMs that comprise a given region:
-[verse]
+
 # ndctl list -RD --region=region1
 {
   "dimms":[
@@ -51,23 +51,28 @@ Find the DIMMs that comprise a given region:
 }
   ]
 }
+
 
 Disable that region so the DIMM label area can be written from
 userspace:
-[verse]
+
 # ndctl disable-region region1
+
 
 Initialize labels:
-[verse]
+
 # ndctl init-labels nmem0
+
 
 Re-enable the region:
-[verse]
+
 # ndctl enable-region region1
+
 
 Create a namespace in that region:
-[verse]
+
 # ndctl create-namespace --region=region1
+
 
 OPTIONS
 ---
diff --git a/Documentation/ndctl/ndctl-list.txt 
b/Documentation/ndctl/ndctl-list.txt
index 2abc572a6ad5..13ebdcdd55ff 100644
--- a/Documentation/ndctl/ndctl-list.txt
+++ b/Documentation/ndctl/ndctl-list.txt
@@ -23,10 +23,9 @@ ndctl list --namespaces --bus=all --region=all
 
 EXAMPLE
 ---
-[verse]
+
 # ndctl list --buses --namespaces
 
-["literal"]
 {
   "provider":"nfit_test.1",
   "dev":"ndbus2",
@@ -55,6 +54,7 @@ EXAMPLE
 }
   ]
 }
+
 
 OPTIONS
 ---
@@ -67,8 +67,9 @@ include::xable-region-options.txt[]
An 'nmemX' device name, or dimm id number. Filter listing by
devices that reference the given dimm. For example to see all
namespaces comprised of storage capacity on nmem0:
-[verse]
+
 # ndctl list --dimm=nmem0 --namespaces
+
 
 -n::
 --namespace=::
@@ -201,7 +202,7 @@ include::xable-region-options.txt[]
 
 include::human-option.txt[]
 
-[verse]
+
 # ndctl list --region=7
 {
   "dev":"region7",
@@ -211,8 +212,9 @@ include::human-option.txt[]
   "iset_id":-6382611090938810793,
   "badblock_count":8
 }
+
 
-[verse]
+
 # ndctl list --human --region=7
 {
   "dev":"region7",
@@ -222,6 +224,7 @@ include::human-option.txt[]
   "iset_id":"0xa76c6907811fae57",
   "badblock_count":8
 }
+
 
 include::../copyright.txt[]
 
diff --git a/Documentation/ndctl/ndctl-start-scrub.txt 

[PATCH ndctl v2 0/3] Documentation: add asciidoctor support

[Takashi Iwai]

Hi,

this is a revised patchset to add the support for asciidoctor to
generate documents.  The reason for adding this feature is that the
future of asciidoc isn't clear as it's written in python2, which is
now hated by all people out of sudden :)

The asciidoctor support is enabled via configure option, the default
is still asciidoc for now.

thanks,

Takashi


v1->v2:
 * more marker fixes to ndctl man pages
 * skip superfluous xmlto processing for asciidoctor
 * add .gitignore entries

===

Takashi Iwai (3):
  Documentation: fix title and section markers
  Documentation: Add the support for asciidoctor
  Documentation: add asciidoctor-extensions.rb to .gitignore

 .gitignore  |  2 ++
 Documentation/asciidoctor-extensions.rb.in  | 28 
 Documentation/daxctl/Makefile.am| 28 ++--
 Documentation/daxctl/daxctl-list.txt| 13 +++--
 Documentation/ndctl/Makefile.am | 28 ++--
 Documentation/ndctl/ndctl-disable-dimm.txt  |  2 +-
 Documentation/ndctl/ndctl-enable-region.txt |  2 +-
 Documentation/ndctl/ndctl-init-labels.txt   | 15 ++-
 Documentation/ndctl/ndctl-list.txt  | 13 -
 Documentation/ndctl/ndctl-start-scrub.txt   |  6 --
 Documentation/ndctl/ndctl-wait-scrub.txt|  6 --
 configure.ac| 17 +++--
 12 files changed, 132 insertions(+), 28 deletions(-)
 create mode 100644 Documentation/asciidoctor-extensions.rb.in

-- 
2.16.3

___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

[PATCH ndctl v2 3/3] Documentation: add asciidoctor-extensions.rb to .gitignore

[Takashi Iwai]

Two new files were added for asciidoctor support.

Signed-off-by: Takashi Iwai 
---
 .gitignore | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/.gitignore b/.gitignore
index 20a04dedd862..c7d11d91398c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,6 +15,8 @@ Makefile.in
 *.1
 Documentation/daxctl/asciidoc.conf
 Documentation/ndctl/asciidoc.conf
+Documentation/daxctl/asciidoctor-extensions.rb
+Documentation/ndctl/asciidoctor-extensions.rb
 .dirstamp
 daxctl/daxctl
 daxctl/lib/libdaxctl.la
-- 
2.16.3

___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH v8 15/18] mm, fs, dax: handle layout changes to pinned dax mappings

[Jan Kara]

On Fri 13-04-18 15:03:51, Dan Williams wrote:
> On Mon, Apr 9, 2018 at 9:51 AM, Dan Williams  wrote:
> > On Mon, Apr 9, 2018 at 9:49 AM, Jan Kara  wrote:
> >> On Sat 07-04-18 12:38:24, Dan Williams wrote:
> > [..]
> >>> I wonder if this can be trivially solved by using srcu. I.e. we don't
> >>> need to wait for a global quiescent state, just a
> >>> get_user_pages_fast() quiescent state. ...or is that an abuse of the
> >>> srcu api?
> >>
> >> Well, I'd rather use the percpu rwsemaphore (linux/percpu-rwsem.h) than
> >> SRCU. It is a more-or-less standard locking mechanism rather than relying
> >> on implementation properties of SRCU which is a data structure protection
> >> method. And the overhead of percpu rwsemaphore for your use case should be
> >> about the same as that of SRCU.
> >
> > I was just about to ask that. Yes, it seems they would share similar
> > properties and it would be better to use the explicit implementation
> > rather than a side effect of srcu.
> 
> ...unfortunately:
> 
>  BUG: sleeping function called from invalid context at
> ./include/linux/percpu-rwsem.h:34
>  [..]
>  Call Trace:
>   dump_stack+0x85/0xcb
>   ___might_sleep+0x15b/0x240
>   dax_layout_lock+0x18/0x80
>   get_user_pages_fast+0xf8/0x140
> 
> ...and thinking about it more srcu is a better fit. We don't need the
> 100% exclusion provided by an rwsem we only need the guarantee that
> all cpus that might have been running get_user_pages_fast() have
> finished it at least once.
> 
> In my tests synchronize_srcu is a bit slower than unpatched for the
> trivial 100 truncate test, but certainly not the 200x latency you were
> seeing with syncrhonize_rcu.
> 
> Elapsed time:
> 0.006149178 unpatched
> 0.009426360 srcu

Hum, right. Yesterday I was looking into KSM for a different reason and
I've noticed it also does writeprotect pages and deals with races with GUP.
And what KSM relies on is:

write_protect_page()
  ...
  entry = ptep_clear_flush(vma, pvmw.address, pvmw.pte);
  /*
   * Check that no O_DIRECT or similar I/O is in progress on the
   * page
   */
  if (page_mapcount(page) + 1 + swapped != page_count(page)) {
page used -> bail
  }

And this really works because gup_pte_range() does:

  page = pte_page(pte);
  head = compound_head(page);

  if (!page_cache_get_speculative(head))
goto pte_unmap;

  if (unlikely(pte_val(pte) != pte_val(*ptep))) {
bail
  }

So either write_protect_page() page sees the elevated reference or
gup_pte_range() bails because it will see the pte changed.

In the truncate path things are a bit different but in principle the same
should work - once truncate blocks page faults and unmaps pages from page
tables, we can be sure GUP will not grab the page anymore or we'll see
elevated page count. So IMO there's no need for any additional locking
against the GUP path (but a comment explaining this is highly desirable I
guess). 

Honza
-- 
Jan Kara 
SUSE Labs, CR
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm