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
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:
>
>
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
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
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
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
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
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
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
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 "
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
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()"
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
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
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,
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
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
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").
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
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
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
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
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
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
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
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
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
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
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
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;
>
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
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
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,
> >
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
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
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,
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,
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
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
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
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
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
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
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)?
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
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
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
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
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. :-/
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
[ 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
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
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
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
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
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")
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: [:
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
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
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
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
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
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
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
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
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
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
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_*
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
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
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
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.
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
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
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
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
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
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
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
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):
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
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.
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:
>
>
>
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
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
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
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 - 100 of 24393 matches
Mail list logo
