Re: [PATCH v3.4] capabilities: require CAP_SETFCAP to map uid 0

2021-04-20 Thread Linus Torvalds
On Tue, Apr 20, 2021 at 9:47 AM Christian Brauner wrote: > > If there's no objections then Linus can probably just pick up the single > patch here directly: I'm ok with that assuming I don't hear any last-minute concerns.. I'll plan on appling it later today, so anybody with concerns please

Re: [patch 11/12] gcov: clang: fix clang-11+ build

2021-04-19 Thread Linus Torvalds
On Mon, Apr 19, 2021 at 2:37 PM Nathan Chancellor wrote: > > This should not have been merged into mainline by itself. It was a fix > for "gcov: use kvmalloc()", which is still in -mm/-next. Merging it > alone has now broken the build: > >

Re: [PATCH 00/13] [RFC] Rust support

2021-04-19 Thread Linus Torvalds
On Mon, Apr 19, 2021 at 11:38 AM Paolo Bonzini wrote: > > It changes it for the worse, in that access to fields that are shared > across threads *must* either use atomic types Well, we won't be using those broken types in the core kernel, so that would all be entirely on the Rust side. And I

Re: [PATCH 00/13] [RFC] Rust support

2021-04-19 Thread Linus Torvalds
On Mon, Apr 19, 2021 at 2:36 AM Peter Zijlstra wrote: > > I also don't see how this is better than seq_cst. > > But yes, not broken, but also very much not optimal. I continue to feel like kernel people should just entirely ignore the C++ memory ordering standard. It's inferior to what we

Linux 5.12-rc8

2021-04-18 Thread Linus Torvalds
n open function MAINTAINERS: update my email Linus Torvalds (2): readdir: make sure to verify directory entry for legacy interfaces too Linux 5.12-rc8 Luke D Jones (1): HID: asus: Add support for 2021 ASUS N-Key keyboard Lv Yunlong (1): dmaengine: Fix a double free in

Re: [GIT PULL] Re: ARM SoC fixes for v5.12, part 2

2021-04-18 Thread Linus Torvalds
On Sun, Apr 18, 2021 at 12:24 PM Arnd Bergmann wrote: > > I forgot to add the '[GIT PULL]' in the subject line, replying to myself > here to ensure it hits the right email folder. Well, the reply hit _my_ search criterion, but the pr-tracker-bot is a bit more picky. As a result, I don't think

Re: [PATCH] x86/uaccess: small optimization in unsafe_copy_to_user()

2021-04-17 Thread Linus Torvalds
On Sat, Apr 17, 2021 at 1:35 PM Al Viro wrote: > > No, wait - we have non-NULL buf->prev_reclen, so we'll hit > with buf->error completely ignored. Nevermind. Yeah, I'm pretty sure I even tested that -EINTR case at one point. Of course, it could easily have gotten broken again, so that's not a

Re: [PATCH] x86/uaccess: small optimization in unsafe_copy_to_user()

2021-04-17 Thread Linus Torvalds
On Sat, Apr 17, 2021 at 12:44 PM Eric Dumazet wrote: > > I thought put_cmsg() callers were from the kernel, with no possibility > for user to abuse this interface trying to push GB of data. My point is that "I thought" is not good enough for the unsafe interfaces. It needs to be "I can see that

Re: [PATCH] x86/uaccess: small optimization in unsafe_copy_to_user()

2021-04-17 Thread Linus Torvalds
On Sat, Apr 17, 2021 at 9:08 AM Linus Torvalds wrote: > > Side note: I'm, looking at the readdir cases that I wrote, and I have > to just say that is broken too. So "stones and glass houses" etc, and > I'll have to fix that too. In particular, the very very old OLD_READD

Re: [PATCH] x86/uaccess: small optimization in unsafe_copy_to_user()

2021-04-17 Thread Linus Torvalds
On Sat, Apr 17, 2021 at 9:03 AM Linus Torvalds wrote: > > Really. The "unsafe" user accesses are named that way very explicitly, > and for a very very good reason: the safety needs to be guaranteed and > obvious within the context of those accesses. Not within some "

Re: [PATCH] x86/uaccess: small optimization in unsafe_copy_to_user()

2021-04-17 Thread Linus Torvalds
On Fri, Apr 16, 2021 at 12:24 PM Eric Dumazet wrote: > > From: Eric Dumazet > > We have to loop only to copy u64 values. > After this first loop, we copy at most one u32, one u16 and one byte. As Al mentioned, at least in trivial cases the compiler understands that the subsequent loops can only

Re: [PATCH 04/13] Kbuild: Rust support

2021-04-16 Thread Linus Torvalds
On Fri, Apr 16, 2021 at 6:38 AM Peter Zijlstra wrote: > > AFAICT rust has try/throw/catch exception handling (like > C++/Java/others) which is typically implemented with stack unwinding of > its own. I was assuming that the kernel side would never do that. There's some kind of "catch_unwind()"

Re: [PATCH 00/13] [RFC] Rust support

2021-04-14 Thread Linus Torvalds
On Wed, Apr 14, 2021 at 1:10 PM Matthew Wilcox wrote: > > There's a philosophical point to be discussed here which you're skating > right over! Should rust-in-the-linux-kernel provide the same memory > allocation APIs as the rust-standard-library, or should it provide a Rusty > API to the

Re: [PATCH 00/13] [RFC] Rust support

2021-04-14 Thread Linus Torvalds
On Wed, Apr 14, 2021 at 11:46 AM wrote: > > Some of you have noticed the past few weeks and months that > a serious attempt to bring a second language to the kernel was > being forged. We are finally here, with an RFC that adds support > for Rust to the Linux kernel. So I replied with my

Re: [PATCH 09/13] Samples: Rust examples

2021-04-14 Thread Linus Torvalds
On Wed, Apr 14, 2021 at 11:47 AM wrote: > > From: Miguel Ojeda > > A set of Rust modules that showcase how Rust modules look like > and how to use the abstracted kernel features. Honestly, I'd like to see a real example. This is fine for testing, but I'd like to see something a bit more real,

Re: [PATCH 07/13] Rust: Kernel crate

2021-04-14 Thread Linus Torvalds
On Wed, Apr 14, 2021 at 11:47 AM wrote: > > +#[alloc_error_handler] > +fn oom(_layout: Layout) -> ! { > +panic!("Out of memory!"); > +} > + > +#[no_mangle] > +pub fn __rust_alloc_error_handler(_size: usize, _align: usize) -> ! { > +panic!("Out of memory!"); > +} Again, excuse my lack of

Re: [PATCH 05/13] Rust: Compiler builtins crate

2021-04-14 Thread Linus Torvalds
On Wed, Apr 14, 2021 at 11:46 AM wrote: > > We also need a helpers C source file to contain some forwarders > to C macros and inlined functions. For the moment, we only need it > to call the `BUG()` macro, but we will be adding more later. Not being a Rust person, I can only guess based on

Re: Linux 5.12-rc7

2021-04-12 Thread Linus Torvalds
On Sun, Apr 11, 2021 at 10:14 PM Guenter Roeck wrote: > > Qemu test results: > total: 460 pass: 459 fail: 1 > Failed tests: > sh:rts7751r2dplus_defconfig:ata:net,virtio-net:rootfs > > The failure bisects to commit 0f6925b3e8da ("virtio_net: Do not pull payload > in > skb->head").

Linux 5.12-rc7

2021-04-11 Thread Linus Torvalds
ASoC: SOF: Intel: ICL: set shutdown callback to hda_dsp_shutdown ASoC: SOF: Intel: CNL: set shutdown callback to hda_dsp_shutdown ASoC: SOF: Intel: APL: set shutdown callback to hda_dsp_shutdown Linus Torvalds (1): Linux 5.12-rc7 Loic Poulain (1): net: qrtr: Fix

Re: [PATCH] vt_ioctl: make VT_RESIZEX behave like VT_RESIZE

2021-04-11 Thread Linus Torvalds
On Sun, Apr 11, 2021 at 2:43 PM Maciej W. Rozycki wrote: > > So it does trigger with vgacon and my old server, which I have started > experimenting with and for a start I have switched to a new kernel for an > unrelated purpose (now that I have relieved it from all its usual tasks > except for

Re: [RFC][PATCH] mm: Split page_has_private() in two to better handle PG_private_2

2021-04-08 Thread Linus Torvalds
On Thu, Apr 8, 2021 at 2:15 PM David Howells wrote: > > mm: Split page_has_private() in two to better handle PG_private_2 >From a look through the patch and some (limited) thinking about it, I like the patch. I think it clarifies the two very different cases, and makes it clear that one is about

Re: 08ed4efad6: stress-ng.sigsegv.ops_per_sec -41.9% regression

2021-04-08 Thread Linus Torvalds
On Thu, Apr 8, 2021 at 1:32 AM kernel test robot wrote: > > FYI, we noticed a -41.9% regression of stress-ng.sigsegv.ops_per_sec due to > commit > 08ed4efad684 ("[PATCH v10 6/9] Reimplement RLIMIT_SIGPENDING on top of > ucounts") Ouch. I *think* this test may be testing "send so many signals

Re: [PATCH 0/5] 4.14 backports of fixes for "CoW after fork() issue"

2021-04-07 Thread Linus Torvalds
On Wed, Apr 7, 2021 at 11:47 AM Mikulas Patocka wrote: > > So, we fixed it, but we don't know why. > > Peter Xu's patchset that fixed it is here: > https://lore.kernel.org/lkml/20200821234958.7896-1-pet...@redhat.com/ Yeah, that's the part that ends up being really painful to backport (with all

Re: [PATCH 0/5] 4.14 backports of fixes for "CoW after fork() issue"

2021-04-07 Thread Linus Torvalds
On Wed, Apr 7, 2021 at 9:33 AM Suren Baghdasaryan wrote: > > Trying my hand at backporting the patchsets Peter mentioned proved > this to be far from easy with many dependencies. Let me look into > Vlastimil's suggestion to backport only 17839856fd58 and it sounds > like 5.4 already followed that

Re: [GIT PULL] parisc architecture fixes for kernel v5.12-rc7

2021-04-07 Thread Linus Torvalds
On Wed, Apr 7, 2021 at 2:09 AM Helge Deller wrote: > > http://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git > parisc-5.12-3 Not technically related to this pull (which I just did), but doing the pull did remind me that you're one of the people who don't use signed tags for

Re: [PATCH 0/5] 4.14 backports of fixes for "CoW after fork() issue"

2021-04-07 Thread Linus Torvalds
On Wed, Apr 7, 2021 at 6:22 AM Vlastimil Babka wrote: > > 1) Ignore the issue (outside of Android at least). The security model of > zygote > is unusual. Where else a parent of fork() doesn't trust the child, which is > the > same binary? Agreed. I think this is basically an android-only issue

Re: Linux 5.12-rc6

2021-04-05 Thread Linus Torvalds
On Mon, Apr 5, 2021 at 10:10 AM Guenter Roeck wrote: > > No change in test results since last week [..] Let's ping Frank for the alignment issue. If that promised patch isn't timely (and trivial), I really think that removing the alignment check is by now the way forward for that libftd

Linux 5.12-rc6

2021-04-04 Thread Linus Torvalds
extcon: Add stubs for extcon_register_notifier_all() functions Lars Povlsen (1): pinctrl: microchip-sgpio: Fix wrong register offset for IRQ trigger Linus Torvalds (1): Linux 5.12-rc6 Liu Ying (1): drm/imx: imx-ldb: Register LDB channel1 when it is the only channel to be used

Re: [PATCH] firewire: nosy: Fix a use-after-free bug in nosy_ioctl()

2021-04-03 Thread Linus Torvalds
On Fri, Apr 2, 2021 at 11:59 PM Zheyu Ma wrote: > > case NOSY_IOC_START: > + list_for_each_entry(tmp, >lynx->client_list, link) > + if (tmp == client) > + return -EINVAL; I don't think this is safe. You are doing this

Re: [GIT PULL] ftrace: Check if pages were allocated before calling free_pages()

2021-04-01 Thread Linus Torvalds
On Thu, Apr 1, 2021 at 1:07 PM Steven Rostedt wrote: > > On Wed, 31 Mar 2021 11:03:21 -0700 > Linus Torvalds wrote: > > > @@ -6231,7 +6231,8 @@ static int ftrace_process_locs(struct module *mod, > > if (!addr) > > continue; >

Re: [PATCH 0/5] 4.14 backports of fixes for "CoW after fork() issue"

2021-04-01 Thread Linus Torvalds
On Thu, Apr 1, 2021 at 11:17 AM Suren Baghdasaryan wrote: > > We received a report that the copy-on-write issue repored by Jann Horn in > https://bugs.chromium.org/p/project-zero/issues/detail?id=2045 is still > reproducible on 4.14 and 4.19 kernels (the first issue with the reproducer > coded in

Re: [PATCH 0/6] Allow signals for IO threads

2021-04-01 Thread Linus Torvalds
On Thu, Apr 1, 2021 at 9:00 AM Stefan Metzmacher wrote: > > I haven't tried it, but it seems gdb tries to use PTRACE_PEEKUSR > against the last thread tid listed under /proc//tasks/ in order to > get the architecture for the userspace application Christ, what an odd hack. Why wouldn't it just do

Re: [PATCH 0/6] Allow signals for IO threads

2021-04-01 Thread Linus Torvalds
On Thu, Apr 1, 2021 at 7:58 AM Stefan Metzmacher wrote: > > > > > Ok, the following makes gdb happy again: > > > > --- a/arch/x86/kernel/process.c > > +++ b/arch/x86/kernel/process.c > > @@ -163,6 +163,8 @@ int copy_thread(unsigned long clone_flags, unsigned > > long sp, unsigned long arg, > >

Re: [GIT PULL] ftrace: Check if pages were allocated before calling free_pages()

2021-03-31 Thread Linus Torvalds
On Wed, Mar 31, 2021 at 11:51 AM Steven Rostedt wrote: > > Your fls() trick might work too (have to gawk at it more). And I should fix > the comments. But any work on that would be for the next merge window, and > doesn't affect that this patch fixes a possible issue. See my second email. It

Re: [GIT PULL] ftrace: Check if pages were allocated before calling free_pages()

2021-03-31 Thread Linus Torvalds
On Wed, Mar 31, 2021 at 10:45 AM Linus Torvalds wrote: > > Honestly, looking at that code, every single use of > "get_count_order()" seems really really confusing. Side note: I've pulled your fix, but I really think that the bug is almost entirely due to the code being so op

Re: [GIT PULL] ftrace: Check if pages were allocated before calling free_pages()

2021-03-31 Thread Linus Torvalds
On Wed, Mar 31, 2021 at 6:27 AM Steven Rostedt wrote: > > order = get_count_order(pg->size / ENTRIES_PER_PAGE); > - free_pages((unsigned long)pg->records, order); > + if (order >= 0) > + free_pages((unsigned long)pg->records,

Re: exec error: BUG: Bad rss-counter

2021-03-30 Thread Linus Torvalds
On Tue, Mar 30, 2021 at 9:36 AM Ilya Lipnitskiy wrote: > > Sorry, I could have done better linking it to this thread - I actually > did submit it recently - please see > https://lkml.kernel.org/r/20210330044208.8305-1-ilya.lipnits...@gmail.com Oh, ok, that looks fine. Thanks, applied,

Re: exec error: BUG: Bad rss-counter

2021-03-30 Thread Linus Torvalds
On Mon, Mar 29, 2021 at 9:56 PM Zhou Yanjie wrote: > > On 2021/3/29 上午10:48, Ilya Lipnitskiy wrote: > > > > Try: > > diff --git a/mm/memory.c b/mm/memory.c > > index c8e357627318..1fd753245369 100644 > > --- a/mm/memory.c > > +++ b/mm/memory.c > > @@ -166,7 +166,7 @@ static int __init

Re: Linux 5.12-rc5

2021-03-29 Thread Linus Torvalds
On Sun, Mar 28, 2021 at 7:07 PM Guenter Roeck wrote: > > This is not really a new problem. I enabled devicetree unit tests > in the openrisc kernel and was rewarded with a crash. > https://lore.kernel.org/lkml/20210327224116.69309-1-li...@roeck-us.net/ > has all the glorious details. Hmm. I'm

Linux 5.12-rc5

2021-03-28 Thread Linus Torvalds
h for daemon test Li RongQing (1): igb: avoid premature Rx buffer reuse Lijun Pan (1): ibmvnic: update MAINTAINERS Linus Torvalds (1): Linux 5.12-rc5 Louis Peens (3): nfp: flower: fix unsupported pre_tunnel flows nfp: flower: add ipv6 bit to pre_tunn

Re: [PATCH 0/2] x86: Remove ideal_nops[]

2021-03-27 Thread Linus Torvalds
On Sat, Mar 27, 2021 at 5:08 AM Sedat Dilek wrote: > > debian-5.10.19 as host-kernel: > 11655.755564957 seconds time elapsed > > dileks-5.12-rc3 plus x86-nops as host-kernel: > 11941.439350080 seconds time elapsed That's 2.5% - a huge difference. Particularly since kernel build times shouldn't

Re: [PATCH 0/2] Don't show PF_IO_WORKER in /proc//task/

2021-03-25 Thread Linus Torvalds
On Thu, Mar 25, 2021 at 2:44 PM Jens Axboe wrote: > > In the spirit of "let's just try it", I ran with the below patch. With > that, I can gdb attach just fine to a test case that creates an io_uring > and a regular thread with pthread_create(). The regular thread uses > the ring, so you end up

Re: [PATCH 0/2] Don't show PF_IO_WORKER in /proc//task/

2021-03-25 Thread Linus Torvalds
On Thu, Mar 25, 2021 at 12:42 PM Linus Torvalds wrote: > > On Thu, Mar 25, 2021 at 12:38 PM Linus Torvalds > wrote: > > > > I don't know what the gdb logic is, but maybe there's some other > > option that makes gdb not react to them? > > .. maybe we could hav

Re: [PATCH 0/2] Don't show PF_IO_WORKER in /proc//task/

2021-03-25 Thread Linus Torvalds
On Thu, Mar 25, 2021 at 12:38 PM Linus Torvalds wrote: > > I don't know what the gdb logic is, but maybe there's some other > option that makes gdb not react to them? .. maybe we could have a different name for them under the task/ subdirectory, for example (not just the pid)?

Re: [PATCH 0/2] Don't show PF_IO_WORKER in /proc//task/

2021-03-25 Thread Linus Torvalds
On Thu, Mar 25, 2021 at 12:34 PM Eric W. Biederman wrote: > > A quick skim shows that these threads are not showing up anywhere in > proc which appears to be a problem, as it hides them from top. > > Sysadmins need the ability to dig into a system and find out where all > their cpu usage or io's

Re: [PATCH v1 1/1] mfd: intel_quark_i2c_gpio: Don't play dirty trick with const

2021-03-25 Thread Linus Torvalds
On Thu, Mar 25, 2021 at 12:23 PM Andy Shevchenko wrote: > > Replace cell parameter by bar and assign local pointer res to the > respective non-const place holder in the intel_quark_i2c_setup() > and intel_quark_gpio_setup(). Thanks. I assume/hope this got tested on hardware too? It looks

Re: [GIT PULL] MFD fixes for v5.12

2021-03-25 Thread Linus Torvalds
On Thu, Mar 25, 2021 at 9:34 AM Lee Jones wrote: > >- Unconstify editable placeholder structures Hmm. This does show a real issue with that gpio driver. It does garbage things: static int intel_quark_gpio_setup(struct pci_dev *pdev, struct mfd_cell *cell) { struct

Re: [GIT PULL] cachefiles, afs: mm wait fixes

2021-03-24 Thread Linus Torvalds
On Wed, Mar 24, 2021 at 1:21 AM David Howells wrote: > > - I've included these together since they are an excerpt from a patch >series of Willy's, but I can send the first separately from the other >two if you'd prefer since they touch different modules. It's small enough and related

Re: RFC: create mailing list "linux-issues" focussed on issues/bugs and regressions

2021-03-22 Thread Linus Torvalds
On Mon, Mar 22, 2021 at 8:18 AM Thorsten Leemhuis wrote: > > I even requested a > "linux-regressi...@vger.kernel.org" a while later, but didn't hear > anything back; and, sadly, about the same time I started having trouble > finding spare time for working on regression tracking. :-/

Re: Linux 5.12-rc4

2021-03-22 Thread Linus Torvalds
On Mon, Mar 22, 2021 at 11:23 AM Guenter Roeck wrote: > > Build results: > total: 151 pass: 151 fail: 0 > Qemu test results: > total: 437 pass: 437 fail: 0 Thanks, Linus

Linux 5.12-rc4

2021-03-21 Thread Linus Torvalds
an Liang (2): perf/x86/intel: Fix a crash caused by zero PEBS status perf/x86/intel: Fix unchecked MSR access error caused by VLBR_EVENT Kefeng Wang (1): riscv: Correct SPARSEMEM configuration Laurent Vivier (1): vhost: Fix vhost_vq_reset() Leon Romanovsky (1): module: r

Re: [GIT PULL] ext4 fixes for v5.12

2021-03-21 Thread Linus Torvalds
On Sun, Mar 21, 2021 at 11:31 AM Theodore Ts'o wrote: > > zhangyi (F) (3): > ext4: find old entry again if failed to rename whiteout > ext4: do not iput inode under running transaction in ext4_rename() > ext4: do not try to set xattr into ea_inode if value is empty Side note:

Re: linux-next: manual merge of the net tree with Linus' tree

2021-03-20 Thread Linus Torvalds
On Sat, Mar 20, 2021 at 12:28 PM Marc Kleine-Budde wrote: > > Good idea. I'll send a pull request to David and Jakub. I don't think the revert is necessary. The conflict is so trivial that it doesn't really matter. Conflicts like this that are local and obvious aren't really problematic. Any

Re: [PATCHSET 0/2] PF_IO_WORKER signal tweaks

2021-03-20 Thread Linus Torvalds
On Sat, Mar 20, 2021 at 10:51 AM Linus Torvalds wrote: > > Alternatively, make it not use > CLONE_SIGHAND|CLONE_THREAD at all, but that would make it > unnecessarily allocate its own signal state, so that's "cleaner" but > not great either. Thinking some more about that

Re: [PATCH 1/2] signal: don't allow sending any signals to PF_IO_WORKER threads

2021-03-20 Thread Linus Torvalds
On Sat, Mar 20, 2021 at 9:19 AM Eric W. Biederman wrote: > > The creds should be reasonably in-sync with the rest of the threads. It's not about credentials (despite the -EPERM). It's about the fact that kernel threads cannot handle signals, and then get caught in endless loops of "if

Re: [PATCHSET 0/2] PF_IO_WORKER signal tweaks

2021-03-20 Thread Linus Torvalds
On Sat, Mar 20, 2021 at 9:27 AM Eric W. Biederman wrote: > > That makes me uneasy. Because especially the SIGSTOP changes feels like > it is the wrong thing semantically. The group_send_sig_info change > simply feels like it is unnecessary. SIGSTOP handling is fundamentally done at signal

Re: [PATCH RFC 0/3] drivers/char: remove /dev/kmem for good

2021-03-19 Thread Linus Torvalds
On Fri, Mar 19, 2021 at 7:35 AM David Hildenbrand wrote: > > Let's start a discussion if /dev/kmem is worth keeping around and > fixing/maintaining or if we should just remove it now for good. I'll happily do this for the next merge window, but would really want distros to confirm that they

Re: [PATCH master] module: remove never implemented MODULE_SUPPORTED_DEVICE

2021-03-18 Thread Linus Torvalds
On Thu, Mar 18, 2021 at 10:49 AM Leon Romanovsky wrote: > > No, I opened patch and added the note manually, so it is definitely my VIM. > Most likely this part of my .vimrc caused it. Ok, that would do it. Yeah, whitespace is easy to "fix" at patch application time, but it really is meaningful

Re: [PATCH master] module: remove never implemented MODULE_SUPPORTED_DEVICE

2021-03-18 Thread Linus Torvalds
On Thu, Mar 18, 2021 at 12:55 AM Leon Romanovsky wrote: > > > > Also, your email seems to have swallowed spaces at the ends of lines. > > > > I can (and did) apply the patch with "--whitespace=fix", but that then > > causes git to fix some _other_ whitespace too, so the end result isn't > > quite

Re: [PATCH v2] Increase page and bit waitqueue hash size

2021-03-17 Thread Linus Torvalds
e ptl lock - under that lock). Anyway, I don't mind the "make the hash table larger" regardless of this, but I do want it to be documented a bit more. Linus From efdc3feadb493ae7f24c573c8b863d7a51117391 Mon Sep 17 00:00:00 2001 From: Linus Torvalds Date: Tue, 13 Oct 2020

Re: [PATCH master] module: remove never implemented MODULE_SUPPORTED_DEVICE

2021-03-17 Thread Linus Torvalds
On Wed, Mar 17, 2021 at 3:46 AM Leon Romanovsky wrote: > > I'm sending this patch to you directly because it is much saner to > apply it in one place instead of multiple patches saga that will > span for at least two cycles if per-maintainer path will be taken. > > It applies cleanly on v5.12-rc2

Re: [PATCH v2] Increase page and bit waitqueue hash size

2021-03-17 Thread Linus Torvalds
On Wed, Mar 17, 2021 at 3:44 AM Nicholas Piggin wrote: > > Argh, because I didn't test small. Sorry I had the BASE_SMALL setting in > another patch and thought it would be a good idea to mash them together. > In hindsight probably not even if it did build. I was going to complain about that code

Re: [PATCH v4 02/28] mm: Add an unlock function for PG_private_2/PG_fscache

2021-03-16 Thread Linus Torvalds
On Tue, Mar 16, 2021 at 7:12 PM Josef Bacik wrote: > > > Yeah it's just a flag, we use it to tell that the page is part of a range that > has been allocated for IO. The lifetime of the page is independent of the > page, > but is generally either dirty or under writeback, so either it goes

Re: [PATCH v4 02/28] mm: Add an unlock function for PG_private_2/PG_fscache

2021-03-16 Thread Linus Torvalds
[ Adding btrfs people explicitly, maybe they see this on the fs-devel list, but maybe they don't react .. ] On Tue, Mar 16, 2021 at 12:07 PM Matthew Wilcox wrote: > > This isn't a problem with this patch per se, but I'm concerned about > private2 and expected page refcounts. Ugh. You are very

Re: [PATCH v8 3/8] Use atomic_t for ucounts reference counting

2021-03-16 Thread Linus Torvalds
On Tue, Mar 16, 2021 at 11:49 AM Kees Cook wrote: > > Right -- I saw that when digging through the thread. I'm honestly > curious, though, why did the 0-day bot find a boot crash? (I can't > imagine ucounts wrapped in 0.4 seconds.) So it looked like an > increment-from-zero case, which seems like

Re: [kbuild-all] Re: [PATCH] gcov: fail build on gcov_info size mismatch

2021-03-15 Thread Linus Torvalds
On Mon, Mar 15, 2021 at 4:10 PM Herbert Xu wrote: > > The quoting on "!" doesn't help I'm afraid. Even though [ is a > built-in it is not allowed to look at the quoting because it's > supposed to behave in the same way whether you get the builtin [ > or the one from /usr/bin. > > So when it gets

Re: [PATCH v8 3/8] Use atomic_t for ucounts reference counting

2021-03-15 Thread Linus Torvalds
On Mon, Mar 15, 2021 at 3:03 PM Kees Cook wrote: > > On Wed, Mar 10, 2021 at 01:01:28PM +0100, Alexey Gladkov wrote: > > The current implementation of the ucounts reference counter requires the > > use of spin_lock. We're going to use get_ucounts() in more performance > > critical areas like a

Re: [kbuild-all] Re: [PATCH] gcov: fail build on gcov_info size mismatch

2021-03-15 Thread Linus Torvalds
On Mon, Mar 15, 2021 at 1:32 PM Jamie Heilman wrote: > > fwiw, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850202 Yup, that seems to be the exact same thing from 4 years ago. But it looks like nothing ever came out of it. It probably stayed within the Debian bugzilla, and didn't go to

Re: [mm] f3344adf38: fxmark.hdd_btrfs_DWAL_63_bufferedio.works/sec -52.4% regression

2021-03-15 Thread Linus Torvalds
On Sun, Mar 14, 2021 at 11:30 PM kernel test robot wrote: > > FYI, we noticed a -52.4% regression of > fxmark.hdd_btrfs_DWAL_63_bufferedio.works/sec That's quite the huge regression. But: > due to commit: f3344adf38bd ("mm: memcontrol: optimize per-lruvec stats > counter memory usage")

Re: [kbuild-all] Re: [PATCH] gcov: fail build on gcov_info size mismatch

2021-03-15 Thread Linus Torvalds
On Sun, Mar 14, 2021 at 7:32 PM Rong Chen wrote: > > It can be reproduced with '-a' option in dash: Oh, ok. That kind of explains it. 'dash' is trash. Please somebody make a bug report. > $ a="!" > $ [ "$a" = ".size" ] > $ [ "$a" = ".size" -a "$b" = ".LPBX0," ] > sh: 2: [:

Re: [GIT pull] locking/urgent for v5.12-rc3

2021-03-15 Thread Linus Torvalds
On Mon, Mar 15, 2021 at 10:03 AM Josh Poimboeuf wrote: > > Though instead of using objtool, it can be done in the module linker > script: This is obviously the way to go, but it raises another question: do we guarantee that functions are aligned? We actually have a couple of 32-bit x86

Re: Linux 5.12-rc3

2021-03-14 Thread Linus Torvalds
On Sun, Mar 14, 2021 at 3:00 PM Linus Torvalds wrote: > > So rc3 is pretty big this time around, [..] Oh, and I had planned to mention the historical note that goes along with today's date, but then entirely forgot. Some people think today is π-day because of odd US date formatting. But

Linux 5.12-rc3

2021-03-14 Thread Linus Torvalds
lemen Košir (1): netfilter: conntrack: Remove a double space in a log message Kun-Chuan Hsieh (1): tools/resolve_btfids: Fix build error with older host toolchains Lee Gibson (2): staging: rtl8192e: Fix possible buffer overflow in _rtl92e_wx_set_scan staging: rtl8712: Fix poss

Re: [PATCH] prctl: fix PR_SET_MM_AUXV kernel stack leak

2021-03-14 Thread Linus Torvalds
Applied directly, since I'm just about to tag rc3 and was just looking that there were no last-minute pull requests. Andrew, no need to pick it up into your queue. Side note: I think we should return -EINVAL more aggressively: right now we fill up potentially all of user_auxv[] and return

Re: [GIT pull] locking/urgent for v5.12-rc3

2021-03-14 Thread Linus Torvalds
On Sun, Mar 14, 2021 at 8:40 AM Thomas Gleixner wrote: > > - A fix for the static_call mechanism so it handles unaligned >addresses correctly. I'm not disputing the fix in any way, but why weren't the relocation info and function start addresses mutually aligned? Are we perhaps missing

Re: [GIT PULL] userns regression fix for v5.12-rc3

2021-03-12 Thread Linus Torvalds
On Fri, Mar 12, 2021 at 1:34 PM Eric W. Biederman wrote: > > Please pull the for-v5.12-rc3 branch from the git tree. > > Removing the ambiguity broke userspace so please revert the change: > It turns out that there are in fact userspace implementations that > care and this recent change caused a

Re: [PATCH 1/2] x86: Remove dynamic NOP selection

2021-03-12 Thread Linus Torvalds
On Fri, Mar 12, 2021 at 4:09 AM Peter Zijlstra wrote: > > Note that this also made all NOPs single instructions and removed the > special atomic nop. Ack. Good riddance. Linus

Re: [kbuild-all] Re: [PATCH] gcov: fail build on gcov_info size mismatch

2021-03-12 Thread Linus Torvalds
On Thu, Mar 11, 2021 at 7:50 PM Rong Chen wrote: > > > The issue is from a=!, and [ "$a $b" = ".size .LPBX0," ] can avoid the > error. > > + [ ! = .size -a ABI = .LPBX0, ] > ./kernel/gcov/geninfosize.sh: 13: [: =: unexpected operator But that's not what the patch did. The patch used quotes

Re: [PATCH] gcov: fail build on gcov_info size mismatch

2021-03-11 Thread Linus Torvalds
On Thu, Mar 11, 2021 at 11:34 AM kernel test robot wrote: > > >> kernel/gcov/geninfosize.sh: 13: [: =: unexpected operator Wth? I'm not seeing how this can fail on nds32 - doesn't look like a bashism, everything is properly quoted, etc etc. Plus it's a cross-compile anyway, so the shell in

Re: [PATCH] gcov: fail build on gcov_info size mismatch

2021-03-11 Thread Linus Torvalds
On Thu, Mar 11, 2021 at 5:07 AM Peter Oberparleiter wrote: > > This patch adds a compile-time check to ensure that the kernel's version > of struct gcov_info has the same length as the one used by GCC as > determined by looking at GCC's assembler output. So I don't think this is a bad idea, but

Re: [PATCH v2 1/2] init/initramfs.c: allow asynchronous unpacking

2021-03-11 Thread Linus Torvalds
On Wed, Mar 10, 2021 at 5:45 PM Rasmus Villemoes wrote: > > Hm, gcc does elide the test of the return value, but jumps back to a > place where it always loads state from its memory location and does the > whole switch(). To get it to jump directly to the code implementing the > various do_*

Re: [PATCH v8 3/8] Use atomic_t for ucounts reference counting

2021-03-10 Thread Linus Torvalds
On Wed, Mar 10, 2021 at 4:01 AM Alexey Gladkov wrote: > > > +/* 127: arbitrary random number, small enough to assemble well */ > +#define refcount_zero_or_close_to_overflow(ucounts) \ > + ((unsigned int) atomic_read(>count) + 127u <= 127u) > + > +struct ucounts *get_ucounts(struct ucounts

Re: [PATCH 4.14 27/50] mm, slub: consider rest of partial list if acquire_slab() fails

2021-03-10 Thread Linus Torvalds
Just a note to the stable tree: this commit has been reverted upstream, because it causes a huge performance drop (admittedly on a load and setup that may not be all that relevant to most people). It was applied to 4.4, 4.9 and 4.12, because the commit it was marked as "fixing" is from 2012, but

Re: [mm, slub] 8ff60eb052: stress-ng.rawpkt.ops_per_sec -47.9% regression

2021-03-10 Thread Linus Torvalds
On Tue, Mar 9, 2021 at 10:59 PM Christoph Lameter wrote: > > > > > it really looks like this might well have been very intentional > > indeed. Or at least very beneficial for _some_ loads. > > Yes the thought was that adding an additional page when contention is > there on the page objects will

Re: [GIT] SPARC

2021-03-09 Thread Linus Torvalds
On Tue, Mar 9, 2021 at 5:15 PM David Miller wrote: > > Somehow you pull didn't get commits: Look closer at the pull date. That was before you had updated your branch. I did a second pull just moments ago, I'll push it out (along with the networking one), after all my tests have passed.

Re: [mm, slub] 8ff60eb052: stress-ng.rawpkt.ops_per_sec -47.9% regression

2021-03-09 Thread Linus Torvalds
Jann, it looks like that change of yours made a rather big negative impact on this load. On Sun, Feb 28, 2021 at 11:49 PM kernel test robot wrote: > > FYI, we noticed a -47.9% regression of stress-ng.rawpkt.ops_per_sec due to > commit: Looking at the profile, nothing really obvious stands

Re: [PATCH v2 1/2] init/initramfs.c: allow asynchronous unpacking

2021-03-09 Thread Linus Torvalds
On Tue, Mar 9, 2021 at 1:17 PM Rasmus Villemoes wrote: > > So add an initramfs_async= kernel parameter, allowing the main init > process to proceed to handling device_initcall()s without waiting for > populate_rootfs() to finish. Oh, and a completely unrelated second comment about this: some of

Re: [PATCH v2 1/2] init/initramfs.c: allow asynchronous unpacking

2021-03-09 Thread Linus Torvalds
On Tue, Mar 9, 2021 at 1:17 PM Rasmus Villemoes wrote: > > So add an initramfs_async= kernel parameter, allowing the main init > process to proceed to handling device_initcall()s without waiting for > populate_rootfs() to finish. I like this smaller second version of the patch, but am wondering

Re: [GIT PULL] gpio: fixes for v5.12-rc3

2021-03-09 Thread Linus Torvalds
On Tue, Mar 9, 2021 at 7:43 AM Bartosz Golaszewski wrote: > > I realized only after I sent out this PR that I had rebased the branch > on top of v5.12-rc2 (because of the v5.12-rc1 situation) without > --rebase-merges and this caused git to drop the merge commit for > Andy's pull-request. Please

Re: [PATCH v2 4/4] kbuild: remove guarding from TRIM_UNUSED_KSYMS

2021-03-09 Thread Linus Torvalds
On Tue, Mar 9, 2021 at 7:18 AM Masahiro Yamada wrote: > > Now that the build time cost of this option is unnoticeable level, > revert the following two: It might still be a good idea to make it depend on EXPERT. Otherwise you'll have problems with external modules.. Also, can you actually

Re: [GIT] SPARC

2021-03-09 Thread Linus Torvalds
On Tue, Mar 9, 2021 at 11:08 AM David Miller wrote: > > I'll make sure that gets into my next pull req, thanks. Note that it's obviously always easiest for me to just ignore something like sparc entirely, but on the other hand, particularly for low-volume trees it's also ok to just say "I don't

Re: [PATCH 00/11] pragma once: treewide conversion

2021-03-06 Thread Linus Torvalds
On Sat, Mar 6, 2021 at 5:07 AM Miguel Ojeda wrote: > > Concerning #pragma once: I actually would like to have a standard > #once directive if what is a "seen file" could be defined a bit more > precisely. I think it would be ok if you had something like #pragma once IDTOKEN which would

Linux 5.12-rc2

2021-03-05 Thread Linus Torvalds
x parameter error of RREG32_PCIE() in amdgpu_regs_pcie Lee Duncan (1): scsi: iscsi: Restrict sessions and handles to admin capabilities Leon Romanovsky (2): RDMA/mlx5: Set correct kernel-doc identifier RDMA/uverbs: Fix kernel-doc warning of _uverbs_alloc Linus Torvalds (1):

Re: [PATCH 00/11] pragma once: treewide conversion

2021-03-05 Thread Linus Torvalds
On Fri, Mar 5, 2021 at 1:19 AM David Laight wrote: > > The point is that you can skip the unwanted parts of > #if without having to parse the file at all. > You just need to detect the line breaks. That's not actually true AT ALL. You still need to at the very least parse the preprocessor

"struct perf_sample_data" alignment

2021-03-04 Thread Linus Torvalds
Sp there's a note about new warnings in 5.12-rc1 that I looked at, and many of the warnings made me go "Whaaa?". They were all of the type warning: 'perf_event_aux_event' uses dynamic stack allocation and then when I go look, I see nothing that looks like a dynamic stack allocation at all.

Re: [PATCH RFC] gcc-plugins: Handle GCC version mismatch for OOT modules

2021-03-04 Thread Linus Torvalds
On Thu, Mar 4, 2021 at 6:41 PM Josh Poimboeuf wrote: > > This thread is making me dizzy, but I think the patch you NAK'ed from me > was different. It just added an error on GCC mismatch with external > modules: > > >

Re: [PATCH] kbuild: rebuild GCC plugins when the compiler is upgraded

2021-03-04 Thread Linus Torvalds
On Thu, Mar 4, 2021 at 3:20 PM Kees Cook wrote: > > This seems fine to me, but I want to make sure Josh has somewhere to > actually go with this. Josh, does this get you any closer? It sounds > like the plugins need to move to another location for packaged kernels? Well, it might be worth

Re: [PATCH 5.10 000/657] 5.10.20-rc4 review

2021-03-04 Thread Linus Torvalds
On Thu, Mar 4, 2021 at 9:56 AM Naresh Kamboju wrote: > > On Thu, 4 Mar 2021 at 01:34, Guenter Roeck wrote: > > > > Upstream has: > > > > e71a8d5cf4b4 tty: fix up iterate_tty_read() EOVERFLOW handling > > ddc5fda74561 tty: fix up hung_up_tty_read() conversion > > I have applied these two patches

Re: [PATCH 00/11] pragma once: treewide conversion

2021-03-04 Thread Linus Torvalds
On Thu, Mar 4, 2021 at 5:55 AM David Laight wrote: > > > (a) the traditional include guard optimization HAS NO HIDDEN SEMANTIC > > MEANING. It's a pure optimization that doesn't actually change > > anything else. If you don't do the optimization, absolutely nothing > > changes. > > And if the

Re: [PATCH RFC] gcc-plugins: Handle GCC version mismatch for OOT modules

2021-03-04 Thread Linus Torvalds
On Thu, Mar 4, 2021 at 7:36 AM Masahiro Yamada wrote: > > All the kernel-space objects are rebuilt > when the compiler is upgraded. I very much NAK'ed that one. Why did that go in? Or maybe I NAK'ed another version of it (I think the one I NAK'ed was from Josh), and didn't realize that there

  1   2   3   4   5   6   7   8   9   10   >