Re: [PATCH] device-dax/kmem: Use struct_size()

On Sat, Oct 17, 2020 at 2:43 PM Andrew Morton wrote: > > mm-commits is writeable-only-by-akpm. Ahh. That's fine, it's only inconvenient for these kinds of "people replied to patches". It's not necessarily just me either - people reply with Ack's etc, and the fact that the list is

Re: [PATCH] device-dax/kmem: Use struct_size()

On Fri, Oct 16, 2020 at 2:10 PM Dan Williams wrote: > > Link: > http://lore.kernel.org/r/CAHk-=wgntlbvad8mntvh+gqyapnwex20pxhu_+frqevvq42...@mail.gmail.com Does that link work for you? Because I can't see it. In fact, I don't see my email at all on lore, even if I see Andrew's email that I

Re: [PATCH v9 0/2] Renovate memcpy_mcsafe with copy_mc_to_{user, kernel}

On Wed, Sep 30, 2020 at 9:24 AM Borislav Petkov wrote: > > Ok, I'll try to queue them but pls respin soonish. That is, if Linus > cuts -rc8 we have plenty of time but he didn't sound 100% on the -rc8 > thing. Oh, it's pretty much 100%. I can't imagine what would make me skip an rc8 at this

Re: libnvdimm fixes 5.9-rc6

On Sun, Sep 20, 2020 at 11:56 AM Dan Williams wrote: > >You will notice that this branch was rebased this > morning and it has not appeared in -next. I decided to cut short the > soak time because the infinite-recursion regression is currently > crashing anyone attempting to test

Re: [PATCH 2/2] xfs: don't update mtime on COW faults

On Sat, Sep 5, 2020 at 9:47 AM Linus Torvalds wrote: > > So your patch is obviously correct, [..] Oh, and I had a xfs pull request in my inbox already, so rather than expect Darrick to do another one just for this and have Jan do one for ext2, I just applied these two di

Re: [PATCH 2/2] xfs: don't update mtime on COW faults

On Sat, Sep 5, 2020 at 5:13 AM Mikulas Patocka wrote: > > When running in a dax mode, if the user maps a page with MAP_PRIVATE and > PROT_WRITE, the xfs filesystem would incorrectly update ctime and mtime > when the user hits a COW fault. So your patch is obviously correct, but at the same time

Re: a crash when running strace from persistent memory

On Fri, Sep 4, 2020 at 1:08 AM Mikulas Patocka wrote: > > I applied these four patches and strace works well. There is no longer any > warning or crash. Ok. I obviously approve of that series whole-heartedly, but I still didn't want to apply it this way (and with this kind of "mid-rc" timing).

Re: a crash when running strace from persistent memory

On Thu, Sep 3, 2020 at 12:24 PM Mikulas Patocka wrote: > > There's a bug when you run strace from dax-based filesystem. > > -- create real or emulated persistent memory device (/dev/pmem0) > mkfs.ext2 /dev/pmem0 > -- mount it > mount -t ext2 -o dax /dev/pmem0 /mnt/test > -- copy the system to it

Re: [GIT PULL] libnvdimm for v5.8-rc2

On Fri, Jun 19, 2020 at 3:07 PM Dan Williams wrote: > > These patches are tied to specific features that were committed to > customers in upcoming distros releases (RHEL and SLES) whose time-lines > are tied to 5.8 kernel release. Ugh. I'd have much preferred to see this during the

Re: [PATCH v2 0/2] Replace and improve "mcsafe" with copy_safe()

On Thu, Apr 30, 2020 at 6:21 PM Dan Williams wrote: > > However now I see that copy_user_generic() works for the wrong reason. > It works because the exception on the source address due to poison > looks no different than a write fault on the user address to the > caller, it's still just a short

Re: [PATCH v2 0/2] Replace and improve "mcsafe" with copy_safe()

On Thu, Apr 30, 2020 at 5:23 PM Andy Lutomirski wrote: > > > But anyway, I don't hate something like "copy_to_user_fallible()" > > conceptually. The naming needs to be fixed, in that "user" can always > > take a fault, so it's the _source_ that can fault, not the "user" > > part. > > I don’t like

Re: [PATCH v2 0/2] Replace and improve "mcsafe" with copy_safe()

On Thu, Apr 30, 2020 at 5:10 PM Linus Torvalds wrote: > > It's a horrible word, btw. The word doesn't actually mean what Andy > means it to mean. "fallible" means "can make mistakes", not "can > fault". Btw, on naming: the name should be about _why_

Re: [PATCH v2 0/2] Replace and improve "mcsafe" with copy_safe()

On Thu, Apr 30, 2020 at 4:52 PM Dan Williams wrote: > > You had me until here. Up to this point I was grokking that Andy's > "_fallible" suggestion does help explain better than "_safe", because > the copy is doing extra safety checks. copy_to_user() and > copy_to_user_fallible() mean *something*

Re: [PATCH v2 0/2] Replace and improve "mcsafe" with copy_safe()

On Thu, Apr 30, 2020 at 12:23 PM Luck, Tony wrote: > > How about > > try_copy_catch(void *dst, void *src, size_t count, int *fault) > > returns number of bytes not-copied (like copy_to_user etc). > > if return is not zero, "fault" tells you what type of fault > cause the early stop (#PF,

Re: [PATCH v2 0/2] Replace and improve "mcsafe" with copy_safe()

On Thu, Apr 30, 2020 at 9:52 AM Andy Lutomirski wrote: > > If I'm going to copy from memory that might be bad but is at least a > valid pointer, I want a function to do this. If I'm going to copy > from memory that might be entirely bogus, that's a different > operation. In other words, if I'm

Re: [PATCH v2 0/2] Replace and improve "mcsafe" with copy_safe()

On Thu, Apr 30, 2020 at 1:41 AM Dan Williams wrote: > > With the above realizations the name "mcsafe" is no longer accurate and > copy_safe() is proposed as its replacement. x86 grows a copy_safe_fast() > implementation as a default implementation that is independent of > detecting the presence

Re: [PATCH] x86/memcpy: Introduce memcpy_mcsafe_fast

On Mon, Apr 20, 2020 at 1:57 PM Luck, Tony wrote: > > > (a) is a trap, not an exception - so the instruction has been done, > > and you don't need to try to emulate it or anything to continue. > > Maybe for errors on the data side of the pipeline. On the instruction > side we can usually recover

Re: [PATCH] x86/memcpy: Introduce memcpy_mcsafe_fast

On Mon, Apr 20, 2020 at 1:45 PM Luck, Tony wrote: > > Another X86 vendor seems to be adding something like that. See MCOMMIT > in https://www.amd.com/system/files/TechDocs/24594.pdf That sounds potentially very expensive. Particularly, as you say, something like the kernel (or virtualization)

Re: [PATCH] x86/memcpy: Introduce memcpy_mcsafe_fast

On Mon, Apr 20, 2020 at 1:25 PM Dan Williams wrote: > > ...but also some kind of barrier semantic, right? Because there are > systems that want some guarantees when they can commit or otherwise > shoot the machine if they can not. The optimal model would likely be a new instruction that could be

Re: [PATCH] x86/memcpy: Introduce memcpy_mcsafe_fast

On Mon, Apr 20, 2020 at 1:23 PM Luck, Tony wrote: > > I think they do. If the result of the wrong data has already > been sent out the network before you process the signal, then you > will need far smarter application software than has ever been written > to hunt it down and stop the spread of

Re: [PATCH] x86/memcpy: Introduce memcpy_mcsafe_fast

On Mon, Apr 20, 2020 at 12:29 PM Dan Williams wrote: > > I didn't consider asynchronous to be > better because that means there is a gap between when the data > corruption is detected and when it might escape the system that some > external agent could trust the result and start acting on before

Re: [PATCH] x86/memcpy: Introduce memcpy_mcsafe_fast

On Mon, Apr 20, 2020 at 11:20 AM Dan Williams wrote: > > * I'm at a loss of why you seem to be suggesting that hardware should > / could avoid all exceptions. What else could hardware do besides > throw an exception on consumption of a naturally occuring multi-bit > ECC error? Data is gone, and

Re: [PATCH] x86/memcpy: Introduce memcpy_mcsafe_fast

On Sun, Apr 19, 2020 at 10:08 PM Dan Williams wrote: > > Do we have examples of doing exception handling from C? I thought all > the exception handling copy routines were assembly routines? You need assembler for the actual access, but that's a _single_ instruction - best done as inline asm.

Re: [PATCH] x86/memcpy: Introduce memcpy_mcsafe_fast

On Sat, Apr 18, 2020 at 1:30 PM Andy Lutomirski wrote: > > Maybe I’m missing something obvious, but what’s the alternative? The _mcsafe > variants don’t just avoid the REP mess — they also tell the kernel that this > particular access is recoverable via extable. .. which they could easily do

Re: [PATCH] x86/memcpy: Introduce memcpy_mcsafe_fast

On Fri, Apr 17, 2020 at 5:12 PM Dan Williams wrote: > > > @@ -106,12 +108,10 @@ static __always_inline __must_check unsigned long > > memcpy_mcsafe(void *dst, const void *src, size_t cnt) > > { > > #ifdef CONFIG_X86_MCE > > - if (static_branch_unlikely(_key)) > > - return

Re: [PATCH 7/9] drivers/base: fix empty-body warnings in devcoredump.c

On Sat, Apr 18, 2020 at 11:57 AM Joe Perches wrote: > > sysfs_create_link is __must_check The way to handle __must_check if you really really don't want to test and have good reasons is (a) add a big comment about why this case ostensibly doesn't need the check (b) cast a test of it to

Re: [PATCH 2/9] fs: fix empty-body warning in posix_acl.c

On Sat, Apr 18, 2020 at 11:41 AM Randy Dunlap wrote: > > Fix gcc empty-body warning when -Wextra is used: Please don't do this. First off, "do_empty()" adds nothing but confusion. Now it syntactically looks like it does something, and it's a new pattern to everybody. I've never seen it before.

Re: [GIT PULL] libnvdimm for v5.7

On Tue, Apr 7, 2020 at 1:12 PM Dan Williams wrote: > > mm/memremap_pages: Introduce memremap_compat_align() Why is this an exported function that just returns a constant? Why isn't it just a #define (or inline) in a header file? Yes, yes, it would need to be conditional on not having

Re: [PATCH v18 00/19] kunit: introduce KUnit, the Linux kernel unit testing framework

On Sun, Oct 6, 2019 at 9:55 AM Theodore Y. Ts'o wrote: > > Well, one thing we *can* do is if (a) if we can create a kselftest > branch which we know is stable and won't change, and (b) we can get > assurances that Linus *will* accept that branch during the next merge > window, those subsystems

Re: [PATCH v18 00/19] kunit: introduce KUnit, the Linux kernel unit testing framework

On Fri, Oct 4, 2019 at 2:39 PM Theodore Y. Ts'o wrote: > > This question is primarily directed at Shuah and Linus > > What's the current status of the kunit series now that Brendan has > moved it out of the top-level kunit directory as Linus has requested? We seemed to decide to just wait

Re: [GIT PULL] device-dax for 5.1: PMEM as RAM

On Mon, Mar 11, 2019 at 8:37 AM Dan Williams wrote: > > Another feature the userspace tooling can support for the PMEM as RAM > case is the ability to complete an Address Range Scrub of the range > before it is added to the core-mm. I.e at least ensure that previously > encountered poison is

Re: [GIT PULL] device-dax for 5.1: PMEM as RAM

On Sun, Mar 10, 2019 at 4:54 PM Dan Williams wrote: > > Unfortunately this particular b0rkage is not constrained to nvmem. > I.e. there's nothing specific about nvmem requiring mc-safe memory > copy, it's a cpu problem consuming any poison regardless of > source-media-type with "rep; movs". So

Re: [GIT PULL] device-dax for 5.1: PMEM as RAM

On Sun, Mar 10, 2019 at 12:54 PM Dan Williams wrote: > > Hi Linus, please pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm > tags/devdax-for-5.1 > > ...to receive new device-dax infrastructure to allow persistent memory > and other "reserved" / performance

Re: [GIT PULL] libnvdimm fixes for v5.0-rc4

On Sat, Jan 26, 2019 at 3:31 PM Williams, Dan J wrote: > > Hi Linus, please pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm > tags/libnvdimm-fixes-5.0-rc4 Hmm. One more pr-tracker-bot note: going through the pull requests from the last week, I notice that this one

Re: [GIT PULL] libnvdimm for 4.21

Hmm. This pull request doesn't seem to have gotten an automatic pr-tracker reply, even though I pulled it, and even though it was cc'd to lkml. Konstantin, any idea why the automation didn't trigger? I'm not seeing anything all that odd about it. [ looks around ] Oh, I notice that I can't seem

Re: [GIT PULL] dax fixes for 4.20-rc6

On Sun, Dec 9, 2018 at 10:27 AM Dan Williams wrote: > > I can send a cleanup, do you want one immediately, or is post -rc6 ok? post-rc6 is fine, I'd rather have the patch tested anyway, Linus ___ Linux-nvdimm mailing list

Re: [GIT PULL] dax fixes for 4.20-rc6

On Sat, Dec 8, 2018 at 10:26 PM Williams, Dan J wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm > tags/dax-fixes-4.20-rc6 What's going on with the odd non-exclusive exclusive wait? prepare_to_wait_exclusive(wq, , TASK_UNINTERRUPTIBLE); ... /*

Re: [GIT PULL]: libnvdimm updates for 4.19-rc1 v2 [2/2]

On Wed, Aug 22, 2018 at 1:22 PM Jiang, Dave wrote: > > Please pull to receive the libnvdimm dax-memory-failure series for v4.19-rc1. > I have removed the > offending ilog2() call and fixed up the patch accordingly. Ok, not only does the code look fine now, I actually find this split to have

Re: [GIT PULL]: libnvdimm updates for v4.19-rc1

On Fri, Aug 17, 2018 at 9:17 AM Jiang, Dave wrote: > > Please pull to receive libnvdimm contributions for v4.19-rc1 So I don't care about the libnvdimm code itself, but when you guys add code to the core mm/ code, I start looking. And when I then see shit like this: if

Re: [PATCH] mm: reject MAP_SHARED_VALIDATE without new flags

On Wed, Jun 27, 2018 at 7:17 PM Eric Sandeen wrote: > > What broke is that mmap(MAP_SHARED|MAP_PRIVATE) now succeeds without error, > whereas before it rightly returned -EINVAL. You're still confusing *behavior* with breakage. Yes. New *behavior* is that MAP_SHARED|MAP_PRIVATE is now a valid

Re: [PATCH] mm: reject MAP_SHARED_VALIDATE without new flags

On Wed, Jun 27, 2018 at 6:45 PM Eric Sandeen wrote: > > Thus the invalid flag combination of (MAP_SHARED|MAP_PRIVATE) now > passes without error, which is a regression. It's not a regression, it's just new behavior. "regression" doesn't mean "things changed". It means "something broke". What

Re: [GIT PULL] libnvdimm for 4.18

On Sat, Jun 9, 2018 at 8:17 AM Dan Williams wrote: > > Well, crap. I've been doing it the wrong way for a while. .. you're not the only one ;*( I only really catch it when it's very obvious, like it was now when the last merge was just before so it stood out like a sore thumb when I looked at

Re: [GIT PULL] libnvdimm for 4.18

On Fri, Jun 8, 2018 at 5:19 PM Linus Torvalds wrote: > > If I get stuff that looks at all complex at the end of the merge > window, I will just cackle unpleasantly while I press the big 'D' key > on my keyboard. Side note: looking at what I just pulled, there was close to a D

Re: [GIT PULL] libnvdimm for 4.18

On Fri, Jun 8, 2018 at 4:58 PM Williams, Dan J wrote: > > Not included in this pull, but still targeting this cycle, is support > for handling memory media errors (poison) consumed via userspace dax > mappings. Note that since I'm going to be traveling much of next week, I'm going to be even

Re: use memcpy_mcsafe() for copy_to_iter() (was: Re: [PATCH v3 0/9] Series short description)

On Mon, May 14, 2018 at 8:52 AM Dan Williams wrote: > 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. Yeah. I

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

t, and why is anybody using it? > > > I think this is an FAQ from the original submission, in fact some guy > named "Linus Torvalds" asked [1]: Oh, I already mentioned that I remembered that "rep movs" didn't work well. But there's a big gap between "just use 're

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

On Tue, May 1, 2018 at 8:22 PM Dan Williams wrote: > All that to say that having a typical RAM page covering poisoned pmem > would complicate the 'clear badblocks' implementation. Ugh, ok. I guess the good news is that your patches aren't so big, and don't really

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

On Tue, May 1, 2018 at 8:03 PM Dan Williams wrote: > Because dax. There's no page cache indirection games we can play here > to poison a page and map in another page. The mapped page is 1:1 > associated with the filesystem block and physical memory address. I'm not

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

On Tue, May 1, 2018 at 7:26 PM Dan Williams wrote: > Right, but the only way to make MCE non-fatal is to teach the machine > check handler about recoverable conditions. This patch teaches the > machine check handler how to recover copy_to_iter() errors. Why not just

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

On Tue, May 1, 2018 at 4:03 PM Dan Williams wrote: > I'm confused. Are you talking about getting rid of the block-layer > bypass or changing how MCS errors are handled? The latter. > If it's the latter, MCS error handling, I don't see how get > around something like

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

On Tue, May 1, 2018 at 1:55 PM Dan Williams wrote: > The result of the bypass is that the kernel treats machine checks during > read as system fatal (reboot) when they could simply be flagged as an > I/O error, similar to performing reads through the pmem driver.

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Fri, Mar 2, 2018 at 8:57 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > Like the page table caching entries, the memory type range registers > are really just "secondary information". They don't actually select > between PCIe and RAM, they jus

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Fri, Mar 2, 2018 at 8:22 AM, Kani, Toshi wrote: > > FWIW, this thing is called MTRRs on x86, which are initialized by BIOS. No. Or rather, that's simply just another (small) part of it all - and an architected and documented one at that. Like the page table caching

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, Mar 1, 2018 at 2:06 PM, Benjamin Herrenschmidt wrote: > > Could be that x86 has the smarts to do the right thing, still trying to > untangle the code :-) Afaik, x86 will not cache PCI unless the system is misconfigured, and even then it's more likely to just raise a

Re: [PATCH v9 1/6] mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags

On Thu, Oct 12, 2017 at 6:51 AM, Jan Kara wrote: > > When thinking a bit more about this I've realized one problem: Currently > user can call mmap() with MAP_SHARED type and MAP_SYNC or MAP_DIRECT flags > and he will get the new semantics (if the kernel happens to support it). I >

Re: [PATCH] Fix mpage_writepage() for pages with buffers

On Tue, Oct 10, 2017 at 12:44 PM, Andrew Morton wrote: > > This is all pretty mature code (isn't it?). Any idea why this bug > popped up now? Also, while the patch looks sane, the clean_buffers(page, PAGE_SIZE); line really threw me. That's an insane value

Re: [PATCH 2/2] mm: introduce MAP_VALIDATE, a mechanism for for safely defining new mmap flags

On Thu, Aug 31, 2017 at 6:01 PM, Dan Williams wrote: > > Ugh, nommu defeats the MAP_SHARED_VALIDATE proposal from Linus. > > if ((flags & MAP_TYPE) != MAP_PRIVATE && > (flags & MAP_TYPE) != MAP_SHARED) > return -EINVAL; > > ...parisc

Re: [PATCH 2/2] mm: introduce MAP_VALIDATE, a mechanism for for safely defining new mmap flags

This patch strikes me as insane. On Wed, Aug 30, 2017 at 4:08 PM, Dan Williams wrote: > switch (flags & MAP_TYPE) { > + case (MAP_SHARED|MAP_VALIDATE): > + /* TODO: new map flags */ > + return

Re: [RFC] memcpy_nocache() and memcpy_writethrough()

On Tue, Jan 3, 2017 at 3:22 PM, Al Viro wrote: > > 1) memcpy_to_pmem() seems to rely upon the __copy_from_user_nocache() > having only used movnt; it does not attempt clwb at all. > > 2) __copy_from_user_nocache() for short copies does not use movnt at all. > In that case

Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing

On Fri, Nov 25, 2016 at 1:48 PM, Theodore Ts'o wrote: > > There is a reason why people want to be able to do that, and that's > because kprobes doesn't give you access to the arguments and return > codes to the functions. Honestly, that's simply not a good reason. What if

Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing

On Thu, Nov 24, 2016 at 11:37 PM, Al Viro wrote: > > My impression is that nobody (at least kernel-side) wants them to be > a stable ABI, so long as nobody in userland screams about their code > being broken, everything is fine. As usual, if nobody notices an ABI >