RE: v4.16+ seeing many unaligned access in dequeue_task_fair() on IA64

> bisect says: > > d519329f72a6 ("sched/fair: Update util_est only on util_avg updates") > > Reverting just this commit makes the problem go away. The unaligned read and write seem to come from: struct util_est ue = READ_ONCE(p->se.avg.util_est); WRITE_ONCE(p->se.avg.util_est, ue); which is

RE: v4.16+ seeing many unaligned access in dequeue_task_fair() on IA64

> bisect says: > > d519329f72a6 ("sched/fair: Update util_est only on util_avg updates") > > Reverting just this commit makes the problem go away. The unaligned read and write seem to come from: struct util_est ue = READ_ONCE(p->se.avg.util_est); WRITE_ONCE(p->se.avg.util_est, ue); which is

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:47 PM, Matthew Garrett wrote: >> Another way of looking at this: if lockdown is a good idea to enable >> when you booted using secure boot, then why isn't it a good idea when >> you *didn't* boot using secure boot? > > Because it's then trivial to

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:47 PM, Matthew Garrett wrote: >> Another way of looking at this: if lockdown is a good idea to enable >> when you booted using secure boot, then why isn't it a good idea when >> you *didn't* boot using secure boot? > > Because it's then trivial to circumvent and the

Re: BUG: unable to handle kernel paging request in cleanup_bitmap_list

syzbot has found reproducer for the following crash on upstream commit f2d285669aae656dfeafa0bf25e86bbbc5d22329 (Tue Apr 3 17:45:39 2018 +) Merge tag 'pm-4.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm syzbot dashboard link:

Re: BUG: unable to handle kernel paging request in cleanup_bitmap_list

syzbot has found reproducer for the following crash on upstream commit f2d285669aae656dfeafa0bf25e86bbbc5d22329 (Tue Apr 3 17:45:39 2018 +) Merge tag 'pm-4.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm syzbot dashboard link:

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:55 PM Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 4:45 PM, Matthew Garrett wrote: > >> Be honest now. It wasn't generally users who clamored for it. > > > > If you ask a user whether they want a system that lets an

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:55 PM Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 4:45 PM, Matthew Garrett wrote: > >> Be honest now. It wasn't generally users who clamored for it. > > > > If you ask a user whether they want a system that lets an attacker replace > > their kernel or one that

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:56 PM, David Howells wrote: => > Most users haven't even given this a moment's thought, aren't even aware of > the issues, don't even know to ask and, for them, it makes no difference. > They trust their distribution to deal with stuff they don't know

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:56 PM, David Howells wrote: => > Most users haven't even given this a moment's thought, aren't even aware of > the issues, don't even know to ask and, for them, it makes no difference. > They trust their distribution to deal with stuff they don't know about. Right. Like

Re: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support

On Wed, Mar 28, 2018 at 10:43 AM, Arnd Bergmann wrote: > On Wed, Mar 28, 2018 at 4:27 PM, Ioana Ciornei wrote: >> Hi, >> >>> >>> Hi Ioana, >>> >>> So this driver is a direct passthrough to your hardware for passing fixed- >>> length command/response pairs.

Re: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support

On Wed, Mar 28, 2018 at 10:43 AM, Arnd Bergmann wrote: > On Wed, Mar 28, 2018 at 4:27 PM, Ioana Ciornei wrote: >> Hi, >> >>> >>> Hi Ioana, >>> >>> So this driver is a direct passthrough to your hardware for passing fixed- >>> length command/response pairs. Have you considered using a

Re: [PATCH] drm/imx: Remove last traces of struct imx_drm_crtc

On Tue, Mar 27, 2018 at 6:39 PM, Leonard Crestez wrote: > When the definition of this struct was removed a forward declaration and an > unused struct member were still left around. Remove them because they serve > no purpose. > > Fixes 44b460cfe554 ("drm: imx: remove

Re: [GIT PULL] Kernel lockdown for secure boot

Linus Torvalds wrote: > Be honest now. It wasn't generally users who clamored for it. > ... > If the user actually wanted it, and is asking for it, he can enable it. >From the distributions' point of view, this is a rubbish argument. Most users haven't even given

Re: [PATCH] drm/imx: Remove last traces of struct imx_drm_crtc

On Tue, Mar 27, 2018 at 6:39 PM, Leonard Crestez wrote: > When the definition of this struct was removed a forward declaration and an > unused struct member were still left around. Remove them because they serve > no purpose. > > Fixes 44b460cfe554 ("drm: imx: remove struct imx_drm_crtc and >

Re: [GIT PULL] Kernel lockdown for secure boot

Linus Torvalds wrote: > Be honest now. It wasn't generally users who clamored for it. > ... > If the user actually wanted it, and is asking for it, he can enable it. >From the distributions' point of view, this is a rubbish argument. Most users haven't even given this a moment's thought,

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:45 PM, Matthew Garrett wrote: >> Be honest now. It wasn't generally users who clamored for it. > > If you ask a user whether they want a system that lets an attacker replace > their kernel or one that doesn't, what do you think their answer is likely >

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:45 PM, Matthew Garrett wrote: >> Be honest now. It wasn't generally users who clamored for it. > > If you ask a user whether they want a system that lets an attacker replace > their kernel or one that doesn't, what do you think their answer is likely > to be? Goddamnit.

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:39 PM, David Howells wrote: > Linus Torvalds wrote: > >> The same thing is true of some lockdown patch. Maybe it's a good thing >> in general. But whether it's a good thing is _entirely_ independent of >> any secure

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:39 PM, David Howells wrote: > Linus Torvalds wrote: > >> The same thing is true of some lockdown patch. Maybe it's a good thing >> in general. But whether it's a good thing is _entirely_ independent of >> any secure boot issue. I can see using secure boot without it, but

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:39 PM Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 4:26 PM, Linus Torvalds > wrote: > > > > Magically changing kernel behavior depending on some subtle and often > > unintentional bootup behavior detail is

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:39 PM Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 4:26 PM, Linus Torvalds > wrote: > > > > Magically changing kernel behavior depending on some subtle and often > > unintentional bootup behavior detail is completely idiotic. > Another way of looking at this: if

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:26 PM Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 4:17 PM, Matthew Garrett wrote: > > > > 1) Secure Boot is intended to permit the construction of a boot chain that > > only runs ring 0 code that the user considers

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:26 PM Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 4:17 PM, Matthew Garrett wrote: > > > > 1) Secure Boot is intended to permit the construction of a boot chain that > > only runs ring 0 code that the user considers trustworthy > No. > That may be *one* intention,

Re: [PATCH] mm/migrate: properly preserve write attribute in special migrate entry

On Tue, 3 Apr 2018 19:03:36 -0400 Jerome Glisse wrote: > > That sounds a bit serious. Was a -stable backport considered? > > Like discuss previously with Michal, for lack of upstream user yet > (and PowerPC users of this code are not upstream either yet AFAIK). > > Once i

Re: [PATCH] mm/migrate: properly preserve write attribute in special migrate entry

On Tue, 3 Apr 2018 19:03:36 -0400 Jerome Glisse wrote: > > That sounds a bit serious. Was a -stable backport considered? > > Like discuss previously with Michal, for lack of upstream user yet > (and PowerPC users of this code are not upstream either yet AFAIK). > > Once i get HMM inside

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:12 PM, David Howells wrote: > Andy Lutomirski wrote: > >> I'm having a very, very hard time coming up with a scenario where I >> can "trust" something if an attacker can get root but can't modify the >> running kernel image but I

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:12 PM, David Howells wrote: > Andy Lutomirski wrote: > >> I'm having a very, very hard time coming up with a scenario where I >> can "trust" something if an attacker can get root but can't modify the >> running kernel image but I can't "trust" something if the attacker

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:26 PM, Linus Torvalds wrote: > > Magically changing kernel behavior depending on some subtle and often > unintentional bootup behavior detail is completely idiotic. Another way of looking at this: if lockdown is a good idea to enable when

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:26 PM, Linus Torvalds wrote: > > Magically changing kernel behavior depending on some subtle and often > unintentional bootup behavior detail is completely idiotic. Another way of looking at this: if lockdown is a good idea to enable when you booted using secure boot,

Re: [GIT PULL] Kernel lockdown for secure boot

Linus Torvalds wrote: > The same thing is true of some lockdown patch. Maybe it's a good thing > in general. But whether it's a good thing is _entirely_ independent of > any secure boot issue. I can see using secure boot without it, but I > can very much also see

Re: [GIT PULL] Kernel lockdown for secure boot

Linus Torvalds wrote: > The same thing is true of some lockdown patch. Maybe it's a good thing > in general. But whether it's a good thing is _entirely_ independent of > any secure boot issue. I can see using secure boot without it, but I > can very much also see using lockdown without secure

Re: [PATCH v2] ARM: dts: tpc: Device tree description of the iMX6Q TPC board

Hi Lukasz, On Tue, Apr 3, 2018 at 1:59 PM, Lukasz Majewski wrote: > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt > b/Documentation/devicetree/bindings/vendor-prefixes.txt > index ae850d6c0ad3..8ff7eadc8bef 100644 > ---

Re: [PATCH v2] ARM: dts: tpc: Device tree description of the iMX6Q TPC board

Hi Lukasz, On Tue, Apr 3, 2018 at 1:59 PM, Lukasz Majewski wrote: > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt > b/Documentation/devicetree/bindings/vendor-prefixes.txt > index ae850d6c0ad3..8ff7eadc8bef 100644 > ---

Re: [PATCH 00/12] SWIM driver fixes

On 4/3/18 5:32 PM, Jens Axboe wrote: > On 3/31/18 7:41 PM, Finn Thain wrote: >> This patch series has fixes for bugs in the SWIM floppy disk controller >> driver, including an oops and a soft lockup. >> >> There are also patches to add support for SWIM devices connected to IOPs. >> >> Geert, would

Re: [PATCH 00/12] SWIM driver fixes

On 4/3/18 5:32 PM, Jens Axboe wrote: > On 3/31/18 7:41 PM, Finn Thain wrote: >> This patch series has fixes for bugs in the SWIM floppy disk controller >> driver, including an oops and a soft lockup. >> >> There are also patches to add support for SWIM devices connected to IOPs. >> >> Geert, would

Re: [PATCH 00/12] SWIM driver fixes

On 3/31/18 7:41 PM, Finn Thain wrote: > This patch series has fixes for bugs in the SWIM floppy disk controller > driver, including an oops and a soft lockup. > > There are also patches to add support for SWIM devices connected to IOPs. > > Geert, would you please take this series through the

Re: [PATCH 00/12] SWIM driver fixes

On 3/31/18 7:41 PM, Finn Thain wrote: > This patch series has fixes for bugs in the SWIM floppy disk controller > driver, including an oops and a soft lockup. > > There are also patches to add support for SWIM devices connected to IOPs. > > Geert, would you please take this series through the

Re: [PATCH v4 2/2] KVM: X86: Add Force Emulation Prefix for "emulate the next instruction"

2018-04-04 3:24 GMT+08:00 Radim Krčmář : > 2018-03-30 02:06-0700, Wanpeng Li: >> From: Wanpeng Li >> >> There is no easy way to force KVM to run an instruction through the emulator >> (by design as that will expose the x86 emulator as a significant >>

Re: [PATCH v4 2/2] KVM: X86: Add Force Emulation Prefix for "emulate the next instruction"

2018-04-04 3:24 GMT+08:00 Radim Krčmář : > 2018-03-30 02:06-0700, Wanpeng Li: >> From: Wanpeng Li >> >> There is no easy way to force KVM to run an instruction through the emulator >> (by design as that will expose the x86 emulator as a significant >> attack-surface). >> However, we do wish to

[PATCH v5 1/2] KVM: X86: Introduce handle_ud()

From: Wanpeng Li Introduce handle_ud() to handle invalid opcode, this function will be used by later patches. Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Liran Alon Cc: Paolo Bonzini Cc: Radim

[PATCH v5 1/2] KVM: X86: Introduce handle_ud()

From: Wanpeng Li Introduce handle_ud() to handle invalid opcode, this function will be used by later patches. Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Liran Alon Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Andrew Cooper Cc: Konrad Rzeszutek Wilk Cc: Liran Alon Signed-off-by: Wanpeng Li

[PATCH v5 2/2] KVM: X86: Add Force Emulation Prefix for "emulate the next instruction"

From: Wanpeng Li There is no easy way to force KVM to run an instruction through the emulator (by design as that will expose the x86 emulator as a significant attack-surface). However, we do wish to expose the x86 emulator in case we are testing it (e.g. via

[PATCH v5 2/2] KVM: X86: Add Force Emulation Prefix for "emulate the next instruction"

From: Wanpeng Li There is no easy way to force KVM to run an instruction through the emulator (by design as that will expose the x86 emulator as a significant attack-surface). However, we do wish to expose the x86 emulator in case we are testing it (e.g. via kvm-unit-tests). Therefore, this

[PATCH v5 0/2] KVM: X86: Add Force Emulation Prefix for "emulate the next instruction"

There is no easy way to force KVM to run an instruction through the emulator (by design as that will expose the x86 emulator as a significant attack-surface). However, we do wish to expose the x86 emulator in case we are testing it (e.g. via kvm-unit-tests). Therefore, this patch adds a "force

[PATCH v5 0/2] KVM: X86: Add Force Emulation Prefix for "emulate the next instruction"

There is no easy way to force KVM to run an instruction through the emulator (by design as that will expose the x86 emulator as a significant attack-surface). However, we do wish to expose the x86 emulator in case we are testing it (e.g. via kvm-unit-tests). Therefore, this patch adds a "force

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:12 PM, David Howells wrote: > > What use is secure boot if processes run as root can subvert your kernel? Stop this idiocy. The above has now been answered multiple times, several different ways. The "point" of secure boot may be that you had no

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:12 PM, David Howells wrote: > > What use is secure boot if processes run as root can subvert your kernel? Stop this idiocy. The above has now been answered multiple times, several different ways. The "point" of secure boot may be that you had no choice, or there was no

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:17 PM, Matthew Garrett wrote: > > 1) Secure Boot is intended to permit the construction of a boot chain that > only runs ring 0 code that the user considers trustworthy No. That may be *one* intention, for some people. It's not an a-priori one for the

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:17 PM, Matthew Garrett wrote: > > 1) Secure Boot is intended to permit the construction of a boot chain that > only runs ring 0 code that the user considers trustworthy No. That may be *one* intention, for some people. It's not an a-priori one for the actual user. >

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:08 PM Linus Torvalds wrote: > That's not the right approach to begin with, Matthew. The onus is on > *you* to explain why you tied them together, not on others to explain > to you - over and over - that they have nothing to do with each

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:08 PM Linus Torvalds wrote: > That's not the right approach to begin with, Matthew. The onus is on > *you* to explain why you tied them together, not on others to explain > to you - over and over - that they have nothing to do with each other. 1) Secure Boot is

Re: [RFC PATCH] packet: mark ring entry as in-use inside spin_lock to prevent RX ring overrun

On Tue, 3 Apr 2018 17:55:25 -0400 Jon Rosen wrote: > Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which > casues the ring to get corrupted by allowing multiple kernel threads > to claim ownership of the same ring entry, Mark the ring entry as > already being

Re: [RFC PATCH] packet: mark ring entry as in-use inside spin_lock to prevent RX ring overrun

On Tue, 3 Apr 2018 17:55:25 -0400 Jon Rosen wrote: > Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which > casues the ring to get corrupted by allowing multiple kernel threads > to claim ownership of the same ring entry, Mark the ring entry as > already being used within the

Re: [RFC] prctl: Deprecate non PR_SET_MM_MAP operations

On 4/3/18 3:37 PM, Cyrill Gorcunov wrote: An ability to manipulate mm_struct fields was introduced in sake of CRIU in first place. Later we provide more suitable and safe operation PR_SET_MM_MAP where all fields to be modifed are passed in one structure which allows us to make more detailed

Re: [RFC] prctl: Deprecate non PR_SET_MM_MAP operations

On 4/3/18 3:37 PM, Cyrill Gorcunov wrote: An ability to manipulate mm_struct fields was introduced in sake of CRIU in first place. Later we provide more suitable and safe operation PR_SET_MM_MAP where all fields to be modifed are passed in one structure which allows us to make more detailed

Re: [GIT PULL] Kernel lockdown for secure boot

Andy Lutomirski wrote: > I'm having a very, very hard time coming up with a scenario where I > can "trust" something if an attacker can get root but can't modify the > running kernel image but I can't "trust" something if the attacker > can [modify the running kernel image]. (I

Re: [GIT PULL] Kernel lockdown for secure boot

Andy Lutomirski wrote: > I'm having a very, very hard time coming up with a scenario where I > can "trust" something if an attacker can get root but can't modify the > running kernel image but I can't "trust" something if the attacker > can [modify the running kernel image]. (I think the above

Re: [RFC] Is it correctly that the usage for spin_{lock|unlock}_irq in clear_page_dirty_for_io

On Tue, Apr 3, 2018 at 5:03 AM Michal Hocko wrote: > On Mon 02-04-18 19:50:50, Wang Long wrote: > > > > Hi, Johannes Weiner and Tejun Heo > > > > I use linux-4.4.y to test the new cgroup controller io and the current > > stable kernel linux-4.4.y has the follow logic > > > >

Re: [RFC] Is it correctly that the usage for spin_{lock|unlock}_irq in clear_page_dirty_for_io

On Tue, Apr 3, 2018 at 5:03 AM Michal Hocko wrote: > On Mon 02-04-18 19:50:50, Wang Long wrote: > > > > Hi, Johannes Weiner and Tejun Heo > > > > I use linux-4.4.y to test the new cgroup controller io and the current > > stable kernel linux-4.4.y has the follow logic > > > > > > int

Re: linux-next: manual merge of the asm-generic tree with the kbuild tree

Hi all, On Wed, 28 Mar 2018 09:02:22 +1100 Stephen Rothwell wrote: > > Today's linux-next merge of the asm-generic tree got a conflict in: > > arch/metag/boot/dts/Makefile > > between commit: > > b985b71d295f ("kbuild: mark $(targets) as .SECONDARY and remove

Re: linux-next: manual merge of the asm-generic tree with the kbuild tree

Hi all, On Wed, 28 Mar 2018 09:02:22 +1100 Stephen Rothwell wrote: > > Today's linux-next merge of the asm-generic tree got a conflict in: > > arch/metag/boot/dts/Makefile > > between commit: > > b985b71d295f ("kbuild: mark $(targets) as .SECONDARY and remove .PRECIOUS > markers") > >

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:08 PM, Linus Torvalds wrote: > > This discussion is over until you give an actual honest-to-goodness > reason for why you tied the two features together. No more "Why not?" > crap. Side note: I suspect the reason is something along the

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:08 PM, Linus Torvalds wrote: > > This discussion is over until you give an actual honest-to-goodness > reason for why you tied the two features together. No more "Why not?" > crap. Side note: I suspect the reason is something along the lines of "there are political

Re: linux-next: manual merge of the v4l-dvb tree with the asm-generic tree

Hi all, On Thu, 15 Mar 2018 12:29:21 +1100 Stephen Rothwell wrote: > > Today's linux-next merge of the v4l-dvb tree got a conflict in: > > drivers/media/platform/blackfin/bfin_capture.c > > between commit: > > b9ec40bf7d29 ("media: platform: remove blackfin capture

Re: linux-next: manual merge of the v4l-dvb tree with the asm-generic tree

Hi all, On Thu, 15 Mar 2018 12:29:21 +1100 Stephen Rothwell wrote: > > Today's linux-next merge of the v4l-dvb tree got a conflict in: > > drivers/media/platform/blackfin/bfin_capture.c > > between commit: > > b9ec40bf7d29 ("media: platform: remove blackfin capture driver") > > from the

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 3:53 PM Andy Lutomirski wrote: > On Tue, Apr 3, 2018 at 3:51 PM, Matthew Garrett wrote: > > Lockdown is clearly useful without Secure Boot (and I intend to deploy it > > that way for various things), but I still don't understand why you

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 3:53 PM Andy Lutomirski wrote: > On Tue, Apr 3, 2018 at 3:51 PM, Matthew Garrett wrote: > > Lockdown is clearly useful without Secure Boot (and I intend to deploy it > > that way for various things), but I still don't understand why you feel > > that the common case of

Re: [alsa-devel] [PATCH] ASoC: atmel_ssc_dai: fix spelling mistake: "Stoping" -> "Stopping"

On Tue, 2018-04-03 at 20:54 +0200, Ladislav Michl wrote: > > > > No dai device. > > As all call sites are already providing error message, so what about just > removing this one completely? No idea, none of this is code I know or care about. Do what's appropriate.

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 3:51 PM, Matthew Garrett wrote: > > Lockdown is clearly useful without Secure Boot (and I intend to deploy it > that way for various things), but I still don't understand why you feel > that the common case of booting a kernel from a boot chain that's

Re: [alsa-devel] [PATCH] ASoC: atmel_ssc_dai: fix spelling mistake: "Stoping" -> "Stopping"

On Tue, 2018-04-03 at 20:54 +0200, Ladislav Michl wrote: > > > > No dai device. > > As all call sites are already providing error message, so what about just > removing this one completely? No idea, none of this is code I know or care about. Do what's appropriate.

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 3:51 PM, Matthew Garrett wrote: > > Lockdown is clearly useful without Secure Boot (and I intend to deploy it > that way for various things), but I still don't understand why you feel > that the common case of booting a kernel from a boot chain that's widely > trusted

Re: linux-next: manual merge of the asm-generic tree with the kbuild tree

Hi all, On Thu, 15 Mar 2018 09:42:01 +1100 Stephen Rothwell wrote: > > Today's linux-next merge of the asm-generic tree got a conflict in: > > arch/blackfin/kernel/bfin_ksyms.c > > between commit: > > 4d9c7a5907dd ("kbuild: rename built-in.o to built-in.a") > >

Re: linux-next: manual merge of the asm-generic tree with the kbuild tree

Hi all, On Thu, 15 Mar 2018 09:42:01 +1100 Stephen Rothwell wrote: > > Today's linux-next merge of the asm-generic tree got a conflict in: > > arch/blackfin/kernel/bfin_ksyms.c > > between commit: > > 4d9c7a5907dd ("kbuild: rename built-in.o to built-in.a") > > from the kbuild tree and

Re: linux-next: manual merge of the asm-generic tree with the input-current tree

Hi all, On Thu, 15 Mar 2018 09:56:56 +1100 Stephen Rothwell wrote: > > [Just adding Dimitry to cc] > > On Thu, 15 Mar 2018 09:37:05 +1100 Stephen Rothwell > wrote: > > > > Today's linux-next merge of the asm-generic tree got a conflict in: > > >

Re: linux-next: manual merge of the asm-generic tree with the input-current tree

Hi all, On Thu, 15 Mar 2018 09:56:56 +1100 Stephen Rothwell wrote: > > [Just adding Dimitry to cc] > > On Thu, 15 Mar 2018 09:37:05 +1100 Stephen Rothwell > wrote: > > > > Today's linux-next merge of the asm-generic tree got a conflict in: > > > > drivers/input/joystick/analog.c > > > >

Re: [PATCH] mm/migrate: properly preserve write attribute in special migrate entry

On Tue, Apr 03, 2018 at 03:30:46PM -0700, Andrew Morton wrote: > On Sun, 1 Apr 2018 22:35:06 -0400 jgli...@redhat.com wrote: > > > From: Ralph Campbell > > > > Use of pte_write(pte) is only valid for present pte, the common code > > which set the migration entry can be

Re: [PATCH] mm/migrate: properly preserve write attribute in special migrate entry

On Tue, Apr 03, 2018 at 03:30:46PM -0700, Andrew Morton wrote: > On Sun, 1 Apr 2018 22:35:06 -0400 jgli...@redhat.com wrote: > > > From: Ralph Campbell > > > > Use of pte_write(pte) is only valid for present pte, the common code > > which set the migration entry can be reach for both valid

Re: [RFC][PATCH] tracing, printk: Force no hashing when trace_printk() is used

On Wed, 4 Apr 2018 07:43:49 +1000 "Tobin C. Harding" wrote: > > static noinline_for_stack > > char *restricted_pointer(char *buf, char *end, const void *ptr, > > @@ -1962,6 +1963,10 @@ char *pointer(const char *fmt, char *buf, char *end, > > void *ptr, > > return

Re: [RFC][PATCH] tracing, printk: Force no hashing when trace_printk() is used

On Wed, 4 Apr 2018 07:43:49 +1000 "Tobin C. Harding" wrote: > > static noinline_for_stack > > char *restricted_pointer(char *buf, char *end, const void *ptr, > > @@ -1962,6 +1963,10 @@ char *pointer(const char *fmt, char *buf, char *end, > > void *ptr, > > return

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Tue, 3 Apr 2018 18:11:19 +0200 Michal Hocko wrote: > You can do so, of course. In fact it would have some advantages over > single pages because you would fragment the memory less but this is not > a reliable prevention from OOM killing and the complete memory > depletion

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Tue, 3 Apr 2018 18:11:19 +0200 Michal Hocko wrote: > You can do so, of course. In fact it would have some advantages over > single pages because you would fragment the memory less but this is not > a reliable prevention from OOM killing and the complete memory > depletion if you allow

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 3:51 PM, Matthew Garrett wrote: > On Tue, Apr 3, 2018 at 3:46 PM Linus Torvalds > > wrote: > >> For example, I love signed kernel modules. The fact that I love them >> has absolutely zero to do with secure boot, though.

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 3:51 PM, Matthew Garrett wrote: > On Tue, Apr 3, 2018 at 3:46 PM Linus Torvalds > > wrote: > >> For example, I love signed kernel modules. The fact that I love them >> has absolutely zero to do with secure boot, though. There is >> absolutely no linkage between the two

Re: [PATCH 00/12] SWIM driver fixes

On Tue, 3 Apr 2018, Laurent Vivier wrote: > FWIW, for the series: > FWIW, https://en.wikipedia.org/wiki/Floppy_disk_hardware_emulator ;-)

Re: [PATCH 00/12] SWIM driver fixes

On Tue, 3 Apr 2018, Laurent Vivier wrote: > FWIW, for the series: > FWIW, https://en.wikipedia.org/wiki/Floppy_disk_hardware_emulator ;-)

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 3:46 PM Linus Torvalds wrote: > For example, I love signed kernel modules. The fact that I love them > has absolutely zero to do with secure boot, though. There is > absolutely no linkage between the two issues: I use (self-)signed > kernel

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 3:46 PM Linus Torvalds wrote: > For example, I love signed kernel modules. The fact that I love them > has absolutely zero to do with secure boot, though. There is > absolutely no linkage between the two issues: I use (self-)signed > kernel modules simply because I think

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 3:39 PM, Andy Lutomirski wrote: > > Sure. I have no problem with having an upstream kernel have a > lockdown feature, although I think that feature should distinguish > between reads and writes. But I don't think the upstream kernel > should apply a patch

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 3:39 PM, Andy Lutomirski wrote: > > Sure. I have no problem with having an upstream kernel have a > lockdown feature, although I think that feature should distinguish > between reads and writes. But I don't think the upstream kernel > should apply a patch that ties any of

Re: [PATCH v4 1/3] Add notrace to lib/ucmpdi2.c

On Tue, 03 Apr 2018 07:45:45 PDT (-0700), jho...@kernel.org wrote: On Tue, Apr 03, 2018 at 02:51:06PM +0100, Matt Redfearn wrote: On 29/03/18 22:59, Palmer Dabbelt wrote: > Ah, thanks, I think I must have forgotten about this.  I assume these > three are going through your tree? Yeah I think

Re: [PATCH v4 1/3] Add notrace to lib/ucmpdi2.c

On Tue, 03 Apr 2018 07:45:45 PDT (-0700), jho...@kernel.org wrote: On Tue, Apr 03, 2018 at 02:51:06PM +0100, Matt Redfearn wrote: On 29/03/18 22:59, Palmer Dabbelt wrote: > Ah, thanks, I think I must have forgotten about this.  I assume these > three are going through your tree? Yeah I think

[RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

Add an atomic helper to implement dirtyfb support. This is needed to support DSI command-mode panels with x11 userspace (ie. when we can't rely on pageflips to trigger a flush to the panel). To signal to the driver that the async atomic update needs to synchronize with fences, even though the fb

[RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

Add an atomic helper to implement dirtyfb support. This is needed to support DSI command-mode panels with x11 userspace (ie. when we can't rely on pageflips to trigger a flush to the panel). To signal to the driver that the async atomic update needs to synchronize with fences, even though the fb

Re: [PATCH v4 1/3] Add notrace to lib/ucmpdi2.c

On Tue, 03 Apr 2018 06:51:06 PDT (-0700), matt.redfe...@mips.com wrote: Hi Palmer, On 29/03/18 22:59, Palmer Dabbelt wrote: On Thu, 29 Mar 2018 03:41:21 PDT (-0700), matt.redfe...@mips.com wrote: From: Palmer Dabbelt As part of the MIPS conversion to use the generic GCC

Re: [PATCH v5 2/3] lib: Rename compiler intrinsic selects to GENERIC_LIB_*

On Tue, 03 Apr 2018 02:24:25 PDT (-0700), matt.redfe...@mips.com wrote: When these are included into arch Kconfig files, maintaining alphabetical ordering of the selects means these get split up. To allow for keeping things tidier and alphabetical, rename the selects to GENERIC_LIB_*

[PATCH] x86/entry/64: Drop idtentry's manual stack switch for user entries

For non-paranoid entries, idtentry knows how to switch from the kernel stack to the user stack, as does error_entry. This results in pointless duplication and code bloat. Make idtentry stop thinking about stacks for non-paranoid entries. This reduces text size by 5377 bytes. This goes back to

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 3:32 PM, David Howells wrote: > Andy Lutomirski wrote: > >> > If the user can arbitrarily modify the running kernel image, you cannot >> > trust anything. You cannot determine the trustworthiness of something >> > because your basis

Re: [GIT pull] irq updates for 4.17

On Tue, 03 Apr 2018 05:03:56 PDT (-0700), t...@linutronix.de wrote: Palmer Dabbelt (2): genirq: Add CONFIG_GENERIC_IRQ_MULTI_HANDLER RISC-V: Move to the new GENERIC_IRQ_MULTI_HANDLER handler Oh, sorry, I must have screwed something up here. I attempted to send out a v4 of this

Re: [PATCH v5 2/3] lib: Rename compiler intrinsic selects to GENERIC_LIB_*

On Tue, 03 Apr 2018 02:24:25 PDT (-0700), matt.redfe...@mips.com wrote: When these are included into arch Kconfig files, maintaining alphabetical ordering of the selects means these get split up. To allow for keeping things tidier and alphabetical, rename the selects to GENERIC_LIB_*

<    1   2   3   4   5   6   7   8   9   10   >