On Mon, May 14, 2018 at 11:49 PM, Ingo Molnar <mingo@xxxxxxxxxx> wrote: > > * Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > >> On Mon, May 14, 2018 at 12:26 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote: >> > >> > * Dan Williams <dan.j.williams@xxxxxxxxx> 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 the >> > 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. > Thanks, > > Ingo Thanks!
