On Mon, May 14, 2018 at 11:49 PM, Ingo Molnar <mingo(a)kernel.org> wrote:
* Dan Williams <dan.j.williams(a)intel.com> wrote:
> On Mon, May 14, 2018 at 12:26 AM, Ingo Molnar <mingo(a)kernel.org> wrote:
> > * Dan Williams <dan.j.williams(a)intel.com> wrote:
> >> Ingo, Thomas, Al, any concerns with this series?
> > Yeah, so:
> > "[PATCH v3 0/9] Series short description"
> > ... isn't the catchiest of titles to capture my [all too easily distracted]
> > attention! ;-)
> My bad! After that mistake it became a toss-up between more spam and
> hoping the distraction would not throw you off.
> > I have marked it now for -tip processing. Linus was happy with this and acked
> > approach, right?
> I think "happy" is a strong word when it comes to x86 machine check
> handling. My interpretation is that he and Andy acquiesced that this
> is about the best we can do with dax+mce as things stand today.
So, how would you like to go about this series?
To help move it forward I applied the first 5 commits to tip:x86/dax, on a
vanilla v4.17-rc5 base, did some minor edits to the changelogs, tested it
superficially (I don't have DAX so this essentially means build tests) and
pushed out the result.
Thanks for that. Technically speaking, you do have dax, but setting up
our unit tests is currently not friction free, so I would not expect
you to go through that effort. Hopefully we can revive 0day running
our unit tests one of these days.
Barring some later generic-x86 regression (unlikely) this looks good
to me - feel
free to cross-pull that branch into your DAX/nvdimm tree.
Or we could apply the remaining changes to -tip too - your call.
The remainder patches have developed a conflict with another topic
branch in the nvdimm tree, in particular "dax: introduce a
->copy_to_iter dax operation". I think the best course is for me to
rebase the remaining 4 on top of tip/x86/dax and carry the merge
conflict through the nvdimm tree.