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
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
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
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
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
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
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
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
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:
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:
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
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
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
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
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
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
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:
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:
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
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
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
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
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.
>
>
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.
>
>
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:
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:
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
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
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 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 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\
>
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\
>
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
>>
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
>>
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
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
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
>>
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
>>
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 +-
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 +-
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
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
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
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
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.
> >
>
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 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
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
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: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
>
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
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
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
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
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
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
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)
> >>
>
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)
> >>
>
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:
> >
> >
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:
> >
> >
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 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 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 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 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
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
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
>
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
>
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
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
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
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
> 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
> 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
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
---
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
---
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
>
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
>
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
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
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
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
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
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
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 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
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
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
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 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 >
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
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 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 >
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
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:
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:
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
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
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
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
301 - 400 of 890 matches
Mail list logo
