[PATCH] device-dax: make dev_dax_kmem_probe() static

2020-09-11 Thread Jason Yan 
This eliminates the following sparse warning:

drivers/dax/kmem.c:38:5: warning: symbol 'dev_dax_kmem_probe' was not
declared. Should it be static?

Reported-by: Hulk Robot 
Signed-off-by: Jason Yan 
---
 drivers/dax/kmem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
index 7dcb2902e9b1..e79afbadd4e0 100644
--- a/drivers/dax/kmem.c
+++ b/drivers/dax/kmem.c
@@ -35,7 +35,7 @@ static int dax_kmem_range(struct dev_dax *dev_dax, int i, 
struct range *r)
return 0;
 }
 
-int dev_dax_kmem_probe(struct dev_dax *dev_dax)
+static int dev_dax_kmem_probe(struct dev_dax *dev_dax)
 {
int numa_node = dev_dax->target_node;
struct device *dev = _dax->dev;
-- 
2.25.4
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org

Saisissez les offres attrayantes avec les meilleures offres de téléphonie mobile

2020-09-11 Thread hegmannkrisfhgr 
Si pour un iPhone, il n'est pas question d'aimer ses fonctionnalités, son look 
et ses capacités incroyables. C'est un excellent téléphone qui exécute presque 
tout ce que vous désirez. Lorsque vous obtenez votre iPhone, la 
personnalisation fait probablement partie de votre liste. Si vous souhaitez que 
votre téléphone soit unique et personnalisé, avoir sa propre sonnerie 
fonctionnera exactement. Vous pouvez vous référer à quelques sonneries ici: 
https://sonnerieportable.com/

Une fois une personne, ces éléments doivent être collectés. Autour de ce point, 
vous voudrez peut-être savoir si ce n'est pas vraiment le cas pour l'universel. 
Cela signifie la même chanson pour chaque appel. La configuration peut être 
effectuée avec l'option Paramètres de votre téléphone. Je suis allé voir 
quelque chose pour définir ou personnaliser des sonneries. Là où vous les 
ajoutez. Les sonneries ne sont pas une chose en particulier sur laquelle vous 
trouverez vraiment beaucoup de données. On pourrait vouloir vérifier 
SonneriePortable. Si vous définissez des tonalités par rapport à dans votre 
répertoire, une personne doit commencer ses noms dans le répertoire. Par nom, 
plus il peut vraiment avoir à regarder un sous-menu qui vous permettra de 
définir des données personnalisées. Cela s'est avéré une alternative 
intéressante au filtrage des appels aussi clairement.

Je ne préconise pas nécessairement de faire des mouvements d'emporte-pièce. 
Cependant, si votre musique est absolument bonne (après tout, utiliser une 
courte intro n'est clairement pas la seule chose que les professionnels 
amusants recherchent) et que vous voulez augmenter les chances qu'elle soit 
entendue, cette brève intro est un très bon choix. Je sais qu'il y a
 
beaucoup d'exemples de chansons à succès avec de longues intros (en particulier 
dans les chansons de rock classique), mais ce n'est en fait pas normal de nos 
jours à des semaines.

Vous pouvez télécharger des sonneries gratuites sur Internet sans tracas. Vous 
n'avez pas vraiment besoin d'être techniquement enclin à essayer cela. 
Travaillez même pour aider à payer ou vous abonner pour obtenir des sonneries 
car vous pouvez le stimuler absolument sans frais. Tout ce que vous avez à 
faire est de passer plusieurs minutes du temps et d'aller en ligne pour 
rechercher des sonneries gratuites. Vous seriez submergé par les résultats des 
sites Web qu'une personne peut visiter. Parcourez tout ce que vous voulez et 
comparez les sites Web qui téléchargent totalement gratuitement.

Durée raisonnable - je suis totalement contre les chansons qui durent 20 
minutes. La chanson typique pour environ 3-5 minutes. Si vous n'êtes pas en 
mesure de parler dans ce laps de temps, j'ai simplement un conseil, vous former 
pour finalement vous rendre rapidement à la situation.

Vous êtes capable de gagner des sonneries monophoniques. Il existe des 
logiciels gratuits ou payants à utiliser pour ces teintes monophoniques. Rock, 
Alternative, Pop, Reggae ou classique, vous offrez le choix de créer votre 
propre sonnerie. Ce qui vous limitera, ce n'est que votre créativité. Essayez 
enfin de créer votre propre sonnerie.

Pour procéder à l'analogie du mariage, considérez que les mariées marchent dans 
l'allée sans musique. (Je voudrais servir le pas rapide pour arriver à mon 
marié.) La musique se révèle être et donne de la dignité à la procession. Vos 
participants savent à quels points se trouvent les débats en utilisant la 
guitare. Il n'y a pas besoin de vos commentaires ou avis. La musique de fond 
raconte l'histoire. Pourquoi nous avons de la musique, c'est pour quantifier. 
La manière dont nous utilisons la musique et pourquoi nous utilisons la musique 
comme nous le faisons tous est bien mieux à expliquer. La musique imprègne la 
vie. De la musique d'église primitive, en passant par la musique de combat et 
le divertissement, la musique est constamment entendue et utilisée dans les 
débats.
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org

[GIT PULL] libnvdimm fix for v5.9-rc5

2020-09-11 Thread Verma, Vishal L 
Hi Linus, please pull from:

git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git
tags/libnvdimm-fix-v5.9-rc5

...to receive another fix for detection of DAX support for block
devices. The previous fix in this area (merged in -rc3) was incomplete,
and this should finally address all the problems.

---

The following changes since commit c2affe920b0e0669650943ac086215cf6519be34:

  dax: do not print error message for non-persistent memory block device 
(2020-08-20 11:43:18 -0600)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git 
tags/libnvdimm-fix-v5.9-rc5

for you to fetch changes up to 6180bb446ab624b9ab8bf201ed251ca87f07b413:

  dax: fix detection of dax support for non-persistent memory block devices 
(2020-09-03 12:28:03 -0600)


libnvdimm fix for v5.9-rc5

Fix decetion of dax support for block devices. Previous fixes in this
area, which only affected printing of debug messages, had an incorrect
condition for detection of dax. This fix should finally do the right thing.


Coly Li (1):
  dax: fix detection of dax support for non-persistent memory block devices

 drivers/dax/super.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dax/super.c b/drivers/dax/super.c
index 32642634c1bb..e5767c83ea23 100644
--- a/drivers/dax/super.c
+++ b/drivers/dax/super.c
@@ -100,7 +100,7 @@ bool __generic_fsdax_supported(struct dax_device *dax_dev,
return false;
}
 
-   if (!dax_dev && !bdev_dax_supported(bdev, blocksize)) {
+   if (!dax_dev || !bdev_dax_supported(bdev, blocksize)) {
pr_debug("%s: error: dax unsupported by block device\n",
bdevname(bdev, buf));
return false;
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org

Re: [PATCH] powerpc/papr_scm: Fix warning triggered by perf_stats_show()

2020-09-11 Thread Ira Weiny 
On Sat, Sep 12, 2020 at 01:36:46AM +0530, Vaibhav Jain wrote:
> Thanks for reviewing this patch Ira,
> 
> 
> Ira Weiny  writes:
> 
> > On Thu, Sep 10, 2020 at 02:52:12PM +0530, Vaibhav Jain wrote:
> >> A warning is reported by the kernel in case perf_stats_show() returns
> >> an error code. The warning is of the form below:
> >> 
> >>  papr_scm ibm,persistent-memory:ibm,pmemory@4411:
> >>  Failed to query performance stats, Err:-10
> >>  dev_attr_show: perf_stats_show+0x0/0x1c0 [papr_scm] returned bad count
> >>  fill_read_buffer: dev_attr_show+0x0/0xb0 returned bad count
> >> 
> >> On investigation it looks like that the compiler is silently truncating the
> >> return value of drc_pmem_query_stats() from 'long' to 'int', since the
> >> variable used to store the return code 'rc' is an 'int'. This
> >> truncated value is then returned back as a 'ssize_t' back from
> >> perf_stats_show() to 'dev_attr_show()' which thinks of it as a large
> >> unsigned number and triggers this warning..
> >> 
> >> To fix this we update the type of variable 'rc' from 'int' to
> >> 'ssize_t' that prevents the compiler from truncating the return value
> >> of drc_pmem_query_stats() and returning correct signed value back from
> >> perf_stats_show().
> >> 
> >> Fixes: 2d02bf835e573 ('powerpc/papr_scm: Fetch nvdimm performance
> >>stats from PHYP')
> >> Signed-off-by: Vaibhav Jain 
> >> ---
> >>  arch/powerpc/platforms/pseries/papr_scm.c | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >> 
> >> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c 
> >> b/arch/powerpc/platforms/pseries/papr_scm.c
> >> index a88a707a608aa..9f00b61676ab9 100644
> >> --- a/arch/powerpc/platforms/pseries/papr_scm.c
> >> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> >> @@ -785,7 +785,8 @@ static int papr_scm_ndctl(struct nvdimm_bus_descriptor 
> >> *nd_desc,
> >>  static ssize_t perf_stats_show(struct device *dev,
> >>   struct device_attribute *attr, char *buf)
> >>  {
> >> -  int index, rc;
> >> +  int index;
> >> +  ssize_t rc;
> >
> > I'm not sure this is really fixing everything here.
> 
> The issue is with the statement in perf_stats_show():
> 
> 'return rc ? rc : seq_buf_used();'
> 
> The function seq_buf_used() returns an 'unsigned int' and with 'rc'
> typed as 'int', forces a promotion of the expression to 'unsigned int'
> which causes a loss of signedness of 'rc' and compiler silently
> assigns this unsigned value to the function return typed as 'signed
> long'.
> 
> Making 'rc', a 'signed long' forces a promotion of the expresion to
> 'signed long' which preserves the signedness of 'rc' and will also be
> compatible with the function return type.

Ok, ok, I read this all wrong.

FWIW I would also cast seq_buf_used() to ssize_t to show you know what you are
doing there.

> 
> >
> > drc_pmem_query_stats() can return negative errno's.  Why are those not 
> > checked
> > somewhere in perf_stats_show()?
> >
> For the specific invocation 'drc_pmem_query_stats(p, stats, 0)' we only
> expect return value 'rc <=0' with '0' indicating a successful fetch of
> nvdimm performance stats from hypervisor. Hence there are no explicit
> checks for negative error codes in the functions as all return values
> !=0 indicate an error.
> 
> 
> > It seems like all this fix is handling is a > 0 return value: 'ret[0]' from
> > line 289 in papr_scm.c...  Or something?
> No, in case the arg 'num_stats' is '0' and 'buff_stats != NULL' the
> variable 'size' is assigned a non-zero value hence that specific branch
> you mentioned  is never taken. Instead in case of success
> drc_pmem_query_stats() return '0' and in case of an error a negative
> error code is returned.
> 
> >
> > Worse yet drc_pmem_query_stats() is returning ssize_t which is a signed 
> > value.
> > Therefore, it should not be returning -errno.  I'm surprised the static
> > checkers did not catch that.
> Didnt quite get the assertion here. The function is marked to return
> 'ssize_t' because we can return both +ve for success and -ve values to
> indicate errors.

Sorry I was reading this as size_t and meant to say unsigned...  I was looking
at this too quickly.

> 
> >
> > I believe I caught similar errors with a patch series before which did not 
> > pay
> > attention to variable types.
> >
> > Please audit this code for these types of errors and ensure you are really
> > doing the correct thing when using the sysfs interface.  I'm pretty sure bad
> > things will eventually happen (if they are not already) if you return some
> > really big number to the sysfs core from *_show().
> I think this problem is different compared to what you had previously pointed
> to. The values returned from drc_pmem_query_stats() can be stored in an
> 'int' variable too, however it was the silent promotion of a signed type
> to unsigned type was what caused this specific issue.

Ok this makes more sense now.  Sorry about not looking more carefully.

But I still think

Re: [PATCH] powerpc/papr_scm: Fix warning triggered by perf_stats_show()

2020-09-11 Thread Vaibhav Jain 
Thanks for reviewing this patch Ira,


Ira Weiny  writes:

> On Thu, Sep 10, 2020 at 02:52:12PM +0530, Vaibhav Jain wrote:
>> A warning is reported by the kernel in case perf_stats_show() returns
>> an error code. The warning is of the form below:
>> 
>>  papr_scm ibm,persistent-memory:ibm,pmemory@4411:
>>Failed to query performance stats, Err:-10
>>  dev_attr_show: perf_stats_show+0x0/0x1c0 [papr_scm] returned bad count
>>  fill_read_buffer: dev_attr_show+0x0/0xb0 returned bad count
>> 
>> On investigation it looks like that the compiler is silently truncating the
>> return value of drc_pmem_query_stats() from 'long' to 'int', since the
>> variable used to store the return code 'rc' is an 'int'. This
>> truncated value is then returned back as a 'ssize_t' back from
>> perf_stats_show() to 'dev_attr_show()' which thinks of it as a large
>> unsigned number and triggers this warning..
>> 
>> To fix this we update the type of variable 'rc' from 'int' to
>> 'ssize_t' that prevents the compiler from truncating the return value
>> of drc_pmem_query_stats() and returning correct signed value back from
>> perf_stats_show().
>> 
>> Fixes: 2d02bf835e573 ('powerpc/papr_scm: Fetch nvdimm performance
>>stats from PHYP')
>> Signed-off-by: Vaibhav Jain 
>> ---
>>  arch/powerpc/platforms/pseries/papr_scm.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c 
>> b/arch/powerpc/platforms/pseries/papr_scm.c
>> index a88a707a608aa..9f00b61676ab9 100644
>> --- a/arch/powerpc/platforms/pseries/papr_scm.c
>> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
>> @@ -785,7 +785,8 @@ static int papr_scm_ndctl(struct nvdimm_bus_descriptor 
>> *nd_desc,
>>  static ssize_t perf_stats_show(struct device *dev,
>> struct device_attribute *attr, char *buf)
>>  {
>> -int index, rc;
>> +int index;
>> +ssize_t rc;
>
> I'm not sure this is really fixing everything here.

The issue is with the statement in perf_stats_show():

'return rc ? rc : seq_buf_used();'

The function seq_buf_used() returns an 'unsigned int' and with 'rc'
typed as 'int', forces a promotion of the expression to 'unsigned int'
which causes a loss of signedness of 'rc' and compiler silently
assigns this unsigned value to the function return typed as 'signed
long'.

Making 'rc', a 'signed long' forces a promotion of the expresion to
'signed long' which preserves the signedness of 'rc' and will also be
compatible with the function return type.

>
> drc_pmem_query_stats() can return negative errno's.  Why are those not checked
> somewhere in perf_stats_show()?
>
For the specific invocation 'drc_pmem_query_stats(p, stats, 0)' we only
expect return value 'rc <=0' with '0' indicating a successful fetch of
nvdimm performance stats from hypervisor. Hence there are no explicit
checks for negative error codes in the functions as all return values
!=0 indicate an error.


> It seems like all this fix is handling is a > 0 return value: 'ret[0]' from
> line 289 in papr_scm.c...  Or something?
No, in case the arg 'num_stats' is '0' and 'buff_stats != NULL' the
variable 'size' is assigned a non-zero value hence that specific branch
you mentioned  is never taken. Instead in case of success
drc_pmem_query_stats() return '0' and in case of an error a negative
error code is returned.

>
> Worse yet drc_pmem_query_stats() is returning ssize_t which is a signed value.
> Therefore, it should not be returning -errno.  I'm surprised the static
> checkers did not catch that.
Didnt quite get the assertion here. The function is marked to return
'ssize_t' because we can return both +ve for success and -ve values to
indicate errors.

>
> I believe I caught similar errors with a patch series before which did not pay
> attention to variable types.
>
> Please audit this code for these types of errors and ensure you are really
> doing the correct thing when using the sysfs interface.  I'm pretty sure bad
> things will eventually happen (if they are not already) if you return some
> really big number to the sysfs core from *_show().
I think this problem is different compared to what you had previously pointed
to. The values returned from drc_pmem_query_stats() can be stored in an
'int' variable too, however it was the silent promotion of a signed type
to unsigned type was what caused this specific issue.

-- 
Cheers
~ Vaibhav
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org

Re: [PATCH 2/2] xfs: don't update mtime on COW faults

2020-09-11 Thread Mikulas Patocka 



On Wed, 9 Sep 2020, Darrick J. Wong wrote:

> On Sat, Sep 05, 2020 at 01:02:33PM -0400, Mikulas Patocka wrote:
> > > > 
> > 
> > I've written this program that tests it - you can integrate it into your 
> > testsuite.
> 
> I don't get it.  You're a filesystem maintainer too, which means you're
> a regular contributor.  Do you:
> 
> (a) not use fstests?  If you don't, I really hope you use something else
> to QA hpfs.

I don't use xfstests on HPFS. I was testing it just by using it. Now I use 
it just a little, but I don't modify it much.

> (b) really think that it's my problem to integrate and submit your
> regression tests for you?
> 
> and (c) what do you want me to do with a piece of code that has no 
> signoff tag, no copyright, and no license?  This is your patch, and 
> therefore your responsibility to develop enough of an appropriate 
> regression test in a proper form that the rest of us can easily 
> determine we have the rights to contribute to it.


If you want a full patch (I copied the script from test 313), I send it 
here.

Mikulas


From: Mikulas Patocka 
Subject: [PATCH] check ctime and mtime vs mmap

Check ctime and mtime are not updated on COW faults
and that they are updated on shared faults

Signed-off-by: Mikulas Patocka 

---
 src/Makefile  |3 +-
 src/mmap-timestamp.c  |   53 ++
 tests/generic/609 |   40 +
 tests/generic/609.out |2 +
 tests/generic/group   |1 
 5 files changed, 98 insertions(+), 1 deletion(-)

Index: xfstests-dev/src/Makefile
===
--- xfstests-dev.orig/src/Makefile  2020-09-06 12:38:40.0 +0200
+++ xfstests-dev/src/Makefile   2020-09-11 17:39:04.0 +0200
@@ -17,7 +17,8 @@ TARGETS = dirstress fill fill2 getpagesi
t_mmap_cow_race t_mmap_fallocate fsync-err t_mmap_write_ro \
t_ext4_dax_journal_corruption t_ext4_dax_inline_corruption \
t_ofd_locks t_mmap_collision mmap-write-concurrent \
-   t_get_file_time t_create_short_dirs t_create_long_dirs
+   t_get_file_time t_create_short_dirs t_create_long_dirs \
+   mmap-timestamp
 
 LINUX_TARGETS = xfsctl bstat t_mtab getdevicesize preallo_rw_pattern_reader \
preallo_rw_pattern_writer ftrunc trunc fs_perms testx looptest \
Index: xfstests-dev/src/mmap-timestamp.c
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ xfstests-dev/src/mmap-timestamp.c   2020-09-11 18:21:40.0 +0200
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2020 Red Hat, Inc. All Rights reserved.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define FILE_NAME  argv[1]
+
+static struct stat st1, st2;
+
+int main(int argc, char *argv[])
+{
+   int h, r;
+   char *map;
+   unlink(FILE_NAME);
+   h = creat(FILE_NAME, 0600);
+   if (h == -1) perror("creat"), exit(1);
+   r = write(h, "x", 1);
+   if (r != 1) perror("write"), exit(1);
+   if (close(h)) perror("close"), exit(1);
+   h = open(FILE_NAME, O_RDWR);
+   if (h == -1) perror("open"), exit(1);
+
+   map = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE, h, 0);
+   if (map == MAP_FAILED) perror("mmap"), exit(1);
+   if (fstat(h, )) perror("fstat"), exit(1);
+   sleep(2);
+   *map = 'y';
+   if (fstat(h, )) perror("fstat"), exit(1);
+   if (st1.st_mtime != st2.st_mtime) fprintf(stderr, "BUG: COW fault 
changed mtime!\n"), exit(1);
+   if (st1.st_ctime != st2.st_ctime) fprintf(stderr, "BUG: COW fault 
changed ctime!\n"), exit(1);
+   if (munmap(map, 4096)) perror("munmap"), exit(1);
+
+   map = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, h, 0);
+   if (map == MAP_FAILED) perror("mmap"), exit(1);
+   if (fstat(h, )) perror("fstat"), exit(1);
+   sleep(2);
+   *map = 'z';
+   if (msync(map, 4096, MS_SYNC)) perror("msync"), exit(1);
+   if (fstat(h, )) perror("fstat"), exit(1);
+   if (st1.st_mtime == st2.st_mtime) fprintf(stderr, "BUG: Shared fault 
did not change mtime!\n"), exit(1);
+   if (st1.st_ctime == st2.st_ctime) fprintf(stderr, "BUG: Shared fault 
did not change ctime!\n"), exit(1);
+   if (munmap(map, 4096)) perror("munmap"), exit(1);
+
+   if (close(h)) perror("close"), exit(1);
+   if (unlink(FILE_NAME)) perror("unlink"), exit(1);
+   return 0;
+}
Index: xfstests-dev/tests/generic/609
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ xfstests-dev/tests/generic/609  2020-09-11 18:30:30.0 +0200
@@ -0,0 +1,40 @@
+#! /bin/bash
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (c) 2020 Red Hat, Inc. All Rights Reserved.
+#
+# FS QA Test No. 609
+#
+# Check ctime and mtime are not updated on COW faults
+# and

Re: Bulk Cargo Shipment for lists.01.org //邓钧文

2020-09-11 Thread 陈鑫 
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org

[PATCH v4 0/8] selective merging of system ram resources

2020-09-11 Thread David Hildenbrand 
Some add_memory*() users add memory in small, contiguous memory blocks.
Examples include virtio-mem, hyper-v balloon, and the XEN balloon.

This can quickly result in a lot of memory resources, whereby the actual
resource boundaries are not of interest (e.g., it might be relevant for
DIMMs, exposed via /proc/iomem to user space). We really want to merge
added resources in this scenario where possible.

Resources are effectively stored in a list-based tree. Having a lot of
resources not only wastes memory, it also makes traversing that tree more
expensive, and makes /proc/iomem explode in size (e.g., requiring
kexec-tools to manually merge resources when creating a kdump header. The
current kexec-tools resource count limit does not allow for more than
~100GB of memory with a memory block size of 128MB on x86-64).

Let's allow to selectively merge system ram resources by specifying a
new flag for add_memory*(). Patch #5 contains a /proc/iomem example. Only
tested with virtio-mem.

v3 -> v4:
- "mm/memory_hotplug: guard more declarations by CONFIG_MEMORY_HOTPLUG"
-- Fix configs without CONFIG_MEMORY_HOTPLUG with the new mhp_t type
-- Did a buch of cross-compiles with different configs, hope there isn't
   anything I missed.

v2 -> v3:
- "mm/memory_hotplug: prepare passing flags to add_memory() and friends"
-- Use proper __bitwise type for flags
-- Use "MHP_NONE" for empty flags
- Rebased to latest -next, added rb's

v1 -> v2:
- I had another look at v1 after vacation and didn't like it - it felt like
  a hack. So I want forward and added a proper flag to add_memory*(), and
  introduce a clean (non-racy) way to mark System RAM resources mergeable.
- "kernel/resource: move and rename IORESOURCE_MEM_DRIVER_MANAGED"
-- Clean that flag up, felt wrong in the PnP section
- "mm/memory_hotplug: prepare passing flags to add_memory() and friends"
-- Previously sent in other context - decided to keep Wei's ack
- "mm/memory_hotplug: MEMHP_MERGE_RESOURCE to specify merging of System
   RAM resources"
-- Cleaner approach to get the job done by using proper flags and only
   merging the single, specified resource
- "virtio-mem: try to merge system ram resources"
  "xen/balloon: try to merge system ram resources"
  "hv_balloon: try to merge system ram resources"
-- Use the new flag MEMHP_MERGE_RESOURCE, much cleaner

RFC -> v1:
- Switch from rather generic "merge_child_mem_resources()" where a resource
  name has to be specified to "merge_system_ram_resources().
- Smaller comment/documentation/patch description changes/fixes

David Hildenbrand (8):
  kernel/resource: make release_mem_region_adjustable() never fail
  kernel/resource: move and rename IORESOURCE_MEM_DRIVER_MANAGED
  mm/memory_hotplug: guard more declarations by CONFIG_MEMORY_HOTPLUG
  mm/memory_hotplug: prepare passing flags to add_memory() and friends
  mm/memory_hotplug: MEMHP_MERGE_RESOURCE to specify merging of System
RAM resources
  virtio-mem: try to merge system ram resources
  xen/balloon: try to merge system ram resources
  hv_balloon: try to merge system ram resources

 arch/powerpc/platforms/powernv/memtrace.c |   2 +-
 .../platforms/pseries/hotplug-memory.c|   2 +-
 drivers/acpi/acpi_memhotplug.c|   3 +-
 drivers/base/memory.c |   3 +-
 drivers/dax/kmem.c|   2 +-
 drivers/hv/hv_balloon.c   |   2 +-
 drivers/s390/char/sclp_cmd.c  |   2 +-
 drivers/virtio/virtio_mem.c   |   3 +-
 drivers/xen/balloon.c |   2 +-
 include/linux/ioport.h|  12 +-
 include/linux/memory_hotplug.h|  35 +++---
 kernel/kexec_file.c   |   2 +-
 kernel/resource.c | 109 ++
 mm/memory_hotplug.c   |  47 +++-
 mm/sparse.c   |   2 +
 15 files changed, 151 insertions(+), 77 deletions(-)

-- 
2.26.2
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org

[PATCH v4 8/8] hv_balloon: try to merge system ram resources

2020-09-11 Thread David Hildenbrand 
Let's try to merge system ram resources we add, to minimize the number
of resources in /proc/iomem. We don't care about the boundaries of
individual chunks we added.

Reviewed-by: Wei Liu 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: Wei Liu 
Cc: Pankaj Gupta 
Cc: Baoquan He 
Cc: Wei Yang 
Signed-off-by: David Hildenbrand 
---
 drivers/hv/hv_balloon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 3c0d52e244520..b64d2efbefe71 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -726,7 +726,7 @@ static void hv_mem_hot_add(unsigned long start, unsigned 
long size,
 
nid = memory_add_physaddr_to_nid(PFN_PHYS(start_pfn));
ret = add_memory(nid, PFN_PHYS((start_pfn)),
-   (HA_CHUNK << PAGE_SHIFT), MHP_NONE);
+   (HA_CHUNK << PAGE_SHIFT), MEMHP_MERGE_RESOURCE);
 
if (ret) {
pr_err("hot_add memory failed error is %d\n", ret);
-- 
2.26.2
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org

[PATCH v4 7/8] xen/balloon: try to merge system ram resources

2020-09-11 Thread David Hildenbrand 
Let's try to merge system ram resources we add, to minimize the number
of resources in /proc/iomem. We don't care about the boundaries of
individual chunks we added.

Reviewed-by: Juergen Gross 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: Roger Pau Monné 
Cc: Julien Grall 
Cc: Pankaj Gupta 
Cc: Baoquan He 
Cc: Wei Yang 
Signed-off-by: David Hildenbrand 
---
 drivers/xen/balloon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 9f40a294d398d..b57b2067ecbfb 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -331,7 +331,7 @@ static enum bp_state reserve_additional_memory(void)
mutex_unlock(_mutex);
/* add_memory_resource() requires the device_hotplug lock */
lock_device_hotplug();
-   rc = add_memory_resource(nid, resource, MHP_NONE);
+   rc = add_memory_resource(nid, resource, MEMHP_MERGE_RESOURCE);
unlock_device_hotplug();
mutex_lock(_mutex);
 
-- 
2.26.2
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org

[PATCH v4 4/8] mm/memory_hotplug: prepare passing flags to add_memory() and friends

2020-09-11 Thread David Hildenbrand 
We soon want to pass flags, e.g., to mark added System RAM resources.
mergeable. Prepare for that.

This patch is based on a similar patch by Oscar Salvador:

https://lkml.kernel.org/r/20190625075227.15193-3-osalva...@suse.de

Acked-by: Wei Liu 
Reviewed-by: Juergen Gross  # Xen related part
Reviewed-by: Pankaj Gupta 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Dan Williams 
Cc: Jason Gunthorpe 
Cc: Pankaj Gupta 
Cc: Baoquan He 
Cc: Wei Yang 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: Greg Kroah-Hartman 
Cc: Vishal Verma 
Cc: Dave Jiang 
Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: Wei Liu 
Cc: Heiko Carstens 
Cc: Vasily Gorbik 
Cc: Christian Borntraeger 
Cc: David Hildenbrand 
Cc: "Michael S. Tsirkin" 
Cc: Jason Wang 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: "Oliver O'Halloran" 
Cc: Pingfan Liu 
Cc: Nathan Lynch 
Cc: Libor Pechacek 
Cc: Anton Blanchard 
Cc: Leonardo Bras 
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-a...@vger.kernel.org
Cc: linux-nvdimm@lists.01.org
Cc: linux-hyp...@vger.kernel.org
Cc: linux-s...@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: xen-de...@lists.xenproject.org
Signed-off-by: David Hildenbrand 
---
 arch/powerpc/platforms/powernv/memtrace.c   |  2 +-
 arch/powerpc/platforms/pseries/hotplug-memory.c |  2 +-
 drivers/acpi/acpi_memhotplug.c  |  3 ++-
 drivers/base/memory.c   |  3 ++-
 drivers/dax/kmem.c  |  2 +-
 drivers/hv/hv_balloon.c |  2 +-
 drivers/s390/char/sclp_cmd.c|  2 +-
 drivers/virtio/virtio_mem.c |  2 +-
 drivers/xen/balloon.c   |  2 +-
 include/linux/memory_hotplug.h  | 16 
 mm/memory_hotplug.c | 14 +++---
 11 files changed, 30 insertions(+), 20 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/memtrace.c 
b/arch/powerpc/platforms/powernv/memtrace.c
index 13b369d2cc454..6828108486f83 100644
--- a/arch/powerpc/platforms/powernv/memtrace.c
+++ b/arch/powerpc/platforms/powernv/memtrace.c
@@ -224,7 +224,7 @@ static int memtrace_online(void)
ent->mem = 0;
}
 
-   if (add_memory(ent->nid, ent->start, ent->size)) {
+   if (add_memory(ent->nid, ent->start, ent->size, MHP_NONE)) {
pr_err("Failed to add trace memory to node %d\n",
ent->nid);
ret += 1;
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c 
b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 0ea976d1cac47..e1c9fa0d730f5 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -615,7 +615,7 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
nid = memory_add_physaddr_to_nid(lmb->base_addr);
 
/* Add the memory */
-   rc = __add_memory(nid, lmb->base_addr, block_sz);
+   rc = __add_memory(nid, lmb->base_addr, block_sz, MHP_NONE);
if (rc) {
invalidate_lmb_associativity_index(lmb);
return rc;
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index e294f44a78504..2067c3bc55763 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -207,7 +207,8 @@ static int acpi_memory_enable_device(struct 
acpi_memory_device *mem_device)
if (node < 0)
node = memory_add_physaddr_to_nid(info->start_addr);
 
-   result = __add_memory(node, info->start_addr, info->length);
+   result = __add_memory(node, info->start_addr, info->length,
+ MHP_NONE);
 
/*
 * If the memory block has been used by the kernel, add_memory()
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 4db3c660de831..b4c297dd04755 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -432,7 +432,8 @@ static ssize_t probe_store(struct device *dev, struct 
device_attribute *attr,
 
nid = memory_add_physaddr_to_nid(phys_addr);
ret = __add_memory(nid, phys_addr,
-  MIN_MEMORY_BLOCK_SIZE * sections_per_block);
+  MIN_MEMORY_BLOCK_SIZE * sections_per_block,
+  MHP_NONE);
 
if (ret)
goto out;
diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
index 7dcb2902e9b1b..896cb9444e727 100644
--- a/drivers/dax/kmem.c
+++ b/drivers/dax/kmem.c
@@ -95,7 +95,7 @@ int dev_dax_kmem_probe(struct dev_dax *dev_dax)
 * this as RAM automatically.
 */
rc = add_memory_driver_managed(numa_node, range.start,
-   range_len(), kmem_name);
+

[PATCH v4 5/8] mm/memory_hotplug: MEMHP_MERGE_RESOURCE to specify merging of System RAM resources

2020-09-11 Thread David Hildenbrand 
Some add_memory*() users add memory in small, contiguous memory blocks.
Examples include virtio-mem, hyper-v balloon, and the XEN balloon.

This can quickly result in a lot of memory resources, whereby the actual
resource boundaries are not of interest (e.g., it might be relevant for
DIMMs, exposed via /proc/iomem to user space). We really want to merge
added resources in this scenario where possible.

Let's provide a flag (MEMHP_MERGE_RESOURCE) to specify that a resource
either created within add_memory*() or passed via add_memory_resource()
shall be marked mergeable and merged with applicable siblings.

To implement that, we need a kernel/resource interface to mark selected
System RAM resources mergeable (IORESOURCE_SYSRAM_MERGEABLE) and trigger
merging.

Note: We really want to merge after the whole operation succeeded, not
directly when adding a resource to the resource tree (it would break
add_memory_resource() and require splitting resources again when the
operation failed - e.g., due to -ENOMEM).

Reviewed-by: Pankaj Gupta 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Dan Williams 
Cc: Jason Gunthorpe 
Cc: Kees Cook 
Cc: Ard Biesheuvel 
Cc: Thomas Gleixner 
Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: Wei Liu 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: Roger Pau Monné 
Cc: Julien Grall 
Cc: Pankaj Gupta 
Cc: Baoquan He 
Cc: Wei Yang 
Signed-off-by: David Hildenbrand 
---
 include/linux/ioport.h |  4 +++
 include/linux/memory_hotplug.h |  7 
 kernel/resource.c  | 60 ++
 mm/memory_hotplug.c|  7 
 4 files changed, 78 insertions(+)

diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index d7620d7c941a0..7e61389dcb017 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -60,6 +60,7 @@ struct resource {
 
 /* IORESOURCE_SYSRAM specific bits. */
 #define IORESOURCE_SYSRAM_DRIVER_MANAGED   0x0200 /* Always detected 
via a driver. */
+#define IORESOURCE_SYSRAM_MERGEABLE0x0400 /* Resource can be 
merged. */
 
 #define IORESOURCE_EXCLUSIVE   0x0800  /* Userland may not map this 
resource */
 
@@ -253,6 +254,9 @@ extern void __release_region(struct resource *, 
resource_size_t,
 extern void release_mem_region_adjustable(struct resource *, resource_size_t,
  resource_size_t);
 #endif
+#ifdef CONFIG_MEMORY_HOTPLUG
+extern void merge_system_ram_resource(struct resource *res);
+#endif
 
 /* Wrappers for managed devices */
 struct device;
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 33eb80fdba22f..d65c6fdc5cfc3 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -62,6 +62,13 @@ typedef int __bitwise mhp_t;
 
 /* No special request */
 #define MHP_NONE   ((__force mhp_t)0)
+/*
+ * Allow merging of the added System RAM resource with adjacent,
+ * mergeable resources. After a successful call to add_memory_resource()
+ * with this flag set, the resource pointer must no longer be used as it
+ * might be stale, or the resource might have changed.
+ */
+#define MEMHP_MERGE_RESOURCE   ((__force mhp_t)BIT(0))
 
 /*
  * Extended parameters for memory hotplug:
diff --git a/kernel/resource.c b/kernel/resource.c
index 36b3552210120..7a91b935f4c20 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -1363,6 +1363,66 @@ void release_mem_region_adjustable(struct resource 
*parent,
 }
 #endif /* CONFIG_MEMORY_HOTREMOVE */
 
+#ifdef CONFIG_MEMORY_HOTPLUG
+static bool system_ram_resources_mergeable(struct resource *r1,
+  struct resource *r2)
+{
+   /* We assume either r1 or r2 is IORESOURCE_SYSRAM_MERGEABLE. */
+   return r1->flags == r2->flags && r1->end + 1 == r2->start &&
+  r1->name == r2->name && r1->desc == r2->desc &&
+  !r1->child && !r2->child;
+}
+
+/*
+ * merge_system_ram_resource - mark the System RAM resource mergeable and try 
to
+ * merge it with adjacent, mergeable resources
+ * @res: resource descriptor
+ *
+ * This interface is intended for memory hotplug, whereby lots of contiguous
+ * system ram resources are added (e.g., via add_memory*()) by a driver, and
+ * the actual resource boundaries are not of interest (e.g., it might be
+ * relevant for DIMMs). Only resources that are marked mergeable, that have the
+ * same parent, and that don't have any children are considered. All mergeable
+ * resources must be immutable during the request.
+ *
+ * Note:
+ * - The caller has to make sure that no pointers to resources that are
+ *   marked mergeable are used anymore after this call - the resource might
+ *   be freed and the pointer might be stale!
+ * - release_mem_region_adjustable() will split on demand on memory hotunplug
+ */
+void merge_system_ram_resource(struct resource *res)
+{
+   const unsigned long flags = IORESOURCE_SYSTEM_RAM |

[PATCH v4 1/8] kernel/resource: make release_mem_region_adjustable() never fail

2020-09-11 Thread David Hildenbrand 
Let's make sure splitting a resource on memory hotunplug will never fail.
This will become more relevant once we merge selected System RAM
resources - then, we'll trigger that case more often on memory hotunplug.

In general, this function is already unlikely to fail. When we remove
memory, we free up quite a lot of metadata (memmap, page tables, memory
block device, etc.). The only reason it could really fail would be when
injecting allocation errors.

All other error cases inside release_mem_region_adjustable() seem to be
sanity checks if the function would be abused in different context -
let's add WARN_ON_ONCE() in these cases so we can catch them.

Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Dan Williams 
Cc: Jason Gunthorpe 
Cc: Kees Cook 
Cc: Ard Biesheuvel 
Cc: Pankaj Gupta 
Cc: Baoquan He 
Cc: Wei Yang 
Signed-off-by: David Hildenbrand 
---
 include/linux/ioport.h |  4 ++--
 kernel/resource.c  | 49 --
 mm/memory_hotplug.c| 22 +--
 3 files changed, 31 insertions(+), 44 deletions(-)

diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 6c2b06fe8beb7..52a91f5fa1a36 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -248,8 +248,8 @@ extern struct resource * __request_region(struct resource *,
 extern void __release_region(struct resource *, resource_size_t,
resource_size_t);
 #ifdef CONFIG_MEMORY_HOTREMOVE
-extern int release_mem_region_adjustable(struct resource *, resource_size_t,
-   resource_size_t);
+extern void release_mem_region_adjustable(struct resource *, resource_size_t,
+ resource_size_t);
 #endif
 
 /* Wrappers for managed devices */
diff --git a/kernel/resource.c b/kernel/resource.c
index f1175ce93a1d5..36b3552210120 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -1258,21 +1258,28 @@ EXPORT_SYMBOL(__release_region);
  *   assumes that all children remain in the lower address entry for
  *   simplicity.  Enhance this logic when necessary.
  */
-int release_mem_region_adjustable(struct resource *parent,
- resource_size_t start, resource_size_t size)
+void release_mem_region_adjustable(struct resource *parent,
+  resource_size_t start, resource_size_t size)
 {
+   struct resource *new_res = NULL;
+   bool alloc_nofail = false;
struct resource **p;
struct resource *res;
-   struct resource *new_res;
resource_size_t end;
-   int ret = -EINVAL;
 
end = start + size - 1;
-   if ((start < parent->start) || (end > parent->end))
-   return ret;
+   if (WARN_ON_ONCE((start < parent->start) || (end > parent->end)))
+   return;
 
-   /* The alloc_resource() result gets checked later */
-   new_res = alloc_resource(GFP_KERNEL);
+   /*
+* We free up quite a lot of memory on memory hotunplug (esp., memap),
+* just before releasing the region. This is highly unlikely to
+* fail - let's play save and make it never fail as the caller cannot
+* perform any error handling (e.g., trying to re-add memory will fail
+* similarly).
+*/
+retry:
+   new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0);
 
p = >child;
write_lock(_lock);
@@ -1298,7 +1305,6 @@ int release_mem_region_adjustable(struct resource *parent,
 * so if we are dealing with them, let us just back off here.
 */
if (!(res->flags & IORESOURCE_SYSRAM)) {
-   ret = 0;
break;
}
 
@@ -1315,20 +1321,23 @@ int release_mem_region_adjustable(struct resource 
*parent,
/* free the whole entry */
*p = res->sibling;
free_resource(res);
-   ret = 0;
} else if (res->start == start && res->end != end) {
/* adjust the start */
-   ret = __adjust_resource(res, end + 1,
-   res->end - end);
+   WARN_ON_ONCE(__adjust_resource(res, end + 1,
+  res->end - end));
} else if (res->start != start && res->end == end) {
/* adjust the end */
-   ret = __adjust_resource(res, res->start,
-   start - res->start);
+   WARN_ON_ONCE(__adjust_resource(res, res->start,
+  start - res->start));
} else {
-   /* split into two entries */
+   /* split into two entries - we need a new resource */
if (!new_res) {
-

[PATCH v4 3/8] mm/memory_hotplug: guard more declarations by CONFIG_MEMORY_HOTPLUG

2020-09-11 Thread David Hildenbrand 
We soon want to pass flags via a new type to add_memory() and friends.
That revealed that we currently don't guard some declarations by
CONFIG_MEMORY_HOTPLUG.

While some definitions could be moved to different places, let's keep it
minimal for now and use CONFIG_MEMORY_HOTPLUG for all functions only
compiled with CONFIG_MEMORY_HOTPLUG.

Wrap sparse_decode_mem_map() into CONFIG_MEMORY_HOTPLUG, it's only
called from CONFIG_MEMORY_HOTPLUG code.

While at it, remove allow_online_pfn_range(), which is no longer around,
and mhp_notimplemented(), which is unused.

Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Dan Williams 
Cc: Pankaj Gupta 
Cc: Baoquan He 
Cc: Wei Yang 
Signed-off-by: David Hildenbrand 
---
 include/linux/memory_hotplug.h | 12 +++-
 mm/sparse.c|  2 ++
 2 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 51a877fec8da8..1504b4d5ae6ce 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -247,13 +247,6 @@ static inline void zone_span_writelock(struct zone *zone) 
{}
 static inline void zone_span_writeunlock(struct zone *zone) {}
 static inline void zone_seqlock_init(struct zone *zone) {}
 
-static inline int mhp_notimplemented(const char *func)
-{
-   printk(KERN_WARNING "%s() called, with CONFIG_MEMORY_HOTPLUG 
disabled\n", func);
-   dump_stack();
-   return -ENOSYS;
-}
-
 static inline void register_page_bootmem_info_node(struct pglist_data *pgdat)
 {
 }
@@ -344,6 +337,7 @@ static inline void __remove_memory(int nid, u64 start, u64 
size) {}
 extern void set_zone_contiguous(struct zone *zone);
 extern void clear_zone_contiguous(struct zone *zone);
 
+#ifdef CONFIG_MEMORY_HOTPLUG
 extern void __ref free_area_init_core_hotplug(int nid);
 extern int __add_memory(int nid, u64 start, u64 size);
 extern int add_memory(int nid, u64 start, u64 size);
@@ -364,8 +358,8 @@ extern void sparse_remove_section(struct mem_section *ms,
unsigned long map_offset, struct vmem_altmap *altmap);
 extern struct page *sparse_decode_mem_map(unsigned long coded_mem_map,
  unsigned long pnum);
-extern bool allow_online_pfn_range(int nid, unsigned long pfn, unsigned long 
nr_pages,
-   int online_type);
 extern struct zone *zone_for_pfn_range(int online_type, int nid, unsigned 
start_pfn,
unsigned long nr_pages);
+#endif /* CONFIG_MEMORY_HOTPLUG */
+
 #endif /* __LINUX_MEMORY_HOTPLUG_H */
diff --git a/mm/sparse.c b/mm/sparse.c
index b25ad8e648392..7bd23f9d6cef6 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -312,6 +312,7 @@ static unsigned long sparse_encode_mem_map(struct page 
*mem_map, unsigned long p
return coded_mem_map;
 }
 
+#ifdef CONFIG_MEMORY_HOTPLUG
 /*
  * Decode mem_map from the coded memmap
  */
@@ -321,6 +322,7 @@ struct page *sparse_decode_mem_map(unsigned long 
coded_mem_map, unsigned long pn
coded_mem_map &= SECTION_MAP_MASK;
return ((struct page *)coded_mem_map) + section_nr_to_pfn(pnum);
 }
+#endif /* CONFIG_MEMORY_HOTPLUG */
 
 static void __meminit sparse_init_one_section(struct mem_section *ms,
unsigned long pnum, struct page *mem_map,
-- 
2.26.2
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org

[PATCH v4 6/8] virtio-mem: try to merge system ram resources

2020-09-11 Thread David Hildenbrand 
virtio-mem adds memory in memory block granularity, to be able to
remove it in the same granularity again later, and to grow slowly on
demand. This, however, results in quite a lot of resources when
adding a lot of memory. Resources are effectively stored in a list-based
tree. Having a lot of resources not only wastes memory, it also makes
traversing that tree more expensive, and makes /proc/iomem explode in
size (e.g., requiring kexec-tools to manually merge resources later
when e.g., trying to create a kdump header).

Before this patch, we get (/proc/iomem) when hotplugging 2G via virtio-mem
on x86-64:
[...]
1-13fff : System RAM
14000-33fff : virtio0
  14000-147ff : System RAM (virtio_mem)
  14800-14fff : System RAM (virtio_mem)
  15000-157ff : System RAM (virtio_mem)
  15800-15fff : System RAM (virtio_mem)
  16000-167ff : System RAM (virtio_mem)
  16800-16fff : System RAM (virtio_mem)
  17000-177ff : System RAM (virtio_mem)
  17800-17fff : System RAM (virtio_mem)
  18000-187ff : System RAM (virtio_mem)
  18800-18fff : System RAM (virtio_mem)
  19000-197ff : System RAM (virtio_mem)
  19800-19fff : System RAM (virtio_mem)
  1a000-1a7ff : System RAM (virtio_mem)
  1a800-1afff : System RAM (virtio_mem)
  1b000-1b7ff : System RAM (virtio_mem)
  1b800-1bfff : System RAM (virtio_mem)
328000-32 : PCI Bus :00

With this patch, we get (/proc/iomem):
[...]
fffc- : Reserved
1-13fff : System RAM
14000-33fff : virtio0
  14000-1bfff : System RAM (virtio_mem)
328000-32 : PCI Bus :00

Of course, with more hotplugged memory, it gets worse. When unplugging
memory blocks again, try_remove_memory() (via
offline_and_remove_memory()) will properly split the resource up again.

Reviewed-by: Pankaj Gupta 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Dan Williams 
Cc: Michael S. Tsirkin 
Cc: Jason Wang 
Cc: Pankaj Gupta 
Cc: Baoquan He 
Cc: Wei Yang 
Signed-off-by: David Hildenbrand 
---
 drivers/virtio/virtio_mem.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index ed99e43354010..ba4de598f6636 100644
--- a/drivers/virtio/virtio_mem.c
+++ b/drivers/virtio/virtio_mem.c
@@ -424,7 +424,8 @@ static int virtio_mem_mb_add(struct virtio_mem *vm, 
unsigned long mb_id)
 
dev_dbg(>vdev->dev, "adding memory block: %lu\n", mb_id);
return add_memory_driver_managed(nid, addr, memory_block_size_bytes(),
-vm->resource_name, MHP_NONE);
+vm->resource_name,
+MEMHP_MERGE_RESOURCE);
 }
 
 /*
-- 
2.26.2
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org

[PATCH v4 2/8] kernel/resource: move and rename IORESOURCE_MEM_DRIVER_MANAGED

2020-09-11 Thread David Hildenbrand 
IORESOURCE_MEM_DRIVER_MANAGED currently uses an unused PnP bit, which is
always set to 0 by hardware. This is far from beautiful (and confusing),
and the bit only applies to SYSRAM. So let's move it out of the
bus-specific (PnP) defined bits.

We'll add another SYSRAM specific bit soon. If we ever need more bits for
other purposes, we can steal some from "desc", or reshuffle/regroup what we
have.

Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Dan Williams 
Cc: Jason Gunthorpe 
Cc: Kees Cook 
Cc: Ard Biesheuvel 
Cc: Pankaj Gupta 
Cc: Baoquan He 
Cc: Wei Yang 
Cc: Eric Biederman 
Cc: Thomas Gleixner 
Cc: Greg Kroah-Hartman 
Cc: ke...@lists.infradead.org
Signed-off-by: David Hildenbrand 
---
 include/linux/ioport.h | 4 +++-
 kernel/kexec_file.c| 2 +-
 mm/memory_hotplug.c| 4 ++--
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 52a91f5fa1a36..d7620d7c941a0 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -58,6 +58,9 @@ struct resource {
 #define IORESOURCE_EXT_TYPE_BITS 0x0100/* Resource extended types */
 #define IORESOURCE_SYSRAM  0x0100  /* System RAM (modifier) */
 
+/* IORESOURCE_SYSRAM specific bits. */
+#define IORESOURCE_SYSRAM_DRIVER_MANAGED   0x0200 /* Always detected 
via a driver. */
+
 #define IORESOURCE_EXCLUSIVE   0x0800  /* Userland may not map this 
resource */
 
 #define IORESOURCE_DISABLED0x1000
@@ -103,7 +106,6 @@ struct resource {
 #define IORESOURCE_MEM_32BIT   (3<<3)
 #define IORESOURCE_MEM_SHADOWABLE  (1<<5)  /* dup: IORESOURCE_SHADOWABLE */
 #define IORESOURCE_MEM_EXPANSIONROM(1<<6)
-#define IORESOURCE_MEM_DRIVER_MANAGED  (1<<7)
 
 /* PnP I/O specific bits (IORESOURCE_BITS) */
 #define IORESOURCE_IO_16BIT_ADDR   (1<<0)
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index ca40bef75a616..dfeeed1aed084 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -520,7 +520,7 @@ static int locate_mem_hole_callback(struct resource *res, 
void *arg)
/* Returning 0 will take to next memory range */
 
/* Don't use memory that will be detected and handled by a driver. */
-   if (res->flags & IORESOURCE_MEM_DRIVER_MANAGED)
+   if (res->flags & IORESOURCE_SYSRAM_DRIVER_MANAGED)
return 0;
 
if (sz < kbuf->memsz)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 4c47b68a9f4b5..8e1cd18b5cf14 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -105,7 +105,7 @@ static struct resource *register_memory_resource(u64 start, 
u64 size,
unsigned long flags =  IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
if (strcmp(resource_name, "System RAM"))
-   flags |= IORESOURCE_MEM_DRIVER_MANAGED;
+   flags |= IORESOURCE_SYSRAM_DRIVER_MANAGED;
 
/*
 * Make sure value parsed from 'mem=' only restricts memory adding
@@ -1160,7 +1160,7 @@ EXPORT_SYMBOL_GPL(add_memory);
  *
  * For this memory, no entries in /sys/firmware/memmap ("raw firmware-provided
  * memory map") are created. Also, the created memory resource is flagged
- * with IORESOURCE_MEM_DRIVER_MANAGED, so in-kernel users can special-case
+ * with IORESOURCE_SYSRAM_DRIVER_MANAGED, so in-kernel users can special-case
  * this memory as well (esp., not place kexec images onto it).
  *
  * The resource_name (visible via /proc/iomem) has to have the format
-- 
2.26.2
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org

Re: [PATCH v3 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends

2020-09-11 Thread David Hildenbrand 
On 11.09.20 04:21, kernel test robot wrote:
> Hi David,
> 
> I love your patch! Yet something to improve:
> 
> [auto build test ERROR on next-20200909]
> [cannot apply to mmotm/master hnaz-linux-mm/master xen-tip/linux-next 
> powerpc/next linus/master v5.9-rc4 v5.9-rc3 v5.9-rc2 v5.9-rc4]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
> 
> url:
> https://github.com/0day-ci/linux/commits/David-Hildenbrand/mm-memory_hotplug-selective-merging-of-system-ram-resources/20200910-171630
> base:7204eaa2c1f509066486f488c9dcb065d7484494
> config: x86_64-randconfig-a016-20200909 (attached as .config)
> compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
> 0a5dc7effb191eff740e0e7ae7bd8e1f6bdb3ad9)
> reproduce (this is a W=1 build):
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install x86_64 cross compiling tool for clang build
> # apt-get install binutils-x86-64-linux-gnu
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross 
> ARCH=x86_64 
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
> 
> All errors (new ones prefixed by >>):
> 
>WARNING: unmet direct dependencies detected for PHY_SAMSUNG_UFS
>Depends on OF && (ARCH_EXYNOS || COMPILE_TEST
>Selected by
>- SCSI_UFS_EXYNOS && SCSI_LOWLEVEL && SCSI && SCSI_UFSHCD_PLATFORM && 
> (ARCH_EXYNOS || COMPILE_TEST
>In file included from arch/x86/kernel/asm-offsets.c:9:
>In file included from include/linux/crypto.h:20:
>In file included from include/linux/slab.h:15:
>In file included from include/linux/gfp.h:6:
>In file included from include/linux/mmzone.h:853:
>>> include/linux/memory_hotplug.h:354:55: error: unknown type name 'mhp_t'
>extern int __add_memory(int nid, u64 start, u64 size, mhp_t mhp_flags);
>^
>include/linux/memory_hotplug.h:355:53: error: unknown type name 'mhp_t'
>extern int add_memory(int nid, u64 start, u64 size, mhp_t mhp_flags);
>^
>include/linux/memory_hotplug.h:357:11: error: unknown type name 'mhp_t'
>mhp_t mhp_flags);
>^
>include/linux/memory_hotplug.h:360:10: error: unknown type name 'mhp_t'
>mhp_t mhp_flags);
>^
>4 errors generated.
>Makefile Module.symvers System.map arch block certs crypto drivers fs 
> include init ipc kernel lib mm modules.builtin modules.builtin.modinfo 
> modules.order net scripts security sound source tools usr virt vmlinux 
> vmlinux.o vmlinux.symvers [scripts/Makefile.build:117: 
> arch/x86/kernel/asm-offsets.s] Error 1
>Target '__build' not remade because of errors.
>Makefile Module.symvers System.map arch block certs crypto drivers fs 
> include init ipc kernel lib mm modules.builtin modules.builtin.modinfo 
> modules.order net scripts security sound source tools usr virt vmlinux 
> vmlinux.o vmlinux.symvers [Makefile:1196: prepare0] Error 2
>Target 'prepare' not remade because of errors.
>make: Makefile Module.symvers System.map arch block certs crypto drivers 
> fs include init ipc kernel lib mm modules.builtin modules.builtin.modinfo 
> modules.order net scripts security sound source tools usr virt vmlinux 
> vmlinux.o vmlinux.symvers [Makefile:185: __sub-make] Error 2
>make: Target 'prepare' not remade because of errors.
> 
> # 
> https://github.com/0day-ci/linux/commit/d88270d1c0783a7f99f24a85692be90fd2ae0d7d
> git remote add linux-review https://github.com/0day-ci/linux
> git fetch --no-tags linux-review 
> David-Hildenbrand/mm-memory_hotplug-selective-merging-of-system-ram-resources/20200910-171630
> git checkout d88270d1c0783a7f99f24a85692be90fd2ae0d7d
> vim +/mhp_t +354 include/linux/memory_hotplug.h
> 
>352
>353extern void __ref free_area_init_core_hotplug(int nid);
>  > 354extern int __add_memory(int nid, u64 start, u64 size, mhp_t 
> mhp_flags);
> 

add_memory() and not protected by CONFIG_MEMORY_HOTPLUG, but the new
type is. Will look into it.

-- 
Thanks,

David / dhildenb
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org

Re: [PATCH v2 9/9] iomap: Change calling convention for zeroing

2020-09-11 Thread Christoph Hellwig 
On Fri, Sep 11, 2020 at 12:47:07AM +0100, Matthew Wilcox (Oracle) wrote:
> Pass the full length to iomap_zero() and dax_iomap_zero(), and have
> them return how many bytes they actually handled.  This is preparatory
> work for handling THP, although it looks like DAX could actually take
> advantage of it if there's a larger contiguous area.

Looks good,

Reviewed-by: Christoph Hellwig 
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org