On Mon, Oct 12, 2020 at 10:24 AM Ingo Molnar wrote:
>
> Do not sync vmalloc/ioremap mappings on x86-64 kernels.
>
> Hopefully now without the bugs!
Let's hope so.
If this turns out to work this time, can we do a similar preallocation
of the page directories on 32-bit? Because I think now x86-32
On Mon, Oct 12, 2020 at 2:44 PM Paul E. McKenney wrote:
>
> So that RCU can tell, even in CONFIG_PREEMPT_NONE=y kernels, whether it
> is safe to invoke the memory allocator.
So in what situation is RCU called from random contexts that it can't even tell?
> But either way, please let me know how
On Mon, Oct 12, 2020 at 2:42 PM Mike Travis wrote:
>
> It should have been an unsigned long instead of an int as Linus
> suggested. I'm not sure it's a write only variable as I think the mask
> is used to check if the interrupt occurred (I'll have to look closer).
At least "git grep" only shows
On Mon, Oct 12, 2020 at 3:10 AM Borislav Petkov wrote:
>
> please pull the x86/platform queue.
Hmm. I didn't immediately notice this new warning, because it only
happens with the clang build that I don't do in between every pull.
But this pull causes new warnings from clang:
arch/x86/platform/u
On Mon, Oct 12, 2020 at 1:22 PM Uros Bizjak wrote:
>
> No, this fact is not documented, although there are close to zero
> chances it will ever change. High registers are independent from their
> 8bit lowparts, but they still clobber corresponding 16bit, 32bit and
> 64bit representations. I guess
On Mon, Oct 12, 2020 at 1:30 PM Michael Kerrisk (man-pages)
wrote:
>
> [CC += Davide]
I'm not sure how active Davide is any more..
> I don't think this is correct. The epoll(7) manual page
> sill carries the text written long ago by Davide Libenzi,
> the creator of epoll:
>
> Since even wit
On Mon, Oct 12, 2020 at 7:14 AM Ingo Molnar wrote:
>
> Please pull the latest core/rcu git tree from:
>
> RCU changes for v5.10:
>
> - Debugging for smp_call_function()
> - RT raw/non-raw lock ordering fixes
> - Strict grace periods for KASAN
> - New smp_call_function() torture test
> - Tortu
On Mon, Oct 12, 2020 at 12:24 PM Uros Bizjak wrote:
>
> I don't think it is even possible to write to a part of a register in the
> asm. An example:
But this example is the *reverse* of what I worry about.
I worry about the asm writing not to a "part" of a register, but to
*more* than we told t
On Mon, Oct 12, 2020 at 12:25 PM Linus Torvalds
wrote:
>
> Now, the old pipe behavior was that it would wake up writers whether
> they needed it or not [..]
That "writers" should be "readers", of course.
Although yes, that commit changed it for both readers and writ
t; commit 1b6b26ae7053e4914181eedf70f2d92c12abda8a
> Author: Linus Torvalds
> Date: Sat Dec 7 12:14:28 2019 -0800
>
> pipe: fix and clarify pipe write wakeup logic
>
> (I also built a kernel from the immediate preceding commit, and did
> not observe the re
On Mon, Oct 12, 2020 at 11:56 AM Linus Torvalds
wrote:
>
> I also find that clang generates code that uses the high byte
> registers, although again, that's not from any knowledge of clang
> internals, and just by looking at my kernel image disassembly.
>
> So yes, it _may
On Mon, Oct 12, 2020 at 11:41 AM Uros Bizjak wrote:
>
> GCC does not distinguish between %ah and %al and it is not possible to pass
> "%ah" to the assembly. To access the high part of the %ax register, %h
> modifier has to be used in the assembly template.
Do you know whether that's true for cl
On Mon, Oct 12, 2020 at 4:06 AM Borislav Petkov wrote:
>
> * Use XORL instead of XORQ to avoid a REX prefix and save some bytes in
> the .fixup section, by Uros Bizjak.
I think this one is actually buggy.
For the 1-byte case, it does this:
__get_user_asm(x_u8__, ptr, retval, "b", "=q");
a
On Sun, Oct 11, 2020 at 11:57 PM Xing Zhengjun
wrote:
>
> Hi Linus,
>
>Do you have time to look at this? Thanks. I re-test it in v5.9-rc8,
> the regression still existed.
This is one of the series vm-scalability tests that got a huge
improvement (up to 160%) when I did the complete page fairn
ng list
Kevin Brace (4):
via-rhine: Fix for the hardware having a reset failure after resume
via-rhine: VTunknown1 device is really VT8251 South Bridge
via-rhine: Eliminate version information
via-rhine: New device driver maintainer
Linus Torvalds (4):
splice: teach spli
On Tue, Oct 6, 2020 at 4:13 PM Joe Perches wrote:
>
> Almost all source files in the kernel use a standardized SPDX header
> at line 1 with a comment /* initiator and terminator */:
>
> /* SPDX-License-Identifier: */
>
> $ git grep -PHn '^/\* SPDX-License-Identifier:.*\*/\s*$' | \
> wc -l
> 178
On Sun, Oct 11, 2020 at 1:09 AM Ingo Molnar wrote:
>
> - Fix a (hopefully final) IRQ state tracking bug vs. MCE handling
Why is the nmi_enter/nmi_exit thing not a problem on non-x86 architectures?
Put another way: x86 does extra work to track IRQ state across NMI.
What makes x86 special? It _fe
On Fri, Oct 9, 2020 at 6:19 PM Eric Biggers wrote:
>
> Okay, that makes more sense. So the patchset from Matthew
> https://lkml.kernel.org/linux-fsdevel/20201003025534.21045-1-wi...@infradead.org/T/#u
> isn't what you had in mind.
No.
That first patch makes sense - it's just the "ppos can be NU
On Fri, Oct 9, 2020 at 3:06 PM Eric Biggers wrote:
>
> It's a bit unintuitive that ppos=NULL means "use pos 0", not "use
> file->f_pos".
That's not at all what it means.
A NULL ppos means "this has no position at all", and is what we use
for FMODE_STREAM file descriptors (ie sockets, pipes, etc
On Thu, Oct 8, 2020 at 10:02 AM Linus Torvalds
wrote:
>
> Here's the first patch anyway. If you actually have a test-case where
> this matters, I guess I need to apply it now..
Actually, I removed the "__page_mapcount()" part of that patch, to
keep it minimal and _only_
Ahh, and I should learn to read all my emails before replying to some of them..
On Thu, Oct 8, 2020 at 2:26 AM Aneesh Kumar K.V
wrote:
>
> This avoids the below warning
> [..]
> WARNING: CPU: 0 PID: 30613 at arch/powerpc/mm/pgtable.c:185
set_pte_at+0x2a8/0x3a0 arch/powerpc/mm/pgtable.c:185
.. a
[ Just adding Leon to the participants ]
This patch (not attached again, Leon has seen it before) has been
tested for the last couple of weeks for the rdma case, so I have no
problems applying it now, just to keep everybody in the loop.
Linus
On Thu, Oct 8, 2020 at 10:02 AM Linus
On Thu, Oct 8, 2020 at 2:27 AM Aneesh Kumar K.V
wrote:
>
> In copy_present_page, after we mark the pte non-writable, we should
> check for previous dirty bit updates and make sure we don't lose the dirty
> bit on reset.
No, we'll just remove that entirely.
Do you have a test-case that shows a pr
xen/events: don't use chip_data for legacy IRQs
Kai-Heng Feng (1):
memstick: Skip allocating card when removing host
Likun Gao (1):
drm/amdgpu: add device ID for sienna_cichlid (v2)
Linus Torvalds (3):
autofs: use __kernel_write() for the autofs pipe writing
pipe
On Sat, Oct 3, 2020 at 7:36 PM Al Viro wrote:
>
> Locking and especially control flow in fs/eventpoll.c is
> overcomplicated. As the result, the code has been hard to follow
> and easy to fuck up while modifying.
Scanning through the patches they all look superficially ok to me, but
I'm
On Fri, Oct 2, 2020 at 10:20 AM Al Viro wrote:
>
> Several race fixes in epoll.
Fudge. I screwed up the commit message due to a cut-and-paste error
(don't ask - sometimes google chrome and gnome-terminal seem to stop
agreeing about the normal X paste buffer)
And I extra stupidly pushed t
On Thu, Oct 1, 2020 at 3:41 PM Al Viro wrote:
>
> Better
> loff_t dummy = 0;
> ...
> wr = __kernel_write(file, data, bytes, &dummy);
No, just fix __kernel_write() to work correctly.
The fact is, NULL _is_ the right pointer for ppos these days.
That commit by Christoph is
On Thu, Oct 1, 2020 at 12:56 PM Roman Gushchin wrote:
>
> Bastian, can you, please, share your config?
Bastian actually did that in the original email, but that was only
sent to me and Andrew in private.
Here's that config replicated for your pleasure,
Linus
#
# Automatically gen
Adding Vlastimil, Roman and the kernel mailing list to the cc.
Vlastimil, Roman - this looks like a slab regression. And while others
have touched slab in this merge window, you guys did so more than
most.. Comments?
On Wed, Sep 30, 2020 at 11:55 PM Bastian Bittorf wrote:
>
> Since 5.9-rc1 i can
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 Mon, Sep 28, 2020 at 12:36 PM Linus Torvalds
wrote:
>
> So I'll do the pte wrprotect/restore removal. Anybody willing to do
> and test the sequence count approach?
So the wrprotect removal is trivial, with most of it being about the comments.
However, when I look at this, I a
On Mon, Sep 28, 2020 at 11:39 AM Jason Gunthorpe wrote:
>
> All of gup_fast and copy_mm could be wrappered in a seq count so that
> gup_fast always goes to the slow path if fork is concurrent.
>
> That doesn't sound too expensive and avoids all the problems you
> pointed with the WP scheme.
Ok, I
On Mon, Sep 28, 2020 at 11:39 AM Jason Gunthorpe wrote:
>
> I prefer the version where read pin and write pin are symmetric. The
> PTE in the MM should not change once pinned.
The thing is, I don't really see how to do that.
Right now the write pin fastpath part depends on the PTE being
writable
On Mon, Sep 28, 2020 at 10:23 AM Peter Xu wrote:
>
> Yes... Actually I am also thinking about the complete solution to cover
> read-only fast-gups too, but now I start to doubt this, at least for the
> fork()
> path. E.g. if we'd finally like to use pte_protnone() to replace the current
> pte_w
On Mon, Sep 28, 2020 at 7:07 AM Harald Arnesen wrote:
>
> I will try bisecting if no-one has a simple explanation.
There's a simple explanation, no need to bisect.
I'll push out the fix asap,
Linus
On Mon, Sep 28, 2020 at 5:49 AM Jason Gunthorpe wrote:
>
> Not seeing an obvious option besides adding a smp_mb() before
> page_maybe_dma_pinned() as Peter once suggested.
That is going to be prohibitively expensive - needing it for each pte
whether it's pinned or not.
I really think the better
mcast: fix duplicate mcast packets in BLA backbone from LAN
batman-adv: mcast: fix duplicate mcast packets in BLA backbone from mesh
batman-adv: mcast: fix duplicate mcast packets from BLA backbone to mesh
Linus Torvalds (4):
mm: split out the non-present case from copy_on
On Fri, Sep 25, 2020 at 3:26 PM Peter Xu wrote:
>
> This series is majorly inspired by the previous discussion on the list [1],
> starting from the report from Jason on the rdma test failure.
Ok, this is now in my git tree with the changes I outlined in the other email.
> I tested it myself with
On Sun, Sep 27, 2020 at 8:08 AM Thomas Gleixner wrote:
>
> please pull the latest timers/urgent branch from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> timers-urgent-2020-09-27
Hmm. I got this (and the x86) pull request twice.
Is it just because the subject line was mess
On Sun, Sep 27, 2020 at 11:16 AM Linus Torvalds
wrote:
>
> Btw, I'm not convinced about the whole "turn the pte read-only and
> then back". If the fork races with another thread doing a pinning
> fast-GUP on another CPU, there are memory ordering issues etc too.
>
On Sat, Sep 26, 2020 at 11:24 PM Leon Romanovsky wrote:
>
> We won't be able to test the series till Tuesday due to religious holidays.
That's fine. I've merged the series up, and it will be in rc7 later
today, and with an rc8 next week we'll have two weeks to find any
issues.
I did edit Peter's
On Sat, Sep 26, 2020 at 4:23 PM Jason Gunthorpe wrote:
>
> Linus's version doesn't do pte_sw_mkyoung(), but looks OK to have it
I don't think it matters. But I don't think it should make it young,
since there's no access, but it's not like it's a big deal.
> > + pte =
On Fri, Sep 25, 2020 at 6:15 PM Linus Torvalds
wrote:
>
> I think that over the weekend I'll do Peter's version but with the
> "page_mapcount() == 1" check, because I'm starting to like that
> better than the mm->has_pinned.
Actually, rafter the first r
On Fri, Sep 25, 2020 at 5:41 PM Jason Gunthorpe wrote:
>
> I don't completely grok the consequences of the anon_vma check. We
> can exclude file backed mappings as they are broken for pinning
> anyhow, so what is left that could be MAP_PRIVATE of a non-anon_vma?
It really shouldn't ever happen.
On Fri, Sep 25, 2020 at 2:13 PM Peter Xu wrote:
>
> On Fri, Sep 25, 2020 at 12:56:05PM -0700, Linus Torvalds wrote:
> > So I think we can simply add a
> >
> > if (page_mapcount(page) != 1)
> > return false;
> >
> > to page_m
On Fri, Sep 25, 2020 at 12:56 PM Linus Torvalds
wrote:
>
> And honestly, since this is all getting fairly late in the rc, and it
> took longer than I thought, I think we should do the GFP_ATOMIC
> approach for now - not great, but since it only triggers for this case
> that real
On Thu, Sep 24, 2020 at 2:30 PM Peter Xu wrote:
>
> > >
> > > With the extra mprotect(!WRITE), I think we'll see a !pte_write() entry.
> > > Then
> > > it'll not go into maybe_dma_pinned() at all since cow==false.
> >
> > Hum that seems like a problem in this patch, we still need to do the
> > D
On Fri, Sep 25, 2020 at 9:19 AM Ming Lei wrote:
>
> git bisect shows the first bad commit:
>
> [10befea91b61c4e2c2d1df06a2e978d182fcf792] mm: memcg/slab: use a
> single set of
> kmem_caches for all allocations
>
> And I have double checked that the above commit is really t
On Thu, Sep 24, 2020 at 5:06 AM Gerald Schaefer
wrote:
>
> It's all good now, no more occurrences with unlock_page() before
> wp_page_reuse().
Thanks for the confirmation. When you pointed at that unlock_page()
change, I was pretty sure that was it ("D'oh!"), but it's always good
to have that ver
On Wed, Sep 23, 2020 at 2:33 PM Gerald Schaefer
wrote:
>
> Thanks, very nice walk-through, need some time to digest this. The TLB
> aspect is interesting, and we do have our own __tlb_remove_page_size(),
> which directly calls free_page_and_swap_cache() instead of the generic
> batched approach.
On Wed, Sep 23, 2020 at 10:16 AM Linus Torvalds
wrote:
>
> But these two patches are very intentionally meant to be just "this
> clearly changes NO semantics at all".
The more I look at these, the more I go "this is a cleanup
regardless", so I'
On Tue, Sep 22, 2020 at 6:03 PM Peter Xu wrote:
>
> > If we rely on "copy_ret == COPY_MM_BREAK_COW" we can unify "again" and
> > "again_break_cow", we don't need to clear ->cow_new_page, this makes the
> > logic more understandable. To me at least ;)
>
> I see your point. I'll definitely try it o
On Wed, Sep 23, 2020 at 6:39 AM Gerald Schaefer
wrote:
>
> OK, I can now reproduce this, and unfortunately also with the gup_fast
> fix, so it is something different. Bisecting is a bit hard, as it will
> not always show immediately, sometimes takes up to an hour.
>
> Still, I think I found the cu
On Wed, Sep 23, 2020 at 1:44 AM Pavel Machek wrote:
>
> >
> > https://www.openwall.com/lists/oss-security/2020/09/15/2
>
> Thank you for the pointer!
Note that for me to be willing to take the softscollback code back, it
really would have to be more than just a revert and a trivial fix.
It wou
ded a temporary page but
you hadn't allocated one yet" or "I used up the temporary page you
gave me" or "all good, keep the temporary page around for the future".
But these two patches are very intentionally meant to be just "this
clearly changes NO semantics at all
On Mon, Sep 21, 2020 at 6:44 PM Jakub Kicinski wrote:
>
> Here are the latest updates from the networking tree:
Pulled.
But I'd ask for a couple of things for future pull requests:
(a) please put "git pull" somewhere in the email (lots of people just
put it in the subject by prepending it with
On Tue, Sep 22, 2020 at 8:56 AM Jason Gunthorpe wrote:
>
> I thought MAP_PRIVATE without PROT_WRITE was nonsensical,
MAP_PRIVATE without PROT_WRITE is very common.
It's what happens for every executable mapping, for example.
And no, it's not the same as MAP_SHARED, for a couple of simple
reason
On Mon, Sep 21, 2020 at 12:37 PM Paul E. McKenney wrote:
>
> This bug was reported by Laurent Pinchart (CCed),
> who would like it fixed sooner rather than later.
I'm assuming that sentence and me being cc'd means that you'd prefer
to get this merged directly rather than go through the usual -tip
On Mon, Sep 21, 2020 at 2:11 AM Jan Kara wrote:
>
> Except that on truncate, we have to unmap these
> anonymous pages in private file mappings as well...
I'm actually not 100% sure we strictly would need to care.
Once we've faulted in a private file mapping page, that page is
"ours". That's kind
On Mon, Sep 21, 2020 at 12:39 AM Thomas Gleixner wrote:
>
> If a task is migrated to a different CPU then the mapping address will
> change which will explode in colourful ways.
Heh.
Right you are.
Maybe we really *could* call this new kmap functionality something
like "kmap_percpu()" (or maybe
On Sun, Sep 20, 2020 at 6:06 PM Robert Gadsdon wrote:
>
> drivers/dax/super.c:325:6: error: redefinition of ‘dax_supported’
Gaah. Ok, this should hopefully be fixed in my tree now.
Linus
tencies
Kees Cook (2):
core/entry: Report syscall correctly for trace and audit
mailmap: add older email addresses for Kees Cook
Kuninori Morimoto (3):
ASoC: pcm3168a: ignore 0 Hz settings
ASoC: ti: fixup ams_delta_mute() function name
ASoC: soc-core: add snd_soc_f
On Sun, Sep 20, 2020 at 12:33 PM Borislav Petkov wrote:
>
> I'm simply forwarding Ard's tag, I hope that's ok.
That's ok, although it shows perhaps a weakness in our model.
Git actually would have allowed you to create a signed tag pointing to
Ard's tag, and we'd have had the signature chain tha
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 Sun, Sep 20, 2020 at 10:42 AM Linus Torvalds
wrote:
>
> Yeah, that looks much easier to explain. Ack.
Btw, one thing that might be a good idea at least initially is to add
a check for p->kmap_ctrl.idx being zero at fork, exit and maybe
syscall return time (but that last one m
On Sun, Sep 20, 2020 at 10:40 AM Thomas Gleixner wrote:
>
> I think the more obvious solution is to split the whole exercise:
>
> schedule()
> prepare_switch()
> unmap()
>
> switch_to()
>
> finish_switch()
> map()
Yeah, that looks much easier to explain. Ack.
On Sun, Sep 20, 2020 at 1:49 AM Thomas Gleixner wrote:
>
> Actually most usage sites of kmap atomic do not need page faults to be
> disabled at all.
Right. I think the pagefault disabling has (almost) nothing at all to
do with the kmap() itself - it comes from the "atomic" part, not the
"kmap" pa
On Sat, Sep 19, 2020 at 10:39 AM Matthew Wilcox wrote:
>
> My concern with that is people might use kmap() and then pass the address
> to a different task. So we need to audit the current users of kmap()
> and convert any that do that into using vmap() instead.
Ahh. Yes, I guess they might do th
On Sat, Sep 19, 2020 at 2:50 AM Thomas Gleixner wrote:
>
> this provides a preemptible variant of kmap_atomic & related
> interfaces. This is achieved by:
Ack. This looks really nice, even apart from the new capability.
The only thing I really reacted to is that the name doesn't make sense
to me
On Fri, Sep 18, 2020 at 7:53 PM Arvind Sankar wrote:
>
> Is it ever necessary to allocate _at least_ sizeof() even if
> offsetof()+size is smaller?
Not that I can tell.
Obviously all allocators tend to have their own alignment concerns, so
they'll all align things up internally anyway.
But why
On Fri, Sep 18, 2020 at 3:40 PM Arvind Sankar wrote:
>
> Ouch, offsetof() and sizeof() will give different results in the
> presence of alignment padding.
Indeed. But from an allocation standpoint, the offsetof()+size is I
think the correct size. The padding at the end makes very little sense
for
On Fri, Sep 18, 2020 at 2:00 PM Arvind Sankar wrote:
>
> You could just assert that offsetof(typeof(s),flex) == sizeof(s), no?
No, because the whole point is that I want that "sizeof(s)" to *WARN*.
It's a nonsensical thing to do. That 's' has no statically known size.
The C standard is being ve
On Fri, Sep 18, 2020 at 1:41 PM Peter Xu wrote:
>
> What would be the result if we simply use GFP_ATOMIC? Would there be too many
> pages to allocate in bulk for ATOMIC?
It's very easy to run out of memory with GFP_ATOMIC, and also cause
various nasty issues with networking (ie when you've deple
On Fri, Sep 18, 2020 at 1:29 PM Arvind Sankar wrote:
>
> In general (i.e. outside the implementation of the macro itself), what
> is the preferred way of getting the size of just the header?
> 1) offsetof(typeof(s),flex)
> 2) struct_size(s, flex, 0)
I think those two should end up being equiv
On Fri, Sep 18, 2020 at 1:02 PM Matthew Wilcox wrote:
>
> I suppose it's not really necessary, we could do offsetof here, right?
Yup, that would make a lot more sense.
But right now, the sizeof() obviously silently works.
As do a number of other fairly nonsensical things, like assigning a struc
On Fri, Sep 18, 2020 at 12:28 PM Gustavo A. R. Silva
wrote:
>
> OK. It seems that we are talking about two different things here. One thing
> is to apply sizeof() to a structure that contains a flexible-array member.
> And the other thing is to apply sizeof() to a flexible array. The former
> is a
On Fri, Sep 18, 2020 at 6:13 AM Jan Kara wrote:
>
> Yes, but no Linux filesystem (except for XFS AFAIK) follows the POSIX spec
> in this regard.
Yeah, and we never have. As you say, performance sucks, and nobody has
ever cared.
So the standard in this case is just something that we'll never
foll
On Fri, Sep 18, 2020 at 9:17 AM Gustavo A. R. Silva
wrote:
>
> This bug could have been prevented by either adopting better
> coding practices or through the use[3] of the recent struct_size() helper.
Well, my unspoken point was that coding practices are just
theoretical. Coding practices don't h
On Fri, Sep 18, 2020 at 9:40 AM Peter Xu wrote:
>
> Firstly in the draft patch mm->has_pinned is introduced and it's written to 1
> as long as FOLL_GUP is called once. It's never reset after set.
That's fine. That was what I was expecting you to do. It only needs to
be cleared at mm creation tim
On Thu, Sep 17, 2020 at 1:45 PM Dennis Zhou wrote:
>
>
> diff --git a/mm/percpu.c b/mm/percpu.c
> index f4709629e6de..1ed1a349eab8 100644
> --- a/mm/percpu.c
> +++ b/mm/percpu.c
> @@ -1316,7 +1316,7 @@ static struct pcpu_chunk * __init
> pcpu_alloc_first_chunk(unsigned long tmp_addr,
>
>
On Thu, Sep 17, 2020 at 3:09 PM Jason Gunthorpe wrote:
>
> My advice for this -rc fix is to go with a single bit in the mm_struct
> set on any call to pin_user_pages*
Ack, except make sure it's a byte rather than a bitfield that could
have races. Or even just a separate atomic_t.
Keep it simple
On Thu, Sep 17, 2020 at 1:06 PM Jason Gunthorpe wrote:
>
> Given that this is a user visible regression, it is nearly rc6, what
> do you prefer for next steps?
Since I had to deal with the page lock performance regression too, and
I think we have a fairly simple way forward, I'd rather do an rc8
On Thu, Sep 17, 2020 at 12:03 PM Peter Xu wrote:
>
> The fork() should be slightly slower though, since we'll need to copy the data
> for all the DMA buffers for each of the child processes, even if we should be
> pretty sure those processes won't use these pages at all.
I think that as long as w
On Thu, Sep 17, 2020 at 12:38 PM Jason Gunthorpe wrote:
>
> Looking for awhile, this now looks reasonable and
> doable. page_maybe_dma_pinned() was created for exactly this kind of
> case.
>
> I've attached a dumb sketch for the pte level (surely wrong! I have
> never looked at this part of the mm
On Thu, Sep 17, 2020 at 11:14 AM Peter Xu wrote:
>
> In my humble opinion, the real solution is still to use MADV_DONTFORK properly
> so we should never share the DMA pages with others when we know the fact.
Is this all just because somebody does a fork() after doing page pinning?
If so, I feel
> I botched the last version of the patch, here is something a bit
> better.
So I'd like to understand why this problem happens.
Myt argument to Hugh a few weeks ago was that page pinning should take
care of all this:
(a) if the pinner is going to change the page, it will have to get
the pin wi
On Thu, Sep 17, 2020 at 6:16 AM John Ogness wrote:
>
> Since there is no code that will ever store anything into the dict
> ring, remove it. If any future dictionary properties are to be
> added, these should be added to the struct printk_info.
Ack. I'm very happy to see the dictionary stuff go.
On Tue, Sep 15, 2020 at 12:57 PM Thomas Gleixner wrote:
>
> You wish. I just found a 7 year old bug in a 10G network driver which
> surely would have been found if people would enable debug configs and
> not just run the crap on their PREEMPT_NONE, all debug off kernel. And
> that driver is not su
On Wed, Sep 16, 2020 at 8:29 AM Paul E. McKenney wrote:
>
> All fair, but some of us need to write code that must handle being
> invoked from a wide variety of contexts.
Note that I think that core functionality is different from random drivers.
Of course core code can (and will) look at things
On Tue, Sep 15, 2020 at 7:28 AM Greg Kroah-Hartman
wrote:
>
> GCOV built with GCC 10 doesn't initialize n_function variable. This
> produces different kernel panics as was seen by Colin in Ubuntu and me
> in FC 32.
>
> As a workaround, let's disable GCOV build for broken GCC 10 version.
Oh, Pete
On Tue, Sep 15, 2020 at 1:39 AM Thomas Gleixner wrote:
>
> OTOH, having a working 'preemptible()' or maybe better named
> 'can_schedule()' check makes tons of sense to make decisions about
> allocation modes or other things.
No. I think that those kinds of decisions about actual behavior are
alwa
On Tue, Sep 15, 2020 at 12:24 AM Thomas Gleixner wrote:
>
> Alternatively we just make highmem a bit more expensive by making these
> maps preemptible. RT is doing this for a long time and it's not that
> horrible.
Ack.
In fact, I've wanted to start just removing kmap support entirely. At
some p
On Mon, Sep 14, 2020 at 11:45 PM Linus Torvalds
wrote:
>
> I mean, I did find one case that didn't set it (cb710-mmc.c), but
> pattern-matching to the other mmc cases, that one looks like it
> _should_ have set the atomic flag like everybody else did.
Oh, and immediately after s
On Mon, Sep 14, 2020 at 8:30 PM Herbert Xu wrote:
>
> There is no reason for the chacha20poly1305 SG miter code to use
> kmap instead of kmap_atomic as the critical section doesn't sleep
> anyway. So we can simply get rid of the preemptible check and
> set SG_MITER_ATOMIC unconditionally.
So I'd
On Mon, Sep 14, 2020 at 11:24 PM Herbert Xu wrote:
>
> On Tue, Sep 15, 2020 at 09:20:59AM +0300, Ard Biesheuvel wrote:
> >
> > The documentation of kmap_atomic() states the following:
> >
> > * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap
> > * gives a more generic (and cach
On Mon, Sep 14, 2020 at 6:28 PM Bhaskar Chowdhury wrote:
>
> Documentation/admin-guide/kernel-parameters.txt:no-scroll [VGA]
> Disables scrollback.
So this one at least should be still valid.
But these:
> Documentation/fb/fbcon.rst:2. fbcon=scrollback:[k]
> Documentation/fb/fbcon
On Mon, Sep 14, 2020 at 6:19 PM Randy Dunlap wrote:
>
> Now someone can remove the documentation for scrollback (and "no-scroll")...
Note that scrollback hasn't actually gone away entirely - the original
scrollback supported by _hardware_ still exists.
Of course, that's really just the old-fashi
On Mon, Sep 14, 2020 at 4:28 PM Jason Gunthorpe wrote:
>
> Hmm. If symptoms stop with this patch should we investigate
> MADV_DONTFORK?
I took a quick look at it, and it all looks trivially correct.
All MADV_DONTFORK does is to set the VM_DONTCOPY flag in the vma.
And dup_mmap() in kernel/fork.
On Mon, Sep 14, 2020 at 3:55 PM Jason Gunthorpe wrote:
>
> Just as an aside, the RDMA stuff is also supposed to set MADV_DONTFORK
> on these regions, so I'm a bit puzzled what is happening here.
Did the fork perhaps happen _before_ , so the pages are shared when
you do the pin?
MADV_DONTFORK doe
On Mon, Sep 14, 2020 at 10:59 AM Peter Xu wrote:
>
> However now I'm a bit confused on why FOLL_COW must be with FOLL_FORCE even
> without the enforced COW... Shouldn't FOLL_COW be able to happen even without
> FOLL_FORCE (as long as when a page is shared, and the gup is with WRITE
> permission)?
701 - 800 of 9519 matches
Mail list logo
