rmerly: arm-soc)
MAINTAINERS: add a limited ARM and ARM64 SoC entry
Kuan-Ying Lee (1):
kasan: fix object remaining in offline per-cpu quarantine
Leon Romanovsky (1):
RDMA/cm: Fix an attempt to use non-valid pointer when cleaning timewait
Libo Chen (1):
ktest.pl: Fix incorre
On Thu, Dec 10, 2020 at 9:32 AM Jens Axboe wrote:
>
> Here's a potentially better attempt - basically we allow LOOKUP_NONBLOCK
> with LOOKUP_RCU, and if we end up dropping LOOKUP_RCU, then we generally
> return -EAGAIN if LOOKUP_NONBLOCK is set as we can no longer guarantee
> that we won't block.
On Thu, Dec 10, 2020 at 7:08 AM Kirill A. Shutemov
wrote:
>
> See lightly tested patch below. Is it something you had in mind?
This is closer, in that at least it removes the ostensibly blocking
allocation (that can't happen) from the prefault path.
But the main issue remains:
> > At that point
On Wed, Dec 9, 2020 at 4:39 PM Paul E. McKenney wrote:
>
> Like this, then?
Ack.
Linus
On Wed, Dec 9, 2020 at 3:07 PM Matthew Wilcox wrote:
>
> #. It is not necessary to use rcu_assign_pointer() when creating
> linked structures that are to be published via a single external
> - pointer. The RCU_INIT_POINTER() macro is provided for this task
> - and also for assigning ``NUL
On Wed, Dec 9, 2020 at 3:01 PM Linus Torvalds
wrote:
>
> rcu_assign_pointer() itself already does the optimization for the case
> of a constant NULL pointer assignment.
>
> So there's no need to manually change things to RCU_INIT_POINTER().
Side note: what should be done inst
On Wed, Dec 9, 2020 at 2:58 PM Al Viro wrote:
>
> On Wed, Dec 09, 2020 at 07:49:38PM +, Matthew Wilcox wrote:
> >
> > Assuming this is safe, you can use RCU_INIT_POINTER() here because you're
> > storing NULL, so you don't need the wmb() before storing the pointer.
>
> fs/file.c:pick_file() wo
On Wed, Dec 9, 2020 at 2:07 PM Arnd Bergmann wrote:
>
> Stephen Rothwell just pointed out that one of the fixes I added today
> was missing a Signed-off-by. I corrected that and uploaded a new tag
Gaah. I had already pulled, but since I hadn't pushed out, I undid it
and re-pulled..
Lin
On Wed, Dec 9, 2020 at 12:32 PM Matthew Wilcox wrote:
>
> If a filesystem has put an Uptodate page into the page cache, the
> rest of the kernel can read it without telling the filesystem.
XFS does the same thing for xfs_file_read_iter() too.
Not that I disagree with you - when you mmap a file,
On Wed, Dec 9, 2020 at 11:12 AM Jerry Snitselaar wrote:
>
> Since the field in the device table entry format expects it to be n
> where there are 2^n entries in the table I guess it should be:
>
> #define DTE_IRQ_TABLE_LEN 9
> #define MAX_IRQS_PER_TABLE (1 << DTE_IRQ_TABLE_LEN)
No, that "DTE_IRQ_
On Wed, Dec 9, 2020 at 10:05 AM Eric W. Biederman wrote:
>
> - struct file * file = xchg(&fdt->fd[i], NULL);
> + struct file * file = fdt->fd[i];
> if (file) {
> + rcu_
On Wed, Dec 9, 2020 at 10:40 AM Will Deacon wrote:
>
> > And yes, that probably means that you need to change "alloc_set_pte()"
> > to actually pass in the real address, and leave "vmf->address" alone -
> > so that it can know which ones are prefaulted and which one is real,
> > but that sounds li
On Wed, Dec 9, 2020 at 6:12 AM Will Deacon wrote:
>
> Please pull this one-liner AMD IOMMU fix for 5.10. It's actually a fix
> for a fix, where the size of the interrupt remapping table was increased
> but a related constant for the size of the interrupt table was forgotten.
Pulled.
However, why
On Wed, Dec 9, 2020 at 8:40 AM Will Deacon wrote:
>
> @@ -3978,8 +3994,17 @@ static vm_fault_t do_fault_around(struct vm_fault *vmf)
>
> /* check if the page fault is solved */
> vmf->pte -= (vmf->address >> PAGE_SHIFT) - (address >> PAGE_SHIFT);
> - if (!pte_none(*vmf->pte))
On Tue, Dec 8, 2020 at 7:22 PM Minchan Kim wrote:
>
> Jann spotted the security hole due to race of mm ownership check.
> If the task is sharing the mm_struct but goes through execve()
> before mm_access(), it could skip process_madvise_behavior_valid
> check. That makes *any advice hint* to reach
On Tue, Dec 8, 2020 at 2:54 PM Martin K. Petersen
wrote:
>
> Oh, I just realized the megaraid patch went in through block.
I'll take this as an "ack" for the revert, though ;)
Linus
On Tue, Dec 8, 2020 at 2:47 PM Jens Axboe wrote:
>
> On Tue, Dec 8, 2020 at 3:42 PM Julia Lawall wrote:
> >
> > This solves the problem. Starting from 5.10-rc7 and doing this
> > revert, I get a kernel that boots.
>
> Thanks for testing! Linus, do you just want to revert this, or do you
> want m
[ Just re-sending with Jens added back - he's been on a couple of the
emails, but wean't on this one. Sorry for the duplication ]
On Tue, Dec 8, 2020 at 1:23 PM Linus Torvalds
wrote:
>
> On Tue, Dec 8, 2020 at 1:14 PM John Garry wrote:
> >
> > JFYI, About "scsi
On Tue, Dec 8, 2020 at 1:14 PM John Garry wrote:
>
> JFYI, About "scsi: megaraid_sas: Added support for shared host tagset
> for cpuhotplug", we did have an issue reported here already from Qian
> about a boot hang:
Hmm. That does sound like it might be it.
At this point, the patches from Ming L
On Tue, Dec 8, 2020 at 12:53 PM Al Viro wrote:
>
> Umm... I've got
> fs: Handle I_DONTCACHE in iput_final() instead of generic_drop_inode()
> and
> fs: Kill DCACHE_DONTCACHE dentry even if DCACHE_REFERENCED is set
> in "to apply" pile; if that's what you are talking about,
Yup, those were the on
On Tue, Dec 8, 2020 at 12:34 AM Peter Zijlstra wrote:
>
> I suppose I'll queue the below into tip/perf/core for next merge window,
> unless you want it in a hurry?
LGTM, and there's no hurry. This is not a new thing, and I don't think
it has been a problem in practice.
Linus
On Tue, Dec 8, 2020 at 11:49 AM Al Viro wrote:
>
> Said that, it does appear to survive all beating, and it does fix
> a regression introduced in this cycle, so, provided that amount of
> comments in there is OK with you...
Ok, considering Greg's note, I've pulled it. It's early in the last
week,
On Tue, Dec 8, 2020 at 11:29 AM Julia Lawall wrote:
>
> A dmesg after successfully booting in 5.9 is attached.
Ok, from a quick look it's megaraid_sas.
The only thing I see there is that commit 103fbf8e4020 ("scsi:
megaraid_sas: Added support for shared host tagset for cpuhotplug").
Of course,
On Tue, Dec 8, 2020 at 10:59 AM Martin K. Petersen
wrote:
>
> > So I'm adding SCSI people to the cc, just in case they go "Hmm..".
>
> Only change in this department was:
>
> 831e3405c2a3 scsi: core: Don't start concurrent async scan on same host
Yeah, I found that one too, and dismissed it for t
On Tue, Dec 8, 2020 at 8:35 AM Christoph Hellwig wrote:
> >
> > Shouldn't this go to Linus before v5.10 is released?
>
> ping?
So by now I'm a bit worried about this series, because the early fixes
caused more problems than the current state.
So considering the timing and Al having been spotty,
On Tue, Dec 8, 2020 at 9:37 AM Julia Lawall wrote:
>
> We have not succeeded to boot 5.10 on our Intel(R) Xeon(R) CPU E7-8870 v4 @
> 2.10GHz server. Previous versions (eg 4.19 - 5.9) boot fine. We have
> tried various rcs.
So the problem started with rc1?
Could you try bisecting - even partial
On Mon, Dec 7, 2020 at 1:10 AM Peter Zijlstra wrote:
>
> > PeterZ, is there something I'm missing?
>
> Like this?
>
>
> https://lkml.kernel.org/r/20200828123720.gz1362...@hirez.programming.kicks-ass.net
Yes, except I think you should remove the old ptrace_may_access() check.
Because otherwise
tone
ALSA: hda/realtek - Add new codec supported for ALC897
Krzysztof Kozlowski (1):
dt-bindings: net: correct interrupt flags in examples
Laurent Vivier (2):
genirq/irqdomain: Add an irq_create_mapping_affinity() function
powerpc/pseries: Pass MSI affinity to irq_
On Sat, Dec 5, 2020 at 2:34 PM Jakub Kicinski wrote:
>
> Am I the only one who thinks this would be a good idea?
I don't think it's likely to be very useful, because a very common
pattern is to not have that separate "return 0" in the middle, but
more along the lines of
err = first_step(
On Fri, Dec 4, 2020 at 12:30 PM Bernd Edlinger
wrote:
>>
> >perf_event_open (exec_update_mutex -> ovl_i_mutex)
Side note: this one looks like it should be easy to fix.
Is there any real reason why exec_update_mutex is actually gotten that
early, and held for that long in the perf event code
On Fri, Dec 4, 2020 at 11:35 AM Eric W. Biederman wrote:
>
> From a deadlock perspective the change is strictly better than what we
> have today. The readers will no longer block on each other.
No, agreed, it's better regardless.
> For the specific case that syzbot reported it is readers who we
On Fri, Dec 4, 2020 at 8:08 AM Bernd Edlinger wrote:
>
> >
> > -static void kcmp_unlock(struct mutex *m1, struct mutex *m2)
> > +static void kcmp_unlock(struct rw_semaphore *l1, struct rw_semaphore *l2)
> > {
> > - if (likely(m2 != m1))
> > - mutex_unlock(m2);
> > - mutex_unlo
On Thu, Dec 3, 2020 at 12:10 PM Eric W. Biederman wrote:
>
> The simplest and most robust solution appears to be making
> exec_update_mutex a read/write lock and having everything execept for
> exec take the lock for read.
Looks sane to me.
I'd like the locking people to look at the down_read_*(
On Thu, Dec 3, 2020 at 2:15 PM Dominique Martinet
wrote:
>
> The problems I had with dkim are all lists that add footers so really
> not much to do about header filtering
Yeah, that's obviously always going to be a problem with DKIM.
But I think all the kernel mailing lists are good now - at lea
On Thu, Dec 3, 2020 at 1:46 PM Al Viro wrote:
>
> The answer (for mainline) is that mips compat does *NOT* want
> COMPAT_BINFMT_ELF. Not a problem with that series, though, so I'd
> retested it (seems to work, both for x86_64 and mips64, execs and
> coredumps for all ABIs alike), with centraliza
On Thu, Dec 3, 2020 at 12:45 PM Jakub Kicinski wrote:
>
> Networking fixes for 5.10-rc7, including fixes from bpf, netfilter,
> wireless drivers, wireless mesh and can.
Thanks, pulled.
And btw - maybe I've already talked about this, but since next week is
(hopefully) going to be the last week of
On Thu, Dec 3, 2020 at 2:33 AM Dominique Martinet
wrote:
>
>
> Hi Linus,
>
> Someone just reported splice got disabled in 5.10-rc1, here's a couple
> of patches to turn it back on using generic helpers.
Pulled.
> (Thanks for letting me know my mails got flagged as spam last time, I've
> taken th
On Wed, Dec 2, 2020 at 6:45 PM Ira Weiny wrote:
> >
> > What would the typical failure cases be in practice?
>
> The failure will be a user not seeing their file operating in DAX mode when
> they expect it to.
>
> I discussed this with Dan Williams today. He and I agreed the flag is new
> enough
On Wed, Dec 2, 2020 at 10:31 PM kernel test robot wrote:
>
> FYI, we noticed a -4.8% regression of will-it-scale.per_process_ops due to
> commit:
Ok, I guess that's bigger than expected, but the profile data does
show how bad the indirect branches are.
There's both a "direct" cost of them:
>
On Thu, Dec 3, 2020 at 5:03 AM Masahiro Yamada wrote:
>
> Checking the existence of plugin-version.h is still needed to ensure
> the plugin-dev package is installed. The test code is now small enough
> to be embedded in scripts/gcc-plugins/Kconfig.
Ack. I think the "plugin" directory name should
On Tue, Dec 1, 2020 at 6:16 PM Ira Weiny wrote:
>
> This will force a change to xfstests at a minimum. And I do know of users who
> have been using this value. But I have gotten inquires about using the
> feature
> so there are users out there.
If it's only a few tests that fail, I wouldn't wo
On Wed, Dec 2, 2020 at 4:54 AM Masahiro Yamada wrote:
>
> Just a nit:
> Now that the test code does not include any header,
> you can also delete
> "-I $srctree/gcc-plugins -I $gccplugins_dir/include"
Ahh,m yes.
It sounds like we might be able to delete the build test entirely if
we just always
On Tue, Dec 1, 2020 at 2:03 PM Eric Sandeen wrote:
>
> That's why I was keen to just add DAX unconditionally at this point, and if
> we want
> to invent/refine meanings for the mask, we can still try to do that?
Oh Gods. Let's *not* make this some "random filesystem choice" where
now semantics
On Tue, Dec 1, 2020 at 1:04 PM David Howells wrote:
>
> Linus Torvalds wrote:
>
> > And if IS_DAX() is correct, then why shouldn't this just be done in
> > generic code? Why move it to every individual filesystem?
>
> One way of looking at it is that the check i
On Tue, Dec 1, 2020 at 8:59 AM Eric Sandeen wrote:
>
> It's a bit odd to set STATX_ATTR_DAX into the statx attributes in the VFS;
> while the VFS can detect the current DAX state, it is the filesystem which
> actually sets S_DAX on the inode, and the filesystem is the place that
> knows whether DA
On Mon, Nov 30, 2020 at 11:56 PM Peter Zijlstra wrote:
>
> So even if an architecture needs to enable interrupts on idle, we need
> it disabled again when coming out. So we might as well have the arch
> idle routine then be: STI; HLT; CLI; because then architectures than can
> idle with interrupts
On Mon, Nov 30, 2020 at 10:11 AM Doug Anderson wrote:
>
> So I guess the answer here is: strive very hard but you don't have to
> guarantee that every corner case is covered?
Yes. Covering every possible theoretical case is basically impossible.
I mean, it can be something like "the firmware glit
On Mon, Nov 30, 2020 at 10:05 AM Russell King - ARM Linux admin
wrote:
>
> If you think that /dev/sda for example is always the machine's internal
> HDD, that is wrong.
Yes. See the whole part about
"Note that it really is only the internal devices that matter. Once you
start plugging in an e
On Mon, Nov 30, 2020 at 5:03 AM Peter Zijlstra wrote:
>
> > But but but...
> >
> > do_idle() # IRQs on
> > local_irq_disable(); # IRQs off
> > defaul_idle_call()# IRQs off
> lockdep_hardirqs_on(); # IRQs off, but lockdep things they're on
> >
On Sun, Nov 29, 2020 at 11:57 PM Peter Zijlstra wrote:
>
> The idea was to flip all of arch_cpu_idle() to not enable interrupts.
I don't think that's realistic.
> This is suboptimal for things like x86 where arch_cpu_idle() is
> basically STI;HLT, but x86 isn't likely to actually use this code p
On Mon, Nov 30, 2020 at 9:04 AM Doug Anderson wrote:
>
> Without static assignment, maybe we could do numbering of MMC devices
> in some type of a pre-probe routine? Is that what you're suggesting?
Yes.
So basically, the way the async probing works for say SCSI is that we
have multiple "layers
dereference in ibmvic_reset_crq
ibmvnic: enhance resetting status check during module exit
Likun Gao (1):
drm/amdgpu: update golden setting for sienna_cichlid
Lincoln Ramsay (1):
aquantia: Remove the build_skb path
Linus Torvalds (1):
Linux 5.10-rc6
Lionel Landwerl
On Sun, Nov 29, 2020 at 5:38 AM Thomas Gleixner wrote:
>
> Yet two more places which invoke tracing from RCU disabled regions in the
> idle path. Similar to the entry path the low level idle functions have to
> be non-instrumentable.
This really seems less than optimal.
In particular, lookie her
On Sun, Nov 29, 2020 at 2:42 AM Borislav Petkov wrote:
>
> please pull more forwarded EFI urgent fixes.
Ard seems to be using almost random signing of his tags. Last time it
was signed with subkey 9CD2A0DA, this time it's subkey FBD9627C.
I see that it's all the same primary key, and I'm pretty
On Sat, Nov 28, 2020 at 2:07 PM Randy Dunlap wrote:
>
> Could it just be a vger issue? vger has been acting ill today...
Possible. pr-tracker-bot obviously is back, it just had a very long delay.
And yes, the delay might have been due to it not seeing the original
pull requests due to vger slow
On Fri, Nov 27, 2020 at 11:05 PM Masahiro Yamada wrote:
>
> As for the cc1plus cost, I got a similar result.
>
> Running scripts/gcc-plugin.sh directly
> took me 0.5 sec, which is a fourth
> of the allmodconfig run-time.
>
> Actually, I did not know this shell script
> was so expensive to run...
pr-tracker-bot seems a bit under the weather.
But this has been pulled.
I'm not sure why pt-tracker-bot did react to the Kbuild one, but not
the ones by Greg and Arnaldo. The pull requests all look good to me,
and seem to have all the required markers..
Konstantin?
Linus
On Sat, Nov
On Fri, Nov 27, 2020 at 5:49 AM Mark Brown wrote:
>
> A few fixes for v5.10, one for the core which fixes some potential races
> for controllers with multiple chip selects when configuration of the
> chip select for one client device races with the addition and initial
> setup of an additional cli
On Fri, Nov 27, 2020 at 12:51 PM Arnd Bergmann wrote:
>
> - Some DT patches for the Rockchip RK3399 platform,
>in particular fixing the MMC device ordering that
>recently became nondeterministic with async probe.
Uhhuh.
I didn't realize this MMC breakage happened.
That's just an MMC bu
On Fri, Nov 27, 2020 at 1:53 PM Linus Torvalds
wrote:
>
> 33.68% cc1plus
So a third of the time is the _single_ invocation of cc1plus, which
happens from scrips/gcc-plugin.sh doing that
$HOSTCC -c -x c++ -std=gnu++98 - -fsyntax-only
thing. Which is purely to verify that plugin
On Fri, Nov 27, 2020 at 1:15 PM Linus Torvalds
wrote:
>
> Oh, this is a red herring. It's "make" output being misleading, and it
> just comes from the FORCE keyword.
>
> And no, those don't actually change the end result for me.
.. and that red herring wa
On Fri, Nov 27, 2020 at 1:08 PM Linus Torvalds
wrote:
>
>make --trace allmodconfig
>
> shows a series of
>
> scripts/Makefile.host:112: target 'scripts/kconfig/o' does not exist
>
> lines, which is silly and wrong
Oh, this is a red herring. I
Just a quick note, because it's been a small annoyance for a while (I
don't think it has anything to do with the 5.10 pull, I'm just
responding to your latest pull request)..
I have "make allmodconfig" taking unnecessarily long, and I finally
started asking myself "what's so expensive here". I'd e
On Tue, Nov 24, 2020 at 10:24 PM Feng Tang wrote:
>
> And with the following patch to relayout these members, the regression
> is restored and event better. while reducing 64 bytes of sizeof
> 'struct mem_cgroup'
Thanks, applied.
I do wonder if somebody on the hardware side inside Intel might no
On Wed, Nov 25, 2020 at 1:30 PM Linus Torvalds
wrote:
>
> I'm not sure I'm willing to write and test the real patch, but it
> doesn't look _too_ nasty from just looking at the code. The bookmark
> thing makes it important to only actually clear the bit at the end
On Tue, Nov 24, 2020 at 3:24 PM Linus Torvalds
wrote:
>
> I've applied your second patch (the smaller one that just takes a ref
> around the critical section). If somebody comes up with some great
> alternative, we can always revisit this.
Hmm.
I'm not sure about "
On Tue, Nov 24, 2020 at 1:47 PM Hugh Dickins wrote:
>
> I think the unreferenced struct page asks for trouble.
I do agree.
I've applied your second patch (the smaller one that just takes a ref
around the critical section). If somebody comes up with some great
alternative, we can always revisit t
On Tue, Nov 24, 2020 at 12:16 PM Matthew Wilcox wrote:
>
> So my s/if/while/ suggestion is wrong and we need to do something to
> prevent spurious wakeups. Unless we bury the spurious wakeup logic
> inside wait_on_page_writeback() ...
We can certainly make the "if()" in that loop be a "while()'.
On Tue, Nov 24, 2020 at 11:55 AM Eric W. Biederman
wrote:
>
> If cell happens to be dead we can remove a fair amount of generic kernel
> code that only exists to support cell.
Even if some people might still use cell (which sounds unlikely), I
think we can remove the spu core dumping code.
On Tue, Nov 24, 2020 at 10:33 AM Matthew Wilcox wrote:
>
> We could fix this by turning that 'if' into a 'while' in
> write_cache_pages().
That might be the simplest patch indeed.
At the same time, I do worry about other cases like this: while
spurious wakeup events are normal and happen in othe
On Mon, Nov 23, 2020 at 8:07 PM Hugh Dickins wrote:
>
> Then on crashing a second time, realized there's a stronger reason against
> that approach. If my testing just occasionally crashes on that check,
> when the page is reused for part of a compound page, wouldn't it be much
> more common for t
On Mon, Nov 23, 2020 at 8:07 PM Hugh Dickins wrote:
>
> The problem is that PageWriteback is not accompanied by a page reference
> (as the NOTE at the end of test_clear_page_writeback() acknowledges): as
> soon as TestClearPageWriteback has been done, that page could be removed
> from page cache,
On Mon, Nov 23, 2020 at 9:52 AM Oleg Nesterov wrote:
>
> Can anyone explain why does do_coredump() need unshare_files() at all?
Hmm. It goes back to 2012, and it's placed just before calling
"->core_dump()", so I assume some core dumping function messed with
the file table back when..
I can't se
xtensa: uaccess: Add missing __user to strncpy_from_user() prototype
Laurent Vivier (1):
vdpasim: fix "mac_pton" undefined error
Lee Duncan (1):
scsi: libiscsi: Fix NOP race condition
Leo Yan (4):
perf lock: Correct field name "flags"
perf lock:
On Sun, Nov 22, 2020 at 5:33 AM David Howells wrote:
>
> I don't know enough about how spectre v2 works to say if this would be a
> problem for the ops-table approach, but wouldn't it also affect the chain of
> conditional branches that we currently use, since it's branch-prediction
> based?
No,
On Sat, Nov 21, 2020 at 6:13 AM David Howells wrote:
>
> Can someone recommend a good way to benchmark this properly? The problem
> is that the difference this makes relative to the amount of time taken to
> actually do I/O is tiny.
Maybe try /dev/zero -> /dev/null to try a load where the IO its
On Sat, Nov 21, 2020 at 6:13 AM David Howells wrote:
>
> Switch to using a table of operations. In a future patch the individual
> methods will be split up by type. For the moment, however, the ops tables
> just jump directly to the old functions - which are now static. Inline
> wrappers are pr
On Fri, Nov 20, 2020 at 7:00 PM Jens Axboe wrote:
>
> Actually, I think we can do even better. How about just having
> do_filp_open() exit after LOOKUP_RCU fails, if LOOKUP_RCU was already
> set in the lookup flags? Then we don't need to change much else, and
> most of it falls out naturally.
So
On Fri, Nov 20, 2020 at 1:36 PM Jens Axboe wrote:
>
> I don't disagree with you on that. I've been a bit gun shy on touching
> the VFS side of things, but this one isn't too bad. I hacked up a patch
> that allows io_uring to do LOOKUP_RCU and a quick test seems to indicate
> it's fine. On top of t
On Fri, Nov 20, 2020 at 3:11 PM Eric W. Biederman wrote:
>
> This set of changes cleanups of the code in exec so hopefully this code
> will not regress again. Then it adds helpers and fixes the users of
> files_struct so the reference count is only incremented if COPY_FILES is
> passed to clone (
On Fri, Nov 20, 2020 at 3:16 PM Eric W. Biederman wrote:
>
> @@ -1257,6 +1258,13 @@ int begin_new_exec(struct linux_binprm * bprm)
> if (retval)
> goto out;
>
> + /* Ensure the files table is not shared. */
> + retval = unshare_files(&displaced);
> + if (r
On Fri, Nov 20, 2020 at 10:45 AM Jens Axboe wrote:
> Jens Axboe (4):
> proc: don't allow async path resolution of /proc/self components
This one is ok.
> io_uring: handle -EOPNOTSUPP on path resolution
But this one smells. It talks about how it shouldn't block, but the
fact is, it c
On Fri, Nov 20, 2020 at 9:41 AM Linus Torvalds
wrote:
>
> This code sequence looks bogus to begin with.
Oh, never mind.
I was reading the patches out of order, because 4/6 showed up later in
my inbox since it had other replies.
You seem to have fixed that bogosity in 4/6.
Linus
On Fri, Nov 20, 2020 at 6:36 AM Will Deacon wrote:
>
> Ensure that TLB invalidation is performed after updating soft-dirty
> entries via clear_refs_write() by using the non-fullmm API to MMU gather.
This code sequence looks bogus to begin with.
It does that
tlb_gather_mmu(&tlb,
Oh - wait.
Not ack.
Not because this is wrong, but because I think you should remove the
start/end arguments here too.
The _only_ thing they were used for was that "fullmm" flag, afaik. So
now they no longer make sense.
Hmm?
Linus
On Fri, Nov 20, 2020 at 9:22 AM Linu
On Fri, Nov 20, 2020 at 6:36 AM Will Deacon wrote:
>
> Introduce tlb_gather_mmu_fullmm() to make it clearer that this is for the
> entire mm and WARN() if tlb_gather_mmu() is called with an 'end' address
> greated than TASK_SIZE.
Ack (but with a spello note - "greated").
Linus
On Fri, Nov 20, 2020 at 6:36 AM Will Deacon wrote:
>
> tlb_finish_mmu() takes two confusing and unused 'start'/'end' address
> arguments. Remove them.
Ack, but please add the history to it.
Those arguments were used, up until 7a30df49f63a ("mm: mmu_gather:
remove __tlb_reset_range() for force fl
On Thu, Nov 19, 2020 at 10:34 AM Alexei Starovoitov
wrote:
>
> ping.
I'm ok with this series that adds explanations for why you care and
what bpf does that makes it valid.
So this one you can put in the bpf tree.
Or, if you want me to just apply it as a series, I can do that too, I
just general
On Thu, Nov 19, 2020 at 6:31 AM Masami Hiramatsu wrote:
>
> Here is a seires of patches to change the bootconfig footer format
> to use 8-bytes hexadecimal ASCII string for size and checksum instead
> of u32.
Ugh.,
Just make it little-endian only.
The _worst_ thing to do is to make it some kind
On Thu, Nov 19, 2020 at 3:14 AM Peter Zijlstra wrote:
>
> I still hate all of this, and I really fear that with migrate_disable()
> available, people will be lazy and usage will increase :/
>
> Case at hand is this series, the only reason we need it here is because
> per-cpu page-tables are expens
On Thu, Nov 19, 2020 at 12:46 AM Mel Gorman wrote:
>
> And not start thinking it as a security hardening option.
It's probably the reverse of a hardening option, since it will cause
mapping of stuff in known and controllable virtual addresses.
Although any kmap'able page is likely to already be
On Wed, Nov 18, 2020 at 12:58 PM Thomas Gleixner wrote:
>
> Provide CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP which forces the temporary
> mapping even for lowmem pages. This needs to be a seperate config switch
> because this only works on architectures which do not have cache aliasing
> problems.
Very
On Wed, Nov 18, 2020 at 4:12 AM David Laight wrote:
>
> I've got the 'splat' below during boot.
> This is an 8-core C2758 Atom cpu using the on-board/cpu graphics.
> User space is Ubuntu 20.04.
>
> Additionally the X display has all the colours and alignment slightly
> messed up.
> 5.9.0 was ok.
>
On Tue, Nov 17, 2020 at 3:29 PM Linus Torvalds
wrote:
>
> On Tue, Nov 17, 2020 at 3:24 PM Mimi Zohar wrote:
> >
> > I really wish it wasn't needed.
>
> Seriously, I get the feeling that IMA is completely mis-designed, and
> is doing actively bad things.
>
>
On Tue, Nov 17, 2020 at 3:24 PM Mimi Zohar wrote:
>
> I really wish it wasn't needed.
Seriously, I get the feeling that IMA is completely mis-designed, and
is doing actively bad things.
Who uses this "feature", and who cares? Because I would suggest you
just change the policy and be done with it
On Mon, Nov 16, 2020 at 7:51 AM Minchan Kim wrote:
>
> Let me send a patch with your SoB if you don't mind.
Eric, can you ack this SoB and I'll apply it to me tree?
Or is it already queued up somewhere else?
Linus
On Mon, Nov 16, 2020 at 10:35 AM Mimi Zohar wrote:
>
> We need to differentiate between signed files, which by definition are
> immutable, and those that are mutable. Appending to a mutable file,
> for example, would result in the file hash not being updated.
> Subsequent reads would fail.
Why w
On Mon, Nov 16, 2020 at 2:15 PM Linus Torvalds
wrote:
>
> So I've verified that at least on x86-64, this doesn't really make
> code generation any worse, and I'm ok with the patch from that
> standpoint.
.. looking closer, it will generate extra code on big-endian
On Mon, Nov 16, 2020 at 1:17 PM Daniel Xu wrote:
>
> Based on on-list discussion and some off-list discussion with Alexei,
> I'd like to propose the v4-style patch without the `(*out & ~mask)`
> bit.
So I've verified that at least on x86-64, this doesn't really make
code generation any worse, and
On Mon, Nov 16, 2020 at 8:22 AM Masami Hiramatsu wrote:
>
> /* TODO: Ensure the @path is initramfs/initrd image */
> - ret = write(fd, data, size + 8);
> + ret = write(fd, data, size);
> if (ret < 0) {
> pr_err("Failed to apply a boot config: %d\n", ret)
501 - 600 of 8848 matches
Mail list logo
