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 write-by-akpm-
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 ans
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 point
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 filesystem-da
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 direc
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
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).
I
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 (
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 me
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 c
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
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 a
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*
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, #
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 w
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 of
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
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) ma
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
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 th
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
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 on
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.
The
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 e
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(&mcsafe_key))
> > - re
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 '(void
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.
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 that
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 whi
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 for
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 elimi
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 wh
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 differentiate
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 di
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
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
Linux-nvdimm@
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, &ewait.wait, TASK_UNINTERRUPTIBLE);
...
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 been
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 (is_zone_device_p
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
thi
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 br
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 th
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 clo
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 less
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 definitely wouldn't say "happ
> >
> 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 'rep movs
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
affect anything else.
But can
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 talking page cache indirection
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 unmap the page and remap a ne
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 copy_to_iter_mcsafe().
So t
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. Prevent
> this fatal condition by
On Fri, Mar 2, 2018 at 8:57 AM, Linus Torvalds
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 just affect the behavior on top of that.
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 entries, the memory type r
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 machine check exceptio
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
> think that is u
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 to pick, it looks like
"bytes
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 strikes again.
Why? That's
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 -EINVAL;
> cas
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 neither sfence nor clwb i
On Sun, Nov 27, 2016 at 2:42 PM, Dave Chinner wrote:
>
> And that's exactly why we need a method of marking tracepoints as
> stable. How else are we going to know whether a specific tracepoint
> is stable if the kernel code doesn't document that it's stable?
You are living in some unrealistic dre
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 everybody did this? Do
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
> change, it hasn't happened. Th
62 matches
Mail list logo