On Mon, Aug 19, 2019 at 7:26 PM Christoph Hellwig wrote:
>
> On Mon, Aug 19, 2019 at 06:28:30PM -0700, Dan Williams wrote:
> >
> > Previously we would loudly crash if someone passed NULL to
> > devm_request_free_mem_region(), but now it will silently work and the
> > result will leak. Perhaps
On Mon, Aug 19, 2019 at 08:09:33PM -0700, John Hubbard wrote:
> On 8/19/19 6:20 PM, Dave Chinner wrote:
> > On Mon, Aug 19, 2019 at 05:05:53PM -0700, John Hubbard wrote:
> > > On 8/19/19 2:24 AM, Dave Chinner wrote:
> > > > On Mon, Aug 19, 2019 at 08:34:12AM +0200, Jan Kara wrote:
> > > > > On Sat
On 8/19/19 6:20 PM, Dave Chinner wrote:
On Mon, Aug 19, 2019 at 05:05:53PM -0700, John Hubbard wrote:
On 8/19/19 2:24 AM, Dave Chinner wrote:
On Mon, Aug 19, 2019 at 08:34:12AM +0200, Jan Kara wrote:
On Sat 17-08-19 12:26:03, Dave Chinner wrote:
On Fri, Aug 16, 2019 at 12:05:28PM -0700, Ira
On Mon, Aug 19, 2019 at 06:28:30PM -0700, Dan Williams wrote:
>
> Previously we would loudly crash if someone passed NULL to
> devm_request_free_mem_region(), but now it will silently work and the
> result will leak. Perhaps this wants a:
We'd still instantly crash due to the dev_name
On Sun, Aug 18, 2019 at 2:12 AM Christoph Hellwig wrote:
>
> The kvmppc ultravisor code wants a device private memory pool that is
> system wide and not attached to a device. Instead of faking up one
> provide a low-level memremap_pages for it.
>
> Signed-off-by: Christoph Hellwig
>
On Sun, Aug 18, 2019 at 2:12 AM Christoph Hellwig wrote:
>
> Just clean up for early failures and then piggy back on
> devm_memremap_pages_release. This helps with a pending not device
> managed version of devm_memremap_pages.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Ira Weiny
On Mon, Aug 19, 2019 at 05:05:53PM -0700, John Hubbard wrote:
> On 8/19/19 2:24 AM, Dave Chinner wrote:
> > On Mon, Aug 19, 2019 at 08:34:12AM +0200, Jan Kara wrote:
> > > On Sat 17-08-19 12:26:03, Dave Chinner wrote:
> > > > On Fri, Aug 16, 2019 at 12:05:28PM -0700, Ira Weiny wrote:
> > > > > On
On Mon, Aug 19, 2019 at 09:38:41AM -0300, Jason Gunthorpe wrote:
> On Mon, Aug 19, 2019 at 07:24:09PM +1000, Dave Chinner wrote:
>
> > So that leaves just the normal close() syscall exit case, where the
> > application has full control of the order in which resources are
> > released. We've
On 8/19/19 2:24 AM, Dave Chinner wrote:
On Mon, Aug 19, 2019 at 08:34:12AM +0200, Jan Kara wrote:
On Sat 17-08-19 12:26:03, Dave Chinner wrote:
On Fri, Aug 16, 2019 at 12:05:28PM -0700, Ira Weiny wrote:
On Thu, Aug 15, 2019 at 03:05:58PM +0200, Jan Kara wrote:
On Wed 14-08-19 11:08:49, Ira
On Mon, Aug 19, 2019 at 09:38:41AM -0300, Jason Gunthorpe wrote:
> On Mon, Aug 19, 2019 at 07:24:09PM +1000, Dave Chinner wrote:
>
> > So that leaves just the normal close() syscall exit case, where the
> > application has full control of the order in which resources are
> > released. We've
On Mon, Aug 19, 2019 at 1:26 PM Verma, Vishal L
wrote:
>
> On Wed, 2019-08-14 at 18:23 -0700, Dan Williams wrote:
> > Given the discovery that the original libnvdimm-security implementation
> > is unable to communicate both the 'freeze' status and the 'lock' status
> > simultaneously, newer
On Wed, 2019-08-14 at 18:23 -0700, Dan Williams wrote:
> Given the discovery that the original libnvdimm-security implementation
> is unable to communicate both the 'freeze' status and the 'lock' status
> simultaneously, newer kernels deploy a new 'frozen' attribute for this
> purpose.
>
> Add a
Message-ID: 5208272350913
From: =?sm4lk??=
To:
发送时间:2019-8-20 3:23:04
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
转发邮件信息
发件人：jin...@dn.org
发送日期：2019-8-20 2:32:18
收件人：linux-nvdimm@lists.01.org
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
On Mon, Aug 19, 2019 at 12:07 AM Aneesh Kumar K.V
wrote:
>
> Dan Williams writes:
>
> > On Tue, Aug 13, 2019 at 9:22 PM Dan Williams
> > wrote:
> >>
> >> Hi Aneesh, logic looks correct but there are some cleanups I'd like to
> >> see and a lead-in patch that I attached.
> >>
> >> I've started
Dan Williams writes:
> On Fri, Aug 16, 2019 at 1:49 PM Jeff Moyer wrote:
>>
>> Dan Williams writes:
>>
>> > The blanket blocking of all security operations while the DIMM is in
>> > active use in a region is too restrictive. The only security operations
>> > that need to be aware of the ->busy
Namespaces created with PFN_MODE_PMEM mode stores struct page in the reserve
block area. We need to make sure we account for the right struct page
size while doing this. Instead of directly depending on sizeof(struct page)
which can change based on different kernel config option, use the max
This is needed so that pmem probe 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 | 25 -
2
From: Dan Williams
The nd_region_probe_success() helper collides seed management with
nvdimm->busy tracking. Given the 'busy' increment is handled internal to the
nd_region driver 'probe' path move the decrement to the 'remove' path.
With that cleanup the routine can be renamed to the more
In order to support marking namespaces with unsupported feature/versions
disabled, nvdimm core should advance the namespace seed on these
probe failures. Otherwise, these failed namespaces will be considered a
seed namespace and will be wrongly used while creating new namespaces.
Add -EOPNOTSUPP
We add new members to pfn superblock (PAGE_SIZE and struct page size) in this
series.
This is now checked while initializing the namespace. If we find a mismatch we
mark
the namespace disabled.
This series also handle configs where hugepage support is not enabled by
default.
This can result in
Aneesh Kumar K.V writes:
> Dan Williams writes:
>
>> On Fri, Aug 9, 2019 at 12:45 AM Aneesh Kumar K.V
>> wrote:
>>>
>>
...
>>> diff --git a/drivers/nvdimm/pfn_devs.c b/drivers/nvdimm/pfn_devs.c
>>> index 37e96811c2fc..c1d9be609322 100644
>>> --- a/drivers/nvdimm/pfn_devs.c
>>> +++
On Mon, Aug 19, 2019 at 08:34:12AM +0200, Jan Kara wrote:
> On Sat 17-08-19 12:26:03, Dave Chinner wrote:
> > On Fri, Aug 16, 2019 at 12:05:28PM -0700, Ira Weiny wrote:
> > > On Thu, Aug 15, 2019 at 03:05:58PM +0200, Jan Kara wrote:
> > > > On Wed 14-08-19 11:08:49, Ira Weiny wrote:
> > > > > On
Dan Williams writes:
> On Tue, Aug 13, 2019 at 9:22 PM Dan Williams wrote:
>>
>> Hi Aneesh, logic looks correct but there are some cleanups I'd like to
>> see and a lead-in patch that I attached.
>>
>> I've started prefixing nvdimm patches with:
>>
>> libnvdimm/$component:
>>
>> ...since
On Fri 16-08-19 16:20:07, Ira Weiny wrote:
> On Fri, Aug 16, 2019 at 12:05:28PM -0700, 'Ira Weiny' wrote:
> > On Thu, Aug 15, 2019 at 03:05:58PM +0200, Jan Kara wrote:
> > > On Wed 14-08-19 11:08:49, Ira Weiny wrote:
> > > > On Wed, Aug 14, 2019 at 12:17:14PM +0200, Jan Kara wrote:
> > > > >
On Sat 17-08-19 12:26:03, Dave Chinner wrote:
> On Fri, Aug 16, 2019 at 12:05:28PM -0700, Ira Weiny wrote:
> > On Thu, Aug 15, 2019 at 03:05:58PM +0200, Jan Kara wrote:
> > > On Wed 14-08-19 11:08:49, Ira Weiny wrote:
> > > > On Wed, Aug 14, 2019 at 12:17:14PM +0200, Jan Kara wrote:
> > 2) Second
On Mon, Aug 19, 2019 at 10:57:52AM +0530, Bharata B Rao wrote:
> On Sun, Aug 18, 2019 at 11:05:53AM +0200, Christoph Hellwig wrote:
> > Hi Dan and Jason,
> >
> > Bharata has been working on secure page management for kvmppc guests,
> > and one I thing I noticed is that he had to fake up a struct
Thanks Jeff
This patch works on my side.
# ndctl create-namespace -r region0 -m devdax -a 1g -s 12G
{
"dev":"namespace0.3",
"mode":"devdax",
"map":"dev",
"size":"11.00 GiB (11.81 GB)",
"uuid":"84645a0a-ae21-4608-8512-1248cc48b085",
"daxregion":{
"id":0,
"size":"11.00 GiB
28 matches
Mail list logo
