hips affected by meltdown.
And some of the powerpc64s as well.
--
Jiri Kosina
SUSE Labs
t do the
runtime PM on i2c at all?
--
Jiri Kosina
SUSE Labs
On Mon, 14 Jan 2019, Pavel Machek wrote:
> That one really is Intel-specific (not even all x86s are affectd). Same
> for Meltdown.
At least for Meltdown, your claim is simply not correct.
--
Jiri Kosina
SUSE Labs
Hi,
I've now applied this patchset, so please send any further fixups as
incremental on top of for-5.1/atomic-replace.
Thanks to everybody involved (especially Petr) for the patience and all
the invested effort.
--
Jiri Kosina
SUSE Labs
ck_irq*() and CPU#2 hits the breakpont while holding that very
'lock'.
Then we're stuck forever, because CPU#1 will never handle the pending
sync_core() IPI (it's not NMI).
Or have I misunderstood what you meant?
--
Jiri Kosina
SUSE Labs
uriosity, which repository is this from please? Even google
doesn't seem to know about this SHA.
Thanks,
--
Jiri Kosina
SUSE Labs
ed on a sysctl setting, and letting the admin choose his poison.
If 'secure' mode is selected, RWF_NOWAIT will then probably just always
fail wit EAGAIN.
--
Jiri Kosina
SUSE Labs
m, sorry for being dense, but how would that help that particular attack
scenario on a system that doesn't really employ any namespacing? (which I
still believe is a majority of the systems out there, but I might have
just missed the containers train long time ago :) ).
--
Jiri Kosina
SUSE Labs
hardware cache timing
attack anyway.
Thanks,
--
Jiri Kosina
SUSE Labs
On Tue, 8 Jan 2019, Bernd Petrovitsch wrote:
> Shouldn't the application use e.g. mlock()/ to guarantee no page
> faults in the first place?
Calling mincore() on pages you've just mlock()ed is sort of pointless
though.
--
Jiri Kosina
SUSE Labs
ting).
Hmm.
But unless it has been mapped with MAP_POPULATE (whcih is outside the
attacker's control), there is no guarantee that the mappings would
actually be there, right?
--
Jiri Kosina
SUSE Labs
.
> Who actually _uses_ mincore()? That's probably the best guide to what
> we should do. Maybe they open the file read-only even if they are the
> owner, and we really should look at file ownership instead.
Yeah, well
https://codesearch.debian.net/search?q=mincore
is a bit too much mess to get some idea quickly I am afraid.
--
Jiri Kosina
SUSE Labs
are resident (to
avoid calling process entering some prefaulting mode), or return -ENOMEM
for mappings of files that don't belong to the user (in case it's not
CAP_SYS_ADMIN one).
--
Jiri Kosina
SUSE Labs
ore()
right ?
I think userspace would hate us for that semantics, but on the other hand
I can sort of understand the 'mincore() is racy anyway, so what' argument,
if that's what you are suggesting.
But then, I have no idea what userspace is using mincore() for.
https://codesearch.debian.net/sea
From: Jiri Kosina
There are possibilities [1] how mincore() could be used as a converyor of
a sidechannel information about pagecache metadata.
Provide vm.mincore_privileged sysctl, which makes it possible to mincore()
start returning -EPERM in case it's invoked by a process lacking
: 80050033
> > 46.887: [7.882351] CR2: CR3: 0240a000 CR4:
> > 000406e0
> > 46.887: [7.889746] Kernel panic - not syncing: Attempted to kill the
> > idle task!
> > 46.888: [7.896907] Kernel Offset: disabled
> > 46.888: [7.900558] ---[ end Kernel panic - not syncing: Attempted to
> > kill the idle task! ]---
>
> Please find the whole log, including the coreboot messages, attached. The time
> stamps in the beginning are from the script `readserial.py` from the SeaBIOS
> repository.
>
> Do you have an idea what is going on, and how to fix it?
>
>
> Kind regards,
>
> Paul
>
--
Jiri Kosina
SUSE Labs
: logitech: Use LDJ_DEVICE macro for existing Logitech mice
Jiri Kosina (1):
HID: hidraw: enforce minors_lock locking via lockdep
Jonathan Davies (1):
HID: samples/hidraw: fix typo in printed message
Pan Bian (1):
HID: intel-ish-hid: fixes incorrect error handling
Peter H
On Thu, 3 Jan 2019, Jiri Kosina wrote:
> Linus,
>
> please pull from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-linus
>
> to receive HID merge window updates.
>
> =
> This round is particularly tiny. Some highlights:
>
> -
for Cougar 700K Gaming Keyboard
Hans de Goede (1):
HID: i2c-hid: Add Odys Winbook 13 to descriptor override
Jiri Kosina (1):
HID: hidraw: enforce minors_lock locking via lockdep
Jonathan Davies (1):
HID: samples/hidraw: fix typo in printed message
Pan Bian (1):
HID: intel
Guire (1):
livepatch: check kzalloc return values
samples/livepatch/livepatch-shadow-fix1.c | 5 +
samples/livepatch/livepatch-shadow-mod.c | 4
2 files changed, 9 insertions(+)
--
Jiri Kosina
SUSE Labs
On Mon, 24 Dec 2018, Aditya Pakki wrote:
> In lenovo_probe_tpkbd(), the function of_led_classdev_register() could
> return an error value that is unchecked. The fix adds these checks.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
From: Jiri Kosina
ixgbe_reset_hw_82599() resets the value of hw->mac.num_rar_entries to
pre-defined value of 128. Let's get rid of that hardcoded literal, and use
IXGBE_82599_RAR_ENTRIES instead, the same way the normal initialization
path does.
Signed-off-by: Jiri Kosina
---
drivers/
people will continue to do so until we
> have decent source-based tooling. Will the klp-convert patches be
> revived soon?
Let me add Joao, who's working on that.
Joao, I think you had something basically ready for upstream exposure,
right?
Thanks,
--
Jiri Kosina
SUSE Labs
t documented in the
changelog.
(*) actually measured already for some subset of the IPA optimizations
Thanks,
--
Jiri Kosina
SUSE Labs
= seq_lseek,
> - .release= single_release,
> -};
> +DEFINE_SHOW_ATTRIBUTE(hid_debug_rdesc);
Applied to hid.git#for-4.21/core. Thanks,
--
Jiri Kosina
SUSE Labs
ort of printk_once(), so
that it's immediately apparent from dmesg that the system/device is
suffering from this particular problem? Might potentially be helpful piece
of information.
Thanks,
--
Jiri Kosina
SUSE Labs
ashin
> Cc: Masami Hiramatsu
> Cc: "Steven Rostedt (VMware)"
> Cc: Zhou Chengming
> Cc: Jiri Kosina
Acked-by: Jiri Kosina
--
Jiri Kosina
SUSE Labs
t code transformation, I
think.
Thanks,
--
Jiri Kosina
SUSE Labs
pt channel. You should read the payload and forward
> it to
> - the device. The payload is of type "struct uhid_data_req".
> + the device. The payload is of type "struct uhid_output_req".
>This may be received even though you haven't received UHID_OPEN, yet.
Applied, thanks Peter.
--
Jiri Kosina
SUSE Labs
Petr Mladek for
> catching this) and NULL returned.
>
> Signed-off-by: Nicholas Mc Guire
> Fixes: 439e7271dc2b ("livepatch: introduce shadow variable API")
Applied to for-4.21/upstream, thanks.
--
Jiri Kosina
SUSE Labs
/intel-ish-hid/ishtp-hid.c
> @@ -222,7 +222,7 @@ int ishtp_hid_probe(unsigned int cur_hid_dev,
> err_hid_device:
> kfree(hid_data);
> err_hid_data:
> - kfree(hid);
> + hid_destroy_device(hid);
> return rv;
Applied to for-4.20/upstream-fixes. Thanks,
--
Jiri Kosina
SUSE Labs
-ids.h | 7 +++
drivers/hid/hid-ite.c | 1 +
drivers/hid/hid-quirks.c | 2 ++
include/uapi/linux/input-event-codes.h | 9 +
4 files changed, 19 insertions(+)
--
Jiri Kosina
SUSE Labs
On Fri, 7 Dec 2018, Benjamin Tissoires wrote:
> OK, thanks Dmitry.
>
> Jiri, I have pushed this in for-4.20/upstream-fixes.
>
> I think the branch has enough now to justify a PR towards Linus.
Agreed. I will be sending it today. Thanks,
--
Jiri Kosina
SUSE Labs
ou have any specific wording in mind?
> > >
> > > It also drops the swap size and available RAM limit restrictions on both
> > > hypervisor and bare metal.
> > >
> > > Sounds better?
> > >
> > > > With that
> > > >
>
devastated if it
lands only in next merge window. So I'd just put it to 4.20/fixes and wait
for other more serious trigger for sending that to Linus eventually.
Thanks,
--
Jiri Kosina
SUSE Labs
Intel
> HW architects. This should also help answer some of the questions
> from Thomas and others on STIBP's usages with IBPB and IBRS.
Thanks a lot, this indeed does shed some light.
I have one question though:
[ ... snip ... ]
> On processors with enhanced IBRS support, we recommend
Intel
> HW architects. This should also help answer some of the questions
> from Thomas and others on STIBP's usages with IBPB and IBRS.
Thanks a lot, this indeed does shed some light.
I have one question though:
[ ... snip ... ]
> On processors with enhanced IBRS support, we recommend
(0xb2).
> For all I know, the SMI handler will explode and the computer will catch
> fire.
Ha, therefore noone can't claim any more that SMIs are always harmful :)
--
Jiri Kosina
SUSE Labs
(0xb2).
> For all I know, the SMI handler will explode and the computer will catch
> fire.
Ha, therefore noone can't claim any more that SMIs are always harmful :)
--
Jiri Kosina
SUSE Labs
gt;
> For both patches, actually, I'd much rather see either deletion or a
> rewrite over bleeping out words that somebody might not like.
Exactly. Turning comments into something that often doesn't make sense to
anybody at all is hardly productive.
--
Jiri Kosina
SUSE Labs
gt;
> For both patches, actually, I'd much rather see either deletion or a
> rewrite over bleeping out words that somebody might not like.
Exactly. Turning comments into something that often doesn't make sense to
anybody at all is hardly productive.
--
Jiri Kosina
SUSE Labs
when I was preparing the original
text_poke_bp() implementation, hpa had to provide some answers directly
from inner depths of Intel ... see fd4363fff3 ("x86: Introduce int3
(breakpoint)-based instruction patching") for reference.
--
Jiri Kosina
SUSE Labs
when I was preparing the original
text_poke_bp() implementation, hpa had to provide some answers directly
from inner depths of Intel ... see fd4363fff3 ("x86: Introduce int3
(breakpoint)-based instruction patching") for reference.
--
Jiri Kosina
SUSE Labs
ist any strong reasons for why it should NOT be an IST.
It's CVE-2018-8897.
--
Jiri Kosina
SUSE Labs
ist any strong reasons for why it should NOT be an IST.
It's CVE-2018-8897.
--
Jiri Kosina
SUSE Labs
et the TIF_UPDATE
> bit which is evaluated once.
Yeah, that was a complete brainfart on my side, sorry for the noise,
disregard that crap. I blame it all on the dentist appointment I went
through before writing the patch :p
Thanks,
--
Jiri Kosina
SUSE Labs
et the TIF_UPDATE
> bit which is evaluated once.
Yeah, that was a complete brainfart on my side, sorry for the noise,
disregard that crap. I blame it all on the dentist appointment I went
through before writing the patch :p
Thanks,
--
Jiri Kosina
SUSE Labs
On Tue, 27 Nov 2018, Jiri Kosina wrote:
> > > static int ssb_prctl_set(struct task_struct *task, unsigned long ctrl)
> > > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> > > index 3f5e351bdd37..6c4fcef52b19 100644
> > > --- a/arch/x86/k
On Tue, 27 Nov 2018, Jiri Kosina wrote:
> > > static int ssb_prctl_set(struct task_struct *task, unsigned long ctrl)
> > > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> > > index 3f5e351bdd37..6c4fcef52b19 100644
> > > --- a/arch/x86/k
t; next context switch?
Does it really have to?
We need this special handling only if the next task has TIF_SPEC_UPDATE
set, which is one-off event globally (when seccomp marks all its threads
so due to seccomp filter change), and once all the TIF_SPEC_UPDATE tasks
schedule at least once, we're in a consistent state again and don't need
this, as every running task will then have its TIF consistent with MSR
value.
Thanks,
--
Jiri Kosina
SUSE Labs
t; next context switch?
Does it really have to?
We need this special handling only if the next task has TIF_SPEC_UPDATE
set, which is one-off event globally (when seccomp marks all its threads
so due to seccomp filter change), and once all the TIF_SPEC_UPDATE tasks
schedule at least once, we're in a consistent state again and don't need
this, as every running task will then have its TIF consistent with MSR
value.
Thanks,
--
Jiri Kosina
SUSE Labs
On Tue, 27 Nov 2018, Jiri Kosina wrote:
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -474,6 +474,21 @@ void __switch_to_xtra(struct task_struct *prev_p, struct
> task_struct *next_p)
>
> tifn = READ_ONCE(task_thread_info(next_p)->
On Tue, 27 Nov 2018, Jiri Kosina wrote:
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -474,6 +474,21 @@ void __switch_to_xtra(struct task_struct *prev_p, struct
> task_struct *next_p)
>
> tifn = READ_ONCE(task_thread_info(next_p)->
On Tue, 27 Nov 2018, Jiri Kosina wrote:
> > That's racy and does not prevent the situation because the TIF flags are
> > updated befor the UPDATE bit is set.
>
> > So __speculation_ctrl_update() might see the new bits, but not
> > TIF_SPEC_UPDATE.
>
> Hm, rig
On Tue, 27 Nov 2018, Jiri Kosina wrote:
> > That's racy and does not prevent the situation because the TIF flags are
> > updated befor the UPDATE bit is set.
>
> > So __speculation_ctrl_update() might see the new bits, but not
> > TIF_SPEC_UPDATE.
>
> Hm, rig
d need to do that before updating TIF_SPEC_IB
in task_update_spec_tif(), but that has the opposite ordering issue.
Thanks,
--
Jiri Kosina
SUSE Labs
d need to do that before updating TIF_SPEC_IB
in task_update_spec_tif(), but that has the opposite ordering issue.
Thanks,
--
Jiri Kosina
SUSE Labs
e.
How about the minimalistic aproach below? (only compile tested so far,
applies on top of your latest WIP.x86/pti branch). The downside of course
is wasting another TIF bit.
Thanks.
From: Jiri Kosina
Subject: [PATCH] x86/speculation: Always properly update SPEC_CTRL MSR for
remote seccomp
e.
How about the minimalistic aproach below? (only compile tested so far,
applies on top of your latest WIP.x86/pti branch). The downside of course
is wasting another TIF bit.
Thanks.
From: Jiri Kosina
Subject: [PATCH] x86/speculation: Always properly update SPEC_CTRL MSR for
remote seccomp
ding).
Arjan, Tim, would you have a wording handy that would be guaranteed to
describe the reality for the sake of changelog?
Thanks,
--
Jiri Kosina
SUSE Labs
ding).
Arjan, Tim, would you have a wording handy that would be guaranteed to
describe the reality for the sake of changelog?
Thanks,
--
Jiri Kosina
SUSE Labs
id.c | 25 ++-
include/linux/hid.h| 28 ---
include/uapi/linux/input-event-codes.h | 10 --
11 files changed, 159 insertions(+), 444 deletions(-)
--
Jiri Kosina
SUSE Labs
id.c | 25 ++-
include/linux/hid.h| 28 ---
include/uapi/linux/input-event-codes.h | 10 --
11 files changed, 159 insertions(+), 444 deletions(-)
--
Jiri Kosina
SUSE Labs
ed to the actual IBRS
runtime operation effect.
--
Jiri Kosina
SUSE Labs
ed to the actual IBRS
runtime operation effect.
--
Jiri Kosina
SUSE Labs
+seccomp setup
(irrespective of it's TIF flag value), as you have the extra overhead on
each and every switch_to() (to check exactly for this back-to-back
scheduling), or you penalize only those tasks that are penalized anyway by
the IBPB flush.
I think the latter (which is what this patch implements) makes more sense.
Thanks,
--
Jiri Kosina
SUSE Labs
+seccomp setup
(irrespective of it's TIF flag value), as you have the extra overhead on
each and every switch_to() (to check exactly for this back-to-back
scheduling), or you penalize only those tasks that are penalized anyway by
the IBPB flush.
I think the latter (which is what this patch implements) makes more sense.
Thanks,
--
Jiri Kosina
SUSE Labs
e;
> + return false;
> }
For -stable, which actually makes it to production, I already asked Greg
to drop it.
For -rc, I don't think we need to do this at this moment, given the
prctl+seccomp fixup is basically ready, do we?
Thanks,
--
Jiri Kosina
SUSE Labs
e;
> + return false;
> }
For -stable, which actually makes it to production, I already asked Greg
to drop it.
For -rc, I don't think we need to do this at this moment, given the
prctl+seccomp fixup is basically ready, do we?
Thanks,
--
Jiri Kosina
SUSE Labs
e for-linus branch.
As discussed previously
Acked-by: Jiri Kosina
Thanks,
--
Jiri Kosina
SUSE Labs
e for-linus branch.
As discussed previously
Acked-by: Jiri Kosina
Thanks,
--
Jiri Kosina
SUSE Labs
ull off.
>
> So till we have the accompanying patchset that only apply STIBP on processes
> that really need it instead of universally, it should be withheld from
> stable.
Agreed; it will be trivially reintroduced with the rest, once it's ready.
It's being built on top of that patch.
Thanks,
--
Jiri Kosina
SUSE Labs
ull off.
>
> So till we have the accompanying patchset that only apply STIBP on processes
> that really need it instead of universally, it should be withheld from
> stable.
Agreed; it will be trivially reintroduced with the rest, once it's ready.
It's being built on top of that patch.
Thanks,
--
Jiri Kosina
SUSE Labs
On Sun, 11 Nov 2018, Greg Kroah-Hartman wrote:
> 4.19-stable review patch. If anyone has any objections, please let me know.
Greg, please drop this patch from all -stable for now. Version that
wouldn't have such performance impact is being worked on.
--
Jiri Kosina
SUSE Labs
On Sun, 11 Nov 2018, Greg Kroah-Hartman wrote:
> 4.19-stable review patch. If anyone has any objections, please let me know.
Greg, please drop this patch from all -stable for now. Version that
wouldn't have such performance impact is being worked on.
--
Jiri Kosina
SUSE Labs
accept 'prctl' as the default mode. Namely:
- the whole "proper gadgets need to be present in the process' .text" is
dubious by itself
- the unavoidable overhead it'd impose on network daemons that you can't
really get rid of
The distiled patchset that Thomas will be sending around today is not have
the dumpability restriction in it.
Thanks,
--
Jiri Kosina
SUSE Labs
accept 'prctl' as the default mode. Namely:
- the whole "proper gadgets need to be present in the process' .text" is
dubious by itself
- the unavoidable overhead it'd impose on network daemons that you can't
really get rid of
The distiled patchset that Thomas will be sending around today is not have
the dumpability restriction in it.
Thanks,
--
Jiri Kosina
SUSE Labs
k.
> + seccomp - Same as "prctl" above, but all seccomp threads
> + will disable SSB unless they explicitly opt
> out.
As Dave already pointed out elsewhere -- the "SSB" here is probably a
copy/paste error. It should read something along the lines of "... will
restrict indirect branch speculation ..."
Thanks,
--
Jiri Kosina
SUSE Labs
k.
> + seccomp - Same as "prctl" above, but all seccomp threads
> + will disable SSB unless they explicitly opt
> out.
As Dave already pointed out elsewhere -- the "SSB" here is probably a
copy/paste error. It should read something along the lines of "... will
restrict indirect branch speculation ..."
Thanks,
--
Jiri Kosina
SUSE Labs
/security-software-guidance/api-app/sites/default/files/336996-Speculative-Execution-Side-Channel-Mitigations.pdf?_gclid=5b78f4d130faf8.22277271-5b78f4d130fb70.17467890&_utm_source=xakep&_utm_campaign=mention17&_utm_medium=inline&_utm_content=lnk223716354570
Thanks,
--
Jiri Kosina
SUSE Labs
/security-software-guidance/api-app/sites/default/files/336996-Speculative-Execution-Side-Channel-Mitigations.pdf?_gclid=5b78f4d130faf8.22277271-5b78f4d130fb70.17467890&_utm_source=xakep&_utm_campaign=mention17&_utm_medium=inline&_utm_content=lnk223716354570
Thanks,
--
Jiri Kosina
SUSE Labs
Tim's set
into mergeable state, I've just sent him small addition on top that makes
IBPB also be controlled via the same toggle.
That should make the whole 'spectre v2 userspace-to-userspace' mitigation
control consistent and undestandable. And also give us even few more %
back that are lost due to IBPB as well.
--
Jiri Kosina
SUSE Labs
Tim's set
into mergeable state, I've just sent him small addition on top that makes
IBPB also be controlled via the same toggle.
That should make the whole 'spectre v2 userspace-to-userspace' mitigation
control consistent and undestandable. And also give us even few more %
back that are lost due to IBPB as well.
--
Jiri Kosina
SUSE Labs
noid enough to ask for IBPB,
> *and* they have SMT, they almost certainly want STIBP too.
I think you are not lost :) and this is exactly what makes sense, and what
Tim's patchset implements.
--
Jiri Kosina
SUSE Labs
noid enough to ask for IBPB,
> *and* they have SMT, they almost certainly want STIBP too.
I think you are not lost :) and this is exactly what makes sense, and what
Tim's patchset implements.
--
Jiri Kosina
SUSE Labs
On Tue, 20 Nov 2018, Thomas Gleixner wrote:
> What? IBPB makes tons of sense even without STIBP.
On non-SMT, yes. But this patchset ties those two the other (sensible) way
around AFAICS ("STIBP iff (IBPB && SMT)").
--
Jiri Kosina
SUSE Labs
On Tue, 20 Nov 2018, Thomas Gleixner wrote:
> What? IBPB makes tons of sense even without STIBP.
On non-SMT, yes. But this patchset ties those two the other (sensible) way
around AFAICS ("STIBP iff (IBPB && SMT)").
--
Jiri Kosina
SUSE Labs
her IBPB and STIBP pretty closely, which
is IMO a good thing; there is no good reason why anone would want just one
of those (or each in a different mode), at least before this magical
coscheduling exists.
But I guess this fact should be documented somewhere.
--
Jiri Kosina
SUSE Labs
her IBPB and STIBP pretty closely, which
is IMO a good thing; there is no good reason why anone would want just one
of those (or each in a different mode), at least before this magical
coscheduling exists.
But I guess this fact should be documented somewhere.
--
Jiri Kosina
SUSE Labs
forcing
> these decision at boot time only. Would be nice to add runtime tweak
> options for at least STIBP and SSBD that aren't confined to the prctl.
So if I understand you correctly, what you are proposing here is to keep
the current code, but just switch the default, and make it
runtime/boottime togglable?
Thanks,
--
Jiri Kosina
SUSE Labs
forcing
> these decision at boot time only. Would be nice to add runtime tweak
> options for at least STIBP and SSBD that aren't confined to the prctl.
So if I understand you correctly, what you are proposing here is to keep
the current code, but just switch the default, and make it
runtime/boottime togglable?
Thanks,
--
Jiri Kosina
SUSE Labs
gt; That was my initial thought too. Ingo suggested to export it in
> review of v2. Wonder Ingo has some reason?
>
> https://lore.kernel.org/patchwork/patch/991759/
But why does it have to be exported at all, irrespective whether _GPL() or
not?
Thanks,
--
Jiri Kosina
SUSE Labs
gt; That was my initial thought too. Ingo suggested to export it in
> review of v2. Wonder Ingo has some reason?
>
> https://lore.kernel.org/patchwork/patch/991759/
But why does it have to be exported at all, irrespective whether _GPL() or
not?
Thanks,
--
Jiri Kosina
SUSE Labs
I2C_HID_QUIRK_DELAY_AFTER_SLEEP },
> + { USB_VENDOR_ID_LG, I2C_DEVICE_ID_LG_8001,
> + I2C_HID_QUIRK_NO_RUNTIME_PM },
> { 0, 0 }
> };
Applied.
--
Jiri Kosina
SUSE Labs
I2C_HID_QUIRK_DELAY_AFTER_SLEEP },
> + { USB_VENDOR_ID_LG, I2C_DEVICE_ID_LG_8001,
> + I2C_HID_QUIRK_NO_RUNTIME_PM },
> { 0, 0 }
> };
Applied.
--
Jiri Kosina
SUSE Labs
IN_8,
> + I2C_VENDOR_ID_CIRQUE,
> + I2C_PRODUCT_ID_CIRQUE_121F) },
> +
> /* CJTouch panels */
> { .driver_data = MT_CLS_NSMU,
> MT_USB_DEVICE(USB_VENDOR_ID_CJTOUCH,
Applied, thanks.
--
Jiri Kosina
SUSE Labs
IN_8,
> + I2C_VENDOR_ID_CIRQUE,
> + I2C_PRODUCT_ID_CIRQUE_121F) },
> +
> /* CJTouch panels */
> { .driver_data = MT_CLS_NSMU,
> MT_USB_DEVICE(USB_VENDOR_ID_CJTOUCH,
Applied, thanks.
--
Jiri Kosina
SUSE Labs
https://github.com/ValveSoftware/steam-for-linux/issues/5645
Applied to for-4.20/upstream-fixes. Thanks,
--
Jiri Kosina
SUSE Labs
https://github.com/ValveSoftware/steam-for-linux/issues/5645
Applied to for-4.20/upstream-fixes. Thanks,
--
Jiri Kosina
SUSE Labs
ther mail.
Actually Tim's patchset seems to already deal with IBPB in a consistent
way as well in
[11/16] x86/speculation: Add Spectre v2 app to app protection modes
but the fact that it's still using TIF_STIBP makes it a bit confusing and
hidden. So I'd suggest to fold something like
401 - 500 of 6650 matches
Mail list logo
