On Tue, Dec 6, 2016 at 4:39 PM, Dan Williams wrote:
> Given dimms and bus commands share the same command number space we need
> to be careful that we are translating status in the correct context.
> Otherwise we can, for example, fail an ND_CMD_GET_CONFIG_SIZE command
> because max_xfer is zero.
Hugh notes:
"I think that is more restrictive than you intended: haven't tried, but
I believe it rejects a PROT_READ, MAP_SHARED, O_RDONLY fd mmap, leaving
no way to mmap /dev/dax without write permission to it."
Reported-by: Hugh Dickins
Signed-off-by: Dan Williams
---
test/device-dax.c | 26
Hugh notes in response to commit 4cb19355ea19 "device-dax: fail all
private mapping attempts":
"I think that is more restrictive than you intended: haven't tried, but I
believe it rejects a PROT_READ, MAP_SHARED, O_RDONLY fd mmap, leaving no
way to mmap /dev/dax without write permission to i
On Mon, Dec 5, 2016 at 5:01 PM, Hugh Dickins wrote:
> On Wed, 16 Nov 2016, Dan Williams wrote:
>
>> The device-dax implementation originally tried to be tricky and allow
>> private read-only mappings, but in the process allowed writable
>> MAP_PRIVATE + MAP_NORESERVE mappings. For simplicity and
Given dimms and bus commands share the same command number space we need
to be careful that we are translating status in the correct context.
Otherwise we can, for example, fail an ND_CMD_GET_CONFIG_SIZE command
because max_xfer is zero. It fails because that condition erroneously
correlates with t
A recent flurry of bug discoveries in the nfit driver's DSM marshalling
routine has highlighted the fact that we do not have unit test coverage
for this routine. Add a self-test of acpi_nfit_ctl() routine before
probing the "nfit_test.0" device. This mocks stimulus to acpi_nfit_ctl()
and if any of
If an ARS Status command returns truncated output, do not process
partial records or otherwise consume non-status fields.
Cc:
Fixes: 0caeef63e6d2 ("libnvdimm: Add a poison list and export badblocks")
Signed-off-by: Dan Williams
---
drivers/acpi/nfit/core.c | 21 +
1 file c
From: Vishal Verma
ACPI DSMs can have an 'extended' status which can be non-zero to convey
additional information about the command. In the xlat_status routine,
where we translate the command statuses, we were returning an error for
a non-zero extended status, even if the primary status indicated
>From [PATCH 5/5] tools/testing/nvdimm: unit test acpi_nfit_ctl():
---
A recent flurry of bug discoveries in the nfit driver's DSM marshalling
routine has highlighted the fact that we do not have unit test coverage
for this routine. Add a self-test of acpi_nfit_ctl() routine before
probing the "nf
Given ambiguities in the ACPI 6.1 definition of the "Output (Size)"
field of the ARS (Address Range Scrub) Status command, a firmware
implementation may in practice return 0, 4, or 8 to indicate that there
is no output payload to process.
The specification states "Size of Output Buffer in bytes, i
On Tue, Dec 6, 2016 at 1:47 PM, Logan Gunthorpe wrote:
> Hey,
>
>> Okay, so clearly this needs a kernel side NVMe specific allocator
>> and locking so users don't step on each other..
>
> Yup, ideally. That's why device dax isn't ideal for this application: it
> doesn't provide any way to prevent
Hey,
> Okay, so clearly this needs a kernel side NVMe specific allocator
> and locking so users don't step on each other..
Yup, ideally. That's why device dax isn't ideal for this application: it
doesn't provide any way to prevent users from stepping on each other.
> Or as Christoph says some ki
On Tue, Dec 06, 2016 at 09:51:15AM -0700, Logan Gunthorpe wrote:
> Hey,
>
> On 06/12/16 09:38 AM, Jason Gunthorpe wrote:
> >>> I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial
> >>> to accomplish in sysfs through /sys/dev/char to find the sysfs path of the
> >>> device-dax in
On Tue, Dec 06, 2016 at 09:38:50AM -0700, Jason Gunthorpe wrote:
> > > I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial
> > > to accomplish in sysfs through /sys/dev/char to find the sysfs path of the
> > > device-dax instance under the nvme device, or if you already have the
Hey,
On 06/12/16 09:38 AM, Jason Gunthorpe wrote:
>>> I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial
>>> to accomplish in sysfs through /sys/dev/char to find the sysfs path of the
>>> device-dax instance under the nvme device, or if you already have the nvme
>>> sysfs path
> > I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial
> > to accomplish in sysfs through /sys/dev/char to find the sysfs path of the
> > device-dax instance under the nvme device, or if you already have the nvme
> > sysfs path the dax instance(s) will appear under the "dax" sub
>>> I've already recommended that iopmem not be a block device and
>>> instead be a device-dax instance. I also don't think it should claim
>>> the PCI ID, rather the driver that wants to map one of its bars this
>>> way can register the memory region with the device-dax core.
>>>
>>> I'm not sure
17 matches
Mail list logo
