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
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
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:
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
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
[ 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.
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
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
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
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
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
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:
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
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
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*
On Wed, Dec 5, 2018 at 11:27 AM Randy Dunlap wrote:
>
> BTW, what does PK mean?
"Protection Key"
Linus
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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[]; /*
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
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
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
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
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
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
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
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
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
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.
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
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
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
>
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
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
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
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
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
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
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
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 =
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
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
[ 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
>
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
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
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
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
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...
>
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
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()
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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.
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
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
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*
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
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
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):
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
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
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
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
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
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
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
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
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
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
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
On Thu, Nov 8, 2018 at 5:25 AM Boris Brezillon
wrote:
>
> Here is the MTD fixes PR for 4.20-rc2.
Pulled,
Linus
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
On Wed, Nov 7, 2018 at 2:31 AM Jiri Kosina wrote:
>
> HID subsytem fixes
Pulled,
Linus
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
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
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 - 100 of 10980 matches
Mail list logo
