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
On Mon, 19 Nov 2018, Thomas Gleixner wrote:
> > On Sat, 17 Nov 2018, Jiri Kosina wrote:
>
> > Subject: [PATCH] x86/speculation: enforce STIBP for SECCOMP tasks in lite
> > mode
> >
> > If 'lite' mode of app2app protection from spectre_v2 is selected on
> >
On Mon, 19 Nov 2018, Thomas Gleixner wrote:
> > On Sat, 17 Nov 2018, Jiri Kosina wrote:
>
> > Subject: [PATCH] x86/speculation: enforce STIBP for SECCOMP tasks in lite
> > mode
> >
> > If 'lite' mode of app2app protection from spectre_v2 is selected on
> >
n both
> hypervisor and bare metal.
>
> Sounds better?
>
> > With that
> >
> > Acked-by: Jiri Kosina
>
> Thanks!
Yes, I think that makes it absolutely clear. Thanks,
--
Jiri Kosina
SUSE Labs
n both
> hypervisor and bare metal.
>
> Sounds better?
>
> > With that
> >
> > Acked-by: Jiri Kosina
>
> Thanks!
Yes, I think that makes it absolutely clear. Thanks,
--
Jiri Kosina
SUSE Labs
strncpy(hid->phys, ev->u.create2.phys, len);
> + len = min(sizeof(hid->uniq), sizeof(ev->u.create2.uniq)) - 1;
> + strncpy(hid->uniq, ev->u.create2.uniq, len);
Applied, thanks.
--
Jiri Kosina
SUSE Labs
strncpy(hid->phys, ev->u.create2.phys, len);
> + len = min(sizeof(hid->uniq), sizeof(ev->u.create2.uniq)) - 1;
> + strncpy(hid->uniq, ev->u.create2.uniq, len);
Applied, thanks.
--
Jiri Kosina
SUSE Labs
overlooked that (valid)
concern in the thread. Thanks for spotting that, Andy.
I've now applied Eric's patch. Thanks everybody,
--
Jiri Kosina
SUSE Labs
overlooked that (valid)
concern in the thread. Thanks for spotting that, Andy.
I've now applied Eric's patch. Thanks everybody,
--
Jiri Kosina
SUSE Labs
t;private_data;
@@ -771,6 +780,7 @@ static const struct file_operations uhid_fops = {
.release= uhid_char_release,
.read = uhid_char_read,
.write = uhid_char_write,
+ .splice_write = uhid_char_splice_write,
.poll = uhid_char_poll,
.llseek = no_llseek,
};
--
Jiri Kosina
SUSE Labs
t;private_data;
@@ -771,6 +780,7 @@ static const struct file_operations uhid_fops = {
.release= uhid_char_release,
.read = uhid_char_read,
.write = uhid_char_write,
+ .splice_write = uhid_char_splice_write,
.poll = uhid_char_poll,
.llseek = no_llseek,
};
--
Jiri Kosina
SUSE Labs
so it's going to be explicit an
> explicit requirement.
Do you already have an idea whether you'd proceed with Tim's patchset for
current cycle? If so, great as far as I am concerned. If not, I'll send a
patch that switches this to opt-in via kernel cmdline (+boot-time warning
if not mitigated).
Thanks,
--
Jiri Kosina
SUSE Labs
so it's going to be explicit an
> explicit requirement.
Do you already have an idea whether you'd proceed with Tim's patchset for
current cycle? If so, great as far as I am concerned. If not, I'll send a
patch that switches this to opt-in via kernel cmdline (+boot-time warning
if not mitigated).
Thanks,
--
Jiri Kosina
SUSE Labs
On Sun, 18 Nov 2018, Jiri Kosina wrote:
> It's probably not just browsers, but anything running JITed sandboxed
> code. So the most straightforward way might be the prctl() aproach, where
> userspace would claim "I do care about this, please fix it up for me". So
> prc
On Sun, 18 Nov 2018, Jiri Kosina wrote:
> It's probably not just browsers, but anything running JITed sandboxed
> code. So the most straightforward way might be the prctl() aproach, where
> userspace would claim "I do care about this, please fix it up for me". So
> prc
On Sat, 17 Nov 2018, Jiri Kosina wrote:
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt
> > b/Documentation/admin-guide/kernel-parameters.txt
> > index 81d1d5a..9c306e3 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Do
On Sat, 17 Nov 2018, Jiri Kosina wrote:
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt
> > b/Documentation/admin-guide/kernel-parameters.txt
> > index 81d1d5a..9c306e3 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Do
e consistent (and get even a few more % of performance back),
but that's easy as well.
Thanks,
--
Jiri Kosina
SUSE Labs
e consistent (and get even a few more % of performance back),
but that's easy as well.
Thanks,
--
Jiri Kosina
SUSE Labs
than turning SMT off, which might possibly
have even *worse* performance numbers depending on workload.
[1]
https://lore.kernel.org/lkml/?q=cover.1542418936.git.tim.c.chen%40linux.intel.com
(*) no code to implement STIBP sanely, no recommendation about turning SMT
off at least for some workloads
Thanks,
--
Jiri Kosina
SUSE Labs
than turning SMT off, which might possibly
have even *worse* performance numbers depending on workload.
[1]
https://lore.kernel.org/lkml/?q=cover.1542418936.git.tim.c.chen%40linux.intel.com
(*) no code to implement STIBP sanely, no recommendation about turning SMT
off at least for some workloads
Thanks,
--
Jiri Kosina
SUSE Labs
uot;indirect branch predictions"
in general terms, but really controls only the SMT aspect of it (STIBP),
as quite confusing.
So I believe it should either be renamed, or actually control semantics of
IBPB as well, no?
Thanks,
--
Jiri Kosina
SUSE Labs
uot;indirect branch predictions"
in general terms, but really controls only the SMT aspect of it (STIBP),
as quite confusing.
So I believe it should either be renamed, or actually control semantics of
IBPB as well, no?
Thanks,
--
Jiri Kosina
SUSE Labs
indirect branch speculation via the
> + PR_SET_SPECULATION_CTRL prctl().
Don't we also want to do the same for SECCOMP processess, analogically how
we do it for SSBD?
Thanks,
--
Jiri Kosina
SUSE Labs
indirect branch speculation via the
> + PR_SET_SPECULATION_CTRL prctl().
Don't we also want to do the same for SECCOMP processess, analogically how
we do it for SSBD?
Thanks,
--
Jiri Kosina
SUSE Labs
t some
of the lost performance back (I am pretty sure it will be taken for all
-stable branches as well anyway).
Thanks,
--
Jiri Kosina
SUSE Labs
t some
of the lost performance back (I am pretty sure it will be taken for all
-stable branches as well anyway).
Thanks,
--
Jiri Kosina
SUSE Labs
o avoid any confusion (as otherwise
the l1tf cmdline parameter is purely about hypervisor mitigations).
With that
Acked-by: Jiri Kosina
Thanks,
--
Jiri Kosina
SUSE Labs
o avoid any confusion (as otherwise
the l1tf cmdline parameter is purely about hypervisor mitigations).
With that
Acked-by: Jiri Kosina
Thanks,
--
Jiri Kosina
SUSE Labs
On Fri, 9 Nov 2018, Benjamin Tissoires wrote:
> On Thu, Nov 8, 2018 at 10:38 PM Jiri Kosina wrote:
> >
> > From: Jiri Kosina
> >
> > lockdep is much more powerful enforcing the locking rules than code
> > comments,
> > so let's switch to
On Fri, 9 Nov 2018, Benjamin Tissoires wrote:
> On Thu, Nov 8, 2018 at 10:38 PM Jiri Kosina wrote:
> >
> > From: Jiri Kosina
> >
> > lockdep is much more powerful enforcing the locking rules than code
> > comments,
> > so let's switch to
emoved. For kgdb, the return
> > value can actually be used.
>
> Hm, this looks reasonable and good to me.
>
> Reviewed-by: Masami Hiramatsu
Yes, I guess this is much better than putting the 'enforcement by comment'
back in place :)
Acked-by: Jiri Kosina
Thanks.
--
Jiri Kosina
SUSE Labs
emoved. For kgdb, the return
> > value can actually be used.
>
> Hm, this looks reasonable and good to me.
>
> Reviewed-by: Masami Hiramatsu
Yes, I guess this is much better than putting the 'enforcement by comment'
back in place :)
Acked-by: Jiri Kosina
Thanks.
--
Jiri Kosina
SUSE Labs
From: Jiri Kosina
lockdep is much more powerful enforcing the locking rules than code comments,
so let's switch to it.
Signed-off-by: Jiri Kosina
---
drivers/hid/hidraw.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hidraw.c b/drivers/hid/hidraw.c
From: Jiri Kosina
lockdep is much more powerful enforcing the locking rules than code comments,
so let's switch to it.
Signed-off-by: Jiri Kosina
---
drivers/hid/hidraw.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hidraw.c b/drivers/hid/hidraw.c
wiht CONFIG_ASUS_WMI disabled
Benjamin Tissoires (2):
Revert "HID: add NOGET quirk for Eaton Ellipse MAX UPS"
HID: alps: allow incoming reports when only the trackstick is opened
Breno Leitao (1):
HID: hiddev: fix potential Spectre v1
Jiri Kosina (1):
HID: movin
wiht CONFIG_ASUS_WMI disabled
Benjamin Tissoires (2):
Revert "HID: add NOGET quirk for Eaton Ellipse MAX UPS"
HID: alps: allow incoming reports when only the trackstick is opened
Breno Leitao (1):
HID: hiddev: fix potential Spectre v1
Jiri Kosina (1):
HID: movin
by WMI")
> Signed-off-by: Arnd Bergmann
Applied to for-4.20/upstream-fixes. Thanks,
--
Jiri Kosina
SUSE Labs
by WMI")
> Signed-off-by: Arnd Bergmann
Applied to for-4.20/upstream-fixes. Thanks,
--
Jiri Kosina
SUSE Labs
mmit.
>
> This partially reverts commit 9222f606506c ("x86/alternatives:
> Lockdep-enforce text_mutex in text_poke*()")
Alright, what can we do. It's probably better to have this, rather than to
trying to work this around in kgdb to accomodate the rest of the world.
> Cc: Jiri Kos
mmit.
>
> This partially reverts commit 9222f606506c ("x86/alternatives:
> Lockdep-enforce text_mutex in text_poke*()")
Alright, what can we do. It's probably better to have this, rather than to
trying to work this around in kgdb to accomodate the rest of the world.
> Cc: Jiri Kos
we use '-pg -mfentry', to make sure we hook the function *before*
prologue.
Thanks,
--
Jiri Kosina
SUSE Labs
we use '-pg -mfentry', to make sure we hook the function *before*
prologue.
Thanks,
--
Jiri Kosina
SUSE Labs
On Mon, 29 Oct 2018, Benjamin Tissoires wrote:
> > From: Jiri Kosina
> > Date: Sat, 27 Oct 2018 14:16:13 +0200
> > Subject: [PATCH] HID: moving to group maintainership model
> >
> > Benjamin and myself will from now on be sharing maintainership
> > responsi
On Mon, 29 Oct 2018, Benjamin Tissoires wrote:
> > From: Jiri Kosina
> > Date: Sat, 27 Oct 2018 14:16:13 +0200
> > Subject: [PATCH] HID: moving to group maintainership model
> >
> > Benjamin and myself will from now on be sharing maintainership
> > responsi
indicated that Peter probably has found the issue in the code
(failure to properly reset on direction change) that might be causing
this. Adding to CC.
Peter?
Thanks,
--
Jiri Kosina
SUSE Labs
indicated that Peter probably has found the issue in the code
(failure to properly reset on direction change) that might be causing
this. Adding to CC.
Peter?
Thanks,
--
Jiri Kosina
SUSE Labs
ieve is a very noble and
nice goal. But you really have to know at least a little bit who's there
on the other end. Otherwise failure to communicate might be sort of
inevitable.
--
Jiri Kosina
SUSE Labs
ieve is a very noble and
nice goal. But you really have to know at least a little bit who's there
on the other end. Otherwise failure to communicate might be sort of
inevitable.
--
Jiri Kosina
SUSE Labs
tely escaped attention. That
should never ever have been set to default y, I take blame for not
noticing that while applying the patch.
Thanks,
--
Jiri Kosina
SUSE Labs
tely escaped attention. That
should never ever have been set to default y, I take blame for not
noticing that while applying the patch.
Thanks,
--
Jiri Kosina
SUSE Labs
improve I guess;
will fix that next week.
Benjamin, do you have something for that in place already?
Thanks,
--
Jiri Kosina
SUSE Labs
improve I guess;
will fix that next week.
Benjamin, do you have something for that in place already?
Thanks,
--
Jiri Kosina
SUSE Labs
From: Jiri Kosina
Date: Sat, 27 Oct 2018 14:16:13 +0200
Subject: [PATCH] HID: moving to group maintainership model
Benjamin and myself will from now on be sharing maintainership
responsibilities for hid.git.
Update maintainers to reflect that change, and also move a git
repository to shared
From: Jiri Kosina
Date: Sat, 27 Oct 2018 14:16:13 +0200
Subject: [PATCH] HID: moving to group maintainership model
Benjamin and myself will from now on be sharing maintainership
responsibilities for hid.git.
Update maintainers to reflect that change, and also move a git
repository to shared
From: Jiri Kosina
Benjamin and myself will from now on be sharing maintainership
responsibilities for hid.git.
Update maintainers to reflect that change, and also move a git repository
to shared space at kernel.org.
Signed-off-by: Jiri Kosina
---
Stephen, could you please update
From: Jiri Kosina
Benjamin and myself will from now on be sharing maintainership
responsibilities for hid.git.
Update maintainers to reflect that change, and also move a git repository
to shared space at kernel.org.
Signed-off-by: Jiri Kosina
---
Stephen, could you please update
; while keeping the trackstick active.
>
> Link: https://bugzilla.redhat.com/show_bug.cgi?id=1559632
> Link: https://gitlab.gnome.org/GNOME/mutter/issues/128
> Signed-off-by: Benjamin Tissoires
Applied, thanks.
--
Jiri Kosina
SUSE Labs
; while keeping the trackstick active.
>
> Link: https://bugzilla.redhat.com/show_bug.cgi?id=1559632
> Link: https://gitlab.gnome.org/GNOME/mutter/issues/128
> Signed-off-by: Benjamin Tissoires
Applied, thanks.
--
Jiri Kosina
SUSE Labs
modified kernel and fuzzer-reader
> at: https://gist.github.com/nefigtut/33d56e3870b67493cc867344aed2a062
Vladis,
thanks for cleaning it up. I actually like your rewrite quite a lot.
Quick question -- how well was it tested in which scenarios?
--
Jiri Kosina
SUSE Labs
modified kernel and fuzzer-reader
> at: https://gist.github.com/nefigtut/33d56e3870b67493cc867344aed2a062
Vladis,
thanks for cleaning it up. I actually like your rewrite quite a lot.
Quick question -- how well was it tested in which scenarios?
--
Jiri Kosina
SUSE Labs
> Reported-by: Laurent Bigonville
> Signed-off-by: Benjamin Tissoires
Ok, fingers crossed. Applied,
--
Jiri Kosina
SUSE Labs
> Reported-by: Laurent Bigonville
> Signed-off-by: Benjamin Tissoires
Ok, fingers crossed. Applied,
--
Jiri Kosina
SUSE Labs
; timeframe. So add a small delay to workaround the issue.
>
> Signed-off-by: Kai-Heng Feng
> ---
> v2:
> - Use quirk to only match affected touchpanel
> - Only delay the next power on if the time hasn't elapsed
Applied, thanks.
--
Jiri Kosina
SUSE Labs
; timeframe. So add a small delay to workaround the issue.
>
> Signed-off-by: Kai-Heng Feng
> ---
> v2:
> - Use quirk to only match affected touchpanel
> - Only delay the next power on if the time hasn't elapsed
Applied, thanks.
--
Jiri Kosina
SUSE Labs
extent pages), so there is no need to leave any traces of
> >> freezer in this kthread.
> >>
> >> Fixes: 80ad623edd2d ("Revert "btrfs: clear PF_NOFREEZE in
> >> Fixes: cleaner_kthread()")
> >> Fixes: 696249132158 ("btrfs: clear PF_NOFREEZE in cle
extent pages), so there is no need to leave any traces of
> >> freezer in this kthread.
> >>
> >> Fixes: 80ad623edd2d ("Revert "btrfs: clear PF_NOFREEZE in
> >> Fixes: cleaner_kthread()")
> >> Fixes: 696249132158 ("btrfs: clear PF_NOFREEZE in cle
new PCI/USB/ACPI IDs or DMI quirks are usually accepted
> into stable but normally lack "Fixes" tag.
That could easily be made an easily identifiable exception to the rule
though.
--
Jiri Kosina
SUSE Labs
new PCI/USB/ACPI IDs or DMI quirks are usually accepted
> into stable but normally lack "Fixes" tag.
That could easily be made an easily identifiable exception to the rule
though.
--
Jiri Kosina
SUSE Labs
ble high-resolution scrolling on Logitech mice
HID: logitech: Use LDJ_DEVICE macro for existing Logitech mice
Hong Liu (2):
HID: intel-ish-hid: use resource-managed api
HID: intel-ish-hid: using list_head for ipc write queue
Jason Gerecke (1):
HID: wacom: Work around HID descripto
ble high-resolution scrolling on Logitech mice
HID: logitech: Use LDJ_DEVICE macro for existing Logitech mice
Hong Liu (2):
HID: intel-ish-hid: use resource-managed api
HID: intel-ish-hid: using list_head for ipc write queue
Jason Gerecke (1):
HID: wacom: Work around HID descripto
hat's currently being discussed) is eventually going to achieve.
Thanks,
--
Jiri Kosina
SUSE Labs
hat's currently being discussed) is eventually going to achieve.
Thanks,
--
Jiri Kosina
SUSE Labs
sue.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200995
> BugLink: https://bugs.launchpad.net/bugs/1793846
> Signed-off-by: Kai-Heng Feng
Applied, thanks.
--
Jiri Kosina
SUSE Labs
sue.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200995
> BugLink: https://bugs.launchpad.net/bugs/1793846
> Signed-off-by: Kai-Heng Feng
Applied, thanks.
--
Jiri Kosina
SUSE Labs
return 0;
>
> if (!drvdata->input) {
> - hid_err(hdev, "Input device is not registred\n");
> + hid_err(hdev, "Input device is not registered\n");
Applied, thanks.
--
Jiri Kosina
SUSE Labs
return 0;
>
> if (!drvdata->input) {
> - hid_err(hdev, "Input device is not registred\n");
> + hid_err(hdev, "Input device is not registered\n");
Applied, thanks.
--
Jiri Kosina
SUSE Labs
From: Jiri Kosina
SIMPLE_DEV_PM_OPS() already implies const for the type; drop the extra
modifier.
Fixes: eb1aac4c8744f75460c34d71b0c73bebf3e8ee5c ("HID: google: add support
tablet mode switch for Whiskers")
Signed-off-by: Jiri Kosina
---
In hid.git#for-4.20/google
drivers/hid/
From: Jiri Kosina
SIMPLE_DEV_PM_OPS() already implies const for the type; drop the extra
modifier.
Fixes: eb1aac4c8744f75460c34d71b0c73bebf3e8ee5c ("HID: google: add support
tablet mode switch for Whiskers")
Signed-off-by: Jiri Kosina
---
In hid.git#for-4.20/google
drivers/hid/
okhov
> > ---
> >
> > v2 changes: None
> >
> > Lee, I was wondering if it would be OK for cros_ec_commands.h to be
> > merged through HID tree.
>
> Yes, so long as it goes through in this merge-window.
>
> Acked-by: Lee Jones
Thanks; both patches now queued in hid.git#for-4.20/google
--
Jiri Kosina
SUSE Labs
okhov
> > ---
> >
> > v2 changes: None
> >
> > Lee, I was wondering if it would be OK for cros_ec_commands.h to be
> > merged through HID tree.
>
> Yes, so long as it goes through in this merge-window.
>
> Acked-by: Lee Jones
Thanks; both patches now queued in hid.git#for-4.20/google
--
Jiri Kosina
SUSE Labs
y objtool at
all anyway.
--
Jiri Kosina
SUSE Labs
y objtool at
all anyway.
--
Jiri Kosina
SUSE Labs
ough your tree, as the input-event-codes
> changes that introduce REL_WHEEL_HI_RES are in your for-4.20/logitech-highres.
Applied, thanks Benjamin.
--
Jiri Kosina
SUSE Labs
ough your tree, as the input-event-codes
> changes that introduce REL_WHEEL_HI_RES are in your for-4.20/logitech-highres.
Applied, thanks Benjamin.
--
Jiri Kosina
SUSE Labs
ge the two drivers, and explicitly anotate __hid_request()
> with might_sleep().
Thanks. Are you planning to submit a patch to do that?
--
Jiri Kosina
SUSE Labs
ge the two drivers, and explicitly anotate __hid_request()
> with might_sleep().
Thanks. Are you planning to submit a patch to do that?
--
Jiri Kosina
SUSE Labs
g.\n");
> + else
> + msleep(20);
In case there really is no other way around it, at least please add
comment explaining why this ugly msleep() is there. Thanks,
--
Jiri Kosina
SUSE Labs
g.\n");
> + else
> + msleep(20);
In case there really is no other way around it, at least please add
comment explaining why this ugly msleep() is there. Thanks,
--
Jiri Kosina
SUSE Labs
B and bluetooth, putting
> the device in multi-touch mode.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
B and bluetooth, putting
> the device in multi-touch mode.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
, 12 insertions(+), 18 deletions(-)
--
Jiri Kosina
SUSE Labs
, 12 insertions(+), 18 deletions(-)
--
Jiri Kosina
SUSE Labs
ll probably agree. So
> anyway, I encourage a pragmatic approach similar to that for SSBD.
Which is what Tim's patchset is implementing on top.
Thanks,
--
Jiri Kosina
SUSE Labs
ll probably agree. So
> anyway, I encourage a pragmatic approach similar to that for SSBD.
Which is what Tim's patchset is implementing on top.
Thanks,
--
Jiri Kosina
SUSE Labs
ets on being able to allocate the buffer
> > without sleeping,
>
> In my opinion, I prefer this way.
Why? Forcing all the report buffer to be limited to be non-sleeping
allocations just because of two drivers, looks like an overkill, and
actually calls for more issues (as GFP_ATOMIC is of course in principle
less likely to succeed).
--
Jiri Kosina
SUSE Labs
ets on being able to allocate the buffer
> > without sleeping,
>
> In my opinion, I prefer this way.
Why? Forcing all the report buffer to be limited to be non-sleeping
allocations just because of two drivers, looks like an overkill, and
actually calls for more issues (as GFP_ATOMIC is of course in principle
less likely to succeed).
--
Jiri Kosina
SUSE Labs
Commit-ID: 53c613fe6349994f023245519265999eed75957f
Gitweb: https://git.kernel.org/tip/53c613fe6349994f023245519265999eed75957f
Author: Jiri Kosina
AuthorDate: Tue, 25 Sep 2018 14:38:55 +0200
Committer: Thomas Gleixner
CommitDate: Wed, 26 Sep 2018 14:26:52 +0200
x86/speculation
Commit-ID: 53c613fe6349994f023245519265999eed75957f
Gitweb: https://git.kernel.org/tip/53c613fe6349994f023245519265999eed75957f
Author: Jiri Kosina
AuthorDate: Tue, 25 Sep 2018 14:38:55 +0200
Committer: Thomas Gleixner
CommitDate: Wed, 26 Sep 2018 14:26:52 +0200
x86/speculation
Commit-ID: bb4b3b7762735cdaba5a40fd94c9303d9ffa147a
Gitweb: https://git.kernel.org/tip/bb4b3b7762735cdaba5a40fd94c9303d9ffa147a
Author: Jiri Kosina
AuthorDate: Tue, 25 Sep 2018 14:39:28 +0200
Committer: Thomas Gleixner
CommitDate: Wed, 26 Sep 2018 14:26:52 +0200
x86/speculation
501 - 600 of 6650 matches
Mail list logo
