Hi,
On Wed, Aug 15, 2018 at 11:38:52AM -0500, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Addresses-Coverity-ID: 1462408 ("Missing break in switch")
> Signed-off-by: Gustavo A. R. Silva
> ---
> d
Would this be okay?
diff --git a/arch/x86/kernel/kexec-bzimage64.c
b/arch/x86/kernel/kexec-bzimage64.c
index 7326078e..2ba47e24 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -41,6 +41,9 @@
#define MIN_KERNEL_LOAD_ADDR 0x10
#define MIN_INITRD_LOAD
Jacek
On 08/15/2018 11:56 AM, Jacek Anaszewski wrote:
> Hi Dan,
>
> Thank you for the update.
>
> On 08/15/2018 06:17 PM, Dan Murphy wrote:
>> Add the device tree bindings for the lm3697
>> LED driver for backlighting and display.
>>
>> Signed-off-by: Dan Murphy
>> ---
>>
>> v3 - Updated subjec
Hi Greg & Thomas,
I'd like to report a regression in Linux 4.18.1 regarding the L1TF patches.
The kernel no longer thinks I have SMT enabled in the BIOS. This works fine in
4.18.0.
Not sure if this matters, but in my particular 4-core system, my third core is
broken (core #2). So I must boot us
On Wed, Aug 15, 2018 at 01:24:25PM -0400, Byron Stanoszek wrote:
> Hi Greg & Thomas,
>
> I'd like to report a regression in Linux 4.18.1 regarding the L1TF patches.
>
> The kernel no longer thinks I have SMT enabled in the BIOS. This works fine in
> 4.18.0.
>
> Not sure if this matters, but in m
On Wed, Aug 15, 2018 at 10:26 AM Roman Gushchin wrote:
>
> On Wed, Aug 15, 2018 at 10:12:42AM -0700, Andy Lutomirski wrote:
> >
> >
> > > On Aug 15, 2018, at 9:55 AM, Roman Gushchin wrote:
> > >
> > >> On Wed, Aug 15, 2018 at 12:39:23PM -0400, Johannes Weiner wrote:
> > >>> On Tue, Aug 14, 2018 a
> On Aug 15, 2018, at 10:32 AM, Shakeel Butt wrote:
>
>> On Wed, Aug 15, 2018 at 10:26 AM Roman Gushchin wrote:
>>
>>> On Wed, Aug 15, 2018 at 10:12:42AM -0700, Andy Lutomirski wrote:
>>>
>>>
> On Aug 15, 2018, at 9:55 AM, Roman Gushchin wrote:
>
>> On Wed, Aug 15, 2018 at 12
I'm sorry, the sign-off was missing again (this is my first submission
to linux).
Signed-off-by: Yannik Sembritzki
Cc: sta...@vger.kernel.org
---
arch/x86/kernel/kexec-bzimage64.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/kexec-bzimage64.c
b/arch/x86
On Wed, Aug 15, 2018 at 07:27:33PM +0200, Yannik Sembritzki wrote:
> Would this be okay?
[ CC dave young, Baoquan, Justin Forbes]
Hi Yannik,
I am reading that bug and wondering that what broke it. It used to work,
so some change broke it.
Justin said that we have been signing fedora kernels wi
On Wed, Aug 15, 2018 at 10:27 AM Yannik Sembritzki wrote:
>
> Would this be okay?
No, I meant that it would have to go into the proper header files, and
also be used by verify_pkcs7_signature() and pkcs7_preparse() etc, so
that you could actually grep for this, and understand what it does.
Right
Hi Marcus,
On 8/15/18 12:27 PM, Marcus Folkesson wrote:
> Hi,
>
> On Wed, Aug 15, 2018 at 11:38:52AM -0500, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>> where we are expecting to fall through.
>>
>> Addresses-Coverity-ID: 1462408 ("Missing
On 2018-08-15 19:01 +0200, Sebastian Gottschall wrote:
> nother issue seen on xscale and as it affects all non SMP configured kernels
>
>
> kernel/cpu.c: In function 'boot_cpu_hotplug_init':
> kernel/cpu.c:2204:28: error: 'struct cpuhp_cpu_state' has no member
> named 'booted_once'
> this_cpu_wr
Hi Linus,
Please pull Kbuild updates for v4.19
You can pull this cleanly for now, but please remember that
you will have to change samples/statx/Makefile
when you pull the following commit:
commit 90b413cb970a25109deb292c99120cf65e5b03ce
Author: David Howells
Date: Fri Aug 3 15:34:49 2018 +
On 08/15/2018 09:10 AM, Cornelia Huck wrote:
On Mon, 13 Aug 2018 17:48:11 -0400
Tony Krowiak wrote:
From: Tony Krowiak
Introduces two new KVM interface to clear the APM, AQM and ADM masks in
the guest's CRYCB. The VCPUs are taken out of SIE to ensure the VCPUs do
not get out of sync.
Signe
Hi Linus,
Please pull Kconfig updates for v4.19
You will see a conflict in the top-level Makefile.
Please fix it like follows. (it is also available in linux-next)
---
diff --cc Makefile
index cc4875d,f17dd99..a0650bf
--- a/Makefile
Hello all,
Just wanted to give you a quick update now that I got my hands on an
OEM Windows version of the same machine. I can confirm that Windows
is able to use the TPM to some extent; confirmation and some of the
output of some of the TPM Powershell cmdlets is at
https://gist.github.com/hliebe
Hi Linus,
Please pull this patch series to consolidate arch Kconfig files.
Sorry for many conflicts.
Equivalent fixes are available in linux-next,
but I sorted the 'select' lines alphabetically
in arch/nios2/Kconfig.
(of course, this is not important, though.)
-
diff -
Dan,
On 08/15/2018 07:30 PM, Dan Murphy wrote:
> Jacek
>
> On 08/15/2018 11:56 AM, Jacek Anaszewski wrote:
>> Hi Dan,
>>
>> Thank you for the update.
>>
>> On 08/15/2018 06:17 PM, Dan Murphy wrote:
>>> Add the device tree bindings for the lm3697
>>> LED driver for backlighting and display.
>>>
>>
Jacek
On 08/15/2018 01:09 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 08/15/2018 07:30 PM, Dan Murphy wrote:
>> Jacek
>>
>> On 08/15/2018 11:56 AM, Jacek Anaszewski wrote:
>>> Hi Dan,
>>>
>>> Thank you for the update.
>>>
>>> On 08/15/2018 06:17 PM, Dan Murphy wrote:
Add the device tree bindin
> No, I meant that it would have to go into the proper header files, and
> also be used by verify_pkcs7_signature() and pkcs7_preparse() etc, so
> that you could actually grep for this, and understand what it does.
Thanks, Linus, I'll take care of this right away.
This is my first patch and I'm no
On 08/15/2018 12:08 PM, Cornelia Huck wrote:
On Mon, 13 Aug 2018 17:48:12 -0400
Tony Krowiak wrote:
From: Tony Krowiak
Implements the open callback on the mediated matrix device.
The function registers a group notifier to receive notification
of the VFIO_GROUP_NOTIFY_SET_KVM event. When noti
Am 15.08.2018 um 19:52 schrieb Sven Joachim:
On 2018-08-15 19:01 +0200, Sebastian Gottschall wrote:
nother issue seen on xscale and as it affects all non SMP configured kernels
kernel/cpu.c: In function 'boot_cpu_hotplug_init':
kernel/cpu.c:2204:28: error: 'struct cpuhp_cpu_state' has no me
On Wed, Aug 15, 2018 at 11:19 AM Yannik Sembritzki wrote:
>
> > No, I meant that it would have to go into the proper header files, and
> > also be used by verify_pkcs7_signature() and pkcs7_preparse() etc, so
> > that you could actually grep for this, and understand what it does.
> Thanks, Linus,
On Wed, Aug 15, 2018 at 11:22 AM Sebastian Gottschall
wrote:
>
> btw. i found another compile error with x86 :-)
This should already be fixed by commit d0055f351e64 ("x86/smp: fix
non-SMP broken build due to redefinition of
apic_id_is_primary_thread").
Linus
if i fix the other error (can be reproduced with disable smp on standard
i386 build)
another raises up again related to smp. to be serious. this patchset of
x86 patches is absolutelly broken and put together without any care. not
a simple compile test has been done
sorry for beeing a little
This patch adds CPU hotplug support where the PMU migrates the context to
another online CPU when its CPU is offline.
It fixes the below issue where the user does offline the CPU which is assigned
to this PMU.
Assuming, CPU0 is assigned for this PMU. When the user does offline CPU0
[root@
Am 15.08.2018 um 20:26 schrieb Linus Torvalds:
On Wed, Aug 15, 2018 at 11:22 AM Sebastian Gottschall
wrote:
btw. i found another compile error with x86 :-)
This should already be fixed by commit d0055f351e64 ("x86/smp: fix
non-SMP broken build due to redefinition of
apic_id_is_primary_thread
I propose using following set of GCC flags to enforce code quality in
the long run.
-Wall -Wextra -Werror\
-std=gnu11\
-pedantic \
-Wchar-subscripts\
-Wformat\
-Wformat-nonliteral\
-Wformat-security\
-Wmissing-braces\
-Wparentheses\
-Wsequence-point\
-Ws
On Wed, Aug 15, 2018 at 9:41 AM, Linus Torvalds
wrote:
> On Mon, Aug 13, 2018 at 2:43 PM Kees Cook wrote:
>>
>> Please pull these gcc-plugin changes for v4.19-rc1.
>
> No.
>
> It adds yet another BUG_ON() without having been merged.
>
> I'm not pulling this. Dammit, have you learnt *nothing*?
I
Just tried 4.18.0-02978-g1eb46908b35d on a sparc64 box with Debian Ports
sparc64 unstable (apparmor packages recommended by linux-image package)
and got the following on bootup:
[ 46.315721] Kernel unaligned access at TPC[6b8b98] aa_dfa_unpack+0x38/0x620
[ 46.412375] Kernel unaligned access
Hi,
Please pull these gcc-plugin cleanups for v4.19-rc1. This moves the Kconfig
menu around, makes the Makefile more readable, and clean up a function
declaration.
Thanks!
-Kees
The following changes since commit 7daf201d7fe8334e2d2364d4e8ed3394ec9af819:
Linux 4.18-rc2 (2018-06-24 20:54:29 +
> I am reading that bug and wondering that what broke it. It used to work,
> so some change broke it.
>
> Previously, I think all the keys used to go in system keyring and it
> used to work. Is it somehow because of split in builtin keyring and
> secondary system keyring. Could it be that fedora
On 14/08/18 15:40, Mark Brown wrote:
> On Mon, Aug 13, 2018 at 07:19:16PM +0100, Jon Hunter wrote:
>>
>> I had taken some ftrace graphs but there was not one thing that really
>> stood out. Looking again it seems that each call to
>> async_schedule_domain() can take tens of uS and so it there are
Background:
Recently, when we ran some vm scalability tests on machines with large memory,
we ran into a couple of mmap_sem scalability issues when unmapping large memory
space, please refer to https://lkml.org/lkml/2017/12/14/733 and
https://lkml.org/lkml/2018/2/20/576.
History:
Then akpm sugg
Hello,
syzbot found the following crash on:
HEAD commit:1236568ee3cb Merge tag 'gpio-v4.18-3' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=135f47e040
kernel config: https://syzkaller.appspot.com/x/.config?x=152cb8ccd35b1f70
da
Introduces three new helper functions:
* addr_ok()
* munmap_lookup_vma()
* munlock_vmas()
They will be used by do_munmap() and the new do_munmap with zapping
large mapping early in the later patch.
There is no functional change, just code refactor.
Reviewed-by: Laurent Dufour
Acked-by: Vl
When unmapping VM_HUGETLB mappings, vm flags need to be updated. Since
the vmas have been detached, so it sounds safe to update vm flags with
read mmap_sem.
Cc: Michal Hocko
Cc: Vlastimil Babka
Signed-off-by: Yang Shi
---
mm/mmap.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff
When unmapping VM_PFNMAP mappings, vm flags need to be updated. Since
the vmas have been detached, so it sounds safe to update vm flags with
read mmap_sem.
Cc: Michal Hocko
Cc: Vlastimil Babka
Signed-off-by: Yang Shi
---
mm/mmap.c | 13 +
1 file changed, 5 insertions(+), 8 deletion
When running some mmap/munmap scalability tests with large memory (i.e.
> 300GB), the below hung task issue may happen occasionally.
INFO: task ps:14018 blocked for more than 120 seconds.
Tainted: GE 4.9.79-009.ali3000.alios7.x86_64 #1
"echo 0 > /proc/sys/kernel/hung_task_timeo
We need check if mm or vma has uprobes in the following patch to check
if a vma could be unmapped with holding read mmap_sem. The checks and
pre-conditions used by uprobe_munmap() look just suitable for this
purpose.
Extracting those checks into a helper function, has_uprobes().
Cc: Peter Zijlstr
On Wed, Aug 15, 2018 at 10:11:20AM +1000, Stephen Rothwell wrote:
> Hi Bruce,
>
> On Tue, 14 Aug 2018 13:50:20 -0700 Dmitry Vyukov wrote:
> >
> > On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields
> > wrote:
> > > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
> > >> syzbot has found
On Wed, Aug 15, 2018 at 08:27:00PM +0200, Sebastian Gottschall wrote:
> if i fix the other error (can be reproduced with disable smp on standard
> i386 build)
>
> another raises up again related to smp. to be serious. this patchset of x86
> patches is absolutelly broken and put together without an
On Wed, Aug 15, 2018 at 01:42:47PM -0400, Vivek Goyal wrote:
> On Wed, Aug 15, 2018 at 07:27:33PM +0200, Yannik Sembritzki wrote:
> > Would this be okay?
>
> [ CC dave young, Baoquan, Justin Forbes]
>
> Hi Yannik,
>
> I am reading that bug and wondering that what broke it. It used to work,
> so
This is mostly updates to the usual drivers: mpt3sas, lpfc, qla2xxx,
hisi_sas, smartpqi, megaraid_sas, arcmsr. In addition, with the
continuing absence of Nic we have target updates for tcmu and target
core (all with reviews and acks). The biggest observable change is
going to be that we're (agai
On Wed, Aug 15, 2018 at 11:35 AM Kees Cook wrote:
>
> I swear I'm doing my best. Are you speaking of
> stackleak_check_alloca() or stackleak_erase()? These were both
> discussed on the list, and we weren't able to come up with
> alternatives: in both cases we're off the stack, and recovery is
> se
This change increases the source code readability.
Instead of using `spi->child[cs].direct_access.XXX` use `dir_acc->XXX`.
Instead of using `orion_spi->child[cs].direct_access.vaddr` use `vaddr`.
Signed-off-by: Kosta Zertsekel
Reviewed-by: Andrew Lunn
Reviewed-by: Stefan Roese
---
drivers/spi/
> I am wondering why did we have to split this keyring to begin with.
> So there are use cases where we want to trust builtin keys but
> not the ones which came from other places (UEFI secure boot db, or
> user loaded one)?
>
"User loaded ones" should not be trusted in general to prevent rootkit
Am 15.08.2018 um 20:55 schrieb Guenter Roeck:
On Wed, Aug 15, 2018 at 08:27:00PM +0200, Sebastian Gottschall wrote:
if i fix the other error (can be reproduced with disable smp on standard
i386 build)
another raises up again related to smp. to be serious. this patchset of x86
patches is absol
On Wed, Aug 15, 2018 at 08:33:30PM +0200, Sebastian Gottschall wrote:
>
> Am 15.08.2018 um 20:26 schrieb Linus Torvalds:
> > On Wed, Aug 15, 2018 at 11:22 AM Sebastian Gottschall
> > wrote:
> > > btw. i found another compile error with x86 :-)
> > This should already be fixed by commit d0055f351e
On Wed, Aug 15, 2018 at 07:01:38PM +0200, Sebastian Gottschall wrote:
> nother issue seen on xscale and as it affects all non SMP configured kernels
>
>
> kernel/cpu.c: In function 'boot_cpu_hotplug_init':
> kernel/cpu.c:2204:28: error: 'struct cpuhp_cpu_state' has no member named
> 'booted_once'
On Wed, Aug 15, 2018 at 08:27:00PM +0200, Sebastian Gottschall wrote:
> if i fix the other error (can be reproduced with disable smp on standard
> i386 build)
>
> another raises up again related to smp. to be serious. this patchset of x86
> patches is absolutelly broken and put together without an
On Thu, Aug 16, 2018 at 02:49:48AM +0800, Yang Shi wrote:
> +static int do_munmap_zap_rlock(struct mm_struct *mm, unsigned long start,
> +size_t len, struct list_head *uf)
> +{
> + unsigned long end;
> + struct vm_area_struct *start_vma, *prev, *vma;
> + int
On Mon, Aug 06, 2018 at 02:41:45PM +0100, Suzuki K Poulose wrote:
> Prepare to handle errors in enabling the hardware and
> report it back to the core driver.
>
> Cc: Mathieu Poirier
> Signed-off-by: Suzuki K Poulose
> ---
> drivers/hwtracing/coresight/coresight-tmc-etf.c | 71
> ++
On Wed, Aug 15, 2018 at 11:45:39AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Thu, 26 Jul 2018 13:58:04 +1000 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the block tree got a conflict in:
> >
> > drivers/nvme/target/rdma.c
> >
> > between commit:
> >
> > 23f96d1f15a
On Wed, Aug 15, 2018 at 09:08:08PM +0200, Sebastian Gottschall wrote:
>
> Am 15.08.2018 um 20:55 schrieb Guenter Roeck:
> >On Wed, Aug 15, 2018 at 08:27:00PM +0200, Sebastian Gottschall wrote:
> >>if i fix the other error (can be reproduced with disable smp on standard
> >>i386 build)
> >>
> >>ano
From: Randy Dunlap
Fix missing error check for memory allocation functions in
scripts/mod/modpost.c.
Fixes kernel bugzilla #200319:
https://bugzilla.kernel.org/show_bug.cgi?id=200319
Signed-off-by: Randy Dunlap
Cc: Yuexing Wang
Cc: Masahiro Yamada
---
v2: add checks in more places
scripts/
On 08/14/2018 08:29 AM, Will Deacon wrote:
> On Tue, Aug 14, 2018 at 08:17:48AM -0700, Greg Hackmann wrote:
>> On 08/14/2018 03:40 AM, Will Deacon wrote:
>>> Hi Greg,
>>>
>>> On Mon, Aug 13, 2018 at 12:30:11PM -0700, Greg Hackmann wrote:
ARM64's pfn_valid() shifts away the upper PAGE_SHIFT bit
Em Wed, Aug 15, 2018 at 09:30:39AM +0200, Rasmus Villemoes escreveu:
> On 2018-07-05 15:49, Jiri Olsa wrote:
> > On Thu, Jul 05, 2018 at 03:15:27PM +0200, Rasmus Villemoes wrote:
>
> >> this only happens in combination with a O=... parameter. In any case, we
> >> don't lose much by explicitly disa
On Mon, Aug 06, 2018 at 02:41:47PM +0100, Suzuki K Poulose wrote:
> Add support for reporting errors back from the SMP cross
> function call for enabling ETM.
>
> Cc: Mathieu Poirier
> Signed-off-by: Suzuki K Poulose
> ---
> drivers/hwtracing/coresight/coresight-etm3x.c | 42
>
On Mon, Aug 06, 2018 at 02:41:48PM +0100, Suzuki K Poulose wrote:
> Prepare the etb10 driver to return errors in enabling
> the device.
>
> Cc: Mathieu Poirier
> Signed-off-by: Suzuki K Poulose
> ---
> drivers/hwtracing/coresight/coresight-etb10.c | 18 +-
> 1 file changed, 13 i
Em Wed, Jul 04, 2018 at 05:25:36PM +0200, Jiri Olsa escreveu:
> On Wed, Jul 04, 2018 at 02:13:45PM +0200, Jack Henschel wrote:
> > This is the second version of a patch that improves the error
> > message of the perf events parser when the PMU hardware does not support
> > address filters.
> >
> >
On Wed, Aug 15, 2018 at 12:26 PM Guenter Roeck wrote:
>
> Also seen in mainline. Meaning my non-SMP test builds are broken. Hmm.
Grr. I think it's due mainly due to commit 447ae3166702 ("x86: Don't
include linux/irq.h from asm/hardirq.h"), which exposes a number of
files that had some dodgy inclu
I've written two patches for (a) the logical change of allowing kernels
signed with keys in the secondary keyring to be kexec'd (b) the refactoring
of the magic 1UL Linus requested.
Yannik Sembritzki (2):
Fix kexec forbidding kernels signed with keys in the secondary keyring
to boot
Replac
The split of .system_keyring to .builtin_trusted_keys and
.secondary_trusted_keys broke kexec, as kernels signed by keys which are now in
the secondary keyring cannot be kexec'd anymore.
Signed-off-by: Yannik Sembritzki
CC: sta...@vger.kernel.org
---
arch/x86/kernel/kexec-bzimage64.c | 2 +-
1
Hello Linus,
On 15.08.2018 22:04, Linus Torvalds wrote:
> On Wed, Aug 15, 2018 at 11:35 AM Kees Cook wrote:
>>
>> I swear I'm doing my best. Are you speaking of
>> stackleak_check_alloca() or stackleak_erase()? These were both
>> discussed on the list, and we weren't able to come up with
>> alter
Signed-off-by: Yannik Sembritzki
---
arch/x86/kernel/kexec-bzimage64.c | 2 +-
certs/system_keyring.c | 3 ++-
crypto/asymmetric_keys/pkcs7_key_type.c | 2 +-
include/linux/verification.h| 4
4 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/ar
On Wed, Aug 15, 2018 at 12:04 PM, Linus Torvalds
wrote:
> On Wed, Aug 15, 2018 at 11:35 AM Kees Cook wrote:
>>
>> I swear I'm doing my best. Are you speaking of
>> stackleak_check_alloca() or stackleak_erase()? These were both
>> discussed on the list, and we weren't able to come up with
>> alter
On Wed, Aug 15, 2018 at 08:33:36PM +0200, Martin Schroeder wrote:
> I propose using following set of GCC flags to enforce code quality in
> the long run.
>
> -Wall -Wextra -Werror\
> -std=gnu11\
> -pedantic \
> -Wchar-subscripts\
> -Wformat\
> -Wformat-nonliteral\
> -Wf
On Wed, Aug 15, 2018 at 09:06:13PM +0200, Yannik Sembritzki wrote:
>
> > I am wondering why did we have to split this keyring to begin with.
> > So there are use cases where we want to trust builtin keys but
> > not the ones which came from other places (UEFI secure boot db, or
> > user loaded on
ARM's pfn_valid() has a similar shifting bug to the ARM64 bug fixed in
the previous patch. This only affects non-LPAE kernels, since LPAE
kernels will promote to 64 bits inside __pfn_to_phys().
Fixes: 5e6f6aa1c243 ("memblock/arm: pfn_valid uses memblock_is_memory()")
Cc: sta...@vger.kernel.org
Si
ARM64's pfn_valid() shifts away the upper PAGE_SHIFT bits of the input
before seeing if the PFN is valid. This leads to false positives when
some of the upper bits are set, but the lower bits match a valid PFN.
For example, the following userspace code looks up a bogus entry in
/proc/kpageflags:
On Wed, 15 Aug 2018 17:35:18 +0800
Zong Li wrote:
> This patch support the static function tracer. On nds32 ABI, we need to
> always push return address to stack for __builtin_return_address can
> work correctly, otherwise, it will get the wrong value of $lp at leaf
> function.
>
> Signed-off-by
On Tue, Aug 14, 2018 at 07:16:19PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.18.1 release.
> There are 79 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
On Wed, Aug 15, 2018 at 12:45 PM Kees Cook wrote:
>
> I feel like we're talking cross purposes. The BUG() cases were for
> places where we detect that we're executing with an impossible stack
> pointer. It seems like trying to recover from that would just hide the
> corruption for a later time tha
i8259.h uses inb/outb and thus needs to include asm/io.h to avoid the
following build error, as seen with x86_64:defconfig and CONFIG_SMP=n.
In file included from drivers/rtc/rtc-cmos.c:45:0:
arch/x86/include/asm/i8259.h: In function 'inb_pic':
arch/x86/include/asm/i8259.h:32:24: error:
im
On Tue, Aug 14, 2018 at 07:50:17PM +0300, Leonard Crestez wrote:
> This is required for the imx pci driver to send the PME_Turn_Off TLP.
>
> Signed-off-by: Leonard Crestez
> ---
> drivers/reset/reset-imx7.c | 1 +
> include/dt-bindings/reset/imx7-reset.h | 4 +++-
Acked-by: Rob Herr
This adds the ability to define the initial state of each output line on
device probe.
Signed-off-by: David Bauer
---
Documentation/devicetree/bindings/gpio/gpio-74x164.txt | 5 +
drivers/gpio/gpio-74x164.c | 3 +++
2 files changed, 8 insertions(+)
diff --git a/D
On Tue, 14 Aug 2018 19:50:18 +0300, Leonard Crestez wrote:
> This is documented as "required" but won't be present in old dtbs.
>
> These resets are also present on other imx chips but right now only
> imx7d implements them through the reset controller subsystem.
>
> Signed-off-by: Leonard Creste
syzbot has found a reproducer for the following crash on:
HEAD commit:31130a16d459 Merge tag 'for-linus-4.19-rc1-tag' of git://g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1116b46c40
kernel config: https://syzkaller.appspot.com/x/.config?x=e8d529
On Tue, Aug 14, 2018 at 09:29:06PM +0300, Tali Perry wrote:
>
> Nuvoton NPCM7XX I2C Controller
> NPCM7xx includes 16 I2C contollers. This driver operates the controller.
s/contollers/controllers/
> This module also includes a slave mode, which will be submitted later on.
>
> Any feedback would
Quoting Craig Tatlor (2018-08-11 09:24:50)
> Add the compatible for SDM660.
> This does not need clocks to do scm calls
>
> Signed-off-by: Craig Tatlor
> ---
> Documentation/devicetree/bindings/firmware/qcom,scm.txt | 1 +
> drivers/firmware/qcom_scm.c | 3 +++
> 2 fi
On Tue, Aug 14, 2018 at 07:16:12PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.17.15 release.
> There are 97 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know
Am 15.08.2018 um 21:42 schrieb Linus Torvalds:
On Wed, Aug 15, 2018 at 12:26 PM Guenter Roeck wrote:
Also seen in mainline. Meaning my non-SMP test builds are broken. Hmm.
Grr. I think it's due mainly due to commit 447ae3166702 ("x86: Don't
include linux/irq.h from asm/hardirq.h"), which exp
This changes the behavior of the KASLR logic for allocating memory for the text
sections of loadable modules. It randomizes the location of each module text
section with about 17 bits of entropy in typical use. This is enabled on X86_64
only. For 32 bit, the behavior is unchanged. It refactors exis
Add debugfs file "modfraginfo" for providing info on module space fragmentation.
This can be used for determining if loadable module randomization is causing any
problems for extreme module loading situations, like huge numbers of modules or
extremely large modules.
Sample output when KASLR is ena
Hi,
This is V3 of the "KASLR feature to randomize each loadable module" patchset.
The purpose is to increase the randomization and also to make the modules
randomized in relation to each other instead of just the base, so that if one
module leaks the location of the others can't be inferred.
V3 i
Create __vmalloc_node_try_addr function that tries to allocate at a specific
address and supports caller specified behavior for whether any lazy purging
happens if there is a collision.
Signed-off-by: Rick Edgecombe
---
include/linux/vmalloc.h | 3 +
mm/vmalloc.c| 177 +
On Tue, Aug 14, 2018 at 01:50:20PM -0700, Dmitry Vyukov wrote:
> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields
> wrote:
> > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
> >> syzbot has found a reproducer for the following crash on:
> >>
> >> HEAD commit:5ed5da74de9e Add linux-n
The DT based and ACPI based platform drivers here do the same thing; map
some memory and hand it over to the coreboot bus to populate devices.
The only major difference is that the DT based driver doesn't map the
coreboot table header to figure out how large of a region to map for the
whole coreboo
Now that the /firmware/coreboot node in DT is populated by the core DT
platform code with commit 3aa0582fdb82 ("of: platform: populate
/firmware/ node from of_platform_default_populate_init()") we should and
can remove the platform device creation here. Otherwise, the
of_platform_device_create() ca
On 08/15/2018 12:24 PM, Cornelia Huck wrote:
On Mon, 13 Aug 2018 17:48:14 -0400
Tony Krowiak wrote:
Nit: please drop the leading period in the subject.
I assume you mean the ending period?
From: Tony Krowiak
Let's call PAPQ(ZAPQ) to zeroize a queue:
* For each queue configured for a me
This is all system memory, so we shouldn't be mapping this all with
ioremap() as these aren't I/O regions. Instead, they're memory regions
so we should use memremap(). Pick MEMREMAP_WB so we can map memory from
RAM directly if that's possible, otherwise it falls back to
ioremap_cache() like is bein
This series reworks the coreboot firmware driver a bit to fix some bugs
and then simplify the code by changing the design to get rid of the
different platform drivers, remap memory with memremap() to fix sparse
__iomem issue, and finally simplify code. There's some risk in changing to
memremap() bu
The bus is registered in module_init() but is unregistered when the
platform driver remove() function calls coreboot_table_exit(). That
isn't symmetric and it causes the bus to appear on systems that compile
this code in, even when there isn't any coreboot firmware on the device.
Let's move the reg
Both callers of coreboot_table_init() ioremap the pointer that comes in
but they don't unmap the memory on failure. Both of them also fail probe
immediately with the return value of coreboot_table_init(), leaking a
mapping when it fails. The mapping isn't necessary at all after devices
are populate
This function checks the header for sanity, registers a bus, and
populates devices for each coreboot table entry. Let's just populate
devices here and pull the other bits up into the caller so that this
function can be repurposed for pure device creation and registration.
Cc: Wei-Ning Huang
Cc: J
On Tue, Aug 14, 2018 at 07:16:14PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.63 release.
> There are 104 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me kno
On Wed, Aug 15, 2018 at 12:42:27PM -0700, Linus Torvalds wrote:
> On Wed, Aug 15, 2018 at 12:26 PM Guenter Roeck wrote:
> >
> > Also seen in mainline. Meaning my non-SMP test builds are broken. Hmm.
>
> Grr. I think it's due mainly due to commit 447ae3166702 ("x86: Don't
Yes. It was a side effec
On Wed, Aug 15, 2018 at 1:33 PM Sebastian Gottschall
wrote:
>
> if it would be helpfull i can do this quick here using the latest
> vanilla tree
It would definitely be helpful, since I'm already quite busy with the
normal merge window work. Having the embargo for L1TF end just as the
merge window
On Tue, Aug 14, 2018 at 07:16:23PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.120 release.
> There are 107 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me kno
201 - 300 of 443 matches
Mail list logo
