Hi Eric,
>
> On 07/13/2018 02:52 AM, Pankaj Gupta wrote:
> > This patch adds virtio-pmem Qemu device.
> >
> > This device presents memory address range information to guest
> > which is backed by file backend type. It acts like persistent
> > memory device for KVM guest. Guest can
Hi Andrew,
On 07/19/18 at 12:44pm, Andrew Morton wrote:
> On Thu, 19 Jul 2018 23:17:53 +0800 Baoquan He wrote:
> > > As far as I can tell, the above is the whole reason for the patchset,
> > > yes? To avoid confusing users.
> >
> >
> > In fact, it's not just trying to avoid confusing users.
> -Original Message-
> From: Vishal Verma [mailto:vishal.l.ve...@intel.com]
> Sent: Wednesday, July 25, 2018 9:09 AM
> To: linux-nvdimm@lists.01.org
> Cc: Qi, Fuli/斉 福利 ; Vishal Verma
>
> Subject: [ndctl PATCH] ndctl, monitor: fix a resource leak in
> parse_monitor_event
>
> Static
Static analysis reports we leak dimm_event in the above function.
Fix it by adding an 'out' label for all exit paths, and refactoring out
the 'all events' cases.
Fixes: fdf6b6844ccf ("ndctl, monitor: add a new command - monitor")
Cc: QI Fuli
Signed-off-by: Vishal Verma
---
ndctl/monitor.c | 37
The available_size attribute returns all the unused regions, but a
memory namespace has to use contiguous free regions. This patch uses the
max_available_extent attribute, which reports the largest capacity that
can be created when determining what size to allocate.
If the attribute is available,
On Tue, 2018-07-24 at 15:07 -0600, Keith Busch wrote:
> This patch will find the max contiguous area to determine the largest
> pmem namespace size that can be created. If the requested size exceeds
> the largest available, ENOSPC error will be returned.
>
> This fixes the allocation underrun
On Tue, 2018-07-24 at 15:07 -0600, Keith Busch wrote:
> The 'available_size' attribute showing the combined total of all
> unallocated space isn't always useful to know how large of a
> namespace
> a user may be able to allocate if the region is fragmented. This
> patch
> will export the largest
The 'available_size' attribute showing the combined total of all
unallocated space isn't always useful to know how large of a namespace
a user may be able to allocate if the region is fragmented. This patch
will export the largest extent of unallocated space that may be allocated
to create a new
On Tue, Jul 24, 2018 at 08:40:06AM -0500, Gustavo A. R. Silva wrote:
> ndd is being dereferenced before it is null checked, hence there is a
> potential null pointer dereference.
>
> Fix this by moving the pointer dereference after ndd has been properly
> null checked at line 554: if (!ndd)
I'll
On 07/13/2018 02:52 AM, Pankaj Gupta wrote:
This patch adds virtio-pmem Qemu device.
This device presents memory address range information to guest
which is backed by file backend type. It acts like persistent
memory device for KVM guest. Guest can perform read and persistent
write
On 07/24/2018 12:36 AM, Ingo Molnar wrote:
>
> * Dan Williams wrote:
>
>> In preparation for using set_memory_uc() instead set_memory_np() for
>> isolating poison from speculation, teach the memtype code to sanitize
>> physical addresses vs __PHYSICAL_MASK.
>>
>> The motivation for using
From: Ross Zwisler
Sent: Tuesday, July 24, 2018 10:50 PM
> > Some functions within fs/dax and dax/super don't need to get kaddr from
> > direct_access. Assigning NULL to kaddr to ->direct_access() is more
> > straightforward and simple than offering a useless local pointer.
> >
> > So all
On Tue, Jul 24, 2018 at 04:45:05PM +0800, Huaisheng Ye wrote:
> From: Huaisheng Ye
>
> Some functions within fs/dax and dax/super don't need to get kaddr from
> direct_access. Assigning NULL to kaddr to ->direct_access() is more
> straightforward and simple than offering a useless local pointer.
From: Christian Borntraeger
Sent: Tuesday, July 24, 2018 7:16 PM
> >> So you are trading of a load + add (dev_info->start should be cache hot)
> >> against a
> >> compare+branch . Not sure that this is always a win.
> >
> > Hmm...the calculation process of pfn is more complicated than kaddr. I
ndd is being dereferenced before it is null checked, hence there is a
potential null pointer dereference.
Fix this by moving the pointer dereference after ndd has been properly
null checked at line 554: if (!ndd)
Addresses-Coverity-ID: 1472020 ("Dereference before null check")
Fixes:
On 07/24/2018 11:46 AM, Huaisheng HS1 Ye wrote:
> From: Christian Borntraeger
> Sent: Tuesday, July 24, 2018 4:54 PM
>> On 07/24/2018 10:45 AM, Huaisheng Ye wrote:
>>> From: Huaisheng Ye
>>>
>>> dcssblk_direct_access() needs to check the validity of second rank
>>> pointer kaddr for NULL
From: Christian Borntraeger
Sent: Tuesday, July 24, 2018 4:54 PM
> On 07/24/2018 10:45 AM, Huaisheng Ye wrote:
> > From: Huaisheng Ye
> >
> > dcssblk_direct_access() needs to check the validity of second rank
> > pointer kaddr for NULL assignment. If kaddr equals to NULL, it
> > doesn't need to
On 07/24/2018 10:45 AM, Huaisheng Ye wrote:
> From: Huaisheng Ye
>
> dcssblk_direct_access() needs to check the validity of second rank
> pointer kaddr for NULL assignment. If kaddr equals to NULL, it
> doesn't need to calculate the value.
>
> Signed-off-by: Huaisheng Ye
> ---
>
From: Huaisheng Ye
Some functions within driver/dax don't need to get pointer kaddr from
direct_access. In support of allowing memmap initialization to run in
the background elide requests for pointer kaddr when not required.
Signed-off-by: Huaisheng Ye
---
drivers/dax/super.c | 3 +--
1 file
From: Huaisheng Ye
Some functions within fs/dax don't need to get pointer kaddr from
direct_access. In support of allowing memmap initialization to run
in the background elide requests for pointer kaddr when not required.
Signed-off-by: Huaisheng Ye
---
fs/dax.c | 3 +--
1 file changed, 1
From: Huaisheng Ye
Some functions within fs/dax and dax/super don't need to get kaddr from
direct_access. Assigning NULL to kaddr to ->direct_access() is more
straightforward and simple than offering a useless local pointer.
So all direct_access() need to check the validity of second rank
From: Huaisheng Ye
dcssblk_direct_access() needs to check the validity of second rank
pointer kaddr for NULL assignment. If kaddr equals to NULL, it
doesn't need to calculate the value.
Signed-off-by: Huaisheng Ye
---
drivers/s390/block/dcssblk.c | 3 ++-
1 file changed, 2 insertions(+), 1
From: Huaisheng Ye
The mock / test version of pmem_direct_access() needs to check the
validity of second rank pointer kaddr for NULL assignment. If kaddr
equals to NULL, it doesn't need to calculate the value.
Signed-off-by: Huaisheng Ye
---
tools/testing/nvdimm/pmem-dax.c | 6 --
1 file
From: Huaisheng Ye
pmem_direct_access() needs to check the validity of second rank
pointer kaddr for NULL assignment. If kaddr equals to NULL, it
doesn't need to calculate the value.
Signed-off-by: Huaisheng Ye
---
drivers/nvdimm/pmem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
* Dave Jiang wrote:
> Ingo,
> Is it possible to ack the x86 bits in this patch series? I'm hoping to
> get this pulled through the libnvdimm tree for 4.19. Thanks!
With the minor typo fixed in the first patch, both patches are looking good to
me:
Acked-by: Ingo Molnar
Assuming that it
* Dan Williams wrote:
> In preparation for using set_memory_uc() instead set_memory_np() for
> isolating poison from speculation, teach the memtype code to sanitize
> physical addresses vs __PHYSICAL_MASK.
>
> The motivation for using set_memory_uc() for this case is to allow
> ongoing access
On Mon 23-07-18 09:15:32, Dave Hansen wrote:
> On 07/23/2018 04:09 AM, Michal Hocko wrote:
> > On Thu 19-07-18 11:41:10, Dave Hansen wrote:
> >> Are you looking for the actual end-user reports? This was more of a
> >> case of the customer plugging in some persistent memory DIMMs, noticing
> >>
27 matches
Mail list logo
