[PATCH v5 1/7] libndctl: Use the supported_alignment attribute
by Oliver O'Halloran
Newer kernels provide the "supported_alignments" sysfs attribute that
indicates what alignments can be used with a PFN or DAX namespace. This
patch adds the plumbing inside of libndctl to allow users to query this
information through using:
ndctl_{dax|pfn}_get_supported_alignment(), and
ndctl_{dax|pfn}_get_num_alignments()
Signed-off-by: Oliver O'Halloran <oohall(a)gmail.com>
---
v5: Fixed comment wording
v4: Changed return code of ndctl_pfn_get_supported_alignment from -1 to
-1 to -EINVAL.
Reworded comment about why we default to 4K and 2M alignments when
the sysfs attribute is missing.
Shuffled around prototypes in ndctl.h.
80 char compliance fixes.
rebased onto pending branch
v3: Changed the return type of the *_get_supported_alignment() functions
to unsigned long to match the existing *_get_alignment() functions.
---
ndctl/lib/libndctl.c | 43 ++++++++++++++++++++++++++++++++++++++++++
ndctl/lib/libndctl.sym | 4 ++++
ndctl/libndctl.h | 4 ++++
3 files changed, 51 insertions(+)
diff --git a/ndctl/lib/libndctl.c b/ndctl/lib/libndctl.c
index 830b791339d2..06f835d76117 100644
--- a/ndctl/lib/libndctl.c
+++ b/ndctl/lib/libndctl.c
@@ -31,6 +31,7 @@
#include <ccan/build_assert/build_assert.h>
#include <ndctl.h>
+#include <util/size.h>
#include <util/sysfs.h>
#include <ndctl/libndctl.h>
#include <ndctl/namespace.h>
@@ -237,6 +238,7 @@ struct ndctl_pfn {
int buf_len;
uuid_t uuid;
int id, generation;
+ struct ndctl_lbasize alignments;
};
struct ndctl_dax {
@@ -4814,6 +4816,19 @@ static void *__add_pfn(struct ndctl_pfn *pfn, const char *pfn_base)
else
pfn->size = strtoull(buf, NULL, 0);
+ /*
+ * The supported_alignments attribute was added before arches other
+ * than x86 had pmem support. If the kernel doesn't provide the
+ * attribute then it's safe to assume that we running on x86 where
+ * 4KiB and 2MiB have always been supported.
+ */
+ sprintf(path, "%s/supported_alignments", pfn_base);
+ if (sysfs_read_attr(ctx, path, buf) < 0)
+ sprintf(buf, "%d %d", SZ_4K, SZ_2M);
+
+ if (parse_lbasize_supported(ctx, pfn_base, buf, &pfn->alignments) < 0)
+ goto err_read;
+
free(path);
return pfn;
@@ -5048,6 +5063,23 @@ NDCTL_EXPORT int ndctl_pfn_set_align(struct ndctl_pfn *pfn, unsigned long align)
return 0;
}
+NDCTL_EXPORT int ndctl_pfn_get_num_alignments(struct ndctl_pfn *pfn)
+{
+ return pfn->alignments.num;
+}
+
+NDCTL_EXPORT unsigned long ndctl_pfn_get_supported_alignment(
+ struct ndctl_pfn *pfn, int i)
+{
+ if (pfn->alignments.num == 0)
+ return 0;
+
+ if (i < 0 || i > pfn->alignments.num)
+ return -EINVAL;
+ else
+ return pfn->alignments.supported[i];
+}
+
NDCTL_EXPORT int ndctl_pfn_set_namespace(struct ndctl_pfn *pfn,
struct ndctl_namespace *ndns)
{
@@ -5270,6 +5302,17 @@ NDCTL_EXPORT unsigned long ndctl_dax_get_align(struct ndctl_dax *dax)
return ndctl_pfn_get_align(&dax->pfn);
}
+NDCTL_EXPORT int ndctl_dax_get_num_alignments(struct ndctl_dax *dax)
+{
+ return ndctl_pfn_get_num_alignments(&dax->pfn);
+}
+
+NDCTL_EXPORT unsigned long ndctl_dax_get_supported_alignment(
+ struct ndctl_dax *dax, int i)
+{
+ return ndctl_pfn_get_supported_alignment(&dax->pfn, i);
+}
+
NDCTL_EXPORT int ndctl_dax_has_align(struct ndctl_dax *dax)
{
return ndctl_pfn_has_align(&dax->pfn);
diff --git a/ndctl/lib/libndctl.sym b/ndctl/lib/libndctl.sym
index 275db92ee103..a30a93e3c012 100644
--- a/ndctl/lib/libndctl.sym
+++ b/ndctl/lib/libndctl.sym
@@ -390,4 +390,8 @@ LIBNDCTL_19 {
global:
ndctl_cmd_xlat_firmware_status;
ndctl_cmd_submit_xlat;
+ ndctl_pfn_get_supported_alignment;
+ ndctl_pfn_get_num_alignments;
+ ndctl_dax_get_supported_alignment;
+ ndctl_dax_get_num_alignments;
} LIBNDCTL_18;
diff --git a/ndctl/libndctl.h b/ndctl/libndctl.h
index e55a5932781d..ac639b7d9142 100644
--- a/ndctl/libndctl.h
+++ b/ndctl/libndctl.h
@@ -597,7 +597,9 @@ int ndctl_pfn_set_uuid(struct ndctl_pfn *pfn, uuid_t uu);
void ndctl_pfn_get_uuid(struct ndctl_pfn *pfn, uuid_t uu);
int ndctl_pfn_has_align(struct ndctl_pfn *pfn);
int ndctl_pfn_set_align(struct ndctl_pfn *pfn, unsigned long align);
+int ndctl_pfn_get_num_alignments(struct ndctl_pfn *pfn);
unsigned long ndctl_pfn_get_align(struct ndctl_pfn *pfn);
+unsigned long ndctl_pfn_get_supported_alignment(struct ndctl_pfn *pfn, int i);
unsigned long long ndctl_pfn_get_resource(struct ndctl_pfn *pfn);
unsigned long long ndctl_pfn_get_size(struct ndctl_pfn *pfn);
int ndctl_pfn_set_namespace(struct ndctl_pfn *pfn, struct ndctl_namespace *ndns);
@@ -628,7 +630,9 @@ unsigned long long ndctl_dax_get_resource(struct ndctl_dax *dax);
int ndctl_dax_set_uuid(struct ndctl_dax *dax, uuid_t uu);
enum ndctl_pfn_loc ndctl_dax_get_location(struct ndctl_dax *dax);
int ndctl_dax_set_location(struct ndctl_dax *dax, enum ndctl_pfn_loc loc);
+int ndctl_dax_get_num_alignments(struct ndctl_dax *dax);
unsigned long ndctl_dax_get_align(struct ndctl_dax *dax);
+unsigned long ndctl_dax_get_supported_alignment(struct ndctl_dax *dax, int i);
int ndctl_dax_has_align(struct ndctl_dax *dax);
int ndctl_dax_set_align(struct ndctl_dax *dax, unsigned long align);
int ndctl_dax_set_namespace(struct ndctl_dax *dax,
--
2.20.1
3 years, 3 months
[PATCH] update NFIT flags error message
by Toshi Kani
ACPI NFIT flags field reports major errors on NVDIMM, which need
user's attention.
Update the current log to a proper error message with dev_err().
The current message string is kept for grep-compatibility.
Signed-off-by: Toshi Kani <toshi.kani(a)hpe.com>
Cc: Dan Williams <dan.j.williams(a)intel.com>
Cc: "Rafael J. Wysocki" <rjw(a)rjwysocki.net>
Cc: Robert Elliott <elliott(a)hpe.com>
---
drivers/acpi/nfit/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index e18ade5d74e9..143a77704481 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -2050,7 +2050,7 @@ static int acpi_nfit_register_dimms(struct acpi_nfit_desc *acpi_desc)
if ((mem_flags & ACPI_NFIT_MEM_FAILED_MASK) == 0)
continue;
- dev_info(acpi_desc->dev, "%s flags:%s%s%s%s%s\n",
+ dev_err(acpi_desc->dev, "Error found in NVDIMM %s flags:%s%s%s%s%s\n",
nvdimm_name(nvdimm),
mem_flags & ACPI_NFIT_MEM_SAVE_FAILED ? " save_fail" : "",
mem_flags & ACPI_NFIT_MEM_RESTORE_FAILED ? " restore_fail":"",
3 years, 4 months
[PATCH 0/5] [v5] Allow persistent memory to be used like normal RAM
by Dave Hansen
This is a relatively small delta from v4. The review comments seem
to be settling down, so it seems like we should start thinking about
how this might get merged. Are there any objections to taking it in
via the nvdimm tree?
Dan Williams, our intrepid nvdimm maintainer has said he would
appreciate acks on these from relevant folks before merging them.
Reviews/acks on any in the series would be welcome, but the last
two especially are lacking any non-Intel acks:
mm/resource: let walk_system_ram_range() search child resources
dax: "Hotplug" persistent memory for use like normal RAM
Note: these are based on commit b20a7bfc2f9 in:
git://git.kernel.org/pub/scm/linux/kernel/git/djbw/nvdimm.git for-5.1/devdax
Changes since v4:
* Update powerpc resource return codes too, not just generic
* Update dev_dax_kmem_remove() comment about resource "leaks"
* Make HMM-related warning in __request_region() use %pR's
* Add GPL export for memory_block_size_bytes() to fix build erroe
* Add a FAQ in the documentation
* Make resource.c hmm output a pr_warn() instead of pr_debug()
* Minor CodingStyle tweaks
* Allow device removal by making dev_dax_kmem_remove() return 0.
Note that although the device goes away, the memory stays
in-use, assigned and reserved.
Changes since v3:
* Move HMM-related resource warning instead of removing it
* Use __request_resource() directly instead of devm.
* Create a separate DAX_PMEM Kconfig option, complete with help text
* Update patch descriptions and cover letter to give a better
overview of use-cases and hardware where this might be useful.
Changes since v2:
* Updates to dev_dax_kmem_probe() in patch 5:
* Reject probes for devices with bad NUMA nodes. Keeps slow
memory from being added to node 0.
* Use raw request_mem_region()
* Add comments about permanent reservation
* use dev_*() instead of printk's
* Add references to nvdimm documentation in descriptions
* Remove unneeded GPL export
* Add Kconfig prompt and help text
Changes since v1:
* Now based on git://git.kernel.org/pub/scm/linux/kernel/git/djbw/nvdimm.git
* Use binding/unbinding from "dax bus" code
* Move over to a "dax bus" driver from being an nvdimm driver
--
Persistent memory is cool. But, currently, you have to rewrite
your applications to use it. Wouldn't it be cool if you could
just have it show up in your system like normal RAM and get to
it like a slow blob of memory? Well... have I got the patch
series for you!
== Background / Use Cases ==
Persistent Memory (aka Non-Volatile DIMMs / NVDIMMS) themselves
are described in detail in Documentation/nvdimm/nvdimm.txt.
However, this documentation focuses on actually using them as
storage. This set is focused on using NVDIMMs as DRAM replacement.
This is intended for Intel-style NVDIMMs (aka. Intel Optane DC
persistent memory) NVDIMMs. These DIMMs are physically persistent,
more akin to flash than traditional RAM. They are also expected to
be more cost-effective than using RAM, which is why folks want this
set in the first place.
This set is not intended for RAM-based NVDIMMs. Those are not
cost-effective vs. plain RAM, and this using them here would simply
be a waste. However, if you have a user of a system that does not
care about persistence and wants all the RAM they can get, this
could allow you to use a RAM-based NVDIMM where it would otherwise
go unused.
But, why would you bother with this approach? Intel itself [1]
has announced a hardware feature that does something very similar:
"Memory Mode" which turns DRAM into a cache in front of persistent
memory, which is then as a whole used as normal "RAM"?
Here are a few reasons:
1. The capacity of memory mode is the size of your persistent
memory that you dedicate. DRAM capacity is "lost" because it
is used for cache. With this, you get PMEM+DRAM capacity for
memory.
2. DRAM acts as a cache with memory mode, and caches can lead to
unpredictable latencies. Since memory mode is all-or-nothing
(either all your DRAM is used as cache or none is), your entire
memory space is exposed to these unpredictable latencies. This
solution lets you guarantee DRAM latencies if you need them.
3. The new "tier" of memory is exposed to software. That means
that you can build tiered applications or infrastructure. A
cloud provider could sell cheaper VMs that use more PMEM and
more expensive ones that use DRAM. That's impossible with
memory mode.
Don't take this as criticism of memory mode. Memory mode is
awesome, and doesn't strictly require *any* software changes (we
have software changes proposed for optimizing it though). It has
tons of other advantages over *this* approach. Basically, we
believe that the approach in these patches is complementary to
memory mode and that both can live side-by-side in harmony.
== Patch Set Overview ==
This series adds a new "driver" to which pmem devices can be
attached. Once attached, the memory "owned" by the device is
hot-added to the kernel and managed like any other memory. On
systems with an HMAT (a new ACPI table), each socket (roughly)
will have a separate NUMA node for its persistent memory so
this newly-added memory can be selected by its unique NUMA
node.
== FAQ ==
Q: Will this break my NVDIMMs?
Intel's NVDIMMs were designed with use-cases like this in mind.
Using this feature on that hardware is not expected to affect
its service life. If you have NVDIMMs from other sources, it
would be best to consult your hardware vendor to see if this
kind of use is appropriate.
Q: Will this leave secret data in memory after reboots?
Yes. Data placed in persistent memory will remain there until
it is written again. There are no specific mitigations for
this in the current patch set. However, these kinds of issues
already exist in the kernel. We leave secrets in "free" memory
all the time, and even across kexec-style reboots. The only
difference here is that data can survive power cycles.
The kernel has built-in protections to ensure that sensitive
data is zero'd before being handed out to applications. If
your persistent-memory data was available to an application,
it would almost certainly be a bug with or without this patch
set.
In addition, NVDIMMs have built-in encryption, functionally
similar to the disk passwords present on hard drives. When
available, we suggest configuring NVDIMMs so that they are
locked on any power loss.
Q: What happens if memory errors are encountered?
If encountered at runtime, all the existing DRAM-based memory
error reporting and recovery is used: nothing changes. The
only thing that's different is that the poison can be
persistent across reboots. We suggest using the ndctl utility
to recover these locations for now. Doing this automatically
could be a part of future enabling. But, for now, please do
it from userspace.
== Testing Overview ==
Here's how I set up a system to test this thing:
1. Boot qemu with lots of memory: "-m 4096", for instance
2. Reserve 512MB of physical memory. Reserving a spot a 2GB
physical seems to work: memmap=512M!0x0000000080000000
This will end up looking like a pmem device at boot.
3. When booted, convert fsdax device to "device dax":
ndctl create-namespace -fe namespace0.0 -m dax
4. See patch 5 for instructions on binding the kmem driver
to a device.
5. Now, online the new memory sections. Perhaps:
grep ^MemTotal /proc/meminfo
for f in `grep -vl online /sys/devices/system/memory/*/state`; do
echo $f: `cat $f`
echo online_movable > $f
grep ^MemTotal /proc/meminfo
done
1. https://itpeernetwork.intel.com/intel-optane-dc-persistent-memory-operati...
Cc: Dan Williams <dan.j.williams(a)intel.com>
Cc: Dave Jiang <dave.jiang(a)intel.com>
Cc: Ross Zwisler <zwisler(a)kernel.org>
Cc: Vishal Verma <vishal.l.verma(a)intel.com>
Cc: Tom Lendacky <thomas.lendacky(a)amd.com>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: linux-nvdimm(a)lists.01.org
Cc: linux-kernel(a)vger.kernel.org
Cc: linux-mm(a)kvack.org
Cc: Huang Ying <ying.huang(a)intel.com>
Cc: Fengguang Wu <fengguang.wu(a)intel.com>
Cc: Borislav Petkov <bp(a)suse.de>
Cc: Bjorn Helgaas <bhelgaas(a)google.com>
Cc: Yaowei Bai <baiyaowei(a)cmss.chinamobile.com>
Cc: Takashi Iwai <tiwai(a)suse.de>
Cc: Jerome Glisse <jglisse(a)redhat.com>
Cc: Keith Busch <keith.busch(a)intel.com>
3 years, 4 months
[PATCH v5 1/2] nvdimm, btt: remove unnecessary code in btt_freelist_init
by Vishal Verma
We call btt_log_read() twice, once to get the 'old' log entry, and again
to get the 'new' entry. However, we have no use for the 'old' entry, so
remove it.
Cc: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma(a)intel.com>
---
drivers/nvdimm/btt.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
v5: no changes in this patch
diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c
index b123b0dcf274..cd4fa87ea48c 100644
--- a/drivers/nvdimm/btt.c
+++ b/drivers/nvdimm/btt.c
@@ -541,9 +541,9 @@ static int arena_clear_freelist_error(struct arena_info *arena, u32 lane)
static int btt_freelist_init(struct arena_info *arena)
{
- int old, new, ret;
+ int new, ret;
u32 i, map_entry;
- struct log_entry log_new, log_old;
+ struct log_entry log_new;
arena->freelist = kcalloc(arena->nfree, sizeof(struct free_entry),
GFP_KERNEL);
@@ -551,10 +551,6 @@ static int btt_freelist_init(struct arena_info *arena)
return -ENOMEM;
for (i = 0; i < arena->nfree; i++) {
- old = btt_log_read(arena, i, &log_old, LOG_OLD_ENT);
- if (old < 0)
- return old;
-
new = btt_log_read(arena, i, &log_new, LOG_NEW_ENT);
if (new < 0)
return new;
--
2.20.1
3 years, 4 months
[PATCH 1/2] nvdimm, btt: remove unnecessary code in btt_freelist_init
by Vishal Verma
We call btt_log_read() twice, once to get the 'old' log entry, and again
to get the 'new' entry. However, we have no use for the 'old' entry, so
remove it.
Cc: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma(a)intel.com>
---
drivers/nvdimm/btt.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c
index b123b0dcf274..cd4fa87ea48c 100644
--- a/drivers/nvdimm/btt.c
+++ b/drivers/nvdimm/btt.c
@@ -541,9 +541,9 @@ static int arena_clear_freelist_error(struct arena_info *arena, u32 lane)
static int btt_freelist_init(struct arena_info *arena)
{
- int old, new, ret;
+ int new, ret;
u32 i, map_entry;
- struct log_entry log_new, log_old;
+ struct log_entry log_new;
arena->freelist = kcalloc(arena->nfree, sizeof(struct free_entry),
GFP_KERNEL);
@@ -551,10 +551,6 @@ static int btt_freelist_init(struct arena_info *arena)
return -ENOMEM;
for (i = 0; i < arena->nfree; i++) {
- old = btt_log_read(arena, i, &log_old, LOG_OLD_ENT);
- if (old < 0)
- return old;
-
new = btt_log_read(arena, i, &log_new, LOG_NEW_ENT);
if (new < 0)
return new;
--
2.20.1
3 years, 4 months
find_get_entries_tag regression bisected
by Dan Williams
Hi Willy,
Piotr reports the following crash can be triggered on latest mainline:
EXT4-fs (pmem5): recovery complete
EXT4-fs (pmem5): mounted filesystem with ordered data mode. Opts: dax
------------[ cut here ]------------
kernel BUG at mm/pgtable-generic.c:127!
invalid opcode: 0000 [#1] SMP PTI
CPU: 28 PID: 1193 Comm: a.out Tainted: G W OE 4.19.0-rc5+ #2907
[..]
RIP: 0010:pmdp_huge_clear_flush+0x1e/0x80
[..]
Call Trace:
dax_writeback_mapping_range+0x473/0x8a0
? print_shortest_lock_dependencies+0x40/0x40
? jbd2_journal_stop+0xef/0x470
? ext4_fill_super+0x3071/0x3110
? __lock_is_held+0x4f/0x90
? __lock_is_held+0x4f/0x90
ext4_dax_writepages+0xed/0x2f0
do_writepages+0x41/0xe0
__filemap_fdatawrite_range+0xbe/0xf0
file_write_and_wait_range+0x4c/0xa0
ext4_sync_file+0xa6/0x4f0
I bisected this regression to commit c1901cd33cf4 "page cache: Convert
find_get_entries_tag to XArray". I suspect another case of pte vs pmd
confusion.
Below is the small reproducer from Piotr, it triggers in a qemu
environment with emulated pmem, but only with ext4 that I can see, but
I did not dig too deep. Let me know if anything jumps out to you. I'll
otherwise take a deeper look in the coming days.
#include <sys/mman.h>
#include <unistd.h>
#include <stdio.h>
#include <fcntl.h>
#include <string.h>
#include <assert.h>
#define MB (1ULL << 20)
int
main(int argc, char *argv[])
{
int ret;
int fd;
off_t size = 2 * MB;
char *path = argv[1];
fd = open(path, O_RDWR | O_CREAT | O_EXCL, 0666);
assert(fd > 0);
ret = ftruncate(fd, size);
assert(ret == 0);
char *addr = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
assert(addr != MAP_FAILED);
memset((char*)addr, '0', 1);
ret = msync(addr + 4096, 1, MS_SYNC);
assert(ret == 0);
close(fd);
return 0;
}
3 years, 4 months
Returned mail: Data format error
by Returned mail
9]\F���E0��H�)T"��zb��8Z~�������wo��|��G�������>����e
��Q�,VP���`R���5M�Z{��m��\_]� �����><���du��P�DU�P�>C���,V������
�F����s�/����
������m�
H��99�Ny�&[�S�
�yY�J8�E���k
Y����C�-`�Fc^s��4B�n�W�r���Pj�����7�}d3_v~k-���}�0�v�.o����gHe�(�v��J7��D��&��OF-�lX�W��&eZ>���Ue�ln���g��#i�RX��5a�|�S���[u�����)�~�������������m?6�;%Z|��sF���f�V0���5��(V��4�3�[d��6���ZW��H)��E�����p�!��/4�\�.�a�pF-��'0EzH���NN��.;?5;��`C��u�F^w/���5J����Q�?�n��JT:_�_���N`������#qg�]��L"���K��"���
�'<�]X�p!R75���i�h����BE&|����.��"�q(s`��OQ0�~���p%�.�x^-��������J��W� ��&�I�{�S'��%�;��Phhn�->*���$y`�j��U��A{��83'�s0_X��q!����
��_
�H�~�{/�W���O�J�����H���~��}���������f�e��am�Aq�n��������0���3���YQx9�qN����BW�ZN�W�?�,���}"j�/�o���z�!hS�mO'>4�Y���A�|9����T�����yC"�C���h���Y���
VV�F�R�����l� ����^hu�0�3��a��:e�r���-�1v��'�%"e��Z���K��S��!�!��������M`����`������hof�}��O����M
o��2��c��H
:�R*��n�� �:�R�j�o��1,R�c�*�2�.��
Mz�TL��B9c��o�s�|�-�nZ�/�
v�}B�{[e�e��CgV7�������Hy�R��T�E��
�&��x��_�6�"UmkP*Bxf���f�����P}g
?8���0*����DC��������{j�����4���7��\J����XE�.-�~�V��-���7���"��iD�����m�sb��>t�5�qmy��(�8o�?�YK?kO�b�Em�6���}OFr�T�0���l��<����3Mqf>Q�}
UbjZ����E
�x<u�dc���e���]R���X\XG������5P�����O�D�B�[C�/7k(,y���Z��\D��:^�5K�&6��p���3�����~m�8?�a!��v0�eI�|I���a���'_j�I.���0�kl�v�w8��r�X�������Z���I�U�aU��.t�pe6�yB�i�����s���Q��
<n92�U�$Xi�)K�H����j��2�G���m���*O2�f7����������&��#�����{3����j1���% y�4�t4�����������>����}�
z
���f����������B�y�1�`�k`X�
�0�Tk,
�����`�B��s?(�nIQIy#N*`^`D`� x��3����C0"������D%\�
f�{��~aK\m������</���{9��X��|<�}_jAx�W�'7��3�(�A�u��YX�i����A
��������$,7���s�Sy4�6���1
�����;-,?�gS�)�)��������u�I�O0�
�^b��l�9�M��x�E9�<)k5������q�%`X��n�����b��*n7zD�'Ex
�9���`�;�6e�z`�c�����^�!i��Dvc�?��PH���C
!�����!������}J����������p�0�0z�1p-/��JjK������'���{K��e#�\>�K�f���c�4�)j>5��<�,0x���kt��A��m-.x�1��S�B�w.�iK4x��������*�6�����/Y3�7"���9}��{:��W5�>��NE��l�[r��8�q��l���%\
(�d���o�h��"�[���j[p"j���\\��x�}<��.�":GOm�fE
3 years, 4 months
Security Notice. Someone have access to your system.
by linux-nvdimm＠lists.01.org
Hi!
As you may have noticed, I sent you an email from your account.
This means that I have full access to your account.
I've been watching you for a few months now.
The fact is that you were infected with malware through an adult site that you visited.
If you are not familiar with this, I will explain.
Trojan Virus gives me full access and control over a computer or other device.
This means that I can see everything on your screen, turn on the camera and microphone, but you do not know about it.
I also have access to all your contacts and all your correspondence.
Why your antivirus did not detect malware?
Answer: My malware uses the driver, I update its signatures every 4 hours so that your antivirus is silent.
I made a video showing how you satisfy yourself in the left half of the screen, and in the right half you see the video that you watched.
With one click of the mouse, I can send this video to all your emails and contacts on social networks.
I can also post access to all your e-mail correspondence and messengers that you use.
If you want to prevent this,
transfer the amount of $705 to my bitcoin address (if you do not know how to do this, write to Google: "Buy Bitcoin").
My bitcoin address (BTC Wallet) is: 1GoWy5yMzh3XXBiYxLU9tKCBMgibpznGio
After receiving the payment, I will delete the video and you will never hear me again.
I give you 48 hours to pay.
I have a notice reading this letter, and the timer will work when you see this letter.
Filing a complaint somewhere does not make sense because this email cannot be tracked like my bitcoin address.
I do not make any mistakes.
If I find that you have shared this message with someone else, the video will be immediately distributed.
Best regards!
3 years, 4 months
[PATCH -next] acpi/nfit, device-dax: Fix platform_no_drv_owner.cocci warnings
by YueHaibing
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: YueHaibing <yuehaibing(a)huawei.com>
---
drivers/nvdimm/of_pmem.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/nvdimm/of_pmem.c b/drivers/nvdimm/of_pmem.c
index ecaaa27438e2..a0c8dcfa0bf9 100644
--- a/drivers/nvdimm/of_pmem.c
+++ b/drivers/nvdimm/of_pmem.c
@@ -109,7 +109,6 @@ static struct platform_driver of_pmem_region_driver = {
.remove = of_pmem_region_remove,
.driver = {
.name = "of_pmem",
- .owner = THIS_MODULE,
.of_match_table = of_pmem_region_match,
},
};
3 years, 4 months
[PATCH] nvdimm, btt: fix LBA masking during 'free list' population
by Vishal Verma
The Linux BTT implementation assumes that log entries will never have
the 'zero' flag set, and indeed it never sets that flag for log entries
itself.
However, the UEFI spec is ambiguous on the exact format of the LBA field
of a log entry, specifically as to whether it should include the
additional flag bits or not. While a zero bit doesn't make sense in the
context of a log entry, other BTT implementations might still have it set.
If an implementation does happen to have it set, we would happily read
it in as the next block to write to for writes. Since a high bit is set,
it pushes the block number out of the range of an 'arena', and we fail
such a write with an EIO.
Follow the robustness principle, and tolerate such implementations by
stripping out the zero flag when populating the free list during
initialization.
Cc: Dan Williams <dan.j.williams(a)intel.com>
Reported-by: Dexuan Cui <decui(a)microsoft.com>
Reported-by: Pedro d'Aquino Filocre F S Barbuda <pbarbuda(a)microsoft.com>
Tested-by: Dexuan Cui <decui(a)microsoft.com>
Signed-off-by: Vishal Verma <vishal.l.verma(a)intel.com>
---
drivers/nvdimm/btt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c
index b123b0dcf274..1c5447ac1e39 100644
--- a/drivers/nvdimm/btt.c
+++ b/drivers/nvdimm/btt.c
@@ -562,13 +562,15 @@ static int btt_freelist_init(struct arena_info *arena)
/* sub points to the next one to be overwritten */
arena->freelist[i].sub = 1 - new;
arena->freelist[i].seq = nd_inc_seq(le32_to_cpu(log_new.seq));
- arena->freelist[i].block = le32_to_cpu(log_new.old_map);
+ arena->freelist[i].block =
+ le32_to_cpu(ent_lba(log_new.old_map));
/*
* FIXME: if error clearing fails during init, we want to make
* the BTT read-only
*/
if (ent_e_flag(log_new.old_map)) {
+ set_e_flag(arena->freelist[i].block);
ret = arena_clear_freelist_error(arena, i);
if (ret)
dev_err_ratelimited(to_dev(arena),
--
2.20.1
3 years, 4 months
