On Thu, Jan 7, 2021 at 12:04 PM Andrea Arcangeli wrote:
>
> However there are two cases that could wrprotecting exclusive anon
> pages with only the mmap_read_lock:
I still think the real fix is "Don't do that then", and just take the
write lock.
The UFFDIO_WRITEPROTECT case simply isn't that cr
On Wed, Jan 6, 2021 at 8:45 PM Willem de Bruijn wrote:
>
> But there are three other kmap_atomic callers under net/ that do not
> loop at all, so assume non-compound pages. In esp_output_head,
> esp6_output_head and skb_seq_read. The first two directly use
> skb_page_frag_refill, which can allocat
On Thu, Jan 7, 2021 at 11:15 AM Greg Kroah-Hartman
wrote:
>
> Linus, can you take this directly, or is this going through some other
> tree?
I was _assuming_ that I'd get it through the normal printk pull
request, it doesn't seem to be that timing-critical.
But if there is nothing else pending,
On Thu, Jan 7, 2021 at 11:04 AM Al Viro wrote:
>
> BTW, changing 'event' field in place from another thread is going to
> be interesting - you have two 16bit values next to each other and
> two CPUs modifying those with no exclusion. Sounds like a recipe
> for massive trouble...
It's perfectly f
On Thu, Jan 7, 2021 at 10:34 AM Al Viro wrote:
>
> I'm not sure it's the best approach, TBH. How about simply
> for (walk = head; walk; ufds += walk->len, walk = walk->next) {
> if (copy_to_user(ufds, walk->entries,
> walk->len * sizeof(str
On Thu, Jan 7, 2021 at 9:45 AM Andy Shevchenko
wrote:
>>
> Shouldn't it have Fixes tag along with Reported-by ones and explanation what
> was the actual problem reported?
No need for a "Fixes" tag for a revert - the commit it reverts _is_
the thing it fixes, so that's implicitly there.
But yes,
On Thu, Jan 7, 2021 at 5:32 AM kernel test robot wrote:
>
> FYI, we noticed a -5.8% regression of will-it-scale.per_thread_ops due to
> commit:
Ok, that's noticeable.
And:
> commit: d55564cfc222326e944893eff0c4118353e349ec ("x86: Make __put_user()
> generate an out-of-line call")
Yeah, that
On Wed, Jan 6, 2021 at 3:01 PM Steven Rostedt wrote:
>
> I triggered the following crash on x86_32 by simply doing a:
>
> (ssh'ing into the box)
>
> # head -100 /tmp/output-file
>
> Where the /tmp/output-file was the output of a trace-cmd report.
> Even after rebooting and not running the tracin
On Tue, Jan 5, 2021 at 12:57 PM Guenter Roeck wrote:
>
> NP. The test are running automatically anyway, so I figured I might
> as well report the results. Does that make sense, or is it just noise ?
Definitely not noise. I very much like seeing the results.
In fact, even in situations like this,
On Tue, Jan 5, 2021 at 1:13 PM Hugh Dickins wrote:
>
> I was going to raise a question, whether you should now revert
> 073861ed77b6 ("mm: fix VM_BUG_ON(PageTail) and BUG_ON(PageWriteback)"):
> which would not have gone in like that if c2407cf7d22d were already in.
Honestly, even if it wasn't for
On Tue, Jan 5, 2021 at 12:00 PM Al Viro wrote:
>
> We are not guaranteed the locking environment that would prevent
> dentry getting renamed right under us. And it's possible for
> old long name to be freed after rename, leading to UAF here.
This whole thing isn't important enough to get the den
On Tue, Jan 5, 2021 at 10:46 AM Guenter Roeck wrote:
>
> Problems are as already reported against v5.11-rc1.
Yes. Thanks for keeping on top of this, I'm expecting to get the fixes
as people get back from vacations.
Linus
On Tue, Jan 5, 2021 at 11:31 AM Linus Torvalds
wrote:
>
> On Mon, Jan 4, 2021 at 7:29 PM Hugh Dickins wrote:
> >
> > > So the one-liner of changing the "if" to "while" in
> > > wait_on_page_writeback() should get us back to what we used to d
On Mon, Jan 4, 2021 at 7:29 PM Hugh Dickins wrote:
>
> > But I feel it's really that end_page_writeback() itself is
> > fundamentally buggy, because the "wakeup" is not atomic with the bit
> > clearing _and_ it doesn't actually hold the page lock that is
> > allegedly serializing this all.
>
> And
On Mon, Jan 4, 2021 at 12:41 PM Andrew Morton wrote:
>
> >
> > kernel BUG at mm/page-writeback.c:2241!
> > Call Trace:
> > mpage_writepages+0xd8/0x230 fs/mpage.c:714
> > do_writepages+0xec/0x290 mm/page-writeback.c:2352
> > __filemap_fdatawrite_range+0x2a1/0x380 mm/filemap.c:422
> > fat_cont_e
On Mon, Jan 4, 2021 at 4:32 AM David Howells wrote:
>
> How about the attached, then? I
That looks like the right thing, but I didn't check how the name[]
array (or the overflow[] one) is actually used. But I assume you've
tested this.
Do you want me to apply the patch as-is, or will I be getti
io_uring: don't assume mm is constant across submits
Joe Perches (1):
checkpatch: prefer strscpy to strlcpy
Josh Poimboeuf (1):
kdev_t: always inline major/minor helper functions
Kalesh Singh (1):
mm/mremap.c: fix extent calculation
Linus Torvalds (2):
depmod:
On Sat, Jan 2, 2021 at 1:25 AM Rafael J. Wysocki wrote:
>
> These fix a crash in intel_pstate during resume from suspend-to-RAM
> that may occur after recent changes and two resource leaks in error
> paths in the operating performance points (OPP) framework, add a new
> C-states table to intel_idl
On Fri, Jan 1, 2021 at 12:19 PM James Bottomley
wrote:
>
> Originally this change was slated for the merge window but a late
> arriving build problem with CONFIG_PM=n derailed that.
So I've pulled this, but we need to have a policy for reverting this
quickly if it turns out to cause problems.
I'
On Fri, Jan 1, 2021 at 8:51 AM Rafael J. Wysocki wrote:
>
> - Add new power capping facility called DTPM (Dynamic Thermal Power
>Management), based on the existing power capping framework, to
>allow aggregate power constraints to be applied to sets of devices
>in a distributed manner,
On Tue, Dec 29, 2020 at 6:59 PM kernel test robot wrote:
>
> [ 235.553325] BUG: sleeping function called from invalid context at
> arch/x86/mm/fault.c:1351
> [ 235.554684] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 7515,
> name: trinity-c1
> [ 235.555890] 2 locks held by trinity-c
On Tue, Dec 29, 2020 at 5:28 AM Kirill A. Shutemov wrote:
>
> I reworked do_fault_around() so it doesn't touch vmf->address and pass
> original address down to ->map_pages(). No need in the new argument in
> ->map_pages. filemap_map_pages() calculates address based on pgoff of the
> page handled.
On Mon, Dec 28, 2020 at 2:05 PM Kirill A. Shutemov wrote:
>
>
> But I *think* we should be fine here: do_fault_around() limits start_pgoff
> and end_pgoff to stay within the page table.
Yeah, but I was thinking it would then update ->pte to just past the edge.
But looking at that logic, you're r
On Mon, Dec 28, 2020 at 12:04 AM Sedat Dilek wrote:
>
> > $ dpkg -L kmod | grep bin | grep depmod
> > /sbin/depmod
> >
> > $ which depmod
> > [ empty ]
> >
> > $ echo $PATH
> > /opt/proxychains-ng/bin:/home/dileks/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
Ok, I think this is a
On Mon, Dec 28, 2020 at 7:26 AM Sedat Dilek wrote:
>
> I also tested with LLVM toolchain v11.0.1-rc2 together with passing
> LLVM=1 and LLVM_IAS=1 to my make line.
>
> I had one ERROR:
>
> error: too few operands for instruction in arch/x86/kvm/svm/sev.c
Looks like Paolo already picked up the fix
On Mon, Dec 28, 2020 at 10:47 AM Linus Torvalds
wrote:
>
> I personally think it's wrong to update vmf->pte at all. We should
> just have a local 'ptep' pointer that we update as we walk along. But
> that requires another change to the calling convention, namely to
On Mon, Dec 28, 2020 at 7:51 AM Guenter Roeck wrote:
>
> Build results:
> total: 153 pass: 151 fail: 2
Thanks for doing these for the mainline rc's too. I've seen them for
the stable kernels, but it's lovely to see it for rc1.
> ERROR: modpost: "irq_check_status_bit" [drivers/perf/arm_sp
On Mon, Dec 28, 2020 at 4:53 AM Kirill A. Shutemov wrote:
>
> So far I only found one more pin leak and always-true check. I don't see
> how can it lead to crash or corruption. Keep looking.
Well, I noticed that the nommu.c version of filemap_map_pages() needs
fixing, but that's obviously not the
On Sun, Dec 27, 2020 at 3:48 PM Kirill A. Shutemov wrote:
>
> I did what Hugh proposed and it got clear to my eyes. It gets somewhat
> large, but take a look.
Ok, it's not that much bigger, and the end result is certainly much
clearer wrt locking.
So that last version of yours with the fix for t
Two weeks have passed, Christmas is over, and so is the merge window.
I want to thank all the maintainers who sent in their pull requests
early: we all wanted to get things done before the holidays really
hit, and mostly it seemed to work quite well.
In fact, it was rather nice to handle the big
On Sun, Dec 27, 2020 at 3:12 PM Linus Torvalds
wrote:
>
> Ok, your fix for that folded in, and here's yet another version.
Still not good.
I don't know what happened, but the change of
- vm_fault_t ret = 0;
+ vm_fault_t ret;
is very very wrong. The next user is
+
On Sun, Dec 27, 2020 at 1:25 PM Al Viro wrote:
>
>
> Is there any point in not doing the same (scripted, obviously) for
> all instances with .read == seq_read? IIRC, Christoph even posted
> something along those lines, but it went nowhere for some reason...
I'd rather limit splice (and kernel_re
all improvement in readability.
Signed-off-by: Kirill A. Shutemov
Tested-by: Hugh Dickins
Cc: Damian Tometzki
Signed-off-by: Linus Torvalds
---
include/linux/mm.h | 8 +-
include/linux/pgtable.h | 11 +++
mm/filemap.c| 168 ++--
mm/mem
On Sun, Dec 27, 2020 at 11:05 AM Linus Torvalds
wrote:
>
> On Sun, Dec 27, 2020 at 10:39 AM Jussi Kivilinna
> wrote:
> >
> > 5.10.3 with patch compiles fine, but does not solve the issue.
>
> Duh. adding the read_iter only fixes kernel_read(). For
has gone now. All locking is
explicit.
The price is some code duplication to handle huge pages in faultaround
path, but it should be fine, having overall improvement in readability.
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Linus Torvalds
---
include/linux/mm.h | 8 +-
include/li
On Sun, Dec 27, 2020 at 10:39 AM Jussi Kivilinna wrote:
>
> 5.10.3 with patch compiles fine, but does not solve the issue.
Duh. adding the read_iter only fixes kernel_read(). For splice, it also needs a
.splice_read = generic_file_splice_read,
in the file operations, something like this
On Sun, Dec 27, 2020 at 9:38 AM Linus Torvalds
wrote:
>
> The thing is, "PTR_ERR()" works just fine on a IS_ERR_OR_NULL pointer.
> It doesn't work on a _regular_ non-NULL and non-ERR pointer, and will
> return random garbage for those. But if you've tested for
&g
On Sun, Dec 27, 2020 at 6:16 AM Jon Mason wrote:
>
> Wang Qing (1):
> ntb: idt: fix error check in ntb_hw_idt.c
So this patch seems to be at least partially triggered by a smatch
warning that is a bit questionable.
This part:
if (IS_ERR_OR_NULL(dbgfs_topdir)) {
dev_info(&nde
On Sun, Dec 27, 2020 at 8:32 AM Jussi Kivilinna wrote:
>
> Has this been fixed in 5.11-rc? Is there any patch that I could backport and
> test with 5.10?
Here's a patch to test. Entirely untested by me. I'm surprised at how
people use sendfile() on random files. Oh well..
Linus
patc
On Sat, Dec 26, 2020 at 1:04 PM Hugh Dickins wrote:
>
>
> Hold on. I guess this one will suffer from the same bug as the previous.
> I was about to report back, after satisfactory overnight testing of that
> version - provided that one big little bug is fixed:
>
> --- a/mm/filemap.c
> +++ b/mm/fil
I was going to just apply this patch, because I like it so much, but
then I decided to take one last look, and:
On Sat, Dec 26, 2020 at 12:43 PM Kirill A. Shutemov
wrote:
>
> +static bool filemap_map_pmd(struct vm_fault *vmf, struct page *page)
> +{
> + struct mm_struct *mm = vmf->vma->vm_m
On Fri, Dec 25, 2020 at 3:31 AM Kirill A. Shutemov wrote:
>
> The new helper next_page() returns a stablized page, so filemap_map_pmd()
> can clearly decide if we should set up a page table or a huge page.
I really like that next_page() abstraction, my only comment is that I
think it should be re
On Wed, Dec 23, 2020 at 6:29 PM Dave Airlie wrote:
>
> Xmas eve pull request present. Just some fixes that trickled in this
> past week. Mostly amdgpu fixes, with a dma-buf/mips build fix and some
> misc komeda fixes.
Well, I already pulled and pushed out my merge, but only noticed
afterwards tha
On Tue, Dec 22, 2020 at 4:43 PM Casey Schaufler wrote:
>
> https://github.com/cschaufler/smack-next smack-for-5.11
That is not a tag.
And I really want signed tags for non-kernel.org pull requests.
Digging at that repo, I do find the tag, it's
'tags/Smack-for-5.11-io_uring-fix' and it has a p
On Tue, Dec 22, 2020 at 3:58 PM Thomas Gleixner wrote:
>
> A treewide cleanup of interrupt descriptor (ab)use with all sorts of racy
> accesses, inefficient and disfunctional code. The goal is to remove the
> export of irq_to_desc() to prevent these things from creeping up again.
This expos
On Wed, Dec 23, 2020 at 1:39 PM Andrea Arcangeli wrote:
>
> On Tue, Dec 22, 2020 at 08:36:04PM -0700, Yu Zhao wrote:
> > Thanks for the details.
>
> I hope we can find a way put the page_mapcount back where there's a
> page_count right now.
I really don't think that's ever going to happen - at le
On Tue, Dec 22, 2020 at 4:01 PM Linus Torvalds
wrote:
>
> The more I look at the mprotect code, the less I like it. We seem to
> be much better about the TLB flushes in other places (looking at
> mremap, for example). The mprotect code seems to be very laissez-faire
> about the TL
On Tue, Dec 22, 2020 at 3:50 PM Linus Torvalds
wrote:
>
> The rule is that the TLB flush has to be done before the page table
> lock is released.
I take that back. I guess it's ok as long as the mmap_sem is held for
writing. Then the TLB flush can be delayed until just before
On Tue, Dec 22, 2020 at 3:50 PM Linus Torvalds
wrote:
>
> See zap_pte_range() for an example of doing it right, even in the
> presence of complexities (ie that has an example of both flushing the
> TLB, and doing the actual "free the pages after flush", and it does
>
On Tue, Dec 22, 2020 at 3:39 PM Yu Zhao wrote:
>
> 2) is the false positive because of what we do, and it's causing the
> memory corruption because do_wp_page() tries to make copies of pages
> that seem to be RO but may have stale RW tlb entries pending flush.
Yeah, that's definitely a different
On Tue, Dec 22, 2020 at 6:44 AM syzbot
wrote:
>
> The issue was bisected to:
>
> commit 2f78788b55ba ("ilog2: improve ilog2 for constant arguments")
That looks unlikely, although possibly some constant folding
improvement might make the fortify code notice something with it.
> detected buffer ov
On Tue, Dec 22, 2020 at 9:42 AM Wim Van Sebroeck
wrote:
>
> git://www.linux-watchdog.org/linux-watchdog.git linux-watchdog-5.11-rc1
There's no such tag there. Forgot to push out?
I can see the the top-of-tree has the SHA1 that you mention:
> for you to fetch changes up to 0b9491b621196a5d7f1
On Mon, Dec 21, 2020 at 7:19 PM Andy Lutomirski wrote:
>
> Ugh, this is unpleasantly complicated.
I probably should have phrased it differently, because the case you
quote is actually a good one:
> I will admit that any API that
> takes an address and more-or-less-blindly marks it RO makes me q
On Mon, Dec 21, 2020 at 4:00 PM Yu Zhao wrote:
>
> My first instinct is to be conservative and revert 09854ba94c6a ("mm:
> do_wp_page() simplification") so people are less likely to come back
> and complain about performance issues from holding mmap lock for
> write when clearing pte_write.
Well,
On Mon, Dec 21, 2020 at 2:55 PM Nadav Amit wrote:
>
> So as an alternative solution, I can do copying under the PTL after
> flushing, which seems to solve the problem.
I think that's a valid model, but note that we do the "re-check ptl"
in a (*completely(* different part than we do the actual PTE
On Mon, Dec 21, 2020 at 3:12 PM Yu Zhao wrote:
>
> I can't say I disagree with you but the man has made the call and I
> think we should just move on.
"The man" can always be convinced by numbers.
So if somebody comes up with an alternate patch, and explains it, and
shows that it is better - go
On Mon, Dec 21, 2020 at 2:30 PM Peter Xu wrote:
>
> AFAIU mprotect() is the only one who modifies the pte using the mmap write
> lock. NUMA balancing is also using read mmap lock when changing pte
> protections, while my understanding is mprotect() used write lock only because
> it manipulates th
On Mon, Dec 21, 2020 at 1:55 PM Peter Xu wrote:
>
> Frankly speaking I don't know why it's always safe to do data copy without the
> pgtable lock in wp_page_copy(), since I don't know what guaranteed us from
> data
> changing on the original page due to any reason.
So the reason it should be saf
On Mon, Dec 21, 2020 at 12:23 PM Nadav Amit wrote:
>
> Using mmap_write_lock() was my initial fix and there was a strong pushback
> on this approach due to its potential impact on performance.
>From whom?
Somebody who doesn't understand that correctness is more important
than performance? And th
On Mon, Dec 21, 2020 at 12:21 PM Yu Zhao wrote:
>
> Well, unfortunately we have places that use optimizations like
>
> inc_tlb_flush_pending()
> lock page table
> pte_wrprotect
> flush_tlb_range()
> dec_tlb_flush_pending()
>
> which complicate things.
My point is, none of that ma
On Mon, Dec 21, 2020 at 11:16 AM Yu Zhao wrote:
>
> Nadav Amit found memory corruptions when running userfaultfd test above.
> It seems to me the problem is related to commit 09854ba94c6a ("mm:
> do_wp_page() simplification"). Can you please take a look? Thanks.
>
> TL;DR: it may not safe to make
On Sun, Dec 20, 2020 at 5:52 PM Stephen Boyd wrote:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git
> tags/clk-for-linus
Of 134 non-merge commits, 22 were committed in the last 48 hours.
I took this, but I'm somewhat pissed off about this. And the next
person who does this t
On Mon, Dec 21, 2020 at 8:14 AM David Howells wrote:
>
> CONFIG_FORTIFIED_SOURCE=y now causes an oops in strnlen() from afs (see
> attached patch for an explanation). Is replacing the use with memchr() the
> right approach? Or should I be calling __real_strnlen() or whatever it's
> called?
Ugh.
On Sun, Dec 20, 2020 at 10:22 AM Willem de Bruijn
wrote:
>
> Slightly tangential, it's not immediately clear to me why in
> arch/x86/entry/syscalls/syscall_32.tbl epoll_pwait does not need a
> compat entry, unlike on other architectures and unlike signalfd.
Hmm. Good question. That looks like a b
On Sun, Dec 20, 2020 at 12:14 PM Arnd Bergmann wrote:
>
> The sigset_t argument is actually compatible between x86-32 and x86-64
Well, random high bits in size_t or the pointer value aren't. So it
still looks a bit iffy to me.
But it might end up working almost by accident.
Linus
On Sat, Dec 19, 2020 at 2:12 PM Alexandre Belloni
wrote:
>
> Here is the RTC pull request for 5.11. There is a non trivial conflict
> with the tip tree in include/linux/rtc.h.
Heh. That was actually a trivial one - just changes next to each
other, nothing odd.
It just looked scary because of one
On Sat, Dec 19, 2020 at 4:41 AM Kirill A. Shutemov wrote:
>
> @@ -2884,19 +2966,18 @@ void filemap_map_pages(struct vm_fault *vmf,
> if (vmf->pte)
> vmf->pte += xas.xa_index - last_pgoff;
> last_pgoff = xas.xa_index;
> - if (all
On Sat, Dec 19, 2020 at 4:41 AM Kirill A. Shutemov wrote:
>
> Okay, but we only win the NULL check. xas_retry() and xa_is_value() has to
> be repeated in the beginning of the loop.
Yeah.
I wonder if it might make sense to have a "xas_next_entry_rcu()"
function that does something like
while
On Fri, Dec 18, 2020 at 4:57 PM Thierry Reding wrote:
>
> I didn't realize that this would show up as all new commits. The reason
> why this happens is because the first commit in the tree is a fix for an
> issue for which Uwe had sent an alternative patch to you directly for
> inclusion in v5.10.
On Fri, Dec 18, 2020 at 8:04 AM Thierry Reding wrote:
>
> This is a fairly big release cycle from the PWM framework's point of
> view.
Why does all of this have commit dates from the last day?
It clearly cannot have been in linux-next in this form, at least.
I pulled and then unpulled. Don't se
On Fri, Dec 18, 2020 at 3:04 AM Kirill A. Shutemov wrote:
>
> This should do. See below.
Looks fine.
> > Then that second loop very naturally becomes a "do { } while ()" one.
>
> I don't see it. I haven't found a reasonable way to rework it do-while.
Now that you return early for the "HEAD == N
On Wed, Dec 16, 2020 at 12:23 PM Kees Cook wrote:
>
> Hmm. Yeah, that's a bug. I think that's an existing bug, though. I feel
> like I scratched my head on that too. I will see if there is a sensible
> way to have Kbuild "notice" that -- I hope there's an easier way to
> invalidate all object file
On Fri, Dec 18, 2020 at 7:33 AM Jon Hunter wrote:
>
> However, if you are saying that this is a problem/bug with our builders,
> then of course we will have to get this fixed.
This seems to be a package dependency problem with the gcc plugins -
they clearly want libgmp, but apparently the package
iam Cohen wrote:
> >
> > On 10/27/20 12:54 PM, Linus Torvalds wrote:
> > >
> > > I think the user-space "oprofile" program doesn't actually use the
> > > legacy kernel code any more, and hasn't for a long time.
> >
> > Yes,
On Thu, Dec 17, 2020 at 10:05 AM Trond Myklebust
wrote:
>
> git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-
> 5.11-1
>
> for you to fetch changes up to
> 52104f274e2d7f134d34bab11cada8913d4544e2:
pr-tracker-bot doesn't seem to have reacted to this email.
I suspect it's bec
On Thu, Dec 17, 2020 at 2:54 AM Kirill A. Shutemov wrote:
>
> Also if the range doesn't have a mappable page we would setup a page
> table into the PMD entry. It means we cannot have huge page mapped there
> later. It may be a bummer: getting the page table out of page table tree
> requires mmap_w
On Thu, Dec 17, 2020 at 9:27 AM Linus Torvalds
wrote:
>
> So I think I'll just apply this patch instead.
Commit d652d5f1eeeb ("drm/edid: fix objtool warning in
drm_cvt_modes()") has the long and boring explanation.
Linus
On Thu, Dec 17, 2020 at 8:25 AM Josh Poimboeuf wrote:
>
> Oh yeah, I forgot about that. That would be another option if my patch
> doesn't work out.
Well, one option is to just say "ok, we know gcc generates horrible
code that falls through to another function in a situation that we
claim is unr
On Wed, Dec 16, 2020 at 2:10 PM Will Deacon wrote:
>
> Brill, cheers. I didn't realise you were going by subsystem, so that's
> why I was getting worried.
My "by subsystem" is a bit fuzzy, and it only really happens when I
have a _lot_ of pending pull requests. Which this merge window has had
mor
On Wed, Dec 16, 2020 at 2:04 PM Mark Rutland wrote:
>
> Unfortunately the merge resolution broke the build for arm64 -- could
> you please apply the fixup below? IIUC that matches what we did in
> linux-next, and builds fine locally.
Oops. That was a bit too subtle. I didn't realize that the bits
On Wed, Dec 16, 2020 at 10:54 AM Will Deacon wrote:
>
> I'm hoping to wind down a bit next week (ho ho ho), so I just wanted to
> check whether this had got caught in your spam filters, whether you wanted
> me to change something or whether you're just snowed under in pull requests.
No, it didn't
On Wed, Dec 16, 2020 at 12:23 PM Kees Cook wrote:
>
> Hmm. Yeah, that's a bug. I think that's an existing bug, though. I feel
> like I scratched my head on that too. I will see if there is a sensible
> way to have Kbuild "notice" that -- I hope there's an easier way to
> invalidate all object file
On Tue, Dec 15, 2020 at 12:15 PM Kees Cook wrote:
>
> Please pull these gcc-plugins updates for v5.11-rc1.
Hmm, I pulled this and then did an allmodconfig build.
I expected that to be a full rebuild, since the plugins got
recompiled, but it turned out to just take 16 seconds because it only
comp
On Wed, Dec 16, 2020 at 9:07 AM Kirill A. Shutemov wrote:
>
> If this looks fine, I'll submit a proper patch.
That patch looks good to me.
It would be good if somebody else looked it through - maybe I like it
just because I got to pee in the snow and make my mark. But i think
that filemap_map_pa
On Tue, Dec 15, 2020 at 8:49 PM Josh Poimboeuf wrote:
>
> But yeah, it _might_ be possible to make objtool a little smarter here.
> Gimme the .o file and I can take a look tomorrow.
Hmm. I tried to send it to you, but then I get a bounce with
554 Email rejected due to security policies
becaus
I only see this on my laptop, but that's probably because my desktop
is built using clang. So it's a gcc code generation interaction, I
suspect..
Anyway, the new warning is
drivers/gpu/drm/drm_edid.o: warning: objtool: do_cvt_mode() falls
through to next function drm_mode_detailed.isra.0()
a
On Tue, Dec 15, 2020 at 3:00 PM Eric W. Biederman wrote:
>
> There is a minor conflict with parallel changes to the bpf task_iter
> code. The changes don't fundamentally conflict but both are removing
> code from same areas of the same function.
Ok, that was somewhat confusing.
I think I got it
On Tue, Dec 15, 2020 at 2:44 PM Eric W. Biederman wrote:
>
> Most of this I believe has already come in through Catalin Marinas pull
> request "arm64 updates for 5.11".
Yeah, pretty much all got merged that way earlier, so I edited your
email heavily for the one remaining part that this pull brou
On Tue, Dec 15, 2020 at 2:48 PM Alejandro Colomar (man-pages)
wrote:
>
> 1) Remove that paragraph, as if that behavior had never existed.
If it's been 15 years since that paragraph was relevant, I think just
removing it is the right thing to do.
Linus
On Mon, Dec 14, 2020 at 4:43 AM Hans de Goede wrote:
>
> - New Intel PMT telemetry and crashlog drivers
These have _very_ annoying Kconfig setups.
First it asks about INTEL_PMT support.
If you say no, it then asks about INTEL_PMT_CLASS, INTEL_PMT_TELEMETRY
and INTEL_PMT_CRASHLOG support.
I've
On Mon, Dec 14, 2020 at 6:47 AM Mark Brown wrote:
>
> There was also an addition and revert of use of the new Soundwire
> support for RT715 due to build issues with the driver built in, my tests
> only covered building it as a module, the patch wasn't just dropped as
> it had already been merged e
On Tue, Dec 15, 2020 at 3:48 AM Greg KH wrote:
>
> Linus, your call.
This showed up in my build testing and I fixed it in the merge. No
problem, but thanks to Stephen for tracking these things.
Linus
On Mon, Dec 14, 2020 at 12:25 PM Thomas Gleixner wrote:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> irq-core-2020-12-14
What?
This is completely broken, and doesn't even build.
In particular, look at commit a07d244f00de ("genirq: Move
irq_set_lockdep_class() to core"). L
On Mon, Dec 14, 2020 at 5:27 AM Christian Brauner
wrote:
>
> /* Conflicts */
> At the time of creating this PR no merge conflicts were reported from
> linux-next and no merge conflict with 2c85ebc57b3e ("Linux 5.10") when
> pulling the tag.
Really? It conflicted with your own time namespace fixes
On Mon, Dec 14, 2020 at 10:29 AM Catalin Marinas
wrote:
>
> 114 files changed, 2392 insertions(+), 1401 deletions(-)
My diffstat looked quite different, but that turns out to be because
you use "-C" to generate your patches with not just renames, but file
copies as well.
That's all fine, but ca
On Mon, Dec 14, 2020 at 2:29 PM Alex Deucher wrote:
>
> The relevant fixes are:
Ok, I can confirm that applying those two patches gets my workstation
working properly again.
Would it be possible to get those submitted properly (or I can just
take them as-is, but would like to get a "please just
On Thu, Dec 10, 2020 at 7:52 PM Dave Airlie wrote:
>
> This is an early pull request for drm for 5.11 merge window. I'm going
> to be out for most of the first week of the merge window so thought
> I'd just preempt things and send this early.
Ok, I've merged this, and Dave is likely gone already,
On Mon, Dec 14, 2020 at 12:49 PM Linus Torvalds
wrote:
>
> I suspect the fix is trivial (change the "," to "|"), but I will not
> be pulling this - or anything else that hasn't been in linux-next -
> from you this merge window.
It looks like Stephen Rothwel
On Mon, Dec 14, 2020 at 2:04 AM David Howells wrote:
>
> Here's a set of minor fixes/cleanups that I've collected from various
> people for the next merge window.
This doesn't even build.
And no, that's not because of some merge error on my part. Just to
verify, I tried to build the head of what
On Mon, Dec 14, 2020 at 8:07 AM Kirill A. Shutemov wrote:
>
> Here it is. Still barely tested.
Ok, from looking at the patch (not applying it and looking at the end
result), I think the locking - at least for the filemap_map_pages()
case - is a lot easier to understand.
So you seem to have fixed
401 - 500 of 8741 matches
Mail list logo
