On Fri, Sep 11, 2020 at 12:04 PM Vasily Gorbik wrote:
>
> Currently to make sure that every page table entry is read just once
> gup_fast walks perform READ_ONCE and pass pXd value down to the next
> gup_pXd_range function by value e.g.:
[ ... ]
Ack, this looks sane to me.
I was going to ask how
On Fri, Sep 11, 2020 at 5:20 AM Alexander Gordeev
wrote:
>
> What if the entry is still pud_present, but got remapped after
> READ_ONCE(*pudp)? IOW, it is still valid, but points elsewhere?
That can't happen.
The GUP walk doesn't hold any locks, but it *is* done with interrupts
disabled, and any
On Thu, Sep 10, 2020 at 8:25 AM Josh Poimboeuf wrote:
>
> Fixes the following warning:
Ack, confirmed. I assume I'll be getting this through the usual channels.
[ In the meantime, Peter Oberparleiter figured out what was wrong with
GCOV and it's been re-enabled on my system, so I'm not seeing th
On Thu, Sep 10, 2020 at 12:11 PM Gerald Schaefer
wrote:
>
> That sounds a lot like the pXd_offset_orig() from Martins first approach
> in this thread:
> https://lore.kernel.org/linuxppc-dev/20190418100218.0a4afd51@mschwideX1/
I have to admit to finding that name horrible, but aside from that, yes
On Thu, Sep 10, 2020 at 5:52 AM Peter Oberparleiter
wrote:
>
> Fix this by updating the in-kernel GCOV_COUNTERS value. Also re-enable
> config GCOV_KERNEL for use with GCC 10.
Lovely.
Is there some way we could see this value automatically, or at least
have a check for it? Right now it's that _v
On Thu, Sep 10, 2020 at 11:13 AM Jason Gunthorpe wrote:
>
> So.. To change away from the stack option I think we'd have to pass
> the READ_ONCE value to pXX_offset() as an extra argument instead of it
> derefing the pointer internally.
Yeah, but I think that would actually be the better model tha
On Thu, Sep 10, 2020 at 2:40 AM Alexander Gordeev
wrote:
>
> It is only gup_fast case that exposes the issue. It hits because
> pointers to stack copies are passed to gup_pXd_range iterators, not
> pointers to real page tables itself.
Can we possibly change fast-gup to not do the stack copies?
I
On Wed, Sep 9, 2020 at 11:42 AM Segher Boessenkool
wrote:
>
> It will not work like this in GCC, no. The LLVM people know about that.
> I do not know why they insist on pushing this, being incompatible and
> everything.
Umm. Since they'd be the ones supporting this, *gcc* would be the
incompatib
I'd post these so that
there won't be any surprises during the next merge window when I apply
them after merging the set_fs() removal branch..
Linus
From 52c7574a0d15722df52158a3d766803662d9a6ff Mon Sep 17 00:00:00 2001
From: Linus Torvalds
Date: Wed, 8 Apr 2020 12:50:01 -0700
Subject:
On Tue, Sep 8, 2020 at 11:32 AM Josh Poimboeuf wrote:
>
> Can you share the .o file? At least I can't recreate with GCC 9.3.1,
> which is all I have at the moment.
Done off-list in private, because I don't think anybody else wants
object files flying around on the mailing lists..
On Fri, Sep 4, 2020 at 2:51 PM Harald Arnesen wrote:
>
> Still doesn't work without the three reverts
> (763fedd6a216, 9e0f9464e2ab, 7ac2d2536dfa)...
So this didn't make rc4, but it's in my tree now.
Harald, I'm assuming things work for you again now with the current
git tree, but it is always g
Josh,
On Mon, Sep 7, 2020 at 1:20 AM Petr Mladek wrote:
>
> - Workaround "unreachable instruction" objtool warnings that happen
> with some compiler versions.
I know I said this fixes things for me, but I just realized it doesn't entirely.
I wonder how I missed the remaining one:
arch/x86
e first when alloc gigantic page from cma
Linus Lüssing (1):
batman-adv: Fix own OGM check in aggregated OGMs
Linus Torvalds (2):
mm: do_wp_page() simplification
Linux 5.9-rc4
Louis Peens (1):
nfp: flower: fix ABI mismatch between driver and firmware
Lu Baolu (2):
On Sat, Sep 5, 2020 at 9:44 PM Juergen Gross wrote:
>
> It contains a small series for fixing a problem with Xen PVH guests
> when running as backends (e.g. as dom0). Mapping other guests' memory
> now is working via ZONE_DEVICE, thus not requiring to abuse the memory
> hotplug functionality for t
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 Thu, Sep 3, 2020 at 8:53 PM Dave Airlie wrote:
>
> Not much going on this week, nouveau has a display hw bug workaround,
> amdgpu has some PM fixes and CIK regression fixes, one single radeon
> PLL fix, and a couple of i915 display fixes.
Any movement on the i915 relocation issue? I've only se
On Fri, Sep 4, 2020 at 10:58 AM Alexey Dobriyan wrote:
>
> set_fs() is older than some kernel hackers!
>
> $ cd linux-0.11/
> $ find . -type f -name '*.h' | xargs grep -e set_fs -w -n -A3
Oh, it's older than that. It was there (as set_fs) in 0.10, and may
even predate that. But sa
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 2:30 PM David Laight wrote:
>
> A non-canonical (is that the right term) address between the highest
> valid user address and the lowest valid kernel address (7ffe to fffe?)
> will fault anyway.
Yes.
But we actually warn against that fault, because it's been a good way
to
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 Thu, Sep 3, 2020 at 7:22 AM Christoph Hellwig wrote:
>
> [Note to Linus: I'd like to get this into linux-next rather earlier
> than later. Do you think it is ok to add this tree to linux-next?]
This whole series looks really good to me now, with each patch looking
like a clear cleanup on its
On Wed, Sep 2, 2020 at 11:44 AM Leon Romanovsky wrote:
>
> I already don't remember why, but copy_from_user() caused to second flow
> of gcov_info_dup() through gcov_event() to generate another set of warnings.
>
> As a summary, I have a workaround, but I don't know why it works and not
> proud ab
On Wed, Sep 2, 2020 at 10:46 AM Leon Romanovsky wrote:
>
> Definitely my explanation is wrong, but it was my interpretation of
> "BUG: KASAN: global-out-of-bounds in kmemdup+0x43/0x70" line. I saw
> that the failure was in memcpy() inside of kmemdup(), so I changed
> from memcpy to be copy_from_us
On Wed, Sep 2, 2020 at 10:52 AM Leon Romanovsky wrote:
>
> Are you suggesting something like this?
>
> diff --git a/kernel/gcov/Kconfig b/kernel/gcov/Kconfig
> index 3110c77230c7..bc0e355f64aa 100644
> --- a/kernel/gcov/Kconfig
> +++ b/kernel/gcov/Kconfig
> @@ -3,7 +3,7 @@ menu "GCOV-based kernel
On Wed, Sep 2, 2020 at 8:17 AM Christophe Leroy
wrote:
>
>
> With this fix, I get
>
> root@vgoippro:~# time dd if=/dev/zero of=/dev/null count=1M
> 536870912 bytes (512.0MB) copied, 6.776327 seconds, 75.6MB/s
>
> That's still far from the 91.7MB/s I get with 5.9-rc2, but better than
> the 65.8MB/s
On Wed, Sep 2, 2020 at 1:55 AM Leon Romanovsky wrote:
>
> Bottom line, GCOV is broken on GCC 10.2.
The patches don't really make sense to me.
How about we just disable GCOV with the known-broken compiler version
instead? As mentioned in the replies to individual patches, it looks
like the "fixes
On Wed, Sep 2, 2020 at 1:55 AM Leon Romanovsky wrote:
>
> This trace is seen because n_function value provided by GCC through
> __gcov_init() is ridiculously high, in my case it was 2698213824,
> which probably means that the field is not initialized.
This seems to be wrong - since a different (s
On Wed, Sep 2, 2020 at 1:55 AM Leon Romanovsky wrote:
>
> The kernel with KASAN and GCOV enabled generates the following splat
> due to the situation that gcov_info can be both user and kernel pointer.
I can't parse the above explanation..
> It is triggered by the memcpy() inside kmemdup(), so a
On Tue, Sep 1, 2020 at 3:42 PM Arnaldo Carvalho de Melo wrote:
>
> - The SNOOPX and REMOTE offsets in the data_src bitmask in perf records were
> were both 37, SNOOPX is 38, fix it.
The kernel uapi side thinks it's 37. What's up?
$ git grep PERF_MEM_SNOOPX_SHIFT
results in
include/uapi/l
On Mon, Aug 31, 2020 at 3:03 AM Jan Kara wrote:
>
> On Fri 28-08-20 12:07:55, Jan Kara wrote:
> >
> > Doh, so this is:
> >
> > wait_on_page_writeback(page);
> > >>> BUG_ON(PageWriteback(page));
> >
> > in mpage_prepare_extent_to_map(). So we have PageWri
On Sun, Aug 30, 2020 at 4:47 PM Sasha Levin wrote:
>
> Is it possible you've forgotten to push? I don't see the tag/5.9-rc3
> commit in your repo.
Indeed. Thanks for noticing. Fixed,
Linus
lay platform_driver
Lee Jones (1):
mfd: mfd-core: Ensure disabled devices are ignored without error
Li Jun (1):
usb: host: xhci: fix ep context print mismatch in debugfs
Linus Torvalds (2):
fsldma: fix very broken 32-bit ppc ioread64 functionality
Linux 5.9-rc3
Logan Gu
On Sun, Aug 30, 2020 at 11:04 AM Thomas Gleixner wrote:
>
>The historical inconsistent for_each_cpu() behaviour of
>ignoring the cpumask and unconditionally claiming that CPU0 is in the
>mask struck again. Sigh.
I guess we could remove the UP optimizations these days. It's not like
th
On Sun, Aug 30, 2020 at 11:04 AM Thomas Gleixner wrote:
>
> - Make is_idle_task() __always_inline to prevent the compiler from putting
>it out of line into the wrong section because it's used inside noinstr
>sections.
What completely broken compiler uninlined that single-instruction func
On Sun, Aug 30, 2020 at 8:37 AM Andy Lutomirski wrote:
>
> There's no such thing as "just" using an IST. Using IST opens a huge
> can of works due to its recursion issues.
I absolutely despise all the x86 "indirect system structures". They
are horrible garbage. IST is only yet another example of
On Sat, Aug 29, 2020 at 1:40 PM Guenter Roeck wrote:
>
> Except for
>
> CHECK: spaces preferred around that '+' (ctx:VxV)
> #29: FILE: drivers/dma/fsldma.h:223:
> + u32 val_lo = in_be32((u32 __iomem *)addr+1);
Added spaces.
> I don't see anything wrong with it either, so
>
> Reviewed-by: G
On Sat, Aug 29, 2020 at 11:36 AM Gabriel C wrote:
>
> > This kinda looks like the sqsize regression we had in earlier 5.9-rc,
> > but that should have been fixed in -rc2 with
>
> git tag --contains 7442ddcedc344b6fa073692f165dffdd1889e780
> returns nothing, that commit only exits in master, so pro
Just adding Christoph to the participants list, since at a guess it's
due to his changes whether they came from the nvme side or the dma
side..
Christoph?
Linus
On Sat, Aug 29, 2020 at 10:06 AM Daniel Exner wrote:
>
> Hi,
>
> (please keep me in the loop, as I'm currently not s
On Sat, Aug 29, 2020 at 5:46 AM Luc Van Oostenryck
wrote:
>
> But the pointer is already 32-bit, so simply cast the pointer to u32.
Yeah, that code was completely pointless. If the pointer had actually
been 64-bit, the old code would have warned too.
The odd thing is that the fsl_iowrite64() fun
On Thu, Aug 27, 2020 at 12:28 PM Kees Cook wrote:
>
> The common raw pattern for callbacks is:
>
> void callback(struct callback_handle *inner)
> {
> struct outer *instance;
> ...
> instance = container_of(inner, struct outer, member_name_of_inner);
>
> There's so much redu
On Thu, Aug 27, 2020 at 12:12 PM Arnd Bergmann wrote:
>
> Ah right, that explains why I never saw the warning in my randconfig
> build tests, I run those with COMPILE_TEST force-enabled.
.. but your clang test did enable this?
.. never mind, I have clang locally anyway, and while I usually don't
On Thu, Aug 27, 2020 at 11:42 AM Kees Cook wrote:
>
> Do you mean you checked both gcc and clang and it was only a problem with gcc?
I didn't check with clang, but Arnd claimed it was fine.
> (If so, I can tweak the "depends" below...)
Ugh.
Instead of making the Makefile even uglier, why don't
On Thu, Aug 27, 2020 at 11:40 AM Linus Torvalds
wrote:
>
> On Thu, Aug 27, 2020 at 11:32 AM James Bottomley
> wrote:
> >
> >
> > The tasklet rework people don't want to use container_of, which was our
> > first suggestion, because it produces lines which ar
On Thu, Aug 27, 2020 at 11:32 AM James Bottomley
wrote:
>
>
> The tasklet rework people don't want to use container_of, which was our
> first suggestion, because it produces lines which are "too long".
WTF?
Next somebody will decide that our list handling macros don't match
their mood, and make
On Thu, Aug 27, 2020 at 8:00 AM Christoph Hellwig wrote:
>
> SYM_FUNC_START(__get_user_2)
> add $1,%_ASM_AX
> jc bad_get_user
This no longer makes sense, and
> - mov PER_CPU_VAR(current_task), %_ASM_DX
> - cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX
> + LOAD_TASK_SI
On Thu, Aug 27, 2020 at 8:00 AM Christoph Hellwig wrote:
>
> Once we can't manipulate the address limit, we also can't test what
> happens when the manipulation is abused.
Just remove these tests entirely.
Once set_fs() doesn't exist on x86, the tests no longer make any sense
what-so-ever, becau
On Wed, Aug 26, 2020 at 6:36 PM Allen Pais wrote:
>
> Introduce container_from() as a generic helper instead of
> sub-systems defining a private from_
NAK.
This seems completely broken.
The documentation comment doesn't even match the macro, and claims
that "container" is a type.
Which it isn'
On Thu, Aug 27, 2020 at 10:34 AM Linus Torvalds
wrote:
>
> How are you guys testing? I have UBSAN and GCOV on, and don't see
> crazy frames on either i386 or x86-64.
Oh, never mind. I also have COMPILE_TEST on, so it ends up disabling
GCOV_PROFILE_ALL and UBSAN_SANITIZE_ALL.
On Thu, Aug 27, 2020 at 1:25 AM Herbert Xu wrote:
>
> Interestingly this particular file fails with those options on
> gcc 8, 9 and 10.
How are you guys testing? I have UBSAN and GCOV on, and don't see
crazy frames on either i386 or x86-64.
I see 72 bytes and 64 bytes respectively for chacha_per
On Thu, Aug 27, 2020 at 4:49 AM Jann Horn wrote:
>
> 13 files changed, 346 insertions(+), 498 deletions(-)
Me likey. I had one comment, but I don't think it really matters for
this series. So ack to all of these as far as I'm concerned.
Does anybody else see any problems?
Linus
On Thu, Aug 27, 2020 at 4:50 AM Jann Horn wrote:
>
> Properly take the mmap_lock before calling into the GUP code from
> get_dump_page(); and play nice, allowing the GUP code to drop the mmap_lock
> if it has to sleep.
Hmm. Of all the patches in the series, this simple one is now the only
one I f
On Wed, Aug 26, 2020 at 1:53 PM Harald Arnesen wrote:
>
> It's a Thinkpad T520.
Oh, so this is a 64-bit machine? Yeah, that patch to flush vmalloc
ranges won't make any difference on x86-64.
Or are you for some reason running a 32-bit kernel on that thing? Have
you tried building a 64-bit one (u
On Wed, Aug 26, 2020 at 2:30 AM Harald Arnesen wrote:
>
> Somehow related to lightdm or xfce4? However, it is a regression, since
> kernel 5.8 works.
Yeah, apparently there's something else wrong with the relocation changes too.
That said, does that patch at
https://lore.kernel.org/intel-gfx/
On Wed, Aug 26, 2020 at 6:43 AM Greg KH wrote:
>
> USB fixes for 5.9-rc3
I'm dropping this, since it seems to break things more than it fixes.
I see that the breakage is already figured out, but I'll just wait for
the next fixes pull with the fix for the problem.
Linus
On Wed, Aug 26, 2020 at 8:15 AM Jann Horn wrote:
>
> After this series has landed, we should be able to rip out
> mmget_still_valid().
I think you should just add that to the series, since it's kind of the
point of it all.
But ack on this, it now looks saner than what we used to have regardless.
On Wed, Aug 26, 2020 at 8:15 AM Jann Horn wrote:
>
> A downside of this approach is that we now need a bigger amount of kernel
> memory per userspace VMA in the normal ELF case, and that we need O(n)
> kernel memory in the FDPIC ELF case at all; but 40 bytes per VMA shouldn't
> be terribly bad.
S
On Tue, Aug 25, 2020 at 9:32 AM Harald Arnesen wrote:
>
> > For posterity, I'm told the fix is [1].
> >
> > [1]
> > https://lore.kernel.org/intel-gfx/20200821123746.16904-1-j...@8bytes.org/
>
> Doesn't fix it for me. As soon as I start XFCE, the mouse and keyboard
> freeezes. I can still ssh into
On Sun, Aug 23, 2020 at 8:42 PM Gustavo A. R. Silva
wrote:
>
> Not sure what the problem was with my pull-request for -rc2. So, I'm giving
> this a second try because I think it is worth it.
Just "a ton of lines changed across subsystems, I feel like I need to check it".
For example, you say tha
On Mon, Aug 24, 2020 at 8:38 AM Kirill Tkhai wrote:
>
> Sure, KSM does not increment page counter, when a page becomes PageKsm().
> Is patch comment about that? Even if so, I don't understand what this
> comment is about. "PageKsm() does not take additional counter" is not
> a reason the page can'
On Sun, Aug 23, 2020 at 3:27 PM Andy Lutomirski wrote:
>
> Every interrupt is going to load the CS and SS descriptor cache lines.
Yeah, but this isn't even sharing the same GDT cache line. Those two
are at least in the same cacheline, and hey, that is forced upon us by
the architecture, so we don
On Sun, Aug 23, 2020 at 3:01 PM Thomas Gleixner wrote:
>
> > And I don't think we need the GDT for anything else normally, so it's
> > not even going to be cached.
>
> Who cares, really?
>
> It's pretty irrelevant because the main source of horrors are in having
> to run through _ALL_ registered N
m: Remove set but unused variable 'oldstate'
net: fddi: skfp: cfm: Remove seemingly unused variable 'ID_sccs'
Leon Romanovsky (2):
MAINTAINERS: Update Mellanox and Cumulus Network addresses to new domain
mm/rodata_test.c: fix missing function declaration
Li Heng (1):
On Sun, Aug 23, 2020 at 1:26 AM Thomas Gleixner wrote:
>
> Remove the RDPID optimization, which is not even
> backed by numbers from the paranoid entry path instead.
Ugh, that's sad. I'd expect the LSL to be quite a bit slower than the
RDPID on raw hardware, since LSL has to go out to the GDT.
A
On Sun, Aug 23, 2020 at 1:26 AM Thomas Gleixner wrote:
>
> A single update for perf on x86 which ass support for the
> broken down bandwith counters.
Spot the freudian slip..
Linus
On Sat, Aug 22, 2020 at 4:11 PM Arvind Sankar wrote:
>
> Actually, is a memory clobber required for correctness? Memory accesses
> probably shouldn't be reordered across a CRn write. Is asm volatile
> enough to stop that or do you need a memory clobber?
You do need a memory clobber if you really
On Sat, Aug 22, 2020 at 11:17 AM Miguel Ojeda
wrote:
>
> However, the important question is whether those users/companies care
> about running the latest kernels. Many of those definitely do not want
> to touch their kernel either. For those that do, there are several
> longterms to pick from that
On Fri, Aug 21, 2020 at 9:35 PM Tetsuo Handa
wrote:
>
> Therefore, this patch tries to convert __pipe_lock() in pipe_release() to
> killable, by deferring to a workqueue context when __pipe_lock_killable()
> failed.
I don't think this is an improvement.
If somebody can delay the pipe unlock arbi
On Fri, Aug 21, 2020 at 4:50 PM Peter Xu wrote:
>
> This accounts for wp_page_reuse() case, where we reused a page for COW.
If we do this, wouldn't it make more sense to also count the COW case
to see how they match up?
Right now we count faults and major faults. So as a result you can can
calcu
On Fri, Aug 21, 2020 at 4:50 PM Peter Xu wrote:
>
> - Run a busy loop dirty program [1] that uses 6G of memory, restrict to 1G
> RAM + 5G swap (cgroup). A few hours later, all things still look good.
> Make sure to observe (still massive) correct page reuses using the new
> counter
On Fri, Aug 21, 2020 at 12:57 PM Arvind Sankar wrote:
>
> Look, four stores into memset(), yeah that's a bit weird. I didn't think
> you meant "four" literally. But in any case, that has nothing to do with
> the topic at hand. It would be just as bad if it was a 16-byte structure
> being initializ
On Fri, Aug 21, 2020 at 12:31 PM Peter Xu wrote:
>
> However, do we really want to revert the whole logic of
> 52d1e606ee73? Asking because it still seems to be an improvement to me (after
> all we'll need to look after KSM pages here). So it seems still good to keep.
Does anybody have numbers
On Fri, Aug 21, 2020 at 11:26 AM Palmer Dabbelt wrote:
>
> * The CLINT driver has been split in two: one to handle the M-mode CLINT
> (memory mapped and used on NOMMU systems) and one to handle the S-mode CLINT
> (via SBI).
This looks more like development than fixes.
I guess I don't care de
On Fri, Aug 21, 2020 at 12:15 PM Arvind Sankar wrote:
>
> How are you testing it?
>
> https://godbolt.org/z/eahdGn
Ugh. I tested the reverse thing - that the builtin is still available
for manual use despite the -fno-builtin.
Because I - stupidly - assumed that fno-builtin would do *something*.
On Fri, Aug 21, 2020 at 5:38 AM Joerg Roedel wrote:
>
> From: Joerg Roedel
>
> The __apply_to_page_range() function is also used to change and/or
> allocate page-table pages in the vmalloc area of the address space.
> Make sure these changes get synchronized to other page-tables in the
> system b
On Fri, Aug 21, 2020 at 12:05 PM Linus Torvalds
wrote:
>
> Well, the fix is simple, although I don't love the magic PageKsm
> semantics that hide it from the page count.
>
> But since (a) a Ksm page is presumably normally shared (ie things like
> all zeroes) and (b) copyin
On Fri, Aug 21, 2020 at 11:23 AM Linus Torvalds
wrote:
>
> But the PageKsm() page_count() issue I didn't even realize. That worries me.
Well, the fix is simple, although I don't love the magic PageKsm
semantics that hide it from the page count.
But since (a) a Ksm page is pre
On Fri, Aug 21, 2020 at 11:08 AM Peter Xu wrote:
>
> IIUC, Jan wanted to point out the fact that KSM didn't increase page count for
> stable pages (reasons are above get_ksm_page()).
Ouch.
> Do we still at least need to check the swap count if PageSwapCache(page)?
No. Because a PageSwapCache()
On Fri, Aug 21, 2020 at 10:54 AM Linus Torvalds
wrote:
>
> On Fri, Aug 21, 2020 at 10:29 AM Arvind Sankar wrote:
> >
> > This is why I'm saying clang's no-builtin-foo option is useful for
> > embedded: it doesn't prevent the programmer using __builtin_foo(
On Fri, Aug 21, 2020 at 10:29 AM Arvind Sankar wrote:
>
> The no-builtin- options _don't_ disable
> __builtin_ functions. They remove the default definition of foo() as
> __builtin_foo().
Oh, ok, then it's fine.
> Take the problem that instigated this thread. __builtin_stpcpy() doesn't
> work in
On Fri, Aug 21, 2020 at 8:48 AM Jan Kara wrote:
>
> I was more concerned about the case where you decide to writeably map (i.e.
> wp_page_reuse() path) a PageKsm() page.
Yeah, so I think what I do is stricter than what we used to do - any
KSM page will never be re-used, simply because the KSM par
On Fri, Aug 21, 2020 at 1:50 AM Chris Wilson wrote:
>
> Since synchronising the PTE after assignment is a manual step, use the
> newly exported interface to flush the PTE after assigning via
> alloc_vm_area().
This commit message doesn't make much sense to me.
Are you talking about synchronizing
On Fri, Aug 21, 2020 at 3:13 AM Jan Kara wrote:
>
> > + if (page_mapcount(page) != 1 && page_count(page) != 1) {
>
> So this condition looks strange to me... Did you mean:
>
> if (page_mapcount(page) != 1 || page_count(page) != 1)
Duh. Yes.
> > - if (PageK
On Thu, Aug 20, 2020 at 10:56 AM Arvind Sankar wrote:
>
> Clang's interpretation is more useful for embedded, since you can use
> -fno-builtin-foo and avoid calling __builtin_foo directly, and be
> guaranteed that there will be no calls to foo that you didn't write
> explicitly (outside of memcpy/
o the page
should always break cow towards the writer if there are any GUP users
around (put another way: away from the GUP).
However, to make the test meaningful, it really should do some swap testing too.
Linus
From f41082844ea82ad1278e167fe6e973fa4efc974a Mon Sep 17 00:00:00 2001
From:
On Thu, Aug 20, 2020 at 10:48 AM Joe Perches wrote:
>
> Maybe something like this would be reasonable:
Yes. At this point this improves the code, rather than making it less legible.
Linus
On Thu, Aug 20, 2020 at 2:23 AM Pavel Machek wrote:
>
> Yes, it seems they make things work. (Chris asked for new patch to be
> tested, so I am switching to his kernel, but it survived longer than
> it usually does.)
Ok, so at worst we know how to solve it, at best the reverts won't be
needed bec
On Wed, Aug 19, 2020 at 4:26 PM John Ogness wrote:
>
> Use the new pr_cont_t mechanism.
This looks actively much worse than the old code.
Don't do this.
Just make pr_cont() do what it used to do.
Linus
On Wed, Aug 19, 2020 at 12:41 PM wrote:
>
> I'm not sure I get the "expensive irq_work queues" argument, I fully
> agree with you that adding the atomic op is fairly crap.
There's an atomic op on the actual runing side too, because of the
whole IRQ_WORK_PENDING thing.
So you get that double hit.
On Wed, Aug 19, 2020 at 12:22 AM wrote:
>
> That is, the external serialization comes from the non-atomic
> test-and-set they both have. This works nicely when there is external
> state that already serializes things, but totally comes apart (and
> causes trivial list corruption) when you get it w
On Wed, Aug 19, 2020 at 6:25 AM Eric W. Biederman wrote:
>
> So I sat down and played with it and here is what I wound up with is:
>
> __fcheck_files -> files_lookup_fd_raw
> fcheck_files -> files_lookup_fd_locked
> fcheck_files -> files_lookup_fd_rcu
> fcheck -> lookup_fd_rcu
> ...
>
On Wed, Aug 19, 2020 at 2:44 AM Andy Shevchenko
wrote:
>
> Maybe silly idea, but would it make sense to enable -Werror for default
> warning
> level, let's say W=0, at some point?
I'd love to, and would have done that a long time ago, but we just
haven't been able to depend on the compilers not
On Wed, Aug 19, 2020 at 11:14 AM Kees Cook wrote:
>
> Did anyone pick this up? (Ingo can you snag it, or maybe akpm who took
> the LZ4-specific patch already?) This looks sane to me and provides some
> surprising performance benefits. :)
I'll take this and Arvind's freestanding patch too.
On Tue, Aug 18, 2020 at 8:04 PM Arvind Sankar wrote:
>
> On Tue, Aug 18, 2020 at 05:44:03PM -0700, Linus Torvalds wrote:
> > Using -fno-tree-loop-distribute-patterns seems to really be a bit too
> > incestuous with internal compiler knowledge.
>
> Fair enough
On Tue, Aug 18, 2020 at 6:13 PM Dave Airlie wrote:
>
> I think there's been some discussion about reverting that change for
> other reasons, but it's quite likely the culprit.
Hmm. It reverts cleanly, but the end result doesn't work, because of
other changes.
Reverting all of
763fedd6a216 ("
On Tue, Aug 18, 2020 at 4:43 PM Arvind Sankar wrote:
>
> This by itself is insufficient for gcc if the optimization was
> explicitly enabled by CFLAGS, so also add a flag to explicitly disable
> it.
Using -fno-tree-loop-distribute-patterns seems to really be a bit too
incestuous with internal com
Ping on this?
The code disassembles to
24: 8b 85 d0 fd ff ffmov-0x230(%ebp),%eax
2a:* c7 03 01 00 40 10movl $0x1041,(%ebx) <-- trapping instruction
30: 89 43 04 mov%eax,0x4(%ebx)
33: 8b 85 b4 fd ff ffmov-0x24c(%ebp),%eax
39: 89 43 08
On Tue, Aug 18, 2020 at 1:18 PM Miklos Szeredi wrote:
>
> So why mix a binary structure into it? Would it not make more sense
> to make it text only?
.. because for basic and standard stuff, the binary structure just
makes sense and is easier for everybody.
When I want to get the size of a file
On Tue, Aug 18, 2020 at 12:03 PM H. Peter Anvin wrote:
>
> I'm not saying "change the semantics", nor am I saying that playing
> whack-a-mole *for a limited time* is unreasonable. But I would like to go back
> to the compiler authors and get them to implement such a #pragma: "this
> freestanding i
On Mon, Aug 17, 2020 at 2:04 PM Yang Shi wrote:
>
> We could just skip the spurious TLB flush to mitigate the regression.
Ok, this patch I will apply.
I still hope that arm64 fixes (maybe already fixed) their spurious TLB
function, and I think we should rename it to make sure everybody
understan
801 - 900 of 9597 matches
Mail list logo
