Dan Williams writes:
>> But I agree with your concern that if we have older kernel/applications
>> that continue to use `dcbf` on future hardware we will end up
>> having issues w.r.t powerfail consistency. The plan is what you outlined
>> above as tighter ecosystem control. Considering we don't
;
> }
> @@ -81,6 +82,7 @@ static int of_pmem_region_remove(struct platform_device
> *pdev)
> struct of_pmem_private *priv = platform_get_drvdata(pdev);
>
> nvdimm_bus_unregister(priv->bus);
> + kfree(priv->bus_desc.provider_name);
> kfree(priv);
>
> return 0;
Reviewed-by: Jeff Moyer
nlock;
>
> + if (cmd_rc < 0) {
> + rc = cmd_rc;
> + goto out_unlock;
> + }
> +
> if (!nvdimm && cmd == ND_CMD_CLEAR_ERROR && cmd_rc >= 0) {
> struct nd_cmd_clear_error *clear_err = buf;
Looks good to me.
Reviewed-by: Jeff Moyer
Dan Williams writes:
> ---
>
> Explicit review requests, but any other feedback is of course
> appreciated:
>
> Patch1 needs an ack from ppc arch maintainers, and I'd like a tested-by
> from Aneesh that this still works to solve the ppc issue. Jeff, does
> this look good to you?
OK, I've reviewe
Dan Williams writes:
> On Thu, Feb 13, 2020 at 8:58 AM Jeff Moyer wrote:
>> I have just a couple of questions.
>>
>> First, can you please add a comment above the generic implementation of
>> memremap_compat_align describing its purpose, and why a platform m
ents to current align
> - namespace/size: trim free space to current align
>
> ...to keep the free space accounting conforming to the dynamic align
> setting.
>
> Reported-by: Aneesh Kumar K.V
> Reported-by: Jeff Moyer
> Signed-off-by: Dan Williams
> Reviewed-by: Aneesh Kum
Dan Williams writes:
> On Thu, Feb 13, 2020 at 1:55 PM Jeff Moyer wrote:
>>
>> Dan Williams writes:
>>
>> > The pmem driver on PowerPC crashes with the following signature when
>> > instantiating misaligned namespaces that map their capacity via
>>
> pmem_attach_disk+0x188/0x770
> nvdimm_bus_probe+0xd8/0x470
>
> With the assumption that only memremap_pages() has alignment
> constraints, enforce memremap_compat_align() for
> pmem_should_map_pages(), nd_pfn, or nd_dax cases.
>
> Reported-by: Aneesh Kumar K.V
> Cc
that. What's the relationship, there, and can
we please have a comment explaining it?
Thanks!
Jeff
>
> Link:
> http://lore.kernel.org/r/capcyv4gbgnp95apyabcsocea50tqj9b5h__83vgngjq3oug...@mail.gmail.com
> Reported-by: Aneesh Kumar K.V
> Reported-by: Jeff Moyer
> Cc: Benjamin Herre
> pmem_attach_disk+0x188/0x770
> nvdimm_bus_probe+0xd8/0x470
>
> With the assumption that only memremap_pages() has alignment
> constraints, enforce memremap_compat_align() for
> pmem_should_map_pages(), nd_pfn, or nd_dax cases.
>
> Reported-by: Aneesh Kumar K.V
> Cc
it(NDD_ALIASING, &nvdimm->flags) ? "alias " : "",
> + test_bit(NDD_LABELING, &nvdimm->flags) ? "label" : "",
^
Missing a space.
The rest looks sane.
Reviewed-by: Jeff Moyer
Nicholas Piggin writes:
> On Thu, 5 Apr 2018 15:53:07 +1000
> Balbir Singh wrote:
>> I'm thinking about it, I wonder what "bytes remaining" mean in pmem context
>> in the context of a machine check exception. Also, do we want to be byte
>> accurate or cache-line accurate for the bytes remaining?
:
don't read inode->i_blkbits multiple times") for the reasoning, and
commit b87570f5d3496 ("Fix a crash when block device is read and block
size is changed at the same time") for a more detailed problem
description and reproducer.
Fixes: 20ce44d545844
Signed-off-by: Jeff Moye
Chandan Rajendra writes:
> The code currently uses sdio->blkbits to compute the number of blocks to
> be cleaned. However sdio->blkbits is derived from the logical block size
> of the underlying block device (Refer to the definition of
> do_blockdev_direct_IO()). Due to this, generic/299 test wou
Raghavendra K T writes:
> In nr_hw_queues >1 cases when certain number of cpus are onlined/or
> offlined, that results change in request_queue map in block-mq layer,
> we see the kernel dumping like:
What version is that patch against? This problem should be fixed by the
patch set from Akinobu
15 matches
Mail list logo
