Mike notes that Sphinx needs a newline before the start of a bulleted
list, and v10 of the subsection patch set changed the subsection size
from an arch-variable 'PMD_SIZE' to a constant 2MB.
Cc: Jonathan Corbet
Reported-by: Mike Rapoport
Signed-off-by: Dan Williams
---
Hi Andrew,
Another
On Thu, Jun 6, 2019 at 10:26 PM Santosh Sivaraj wrote:
>
> For QEMU emulated devices, nfit drivers need not be loaded, also the
> nfit_test, libnvdimm_test modules are not required. This patch adds a
> configure option to enable testing on qemu without nfit dependencies.
This looks useful, I
On Tue, 2019-06-11 at 16:25 -0700, Dan Williams wrote:
> Namespace activation expects to be able to reference region badblocks.
> The following warning sometimes triggers when asynchronous namespace
> activation races in front of the completion of namespace probing. Move
> all possible namespace
device-dax based devices were missing a 'resource' attribute to indicate
the physical address range contributed by the device in question. This
information is desirable to userspace tooling that may want to use the
dax device as system-ram, and wants to selectively hotplug and online
the memory
David points out that there is a mixture of 'int' and 'unsigned long'
usage for section number data types. Update the memory hotplug path to
use 'unsigned long' consistently for section numbers.
Cc: Michal Hocko
Cc: Oscar Salvador
Reported-by: David Hildenbrand
Signed-off-by: Dan Williams
---
On Thu 13-06-19 11:43:07, Christoph Hellwig wrote:
> ->mapping isn't even used by HMM users, and the field at the same offset
> in the zone_device part of the union is declared as pad. (Which btw is
> rather confusing, as DAX uses ->pgmap and ->mapping from two different
> sides of the union, but
On Thu 13-06-19 11:43:06, Christoph Hellwig wrote:
> This function has never been used since it was first added to the kernel
> more than a year and a half ago, and if we ever grow a consumer of the
> MEMORY_DEVICE_PUBLIC infrastructure it can easily use devm_memremap_pages
> directly now that
On Thu 13-06-19 11:43:21, Christoph Hellwig wrote:
> The code hasn't been used since it was added to the tree, and doesn't
> appear to actually be usable. Mark it as BROKEN until either a user
> comes along or we finally give up on it.
I would go even further and simply remove all the
On Thu 13-06-19 11:43:08, Christoph Hellwig wrote:
> noveau is currently using this through an odd hmm wrapper, and I plan
> to switch it to the real thing later in this series.
>
> Signed-off-by: Christoph Hellwig
> ---
> mm/mempolicy.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
On Tue, Jun 18, 2019 at 10:51:33PM -0700, Dan Williams wrote:
> Changes since v9 [1]:
> - Fix multiple issues related to the fact that pfn_valid() has
> traditionally returned true for any pfn in an 'early' (onlined at
> boot) section regardless of whether that pfn represented 'System RAM'.
>
On Thu, Jun 20, 2019 at 9:37 AM David Hildenbrand wrote:
>
> On 20.06.19 18:19, Dan Williams wrote:
> > On Thu, Jun 20, 2019 at 3:31 AM David Hildenbrand wrote:
> >>
> >> On 19.06.19 07:52, Dan Williams wrote:
> >>> Prepare the memory hot-{add,remove} paths for handling sub-section
> >>> ranges
On 20.06.19 18:19, Dan Williams wrote:
> On Thu, Jun 20, 2019 at 3:31 AM David Hildenbrand wrote:
>>
>> On 19.06.19 07:52, Dan Williams wrote:
>>> Prepare the memory hot-{add,remove} paths for handling sub-section
>>> ranges by plumbing the starting page frame and number of pages being
>>>
On Thu, Jun 20, 2019 at 5:31 AM Aneesh Kumar K.V
wrote:
>
> Dan Williams writes:
>
> > Changes since v9 [1]:
> > - Fix multiple issues related to the fact that pfn_valid() has
> > traditionally returned true for any pfn in an 'early' (onlined at
> > boot) section regardless of whether that
On Thu, Jun 20, 2019 at 3:31 AM David Hildenbrand wrote:
>
> On 19.06.19 07:52, Dan Williams wrote:
> > Prepare the memory hot-{add,remove} paths for handling sub-section
> > ranges by plumbing the starting page frame and number of pages being
> > handled through arch_{add,remove}_memory() to
> >
On Thu 13-06-19 08:27:55, Matthew Wilcox wrote:
> On Thu, Jun 13, 2019 at 10:25:55AM +1000, Dave Chinner wrote:
> > e.g. Process A has an exclusive layout lease on file F. It does an
> > IO to file F. The filesystem IO path checks that Process A owns the
> > lease on the file and so skips straight
Hi,
Thanks for the email. I will fix this warning with other build fixes found
by test bot and send a v14.
Best regards,
Pankaj
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git
> libnvdimm-for-next
> head: 3b6047778c09037615e7b919c922081ef1a37a7f
> commit:
Hello...Did you get my pervious message ?
John
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
Dan Williams writes:
> Changes since v9 [1]:
> - Fix multiple issues related to the fact that pfn_valid() has
> traditionally returned true for any pfn in an 'early' (onlined at
> boot) section regardless of whether that pfn represented 'System RAM'.
> Teach pfn_valid() to maintain its
On Tue, Jun 18, 2019 at 10:52:29PM -0700, Dan Williams wrote:
> Explain the general mechanisms of 'ZONE_DEVICE' pages and list the users
> of 'devm_memremap_pages()'.
>
> Cc: Jonathan Corbet
> Reported-by: Mike Rapoport
> Signed-off-by: Dan Williams
With one nit below
Reviewed-by: Mike
Good Day.
I know reading my email, will be surprising to you and your
entire family, but please take whatever I am about to share with
you today seriously.
My name is John Mobutu, I am 22 years old, from Congo, my parents
were assassinated by opposition leaders many years ago, but thank
God
On 19.06.19 07:52, Dan Williams wrote:
> Prepare the memory hot-{add,remove} paths for handling sub-section
> ranges by plumbing the starting page frame and number of pages being
> handled through arch_{add,remove}_memory() to
> sparse_{add,remove}_one_section().
>
> This is simply plumbing,
Thanks for the email. Apologies for s390 build failure.
Below patch(untested) should fix this.
Thanks,
Pankaj
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git
> libnvdimm-for-next
> head: 3b6047778c09037615e7b919c922081ef1a37a7f
> commit:
Allow arch to provide the supported alignments and use hugepage alignment only
if we support hugepage. Right now we depend on compile time configs whereas this
patch switch this to runtime discovery.
Architectures like ppc64 can have THP enabled in code, but then can have
hugepage size disabled
This is needed so that we don't wrongly initialize a namespace
which doesn't have enough space reserved for holding struct pages
with the current kernel.
Signed-off-by: Aneesh Kumar K.V
---
drivers/nvdimm/pfn.h | 5 -
drivers/nvdimm/pfn_devs.c | 27 ++-
2 files
Use PAGE_SIZE instead of SZ_4K and sizeof(struct page) instead of 64.
If we have a kernel built with different struct page size the previous
patch should handle marking the namespace disabled.
Signed-off-by: Aneesh Kumar K.V
---
drivers/nvdimm/label.c | 2 +-
vmem_altmap_offset() adjust the section aligned base_pfn offset.
So we need to make sure we account for the same when computing base_pfn.
ie, for altmap_valid case, our pfn_first should be:
pfn_first = altmap->base_pfn + vmem_altmap_offset(altmap);
Signed-off-by: Aneesh Kumar K.V
---
This patch add -EOPNOTSUPP as return from probe callback to
indicate we were not able to initialize a namespace due to pfn superblock
feature/version mismatch. We want to consider this a probe success so that
we can create new namesapce seed and there by avoid marking the failed
namespace as the
nd_label->dpa issue was observed when trying to enable the namespace created
with little-endian kernel on a big-endian kernel. That made me run
`sparse` on the rest of the code and other changes are the result of that.
Fixes: d9b83c756953 ("libnvdimm, btt: rework error clearing")
Fixes:
This series handle configs where hugepage support is not enabled by default.
Also, we update some of the information messages to make sure we use PAGE_SIZE
instead
of SZ_4K. We now store page size and struct page size in pfn_sb and do extra
check
before enabling namespace. There also an
[added some relevant lists to CC - this can safe some people debugging by
being able to google this discussion]
On Wed 19-06-19 15:57:38, Liu Bo wrote:
> I found a weird dead loop within invalidate_inode_pages2_range, the
> reason being that pagevec_lookup_entries(index=1) returns an indices
>
tree: https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git
libnvdimm-for-next
head: 3b6047778c09037615e7b919c922081ef1a37a7f
commit: fee8be32c5bab110c34884dfc4a68dd0105d2607 [5/15] libnvdimm: add dax_dev
sync flag
config: s390-debug_defconfig (attached as .config)
compiler:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git
libnvdimm-for-next
head: 3b6047778c09037615e7b919c922081ef1a37a7f
commit: 38887edec2472179cc79bb45034731f5f816f064 [6/15] dm: enable synchronous
dax
config: parisc-c3000_defconfig (attached as .config)
compiler:
On Wed, Jun 19, 2019 at 03:21:58PM -0700, Dan Williams wrote:
> On Tue, Jun 11, 2019 at 4:40 PM Dan Williams wrote:
> >
> > For good reason, the standard device_lock() is marked
> > lockdep_set_novalidate_class() because there is simply no sane way to
> > describe the myriad ways the
On Wed, Jun 19, 2019 at 03:19:23PM -0300, Jason Gunthorpe wrote:
> > Just make sure that when you backmerge v5.2-rc5 you have a clear
> > reason in the merge commit message about why you needed to do it.
> > While needless rebasing is top of the pet peeve list, second place, as
> > I found out, is
34 matches
Mail list logo
