Re: [GIT PULL] xfs: fixes for v4.20-rc6

2018-12-08 Thread Linus Torvalds
On Sat, Dec 8, 2018 at 8:36 AM Darrick J. Wong wrote: > > Finally, the most important fix is to the pipe splicing code (aka the > generic copy_file_range fallback) to avoid pointless short directio > reads by only asking the filesystem for as much data as there are > available pages in the pipe

Re: [patch for-4.20] Revert "mm, thp: consolidate THP gfp handling into alloc_hugepage_direct_gfpmask"

2018-12-07 Thread Linus Torvalds
On Fri, Dec 7, 2018 at 2:27 PM David Rientjes wrote: > > I noticed the race in 89c83fb539f9 ("mm, thp: consolidate THP gfp handling > into alloc_hugepage_direct_gfpmask") that is fixed by the revert, but as > you noted it didn't cleanup the second part which is the balancing act for > gfp flags

Re: [PATCH v2] x86/fault: Decode and print #PF oops in human readable form

2018-12-07 Thread Linus Torvalds
On Fri, Dec 7, 2018 at 2:06 PM Sean Christopherson wrote: > > Looking at it again, my own personal preference would be to swap the order > of the #PF lines. Yeah, probably. Also: > [ 160.246820] BUG: unable to handle kernel paging request at beef > [ 160.247517] #PF:

Re: [PATCH v2] x86/fault: Decode and print #PF oops in human readable form

2018-12-07 Thread Linus Torvalds
On Fri, Dec 7, 2018 at 11:52 AM Sean Christopherson wrote: > > Remove the per-bit decoding of the error code and instead print: The patch looks fine to me, so feel free to add an acked-by, but: (a) I'm not the one who wanted the human-legible version in the first place, since I'm also

Re: [PATCH] x86/fault: Decode and print #PF oops in human readable form

2018-12-07 Thread Linus Torvalds
On Fri, Dec 7, 2018 at 10:44 AM Sean Christopherson wrote: > > Remove the per-bit decoding of the error code and instead print the raw > error code followed by a brief description of what caused the fault, the > effective privilege level of the faulting access, and whether the fault > originated

Re: MADV_HUGEPAGE vs. NUMA semantic (was: Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression)

2018-12-06 Thread Linus Torvalds
[ Oops. different thread for me due to edited subject, so I saw this after replying to the earlier email by David ] On Thu, Dec 6, 2018 at 1:14 AM Michal Hocko wrote: > > MADV_HUGEPAGE changes the picture because the caller expressed a need > for THP and is willing to go extra mile to get it.

Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression

2018-12-06 Thread Linus Torvalds
On Thu, Dec 6, 2018 at 3:43 PM David Rientjes wrote: > > On Broadwell, the access latency to local small pages was +5.6%, remote > hugepages +16.4%, and remote small pages +19.9%. > > On Naples, the access latency to local small pages was +4.9%, intrasocket > hugepages +10.5%, intrasocket small

Re: [PATCH] x86/mm/fault: Streamline the fault error_code decoder some more

2018-12-06 Thread Linus Torvalds
On Thu, Dec 6, 2018 at 12:28 PM Andy Lutomirski wrote: > > "read" isn't an actual bit in the error code, so I thought it would be > polite to make it look a little bit different. If you care about the bits in the error code, then just look at the number. And if you care about what the numbers

Re: [PATCH] x86/mm/fault: Streamline the fault error_code decoder some more

2018-12-06 Thread Linus Torvalds
On Thu, Dec 6, 2018 at 11:07 AM Andy Lutomirski wrote: > > How do you like the attached patch? I agree with whoever thought it's odd that "read" is in lower case when everything else is in upper case. And honestly, I'd just siggest making the err_text simply have the real user/kernel difference

Re: siginfo pid not populated from ptrace?

2018-12-06 Thread Linus Torvalds
On Thu, Dec 6, 2018 at 6:40 AM Eric W. Biederman wrote: > > We have in the past had ptrace users that weren't just about debugging > so I don't know that it is fair to just dismiss it as debugging > infrastructure. Absolutely. Some uses are more than just debug. People occasionally use ptrace

Re: [RFC] avoid indirect calls for DMA direct mappings

2018-12-06 Thread Linus Torvalds
On Thu, Dec 6, 2018 at 10:28 AM Linus Torvalds wrote: > > Put another way, you made the fast case unnecessarily slow. Side note: the code seems to be a bit confused about it, because *some* cases test the fast case first, and some do it after they've already accessed the pointer for th

Re: [PATCH] x86/mm/fault: Streamline the fault error_code decoder some more

2018-12-06 Thread Linus Torvalds
On Wed, Dec 5, 2018 at 11:34 PM Ingo Molnar wrote: > > Yeah, so I don't like the overly long 'SUPERVISOR' and the somewhat > inconsistent, sporadic handling of negatives. Here's our error code bits: > > /* > * Page fault error code bits: > * > * bit 0 ==0: no page found 1:

Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression

2018-12-05 Thread Linus Torvalds
On Wed, Dec 5, 2018 at 3:51 PM Linus Torvalds wrote: > > Ok, I've applied David's latest patch. > > I'm not at all objecting to tweaking this further, I just didn't want > to have this regression stand. Hmm. Can somebody (David?) also perhaps try to state what the different late

Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression

2018-12-05 Thread Linus Torvalds
On Wed, Dec 5, 2018 at 3:36 PM Andrea Arcangeli wrote: > > Like said earlier still better to apply __GFP_COMPACT_ONLY or David's > patch than to return to v4.18 though. Ok, I've applied David's latest patch. I'm not at all objecting to tweaking this further, I just didn't want to have this

Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression

2018-12-05 Thread Linus Torvalds
On Wed, Dec 5, 2018 at 12:40 PM Andrea Arcangeli wrote: > > So ultimately we decided that the saner behavior that gives the least > risk of regression for the short term, until we can do something > better, was the one that is already applied upstream. You're ignoring the fact that people *did*

Re: [PATCH] x86/fault: Print "SUPERVISOR" and "READ" when decoding #PF oops

2018-12-05 Thread Linus Torvalds
On Wed, Dec 5, 2018 at 11:27 AM Randy Dunlap wrote: > > BTW, what does PK mean? "Protection Key" Linus

Re: [PATCH] Revert "exec: make de_thread() freezable (was: Re: Linux 4.20-rc4)

2018-12-04 Thread Linus Torvalds
On Tue, Dec 4, 2018 at 11:49 AM Linus Torvalds wrote: > > because honestly, the *only* reason we hold on to that lock is for the > insane and not really interesting case of "somebody tried to use > ptrace to change the creds in-flight during the exec". No, sorry, me confuse

Re: [PATCH] Revert "exec: make de_thread() freezable (was: Re: Linux 4.20-rc4)

2018-12-04 Thread Linus Torvalds
On Tue, Dec 4, 2018 at 11:33 AM Linus Torvalds wrote: > > Looking at this, I'm agreeing that ot would be better to just try to > narrow down the cred_guard_mutex use a lot. Ho humm. This is a crazy idea, but I don't see why it wouldn't work. How about we: - stop holding on to cred_gu

Re: [PATCH] Revert "exec: make de_thread() freezable (was: Re: Linux 4.20-rc4)

2018-12-04 Thread Linus Torvalds
On Tue, Dec 4, 2018 at 10:17 AM Michal Hocko wrote: > > > How about something like we set PF_NOFREEZE when we set PF_EXITING? At > > that point we've pretty much turned into a kernel thread, no? > > Hmm, that doesn't sound like a bad idea but I am not sure it will > help because those threads we

Re: [PATCH] Revert "exec: make de_thread() freezable (was: Re: Linux 4.20-rc4)

2018-12-04 Thread Linus Torvalds
On Tue, Dec 4, 2018 at 1:58 AM Michal Hocko wrote: > > AFAIU both suspend and hibernation require the system to enter quiescent > state with no task potentially interfering with suspended devices. And > in this particular case those de-thread-ed threads will certainly not > interfere so silencing

Re: [patch V2 27/28] x86/speculation: Add seccomp Spectre v2 user space protection mode

2018-12-04 Thread Linus Torvalds
On Mon, Dec 3, 2018 at 5:38 PM Tim Chen wrote: > > To make the usage of STIBP and its working principles clear, > here are some additional explanations of STIBP from our Intel > HW architects. This should also help answer some of the questions > from Thomas and others on STIBP's usages with IBPB

Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression

2018-12-03 Thread Linus Torvalds
On Mon, Dec 3, 2018 at 2:04 PM Linus Torvalds wrote: > > so I think all of David's patch is somewhat sensible, even if that > specific "order == pageblock_order" test really looks like it might > want to be clarified. Side note: I think maybe people should just look at

Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression

2018-12-03 Thread Linus Torvalds
On Mon, Dec 3, 2018 at 12:12 PM Andrea Arcangeli wrote: > > On Mon, Dec 03, 2018 at 11:28:07AM -0800, Linus Torvalds wrote: > > > > One is the patch posted by Andrea earlier in this thread, which seems > > to target just this known regression. > > For the short term

Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression

2018-12-03 Thread Linus Torvalds
On Mon, Dec 3, 2018 at 10:59 AM Michal Hocko wrote: > > You are misinterpreting my words. I haven't dismissed anything. I do > recognize both usecases under discussion. > > I have merely said that a better THP locality needs more work and during > the review discussion I have even volunteered to

Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression

2018-12-03 Thread Linus Torvalds
On Mon, Dec 3, 2018 at 10:30 AM Michal Hocko wrote: > > I do not get it. 5265047ac301 which this patch effectively reverts has > regressed kvm workloads. People started to notice only later because > they were not running on kernels with that commit until later. We have > 4.4 based kernels

Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression

2018-12-03 Thread Linus Torvalds
On Mon, Dec 3, 2018 at 10:15 AM Michal Hocko wrote: > > The thing is that there is no universal win here. There are two > different types of workloads and we cannot satisfy both. Ok, if that's the case, then I'll just revert the commit. Michal, our rules are very simple: we don't generate

Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression

2018-12-03 Thread Linus Torvalds
On Wed, Nov 28, 2018 at 8:48 AM Linus Torvalds wrote: > > On Tue, Nov 27, 2018 at 7:20 PM Huang, Ying wrote: > > > > In general, memory allocation fairness among processes should be a good > > thing. So I think the report should have been a "performance > > i

Re: [RFC PATCH 1/1] epoll: use rwlock in order to reduce ep_poll_callback() contention

2018-12-03 Thread Linus Torvalds
On Mon, Dec 3, 2018 at 3:03 AM Roman Penyaev wrote: > > Also I'm not quite sure where to put very special lockless variant > of adding element to the list (list_add_tail_lockless() in this > patch). Seems keeping it locally is safer. That function is scary, and can be mis-used so easily that I

Re: [PATCH] Revert "exec: make de_thread() freezable (was: Re: Linux 4.20-rc4)

2018-12-03 Thread Linus Torvalds
On Mon, Dec 3, 2018 at 6:17 AM Michal Hocko wrote: > > This argument just doesn't make any sense. Rare bugs are maybe even more > annoying because you do not expect them to happen. Absolutely. And valid lockdep complaints are a real issue too. So I don't think there's any question that this

Linux 4.20-rc5

2018-12-02 Thread Linus Torvalds
KVM: nVMX/nSVM: Fix bug which sets vcpu->arch.tsc_offset to L1 tsc_offset Li Zhijian (2): kselftests/bpf: use ping6 as the default ipv6 ping binary when it exists initramfs: clean old path before creating a hardlink Lihong Yang (1): i40e: Fix deletion of MAC filters Linus

Re: [GIT PULL] Driver core fix for 4.20-rc5

2018-11-30 Thread Linus Torvalds
On Fri, Nov 30, 2018 at 8:06 AM Greg KH wrote: > > It resolves an issue with the data alignment in 'struct devres' for the > ARC platform. The full details are in the commit changelog, but the > short summary is the change is a single line: > > - unsigned long long data[]; /*

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-30 Thread Linus Torvalds
On Fri, Nov 30, 2018 at 10:39 AM Josh Poimboeuf wrote: > > AFAICT, all the other proposed options seem to have major issues. I still absolutely detest this patch, and in fact it got worse from the test of the config variable. Honestly, the entry code being legible and simple is more important

Re: [PATCH 0/2] [GIT PULL] tracing: More fixes for 4.20

2018-11-30 Thread Linus Torvalds
On Fri, Nov 30, 2018 at 9:41 AM Linus Torvalds wrote: > > I went back and merged things [..] Note that I did this as two merges, even if one would have done (since the second pull request was just adding new commits on top of the first). This way I got the matching diffstat from you

Re: [PATCH 0/2] [GIT PULL] tracing: More fixes for 4.20

2018-11-30 Thread Linus Torvalds
On Thu, Nov 29, 2018 at 7:19 PM Steven Rostedt wrote: > > Note, this is on top of a previous git pull that I have submitted: > > http://lkml.kernel.org/r/20181127224031.76681...@vmware.local.home Hmm. I had dismissed that, because the patch descriptors for that series had had "for-next" in

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Linus Torvalds
On Thu, Nov 29, 2018 at 12:25 PM Josh Poimboeuf wrote: > > On Thu, Nov 29, 2018 at 11:27:00AM -0800, Andy Lutomirski wrote: > > > > I propose a different solution: > > > > As in this patch set, we have a direct and an indirect version. The > > indirect version remains exactly the same as in this

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Linus Torvalds
On Thu, Nov 29, 2018 at 11:16 AM Steven Rostedt wrote: > > But then we need to implement all numbers of parameters. Oh, I agree, it's nasty. But it's actually a nastiness that we've solved before. In particular, with the system call mappings, which have pretty much the exact same issue of "map

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Linus Torvalds
On Thu, Nov 29, 2018 at 11:08 AM Linus Torvalds wrote: > > What you can do then is basically add a single-byte prefix to the > "call" instruction that does nothing (say, cs override), and then > replace *that* with a 'int3' instruction. Hmm. the segment prefixes are documen

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Linus Torvalds
On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds wrote: > > In contrast, if the call was wrapped in an inline asm, we'd *know* the > compiler couldn't turn a "call wrapper(%rip)" into anything else. Actually, I think I have a better model - if the caller is done with inline as

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Linus Torvalds
On Thu, Nov 29, 2018 at 10:47 AM Steven Rostedt wrote: > > Note, we do have a bit of control at what is getting called. The patch > set requires that the callers are wrapped in macros. We should not > allow just any random callers (like from asm). Actually, I'd argue that asm is often more

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Linus Torvalds
On Thu, Nov 29, 2018 at 10:00 AM Andy Lutomirski wrote: > > then it really sounds pretty safe to just say "ok, just make it > > aligned and update the instruction with an atomic cmpxchg or > > something". > > And how do we do that? With a gcc plugin and some asm magic? Asm magic. You already

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Linus Torvalds
On Thu, Nov 29, 2018 at 9:59 AM Steven Rostedt wrote: > > Do you realize that the cmpxchg used by the first attempts of the > dynamic modification of code by ftrace was the source of the e1000e > NVRAM corruption bug. If you have a static call in IO memory, you have bigger problems than that.

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Linus Torvalds
On Thu, Nov 29, 2018 at 9:50 AM Linus Torvalds wrote: > > - corrupt random registers because we "know" they aren't in use Just to clarify: I think that's a completely unacceptable model. We already have lots of special calling conventions, including ones that do not have an

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Linus Torvalds
On Thu, Nov 29, 2018 at 9:44 AM Steven Rostedt wrote: > > Well, the current method (as Jiri mentioned) did get the OK from at > least Intel (and that was with a lot of arm twisting to do so). Guys, when the comparison is to: - create a huge honking security hole by screwing up the stack frame

Re: remove the ->mapping_error method from dma_map_ops V2

2018-11-29 Thread Linus Torvalds
On Thu, Nov 29, 2018 at 8:23 AM Christoph Hellwig wrote: > > We can. At least in theory. The problem is that depending on the > crazy mapping from physical and kernel virtual address to dma addresses > these might be pages at pretty random places. Look at fun like >

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Linus Torvalds
On Thu, Nov 29, 2018 at 9:13 AM Steven Rostedt wrote: > > No, we really do need to sync after we change the second part of the > command with the int3 on it. Unless there's another way to guarantee > that the full instruction gets seen when we replace the int3 with the > finished command. Making

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Linus Torvalds
On Thu, Nov 29, 2018 at 9:02 AM Andy Lutomirski wrote: > > > > - just restart the instruction (with the suggested "ptregs->rip --") > > > > - to avoid any "oh, we're not making progress" issues, just fix the > > instruction yourself to be the right call, by looking it up in the > > "what needs to

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Linus Torvalds
On Thu, Nov 29, 2018 at 8:33 AM Josh Poimboeuf wrote: > > This seems to work... > > + .if \create_gap == 1 > + .rept 6 > + pushq 5*8(%rsp) > + .endr > + .endif > + > -idtentry int3 do_int3 has_error_code=0 > +idtentry int3

Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression

2018-11-28 Thread Linus Torvalds
On Tue, Nov 27, 2018 at 7:20 PM Huang, Ying wrote: > > From the above data, for the parent commit 3 processes exited within > 14s, another 3 exited within 100s. For this commit, the first process > exited at 203s. That is, this commit makes memory allocation more fair > among processes, so that

Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression

2018-11-27 Thread Linus Torvalds
On Tue, Nov 27, 2018 at 12:57 PM Andrea Arcangeli wrote: > > This difference can only happen with defrag=always, and that's not the > current upstream default. Ok, thanks. That makes it a bit less critical. > That MADV_HUGEPAGE causes flights with NUMA balancing is not great > indeed, qemu

Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression

2018-11-27 Thread Linus Torvalds
On Mon, Nov 26, 2018 at 10:24 PM kernel test robot wrote: > > FYI, we noticed a -61.3% regression of vm-scalability.throughput due > to commit ac5b2c18911f ("mm: thp: relax __GFP_THISNODE for > MADV_HUGEPAGE mappings") Well, that's certainly noticeable and not good. Andrea, I suspect it might

Re: [PATCHi v2] mm: put_and_wait_on_page_locked() while page is migrated

2018-11-27 Thread Linus Torvalds
On Tue, Nov 27, 2018 at 8:49 AM Christopher Lameter wrote: > > A process has no refcount on a page struct and is waiting for it to become > unlocked? Why? Should it not simply ignore that page and continue? The problem isn't that you can just "continue". You need to *retry*. And you can't just

Re: [PATCH 4/8] HID: input: use the Resolution Multiplier for high-resolution scrolling

2018-11-26 Thread Linus Torvalds
On Thu, Nov 22, 2018 at 3:28 PM Peter Hutterer wrote: > > The device sends hi-res values of 4, so it should end up as REL_WHEEL_HI_RES > 30. We are getting 28 instead which doesn't add up to a nice 120. I think you're just doing the math in the wrong order. Why don't you just do update =

Re: [PATCHi v2] mm: put_and_wait_on_page_locked() while page is migrated

2018-11-26 Thread Linus Torvalds
On Mon, Nov 26, 2018 at 11:27 AM Hugh Dickins wrote: > > +enum behavior { > + EXCLUSIVE, /* Hold ref to page and take the bit when woken, like > +* __lock_page() waiting on then setting PG_locked. > +*/ > + SHARED, /* Hold

Linux 4.20-rc4

2018-11-25 Thread Linus Torvalds
n Khlebnikov (1): tools/power/cpupower: fix compilation with STATIC=true Kuppuswamy Sathyanarayanan (1): usb: dwc3: Fix NULL pointer exception in dwc3_pci_remove() Linus Torvalds (1): Linux 4.20-rc4 Lorenzo Bianconi (3): mt76: fix uninitialized mutex access setting rts thresh

Re: [patch V2 27/28] x86/speculation: Add seccomp Spectre v2 user space protection mode

2018-11-25 Thread Linus Torvalds
[ You forgot to fix your quilt setup.. ] On Sun, 25 Nov 2018, Thomas Gleixner wrote: > > The mitigation guide documents how STIPB works: > >Setting bit 1 (STIBP) of the IA32_SPEC_CTRL MSR on a logical processor >prevents the predicted targets of indirect branches on any logical >

Re: [PATCH] mm: put_and_wait_on_page_locked() while page is migrated

2018-11-25 Thread Linus Torvalds
On Sat, Nov 24, 2018 at 7:21 PM Hugh Dickins wrote: > > Linus, I'm addressing this patch to you because I see from Tim Chen's > thread that it would interest you, and you were disappointed not to > root cause the issue back then. I'm not pushing for you to fast-track > this into 4.20-rc, but I

Re: [GIT PULL] XArray updates

2018-11-24 Thread Linus Torvalds
On Sat, Nov 24, 2018 at 7:00 PM Matthew Wilcox wrote: > > I pushed it out to hkps://hkps.pool.sks-keyservers.net ... as I recall, > pgp.mit.edu is frequently not synchronised well with the other keyservers, > but I'm surprised that one of the sks-keyservers didn't have it. I got it now, so it

Re: [GIT PULL] XArray updates

2018-11-24 Thread Linus Torvalds
On Sat, Nov 24, 2018 at 6:38 PM Matthew Wilcox wrote: > > I generated a new key 5EC42E41545C1F5E and signed a new tag > xarray-4.20-rc4 Hmm. Did you publicize it on any keyservers? I'm not finding the key on pgp.mit.edu or on the sks-keyservers.net pool.. > I've signed that key with my old DSA

Re: [GIT PULL] XArray updates

2018-11-24 Thread Linus Torvalds
On Sat, Nov 24, 2018 at 9:32 AM Matthew Wilcox wrote: > > git://git.infradead.org/users/willy/linux-dax.git xarray Can you *please* make that a signed tag. I don't trust infradead.org implicitly, so I really want signed tag pull requests. I may not always notice, but when I do, I abort the

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-23 Thread Linus Torvalds
On Fri, Nov 23, 2018 at 10:39 AM Andy Lutomirski wrote: > > What is memcpy_to_io even supposed to do? I’m guessing it’s defined as > something like “copy this data to IO space using at most long-sized writes, > all aligned, and writing each byte exactly once, in order.” That sounds... >

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-23 Thread Linus Torvalds
On Fri, Nov 23, 2018 at 8:36 AM Linus Torvalds wrote: > > Let me write a generic routine in lib/iomap_copy.c (which already does > the "user specifies chunk size" cases), and hook it up for x86. Something like this? ENTIRELY UNTESTED! It might not compile. Seriously. And

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-23 Thread Linus Torvalds
On Fri, Nov 23, 2018 at 2:12 AM David Laight wrote: > > I've just patched my driver and redone the test on a 4.13 (ubuntu) kernel. > Calling memcpy_fromio(kernel_buffer, PCIe_address, length) > generates a lot of single byte TLP. I just tested it too - it turns out that the __inline_memcpy()

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-22 Thread Linus Torvalds
On Thu, Nov 22, 2018 at 10:07 AM Andy Lutomirski wrote: > > I'm not personally volunteering, but I suspect we can do much better > than we do now: > > - The new MOVDIRI and MOVDIR64B instructions can do big writes to WC > and UC memory. > > - MOVNTDQA can, I think, do 64-byte loads, but only

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-22 Thread Linus Torvalds
On Thu, Nov 22, 2018 at 9:36 AM David Laight wrote: > > The other problem with the ERMS copy is that it gets used > for copy_to/from_io() - and the 'rep movsb' on uncached > locations has to do byte copies. Ugh. I thought we changed that *long* ago, because even our non-ERMS copy is broken for

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-22 Thread Linus Torvalds
On Thu, Nov 22, 2018 at 9:26 AM Andy Lutomirski wrote: > > So I think your patch is viable. Also, with that patch applied, > put_user_ex() should become worse than worthless Yes. I hate those special-case _ex variants. I guess I should just properly forward-port my patch series where the

Re: [PATCH 8/8] HID: logitech: Enable high-resolution scrolling on Logitech mice

2018-11-22 Thread Linus Torvalds
On Wed, Nov 21, 2018 at 10:35 PM Peter Hutterer wrote: > > This patch is a combinations of the now-reverted commits 1ff2e1a44e0, > d56ca9855bf9, 5fe2ccbef9d, 044ee89028 together with some extra bits for the > directional and timeout-based reset. Instead of using an actual timer (which is quite

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-22 Thread Linus Torvalds
On Thu, Nov 22, 2018 at 2:32 AM Ingo Molnar wrote: > * Linus Torvalds wrote: > > > > Random patch (with my "asm goto" hack included) attached, in case > > people want to play with it. > > Doesn't even look all that hacky to me. Any hack in it that I didn't &g

Re: [PATCH] x86/speculation: Revert turning on STIBP all the time

2018-11-21 Thread Linus Torvalds
On Wed, Nov 21, 2018 at 12:51 PM Jiri Kosina wrote: > > For -rc, I don't think we need to do this at this moment, given the > prctl+seccomp fixup is basically ready, do we? Agreed. Linus

Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment

2018-11-21 Thread Linus Torvalds
On Wed, Nov 21, 2018 at 12:28 PM Linus Torvalds wrote: > > Ugh. Now you're using the broken quilt thing that makes a mush of emails for > me. Reading the series in alpine makes it look fine. No testing, but each patch seems sensible. And yes, triggering on seccomp makes more s

Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment

2018-11-21 Thread Linus Torvalds
On Wed, Nov 21, 2018 at 12:18 PM Thomas Gleixner wrote: > > From: Tim Chen "Reduced Data Speculation" is an obsolete term. Ugh. Now you're using the broken quilt thing that makes a mush of emails for me. Linus

Re: [Patch v6 14/16] x86/speculation: Use STIBP to restrict speculation on non-dumpable task

2018-11-21 Thread Linus Torvalds
On Wed, Nov 21, 2018 at 12:07 PM Dave Hansen wrote: > > Repurposing dumpable is really screwy and surely imprecise, but it > really is the closest thing that we have without the new ABI. But we *have* a new ABI. So that's not a valid argument. It's more like "this other thing that some other

Re: [Patch v6 14/16] x86/speculation: Use STIBP to restrict speculation on non-dumpable task

2018-11-21 Thread Linus Torvalds
On Wed, Nov 21, 2018 at 9:41 AM Tim Chen wrote: > > When STIBP is on, it will prevent not only untrusted code from attacking, > but also trusted code from getting attacked. So non-dumpable task running > with STIBP will protect itself from attacks from code running on sibling CPU. I understand.

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-21 Thread Linus Torvalds
On Wed, Nov 21, 2018 at 10:16 AM Linus Torvalds wrote: > > It might be interesting to just change raw_copy_to/from_user() to > handle a lot more cases (in particular, handle cases where 'size' is > 8-byte aligned). The special cases we *do* have may not be the right > ones (t

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-21 Thread Linus Torvalds
On Wed, Nov 21, 2018 at 10:26 AM Andy Lutomirski wrote: > > Can we maybe use this as an excuse to ask for some reasonable instructions to > access user memory? I did that long ago. It's why we have CLAC/STAC today. I was told that what I actually asked for (get an instruction to access user

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-21 Thread Linus Torvalds
On Wed, Nov 21, 2018 at 9:27 AM Linus Torvalds wrote: > > It would be interesting to know exactly which copy it is that matters > so much... *inlining* the erms case might show that nicely in > profiles. Side note: the fact that Jens' patch (which I don't like in that form) alle

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-21 Thread Linus Torvalds
On Wed, Nov 21, 2018 at 5:45 AM Paolo Abeni wrote: > > In my experiments 64 bytes was the break even point for all the CPUs I > had handy, but I guess that may change with other models. Note that experiments with memcpy speed are almost invariably broken. microbenchmarks don't show the impact of

Re: [Patch v6 14/16] x86/speculation: Use STIBP to restrict speculation on non-dumpable task

2018-11-20 Thread Linus Torvalds
On Tue, Nov 20, 2018 at 4:33 PM Tim Chen wrote: > > Implements arch_update_spec_restriction() for x86. Use STIBP to > restrict speculative execution when running a task set to non-dumpable, > or clear the restriction if the task is set to dumpable. I don't think this necessarily makes sense.

Re: STIBP by default.. Revert?

2018-11-18 Thread Linus Torvalds
On Sun, Nov 18, 2018 at 2:17 PM Jiri Kosina wrote: > Which gets us back to Tim's fixup patch. Do you still prefer the revert, > given the existence of that? I don't think the code needs to be reverted, but the *behavior* of just unconditionally enabling STIBP needs to be reverted. Because it

Linux 4.20-rc3

2018-11-18 Thread Linus Torvalds
OX Laurent Pinchart (4): drm/omap: Populate DSS children in omapdss driver drm/omap: hdmi4: Ensure the device is active during bind drm/omap: dsi: Ensure the device is active during probe drm/omap: Move DISPC runtime PM handling to omapdrm Linus Torvalds (1): Linux 4.20-rc

Re: STIBP by default.. Revert?

2018-11-18 Thread Linus Torvalds
On Sun, Nov 18, 2018 at 1:49 PM Jiri Kosina wrote: > > > So why do that STIBP slow-down by default when the people who *really* > > care already disabled SMT? > > BTW for them, there is no impact at all. Right. People who really care about security and are anal about it do not see *any*

STIBP by default.. Revert?

2018-11-18 Thread Linus Torvalds
This was marked for stable, and honestly, nowhere in the discussion did I see any mention of just *how* bad the performance impact of this was. When performance goes down by 50% on some loads, people need to start asking themselves whether it was worth it. It's apparently better to just disable

Re: Oops: 0003 [#1] PREEMPT SMP NOPTI

2018-11-16 Thread Linus Torvalds
On Thu, Nov 15, 2018 at 8:29 PM Kyle Sanderson wrote: > > 2008(!) dual-core Atom box. > [1027541.963573] BUG: unable to handle kernel paging request at > b0428a44 > [1027541.963647] IP: format_decode+0x20/0x3d0 The code decodes to: 0: 55push %rbp 1: 48 8d 2e

Linux 4.20-rc2

2018-11-11 Thread Linus Torvalds
rs Leo Li (1): drm/amd: Update atom_smu_info_v3_3 structure Leonard Crestez (1): ARM: dts: imx6sx-sdb: Fix enet phy regulator Liam Merwick (1): xen/grant-table: Fix incorrect gnttab_dma_free_pages() pr_debug message Linus Torvalds (1): Linux 4.20-rc2 Linus Walleij (1):

Re: [GIT pull] scheduler fixes for 4.20

2018-11-11 Thread Linus Torvalds
On Sun, Nov 11, 2018 at 2:11 AM Thomas Gleixner wrote: > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > sched-urgent-for-linus Hmm. I get Already up to date. with top commit being 993f0b0510da ("sched/topology: Fix off by one bug") that I already merged earlier. Did you

Re: [PULL REQUEST] i2c for 4.20

2018-11-10 Thread Linus Torvalds
On Sat, Nov 10, 2018 at 5:20 AM Wolfram Sang wrote: > > I hope the rc1 rule still applies for this new driver. It consists of the I2C > master part and UCSI client part which has the needed ack from Heikki. I've pulled it, but please don't do this again. The "New driver" rule has become pretty

Re: [GIT PULL] Devicetree fixes for 4.20-rc, round 2

2018-11-09 Thread Linus Torvalds
On Fri, Nov 9, 2018 at 3:39 PM Rob Herring wrote: > > Devicetree fixes for 4.20-rc: This pull request should be getting an automated reply once I've pushed my merge out (soon), so I won't be doing the manual "pulled" ack emails any more. If you don't see the automated reply, or you have any

Re: [GIT PULL] Ceph fixes for 4.20-rc2

2018-11-09 Thread Linus Torvalds
On Fri, Nov 9, 2018 at 10:48 AM Ilya Dryomov wrote: > > Two CephFS fixes (copy_file_range and quota) and a small feature bit > cleanup. .. I'm doing a few final manual "pulled" ack emails just to let people know that I'll be stopping them, because Konstantin's pr-tracker-bot automation should

Re: [PATCH 3/3] lockdep: Use line-buffered printk() for lockdep messages.

2018-11-09 Thread Linus Torvalds
On Fri, Nov 9, 2018 at 12:12 AM Sergey Senozhatsky wrote: > > Dunno. I guess we still haven't heard from Linus because he did quite a good > job setting up his 'email filters' ;) Not filters, just long threads that I lurk on. I don't actually care too much about this - the part I care about is

Re: [GIT PULL] nds32 new features and bug fix for 4.20

2018-11-09 Thread Linus Torvalds
On Fri, Nov 9, 2018 at 4:01 AM Greentime Hu wrote: > > nds32 patches for 4.20 Much much too late for 4.20. Send these the next merge window please. Linus

Re: [GIT PULL] s390 patches for 4.20 #2

2018-11-09 Thread Linus Torvalds
On Fri, Nov 9, 2018 at 1:14 AM Martin Schwidefsky wrote: > > s390 updates for 4.20-rc2 Pulled. > - A fix for the pgtable_bytes misaccounting on s390. The patch changes >common code part in regard to page table folding and adds extra >checks to mm_[inc|dec]_nr_[pmds|puds]. Ugh. This is

Re: [GIT PULL] xfs: fixes for v4.20-rc2

2018-11-08 Thread Linus Torvalds
On Thu, Nov 8, 2018 at 4:40 PM Darrick J. Wong wrote: > > - fix incorrect dropping of error code from bmap > > - print buffer offsets instead of useless hashed pointers when dumping > corrupt metadata > > - fix integer overflow in attribute verifier Pulled, Linus

Re: [GIT PULL] LED fixes for 4.20-rc2

2018-11-08 Thread Linus Torvalds
On Thu, Nov 8, 2018 at 1:29 PM Jacek Anaszewski wrote: > > > All three fixes are related to the newly added pattern trigger: > > - remove mutex_lock() from timer callback, which would trigger problems > related to sleeping in atomic context, the removal is harmless since > mutex protection

Re: [GIT PULL] sound fixes for 4.20-rc2

2018-11-08 Thread Linus Torvalds
On Thu, Nov 8, 2018 at 10:05 AM Takashi Iwai wrote: > > sound fixes for 4.20-rc2 > > Two small regression fixes for HD-audio: one about vga_switcheroo and > runtime PM, and another about Oops on some Thinkpads. Pulled, Linus

Re: [GIT PULL] Compiler Attributes for v4.20-rc2

2018-11-08 Thread Linus Torvalds
On Thu, Nov 8, 2018 at 6:00 AM Miguel Ojeda wrote: > > A small patch for compiler-gcc.h and a trivial one for compiler_attributes.h. Pulled, Linus

Re: [GIT PULL] mtd: Fixes for 4.20-rc2

2018-11-08 Thread Linus Torvalds
On Thu, Nov 8, 2018 at 5:25 AM Boris Brezillon wrote: > > Here is the MTD fixes PR for 4.20-rc2. Pulled, Linus

Re: [GIT PULL] ARM: SoC fixes

2018-11-07 Thread Linus Torvalds
On Wed, Nov 7, 2018 at 9:10 AM Olof Johansson wrote: > > ARM: SoC fixes Pulled. > I was a bit too trigger happy to enable PREEMPT on multi_v7_defconfig, > and it ended up regressing at least BeagleBone XM boards. Odd. Did it hit some "may_sleep()" test in a driver that is hidden by preempt

Re: [GIT PULL] HID fixes

2018-11-07 Thread Linus Torvalds
On Wed, Nov 7, 2018 at 2:31 AM Jiri Kosina wrote: > > HID subsytem fixes Pulled, Linus

Re: [RFC][PATCH] tree-wide: Remove __inline__ and __inline usage

2018-11-06 Thread Linus Torvalds
On Tue, Nov 6, 2018 at 11:42 AM Peter Zijlstra wrote: > > Do you want me to do that patch, or have you already just done it? I'd rather see it go through something like -tip than doing it myself directly, and get at least some of the automated testing before unleashing it on an unsuspecting

Re: [RFC][PATCH] tree-wide: Remove __inline__ and __inline usage

2018-11-06 Thread Linus Torvalds
On Tue, Nov 6, 2018 at 2:02 AM Peter Zijlstra wrote: > > Therefore I'm proposing to run: > > git grep -l "\<__inline\(\|__\)\>" | while read file > do > sed -i -e 's/\<__inline\(\|__\)\>/inline/g' $file > done > > On your current tree, and apply the below fixup patch on top of that

Re: [GIT PULL] tracing/kprobes: Fix strpbrk() argument order

2018-11-06 Thread Linus Torvalds
On Tue, Nov 6, 2018 at 6:12 AM Steven Rostedt wrote: > > Masami found a slight bug in his code where he transposed the arguments of a > call to strpbrk. Pulled, Linus

  1   2   3   4   5   6   7   8   9   10   >