On Wed, Aug 23, 2017 at 10:21 PM, Wanpeng Li wrote:
> From: Wanpeng Li
>
> vmx_complete_interrupts() assumes that the exception is always injected,
> so it would be dropped by kvm_clear_exception_queue(). This patch separates
> exception.pending from exception.injected, exception.inject represent
On 01/05/2018 02:16 PM, Michal Hocko wrote:
> On Fri 05-01-18 12:13:17, Anshuman Khandual wrote:
>> On 01/05/2018 05:50 AM, a...@linux-foundation.org wrote:
>>> The mm-of-the-moment snapshot 2018-01-04-16-19 has been uploaded to
[...]
>>>
>>> This tree is partially included in linux-next. To see
On Sat, Jan 06, 2018 at 10:04:26PM -0700, Kiernan Hager wrote:
> On Thu, Jan 4, 2018 at 5:54 PM, Thomas Gleixner wrote:
> > On Thu, 4 Jan 2018, Jon Masters wrote:
> >> P.S. I've an internal document where I've been tracking "nice to haves"
> >> for later, and one of them is whether it makes sense
On Sat, Jan 06, 2018 at 07:38:14PM -0800, Alexei Starovoitov wrote:
> yep. plenty of unknowns and what's happening now is an overreaction.
To be fair there's overreaction on both sides. The vast majority of
users need to get a 100% safe system and will never notice any
difference. A few of us are
As of now, there're two sk_family are traced with sock:inet_sock_set_state,
which are AF_INET and AF_INET6.
So the sk_family are exposed as well.
Then we can conveniently use it to do the filter.
Both sk_family and sk_protocol are showed in the printk message, so we need
not expose them as tracepo
On Sun, Jan 7, 2018 at 1:46 AM, Song Liu wrote:
>
>> On Jan 5, 2018, at 12:09 AM, Yafang Shao wrote:
>>
>> On Fri, Jan 5, 2018 at 3:21 PM, Song Liu wrote:
>>>
On Jan 4, 2018, at 10:42 PM, Yafang Shao wrote:
sk->sk_protocol and sk->sk_family are exposed as tracepoint arguments.
>>
On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote:
> 4.14-stable review patch. If anyone has any objections, please let me know.
FYI, this broke kdump, or rather the makedumpfile part thereof.
Forward looking wreckage is par for the kdump course, but...
> --
>
> From:
On 01/05/18 06:57, Mark Rutland wrote:
> Document the rationale and usage of the new nospec*() helpers.
>
> Signed-off-by: Mark Rutland
> Signed-off-by: Will Deacon
> Cc: Dan Williams
> Cc: Jonathan Corbet
> Cc: Peter Zijlstra
> ---
> Documentation/speculation.txt | 166
> ++
On Thu, Jan 4, 2018 at 5:54 PM, Thomas Gleixner wrote:
> On Thu, 4 Jan 2018, Jon Masters wrote:
>> P.S. I've an internal document where I've been tracking "nice to haves"
>> for later, and one of them is whether it makes sense to tag binaries as
>> "trusted" (e.g. extended attribute, label, whatev
On Sat, Jan 06, 2018 at 11:05:07PM +, Alan Cox wrote:
> > Even if it would be practical the speed probably going to be in bytes per
> > second,
> > so to read anything meaningful an attack detection techniques (that people
> > are actively working on) will be able to catch it.
> > At the end s
On 01/03/18 01:49, Vincent Legoll wrote:
> No need to get into the submenu to disable all VIRTIO-related
> config entries.
>
> This makes it easier to disable all VIRTIO config options
> without entering the submenu. It will also enable one
> to see that en/dis-abled state from the outside menu.
>
There is only one clock each for "musb-da8xx" and "ohci-da8xx", so we
do not the the con_id. Removing them will also prevent needing an
unnecessary device tree property when device tree bindings are added
for clocks.
Signed-off-by: David Lechner
---
arch/arm/mach-davinci/da830.c | 4 ++--
arch/
This series removes unnecessary con_ids on da8xx USB clocks in preparation
of adding device tree support for clocks on this platform.
Note: this is a resend of "USB: musb: da8xx: remove clock con_id" and
"USB: ohci: da8xx: remove clk con_id". I sent them before I realized that
things break if you
There is only one clock for the DA8xx MUSB device, so we don't need the
con_id, so remove it. This way we don't have to add an unnecessary
property to the device tree bindings for the clock.
Signed-off-by: David Lechner
---
drivers/usb/musb/da8xx.c | 2 +-
1 file changed, 1 insertion(+), 1 delet
The ohci-da8xx device only has one clock, so a con_id is not needed, so
remove it. This way we don't have to add an unnecessary property to the
device tree bindings for the clock.
Signed-off-by: David Lechner
---
drivers/usb/host/ohci-da8xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This removes the watchdog reset code. The reset has been moved to
drivers/watchdog/davinci_wdt.c. The watchdog driver registers the reset
with the kernel so defining a reset for each machine is no longer needed.
Signed-off-by: David Lechner
Acked-by: Guenter Roeck
---
arch/arm/mach-davinci/boar
This series moves the watchdog restart code from arch/arm/mach-davinci
to drivers/watchdog.
Tested working on LEGO MINDSTORMS EV3 (TI AM1808 processor).
v2 changes:
* rebased on linux-davinci/master (fixed conflict with clock.h)
There is also still the unresolved question from Sekhar:
> Hi Wim,
This adds a restart function to the davinci watchdog timer driver.
This is copied from arch/arm/mach-davinci/time.c and will allow us to
remove the code from there.
Signed-off-by: David Lechner
Reviewed-by: Guenter Roeck
---
drivers/watchdog/davinci_wdt.c | 38 +
On Sun, Jan 7, 2018 at 4:03 AM, Willy Tarreau wrote:
> On Sun, Jan 07, 2018 at 01:50:59AM +0800, Jike Song wrote:
>> Signed-off-by: Jike Song
>
> It would be nice to have a commit message, particularly in this quite
> sensitive series...
Yes that's useful, will add it in v2 :)
>
> Willy
--
is a wrapper of scripts/dtc/libfdt/libfdt.h
It should not do more than its job. In fact, libfdt.h depends
on fdt.h, and scripts/dtc/libfdt/libfdt.h includes fdt.h already.
Trust the work in the upstream DTC project.
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Rephrase commit-log a bi
On Sun, Jan 7, 2018 at 3:33 AM, Thomas Gleixner wrote:
> On Sun, 7 Jan 2018, Jike Song wrote:
>
> Care to explain why you think this is not needed?
>
Hi Thomas,
Look at one of the original code snippets:
162 if (pgd_none(*pgd)) {
163 unsigned long new_p4d_page =
After reviewing memdup_user() callers, I've found several places
where it got completely unbounded values passed for size (up to 2Gb),
as well as some bounded by ridiculously high values - e.g.
if (size > 1024 * 128) /* sane value */
return -EINVAL;
contain
Hi folks,
on my old laptop I've a quadcore 2.5 GHz CPU, but the max freq
the governor switches to goes only up to 2.1 GHz (at idle it's 1.4 GHz):
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
250 210 180 140
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuin
On 1/6/2018 3:21 PM, Woodhouse, David wrote:
> On Sat, 2018-01-06 at 21:16 +, Andrew Cooper wrote:
>> On 06/01/18 11:49, David Woodhouse wrote:
>>> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
>>> index 372ba3f..40e6e54 100644
>>> --- a/arch/x86/kernel/cpu/common.c
>
From: Willy Tarreau
Date: Sat, 6 Jan 2018 21:42:29 +0100
> On Sat, Jan 06, 2018 at 06:38:59PM +, Alan Cox wrote:
>> Normally people who propose security fixes don't have to argue about the
>> fact they added 30 clocks to avoid your box being 0wned.
>
> In fact it depends, because if a fix ma
On Sat, Jan 6, 2018 at 11:53 AM, Thomas Gleixner wrote:
> On Sat, 6 Jan 2018, Linus Torvalds wrote:
>
>>
>> [ Goes off and looks ]
>>
>> Oh. The AMD lfence version wants a register. Oh well.
>
> The register load could be put into the macro itself, though we need to
> supply a scratch register
Ye
On Sat, Jan 6, 2018 at 3:31 PM, Dan Williams wrote:
>
> I assume if we put this in uaccess_begin() we also need audit for
> paths that use access_ok but don't do on to call uaccess_begin()? A
> quick glance shows a few places where we are open coding the stac().
> Perhaps land the lfence in stac()
The following build error is seen when building metag:meta2_defconfig
or metag:tz1090_defconfig.
arch/metag/kernel/process.c: In function '__metag_elf_map':
arch/metag/kernel/process.c:421: error: 'tsk' undeclared
Bisect results attached.
Guenter
---
# bad: [990b6a07d18cb30a66db3d18ab7d95380623
untangle sys_close() abuses in xt_bpf, deal with register_shrinker()
failures in sget()
The following changes since commit d7ee946942bdd12394809305e3df05aa4c8b7b8f:
VFS: Handle lazytime in do_mount() (2017-12-09 20:16:33 -0500)
are available in the git repository at:
git://git.kerne
Sphinx emits various warnings when building make target 'htmldocs'.
Currently struct journal_s definition contains duplicate documentation,
some as kernel-docs and some as standard c89 comments. We can reduce
duplication while cleaning up the kernel-docs.
Move all kernel-docs to right above eac
The series is aimed at making input events y2038 safe.
It extends the lifetime of the realtime timestamps in the
events to year 2106.
The series is also a necessary update as glibc is set to provide
64 bit time_t support for 32 bit binaries. glibc plan is detailed
at https://sourceware.org/glibc/wi
struct timeval is not y2038 safe.
All usage of timeval in the kernel will be replaced by
y2038 safe structures.
The change is also necessary as glibc is introducing support
for 32 bit applications to use 64 bit time_t. Without this
change, many applications would incorrectly interpret values
in the
Arjan pointed out that CONFIG_TRIM_UNUSED_SYMBOLS *really* doesn't like
the dot in the symbols that GCC uses for the thunks.
This seems to work, although my eyes are bleeding just a little bit.
Given this, and the hack we already needed for MODVERSIONS, I wonder if
a better approach might be to e
Hi Ahmed,
On Fri, Dec 29, 2017 at 12:07:52PM +0100, Ahmed Abdelsalam wrote:
> It allows matching packets based on Segment Routing Header
> (SRH) information.
> The implementation considers revision 7 of the SRH draft.
> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-07
>
> Cur
On Fri, Jan 5, 2018 at 7:09 PM, Linus Torvalds
wrote:
> On Fri, Jan 5, 2018 at 6:52 PM, Linus Torvalds
> wrote:
>>
>> The fact is, we have to stop speculating when access_ok() does *not*
>> fail - because that's when we'll actually do the access. And it's that
>> access that needs to be non-specu
On Sat, Jan 06, 2018 at 10:18:40PM +0100, Thomas Gleixner wrote:
> On Fri, 5 Jan 2018, Paul E. McKenney wrote:
> > But after more than 1,000 hours of test runs, split roughly evenly
> > among the above three scenarios, there is no statistically significant
> > difference in error rate among them.
> Even if it would be practical the speed probably going to be in bytes per
> second,
> so to read anything meaningful an attack detection techniques (that people
> are actively working on) will be able to catch it.
> At the end security cannot be absolute.
> The current level of paranoia shouldn'
SPHINX build emits multiple warnings of kind:
warning: duplicate section name 'Note'
(when building kernel via make target 'htmldocs')
This is caused by repeated use of comments of form:
* Note: soau soaeusoa uoe
We can change the format without loss of clarity and clear the bu
On Sat, Jan 06, 2018 at 11:02:27AM +, Jonathan McDowell wrote:
> On Sat, Jan 06, 2018 at 12:30:23AM +0100, Rafael J. Wysocki wrote:
> > On Wed, Jan 3, 2018 at 12:49 PM, Rafael J. Wysocki
> > wrote:
> > > From: Rafael J. Wysocki
> > >
> > > Calling acpi_wmi_init() at the subsys_initcall() lev
On Thu, Dec 28, 2017 at 09:48:54AM +0100, Dmitry Vyukov wrote:
> syzkaller triggered OOM kills by passing ipt_replace.size = -1
> to IPT_SO_SET_REPLACE. The root cause is that SMP_ALIGN() in
> xt_alloc_table_info() causes int overflow and the size check passes
> when it should not. SMP_ALIGN() is n
Hi,
commit 7e7a20a2058dc ("Construct init thread stack in the linker script rather
than by union") results in various build failures in -next.
cris:
arch/cris/kernel/vmlinux.lds:67:
undefined symbol `THREAD_SIZE' referenced in expression
crisv32:
arch/cris/kernel/vmlinux.lds:72:
On 01/06/18 12:20, Matthew Wilcox wrote:
>
> I've been thinking about all the kernel-doc we have that's completely
> unincorporated. I've also been thinking about core-api/kernel-api.rst
> which to my mind is completely unreadable in its current form -- look at
> https://www.kernel.org/doc/html/l
On Sat, 6 Jan 2018 22:44:08 +0100
SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sat, 6 Jan 2018 22:34:12 +0100
>
> Two strings should be quickly put into a sequence by two function calls.
> Thus use the function "seq_puts" instead of "seq_printf".
>
> This issue was detected by using
于 2018年1月7日 GMT+08:00 上午6:12:57, Hans de Goede 写到:
>Hi,
>
>On 05-01-18 17:56, Icenowy Zheng wrote:
>> The UAS mode of Norelsys NS1068(X) is reported to fail to work on
>> several platforms with the following error message:
>>
>> xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for unknown stream
Hi,
On 05-01-18 17:56, Icenowy Zheng wrote:
The UAS mode of Norelsys NS1068(X) is reported to fail to work on
several platforms with the following error message:
xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for unknown stream ring slot 1
ep 8
xhci-hcd xhci-hcd.0.auto: @bf04a400 0
>
> ->dev_state can't be both MEI_DEV_RESETTING and
> MEI_DEV_POWER_DOWN at
> the same time. && was clearing intended here.
>
> Fixes: 8d52af6795c0 ("mei: speed up the power down flow")
> Signed-off-by: Dan Carpenter
Thanks Dan but this was already reported and patch was created by Colin.
ht
When building kernel documentation sphinx emits the following warning
warning: No description found for parameter 'owner'
Add description for struct member 'owner'.
Signed-off-by: Tobin C. Harding
---
include/linux/iio/trigger.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/inclu
Kernel-doc for @use_count does not currently have a field identifier.
All the rest of the fields do. @use_count is used internally and should
not be accessed directly by the driver so it should be marked as so.
Add [INTERN] identifier to @use_count field.
Signed-off-by: Tobin C. Harding
---
inc
This series was inspired by a warning emitted by sphinx when running
kernel make target 'htmldocs'.
warning: No description found for parameter 'owner'
Patch 1 adds a kernel-doc description for field @owner.
Patch 2 adds field identifier to kernel-doc string (for @use_count).
v3:
- Fix
On Sat, Jan 06, 2018 at 07:00:48PM +, Al Viro wrote:
> On Sat, Jan 06, 2018 at 06:46:19PM +, Al Viro wrote:
> > On Sat, Jan 06, 2018 at 09:45:41AM -0800, Eric Biggers wrote:
> > > This series removes some cruft (mainly exported functions) from
> > > fs/eventfd.c which seems to have been add
On Sat, 2018-01-06 at 21:34 +, Andrew Cooper wrote:
> On 06/01/18 21:23, Thomas Gleixner wrote:
> >
> > On Sat, 6 Jan 2018, Andrew Cooper wrote:
> > >
> > > On 06/01/18 11:49, David Woodhouse wrote:
> > > >
> > > > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> >
On Sat, Jan 06, 2018 at 10:39:27PM +0100, Thomas Gleixner wrote:
> On Sat, 6 Jan 2018, Konrad Rzeszutek Wilk wrote:
> > On Sat, Jan 06, 2018 at 08:47:19PM +0100, Thomas Gleixner wrote:
> > > On Sat, 6 Jan 2018, Dave Hansen wrote:
> > >
> > > > On 01/06/2018 09:41 AM, Van De Ven, Arjan wrote:
> > >
From: Markus Elfring
Date: Sat, 6 Jan 2018 22:34:12 +0100
Two strings should be quickly put into a sequence by two function calls.
Thus use the function "seq_puts" instead of "seq_printf".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
net/atm/clip
On Sat, 6 Jan 2018, Mauro Carvalho Chehab wrote:
> Hi Josef,
>
> Em Sat, 6 Jan 2018 16:04:16 +0100
> "Josef Griebichler" escreveu:
>
> > Hi,
> >
> > the causing commit has been identified.
> > After reverting commit
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit
> > it's a mistake though... retpoline is what people should be using
> > ... and only in super exception cases should IBRS even be considered
>
> Like on certain Skylake and Broadwell where using the retpoline won't suffice?
skylake is a bit more complex but that was discussed in earlier e
On Tue, Jan 2, 2018 at 7:35 AM, Arnd Bergmann wrote:
> On Tue, Jan 2, 2018 at 7:46 AM, Dmitry Torokhov
> wrote:
>> On Sun, Dec 17, 2017 at 09:18:43PM -0800, Deepa Dinamani wrote:
>>> @@ -304,12 +314,11 @@ static void evdev_events(struct input_handle *handle,
>>> {
>>> struct evdev *evdev =
On Sat, Jan 06, 2018 at 09:34:01PM +, Van De Ven, Arjan wrote:
> > I agree. But this is what customers are told to inspect to see if they
> > are impacted. And if in the future versions this goes away or such - they
> > will freak out and cause needless escalations.
>
>
> it's a mistake thoug
On Sat, Jan 06, 2018 at 01:00:53PM +, Jonathan Cameron wrote:
> On Sat, 6 Jan 2018 12:31:57 +1100
> "Tobin C. Harding" wrote:
>
> > When building kernel documentation sphinx emits the following warning
> >
> > warning: No description found for parameter 'owner'
> >
> > Add description
Variable Length Arrays In Structs (VLAIS) is not supported by Clang, and
frowned upon by others.
https://lkml.org/lkml/2013/9/23/500
Here, the VLAIS was used because the size of the bitmap returned from
xen_mc_entry() depended on possibly (based on kernel configuration)
runtime sized data. Rather
On Sat, 6 Jan 2018, Konrad Rzeszutek Wilk wrote:
> On Sat, Jan 06, 2018 at 08:47:19PM +0100, Thomas Gleixner wrote:
> > On Sat, 6 Jan 2018, Dave Hansen wrote:
> >
> > > On 01/06/2018 09:41 AM, Van De Ven, Arjan wrote:
> > > .macro DISABLE_IBRS
> > > -ALTERNATIVE "jmp .Lskip_\@", "",
On Thu, Jan 04, 2018 at 07:38:00PM +0100, Thomas Zeitlhofer wrote:
> On Thu, Jan 04, 2018 at 06:07:12PM +0100, Peter Zijlstra wrote:
> > On Thu, Jan 04, 2018 at 04:37:24PM +0100, Thomas Gleixner wrote:
> > > > Yes:
> > > >
> > > >BUG: using smp_processor_id() in preemptible [] code:
>
On Sat, Jan 6, 2018 at 4:14 PM, Jonathan Cameron wrote:
> Are you using devicetree or some other method to instantiate the device?
> i.e. How does the kernel know it exists?
>
Yes, I'm using device-tree (in a way like in bindings txt). I have
also max1137 connected, which is loaded and probed well
On 06/01/18 21:23, Thomas Gleixner wrote:
> On Sat, 6 Jan 2018, Andrew Cooper wrote:
>> On 06/01/18 11:49, David Woodhouse wrote:
>>> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
>>> index 372ba3f..40e6e54 100644
>>> --- a/arch/x86/kernel/cpu/common.c
>>> +++ b/arch/x86/
Linus,
The following changes since commit aa12f594f97efe50223611dbd13ecca4e8dafee6:
tools/kvm_stat: sort '-f help' output (2017-12-21 13:03:32 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/virt/kvm/kvm for-linus
for you to fetch changes up to bb4945e60dd0b5afb
> I agree. But this is what customers are told to inspect to see if they
> are impacted. And if in the future versions this goes away or such - they
> will freak out and cause needless escalations.
it's a mistake though... retpoline is what people should be using
... and only in super except
On Sat, Jan 06, 2018 at 08:47:19PM +0100, Thomas Gleixner wrote:
> On Sat, 6 Jan 2018, Dave Hansen wrote:
>
> > On 01/06/2018 09:41 AM, Van De Ven, Arjan wrote:
> > .macro DISABLE_IBRS
> > - ALTERNATIVE "jmp .Lskip_\@", "", X86_FEATURE_SPEC_CTRL
> > + testl $1, dynamic_
On Sat, Jan 06, 2018 at 10:10:59AM -0800, Tim Chen wrote:
>
>
> On 01/06/2018 12:54 AM, Greg KH wrote:
> > On Fri, Jan 05, 2018 at 06:12:19PM -0800, Tim Chen wrote:
> >> From: Tim Chen
> >> From: Andrea Arcangeli
> >>
> >> There are 2 ways to control IBRS
> >>
> >> 1. At boot time
> >> noib
On Sat, 6 Jan 2018, Andrew Cooper wrote:
> On 06/01/18 11:49, David Woodhouse wrote:
> > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> > index 372ba3f..40e6e54 100644
> > --- a/arch/x86/kernel/cpu/common.c
> > +++ b/arch/x86/kernel/cpu/common.c
> > @@ -904,6 +904,11 @@
On Sat, 2018-01-06 at 21:16 +, Andrew Cooper wrote:
> On 06/01/18 11:49, David Woodhouse wrote:
> > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> > index 372ba3f..40e6e54 100644
> > --- a/arch/x86/kernel/cpu/common.c
> > +++ b/arch/x86/kernel/cpu/common.c
> > @@ -90
On Sat, 6 Jan 2018, Alexei Starovoitov wrote:
> So how about we do array_access() macro similar to above by default
> with extra CONFIG_ to convert it to lfence ?
> Why default to AND approach instead of lfence ?
> Because the kernel should still be usable. If security
> sacrifices performance so m
On Fri, 5 Jan 2018, Paul E. McKenney wrote:
> But after more than 1,000 hours of test runs, split roughly evenly
> among the above three scenarios, there is no statistically significant
> difference in error rate among them. This means that there is some
> other bug lurking somewhere, and having t
On 06/01/18 11:49, David Woodhouse wrote:
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 372ba3f..40e6e54 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -904,6 +904,11 @@ static void __init early_identify_cpu(struct cpuinfo_
On Sat, Jan 06, 2018 at 08:22:13PM +, Alan Cox wrote:
> > "Value prediction consists of predicting entire 32- and 64-bit register
> > values
> > based on previously-seen values"
>
> For their implementation yes
>
> >
> > > In other words there are at least two problems with Linus proposal
On 01/04/2018 09:21 AM, Eric Leblond wrote:
> Parse netlink ext attribute to get the error message returned by
> the card. Code is partially take from libnl.
>
> Signed-off-by: Eric Leblond
> Acked-by: Alexei Starovoitov
> ---
> samples/bpf/Makefile | 2 +-
> tools/lib/bpf/Build| 2 +-
Commit-ID: eeab3eee2fa4a8e8eb52e2abf034f14f1d010e0d
Gitweb: https://git.kernel.org/tip/eeab3eee2fa4a8e8eb52e2abf034f14f1d010e0d
Author: Tom Lendacky
AuthorDate: Fri, 5 Jan 2018 10:08:05 -0600
Committer: Thomas Gleixner
CommitDate: Sat, 6 Jan 2018 21:57:41 +0100
x86/msr: Remove now unus
Commit-ID: 0592b0bce1694957fed178fc52f4b11576714b07
Gitweb: https://git.kernel.org/tip/0592b0bce1694957fed178fc52f4b11576714b07
Author: Tom Lendacky
AuthorDate: Fri, 5 Jan 2018 10:07:46 -0600
Committer: Thomas Gleixner
CommitDate: Sat, 6 Jan 2018 21:57:40 +0100
x86/cpu/AMD: Make LFENCE
Commit-ID: 0bf17c102177d5da9363bf8b1e4704b9996d5079
Gitweb: https://git.kernel.org/tip/0bf17c102177d5da9363bf8b1e4704b9996d5079
Author: Tom Lendacky
AuthorDate: Fri, 5 Jan 2018 10:07:56 -0600
Committer: Thomas Gleixner
CommitDate: Sat, 6 Jan 2018 21:57:40 +0100
x86/cpu/AMD: Use LFENCE_
Commit-ID: 01c9b17bf673b05bb401b76ec763e9730ccf1376
Gitweb: https://git.kernel.org/tip/01c9b17bf673b05bb401b76ec763e9730ccf1376
Author: Dave Hansen
AuthorDate: Fri, 5 Jan 2018 09:44:36 -0800
Committer: Thomas Gleixner
CommitDate: Sat, 6 Jan 2018 21:39:10 +0100
x86/Documentation: Add PT
Commit-ID: 99c6fa2511d8a683e61468be91b83f85452115fa
Gitweb: https://git.kernel.org/tip/99c6fa2511d8a683e61468be91b83f85452115fa
Author: David Woodhouse
AuthorDate: Sat, 6 Jan 2018 11:49:23 +
Committer: Thomas Gleixner
CommitDate: Sat, 6 Jan 2018 21:57:19 +0100
x86/cpufeatures: Add
Commit-ID: de53c3786a3ce162a1c815d0c04c766c23ec9c0a
Gitweb: https://git.kernel.org/tip/de53c3786a3ce162a1c815d0c04c766c23ec9c0a
Author: Jiri Kosina
AuthorDate: Fri, 5 Jan 2018 22:35:41 +0100
Committer: Thomas Gleixner
CommitDate: Sat, 6 Jan 2018 21:38:16 +0100
x86/pti: Unbreak EFI old_
Hi,
thanks for adding the people involved!
Yes arm and x86 are affected.
Bisecting was not done by me on a x86_64 machine on mainline kernel and not
raspbian kernel
(https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=75965#post75965).
In the mentioned pos
SOMJATE MOOSIRILERT
Senior Executive Vice President
Thanachart Bank PCL
Bangkok Thailand
Attention: BENEFICIARY
A woman came to my office few days ago with a letter, claiming to be your true
representative to your inheritance funds of $43.6m. Here are her information:
Please do reconfirm to thi
Got it. I suppose that explains why it was so unreliably
reproducible..
In any case, the patch is holding strong still with plenty of activity
since, so it's looking good.
Thak you for all of this; very instructive.
On Sat, Jan 06, 2018 at 08:55:00PM +, Chris Wilson wrote:
> Quoting Alexandr
From: Markus Elfring
Date: Sat, 6 Jan 2018 21:50:20 +0100
A string which did not contain a data format specification should be put
into a sequence. Thus use the corresponding function "seq_puts".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drive
On Fri, 22 Dec 2017 11:09:15 +0100
Andrea Adami wrote:
> On Wed, Dec 20, 2017 at 6:45 AM, Wei Yongjun wrote:
> > Fixes the following sparse warnings:
> >
> > drivers/mtd/parsers/sharpslpart.c:222:6: warning:
> > symbol 'sharpsl_nand_cleanup_ftl' was not declared. Should it be static?
> >
> > Si
On Sat, Jan 06, 2018 at 06:38:59PM +, Alan Cox wrote:
> Normally people who propose security fixes don't have to argue about the
> fact they added 30 clocks to avoid your box being 0wned.
In fact it depends, because if a fix makes the system unusable for its
initial purpose, this fix will simp
Hello,
What are the next steps for this patch?
Note: the MAINTAINERS file does not contain a T: (tree) entry for
ZSMALLOC, so I can't check to see if this has already been merged or
not. Unless you work out of the mm tree?
On Tue, Jan 2, 2018 at 7:00 AM, Boris Ostrovsky
wrote:
> On 01/02/2018 09:32 AM, Andrew Cooper wrote:
>> On 02/01/18 14:24, Juergen Gross wrote:
>>> On 02/01/18 15:18, Boris Ostrovsky wrote:
On 12/23/2017 09:50 PM, Nick Desaulniers wrote:
> The header declares this function as __init but
> "Value prediction consists of predicting entire 32- and 64-bit register values
> based on previously-seen values"
For their implementation yes
>
> > In other words there are at least two problems with Linus proposal
> >
> > 1. The / mask has to be generated and that has to involve
>
Hi Avi,
On Sat, Jan 06, 2018 at 09:33:28PM +0200, Avi Kivity wrote:
> Meltdown and Spectre mitigations focus on protecting the kernel from a
> hostile userspace. However, it's not a given that the kernel is the most
> important target in the system. It is common in server workloads that a
> single
On Sat, Jan 06, 2018 at 11:09:08AM -0700, Jonathan Corbet wrote:
> On Tue, 2 Jan 2018 13:04:31 -0800
> Matthew Wilcox wrote:
>
> > > +When replacing the group list, the new list must be sorted before it
> > > +is added to the credential, as a binary search is used to test for
> > > +membership.
This patch fixes 3 small issues:
- missing 2nd '*' at the beginning of a doxygen comment
- extra space after a '\n' in a dev_dbg message
- extra tab before a 'return" statement
Signed-off-by: Christophe JAILLET
---
sound/soc/intel/atom/sst/sst_stream.c | 6 +++---
1 file changed, 3 insertions
In some error handling paths, an error code is assiegned to 'ret'.
However, the function always return 0.
Fix it and return the error code if such an error paths is taken.
Fixes: 3d9ff34622ba ("ASoC: Intel: sst: add stream operations")
Signed-off-by: Christophe JAILLET
---
sound/soc/intel/atom/
From: Martin Kelly
Currently in a number of Makefiles, we clobber the CC, LD, and/or STRIP env vars
when cross-compiling, which breaks any additional flags that might be set (such
as sysroot). This easily shows up by using, for instance, a Yocto SDK.
Fix this by more carefully overriding the fla
On Sat, Jan 06, 2018 at 07:55:51PM +, Alan Cox wrote:
> > cpus execute what they see. speculative execution does the same
> > except results are not committed to visible registers and stay
> > in renanmed/shadow set. There is no 'undo' of the speculative execution.
> > The whole issue is that c
On Sat, Jan 6, 2018 at 11:37 AM, Dan Williams wrote:
> On Fri, Jan 5, 2018 at 5:09 PM, Dan Williams wrote:
>> Quoting Mark's original RFC:
>>
>> "Recently, Google Project Zero discovered several classes of attack
>> against speculative execution. One of these, known as variant-1, allows
>> explic
On Sun, Jan 07, 2018 at 01:50:59AM +0800, Jike Song wrote:
> Signed-off-by: Jike Song
It would be nice to have a commit message, particularly in this quite
sensitive series...
Willy
On Sat, Jan 6, 2018 at 10:00 PM, Hans de Goede wrote:
> Hi,
>
>
> On 06-01-18 20:56, Alexander Kapshuk wrote:
>>
>> On Sat, Jan 6, 2018 at 9:43 PM, Hans de Goede wrote:
>>>
>>> HI,
>>>
>>>
>>> On 06-01-18 20:30, Alexander Kapshuk wrote:
On Sat, Jan 6, 2018 at 6:00 PM, Hans de Goede
> I propose to create a new capability, CAP_PAYLOAD, that allows the
> system administrator to designate an application as the main workload in
> that system. Other processes (like sshd or monitoring daemons) exist to
> support it, and so it makes sense to protect the rest of the system from
>
Hi,
On 06-01-18 20:56, Alexander Kapshuk wrote:
On Sat, Jan 6, 2018 at 9:43 PM, Hans de Goede wrote:
HI,
On 06-01-18 20:30, Alexander Kapshuk wrote:
On Sat, Jan 6, 2018 at 6:00 PM, Hans de Goede wrote:
Hi,
On 06-01-18 15:20, Alexander Kapshuk wrote:
On Mon, Dec 25, 2017 at 04:42:59
1 - 100 of 324 matches
Mail list logo
