On Mon, Oct 1, 2018 at 8:38 PM Vishal Verma wrote:
>
> When ndctl list --media-errors is invoked, we rely upon the 'region'
> badblocks provided by the kernel, and reference them against the
> namespace start to report namespace badblocks. This can fail for
> non-root users, as the region and
On Mon, Oct 1, 2018 at 8:38 PM Vishal Verma wrote:
>
> We don't need to check for the above flag for each badblock we're
> iterating over. Remove the check in the respective loops, and return
> early if it is not set.
>
> Cc: Dan Williams
> Signed-off-by: Vishal Verma
> ---
> util/json.c | 12
On Mon, Oct 1, 2018 at 8:38 PM Vishal Verma wrote:
>
> The return type of ndctl_region_get_resource() is 'unsigned long long',
> and therefore the error checking for it should be done against
> ULLONG_MAX. Fix an instance where we were checking against ULONG_MAX.
>
Reviewed-by: Dan Williams
On Thu, 2018-09-27 at 17:41 -0700, Dan Williams wrote:
> Changes since v2 [1]:
> * Drop the 'dirty-dimm' command
> * Add ndctl_dimm_get_dirty_shutdown() api
>
> [1]: https://lists.01.org/pipermail/linux-nvdimm/2018-September/017890.html
>
> ---
>
> The latch mechanism is awkward especially
On 10/2/2018 11:41 AM, Tejun Heo wrote:
Hello,
On Tue, Oct 02, 2018 at 11:23:26AM -0700, Alexander Duyck wrote:
Yeah, it's all in wq_select_unbound_cpu(). Right now, if the
requested cpu isn't in wq_unbound_cpumask, it falls back to dumb
round-robin. We can probably do better there and find
On Tue, Oct 2, 2018 at 8:32 AM Jan Kara wrote:
>
> On Tue 02-10-18 07:52:06, Christoph Hellwig wrote:
> > On Tue, Oct 02, 2018 at 04:44:13PM +0200, Johannes Thumshirn wrote:
> > > On Tue, Oct 02, 2018 at 07:37:13AM -0700, Christoph Hellwig wrote:
> > > > No, it should not. DAX is an
Hello,
On Tue, Oct 02, 2018 at 11:23:26AM -0700, Alexander Duyck wrote:
> >Yeah, it's all in wq_select_unbound_cpu(). Right now, if the
> >requested cpu isn't in wq_unbound_cpumask, it falls back to dumb
> >round-robin. We can probably do better there and find the nearest
> >node considering
On 10/2/2018 10:41 AM, Tejun Heo wrote:
Hello,
On Mon, Oct 01, 2018 at 02:54:39PM -0700, Alexander Duyck wrote:
It might be better to leave queue_work_on() to be used for per-cpu
workqueues and introduce queue_work_near() as you suggseted. I just
don't want it to duplicate the node selection
Hello,
On Mon, Oct 01, 2018 at 02:54:39PM -0700, Alexander Duyck wrote:
> >It might be better to leave queue_work_on() to be used for per-cpu
> >workqueues and introduce queue_work_near() as you suggseted. I just
> >don't want it to duplicate the node selection code in it. Would that
> >work?
>
On 10/1/2018 3:02 PM, Dan Williams wrote:
On Mon, Oct 1, 2018 at 2:54 PM Alexander Duyck
wrote:
On 10/1/2018 2:14 PM, Dan Williams wrote:
Use kvzalloc() to bypass the arbitrary PAGE_SIZE limit of label transfer
operations. Given the expense of calling into firmware, maximize the
amount
On Tue 02-10-18 07:52:06, Christoph Hellwig wrote:
> On Tue, Oct 02, 2018 at 04:44:13PM +0200, Johannes Thumshirn wrote:
> > On Tue, Oct 02, 2018 at 07:37:13AM -0700, Christoph Hellwig wrote:
> > > No, it should not. DAX is an implementation detail thay may change
> > > or go away at any time.
>
On Tue 02-10-18 07:37:13, Christoph Hellwig wrote:
> On Tue, Oct 02, 2018 at 04:29:59PM +0200, Jan Kara wrote:
> > > OK naive question from me, how do we want an application to be able to
> > > check if it is running on a DAX mapping?
> >
> > The question from me is: Should application really
On Tue, Oct 02, 2018 at 05:01:24PM +0200, Johannes Thumshirn wrote:
> On Tue, Oct 02, 2018 at 07:45:47AM -0700, Christoph Hellwig wrote:
> > How does an application "make use of DAX"? What actual user visible
> > semantics are associated with a file that has this flag set?
>
> There may not be
On Tue, Oct 02, 2018 at 04:44:13PM +0200, Johannes Thumshirn wrote:
> On Tue, Oct 02, 2018 at 07:37:13AM -0700, Christoph Hellwig wrote:
> > No, it should not. DAX is an implementation detail thay may change
> > or go away at any time.
>
> Well we had an issue with an application checking for
On Tue, Oct 02, 2018 at 04:20:10PM +0200, Johannes Thumshirn wrote:
> Provide a F_GETDAX fcntl(2) command so an application can query
> whether it can make use of DAX or not.
How does an application "make use of DAX"? What actual user visible
semantics are associated with a file that has
On Tue, Oct 02, 2018 at 07:37:13AM -0700, Christoph Hellwig wrote:
> No, it should not. DAX is an implementation detail thay may change
> or go away at any time.
Well we had an issue with an application checking for dax, this is how
we landed here in the first place.
It's not that I want them
On Tue, Oct 02, 2018 at 04:29:59PM +0200, Jan Kara wrote:
> > OK naive question from me, how do we want an application to be able to
> > check if it is running on a DAX mapping?
>
> The question from me is: Should application really care?
No, it should not. DAX is an implementation detail thay
[Added ext4, xfs, and linux-api folks to CC for the interface discussion]
On Tue 02-10-18 14:10:39, Johannes Thumshirn wrote:
> On Tue, Oct 02, 2018 at 12:05:31PM +0200, Jan Kara wrote:
> > Hello,
> >
> > commit e1fb4a086495 "dax: remove VM_MIXEDMAP for fsdax and device dax" has
> > removed
On Tue, Oct 02, 2018 at 02:10:39PM +0200, Johannes Thumshirn wrote:
> On Tue, Oct 02, 2018 at 12:05:31PM +0200, Jan Kara wrote:
> > Hello,
> >
> > commit e1fb4a086495 "dax: remove VM_MIXEDMAP for fsdax and device dax" has
> > removed VM_MIXEDMAP flag from DAX VMAs. Now our testing shows that in
On Tue 02-10-18 12:50:58, Michal Hocko wrote:
> On Tue 02-10-18 12:05:31, Jan Kara wrote:
> > Hello,
> >
> > commit e1fb4a086495 "dax: remove VM_MIXEDMAP for fsdax and device dax" has
> > removed VM_MIXEDMAP flag from DAX VMAs. Now our testing shows that in the
> > mean time certain customer of
On Tue, Oct 02, 2018 at 12:05:31PM +0200, Jan Kara wrote:
> Hello,
>
> commit e1fb4a086495 "dax: remove VM_MIXEDMAP for fsdax and device dax" has
> removed VM_MIXEDMAP flag from DAX VMAs. Now our testing shows that in the
> mean time certain customer of ours started poking into /proc//smaps
> and
On Tue 02-10-18 12:05:31, Jan Kara wrote:
> Hello,
>
> commit e1fb4a086495 "dax: remove VM_MIXEDMAP for fsdax and device dax" has
> removed VM_MIXEDMAP flag from DAX VMAs. Now our testing shows that in the
> mean time certain customer of ours started poking into /proc//smaps
> and looks at VMA
Hello,
commit e1fb4a086495 "dax: remove VM_MIXEDMAP for fsdax and device dax" has
removed VM_MIXEDMAP flag from DAX VMAs. Now our testing shows that in the
mean time certain customer of ours started poking into /proc//smaps
and looks at VMA flags there and if VM_MIXEDMAP is missing among the VMA
23 matches
Mail list logo
