Re: [PATCH v2 2/5] mm: memory_hotplug: Remove assumption on memory state before hotremove

On Wed, Nov 29, 2017 at 08:49:13AM +0800, joeyli wrote: > Hi Andrea, > > On Fri, Nov 24, 2017 at 10:22:35AM +, Andrea Reale wrote: > > Resending the patch adding linux-acpi in CC, as suggested by Rafael. > > Everyone else: apologies for the noise. > > >

Re: [PATCH v2 2/5] mm: memory_hotplug: Remove assumption on memory state before hotremove

On Wed, Nov 29, 2017 at 08:49:13AM +0800, joeyli wrote: > Hi Andrea, > > On Fri, Nov 24, 2017 at 10:22:35AM +, Andrea Reale wrote: > > Resending the patch adding linux-acpi in CC, as suggested by Rafael. > > Everyone else: apologies for the noise. > > >

Re: [PATCH v2 2/5] mm: memory_hotplug: Remove assumption on memory state before hotremove

On Fri, Nov 24, 2017 at 07:17:41PM +0100, Michal Hocko wrote: > On Fri 24-11-17 15:54:59, Andrea Reale wrote: > > On Fri 24 Nov 2017, 16:43, Michal Hocko wrote: > > > On Fri 24-11-17 14:49:17, Andrea Reale wrote: > > > > Hi Rafael, > > > > > > > > On Fri 24 Nov 2017, 15:39, Rafael J. Wysocki

Re: [PATCH v2 2/5] mm: memory_hotplug: Remove assumption on memory state before hotremove

On Fri, Nov 24, 2017 at 07:17:41PM +0100, Michal Hocko wrote: > On Fri 24-11-17 15:54:59, Andrea Reale wrote: > > On Fri 24 Nov 2017, 16:43, Michal Hocko wrote: > > > On Fri 24-11-17 14:49:17, Andrea Reale wrote: > > > > Hi Rafael, > > > > > > > > On Fri 24 Nov 2017, 15:39, Rafael J. Wysocki

Re: [PATCH v2 2/5] mm: memory_hotplug: Remove assumption on memory state before hotremove

Hi Andrea, On Fri, Nov 24, 2017 at 10:22:35AM +, Andrea Reale wrote: > Resending the patch adding linux-acpi in CC, as suggested by Rafael. > Everyone else: apologies for the noise. > > Commit 242831eb15a0 ("Memory hotplug / ACPI: Simplify memory removal") > introduced an assumption whereas

Re: [PATCH v2 2/5] mm: memory_hotplug: Remove assumption on memory state before hotremove

Hi Andrea, On Fri, Nov 24, 2017 at 10:22:35AM +, Andrea Reale wrote: > Resending the patch adding linux-acpi in CC, as suggested by Rafael. > Everyone else: apologies for the noise. > > Commit 242831eb15a0 ("Memory hotplug / ACPI: Simplify memory removal") > introduced an assumption whereas

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

On Fri, Oct 27, 2017 at 03:32:26PM -0400, Mimi Zohar wrote: > On Thu, 2017-10-26 at 10:17 -0400, Mimi Zohar wrote: > > On Thu, 2017-10-26 at 15:42 +0800, joeyli wrote: > > > Hi Mimi, > > > > > > Thank you for reviewing. > > > > > > On M

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

On Fri, Oct 27, 2017 at 03:32:26PM -0400, Mimi Zohar wrote: > On Thu, 2017-10-26 at 10:17 -0400, Mimi Zohar wrote: > > On Thu, 2017-10-26 at 15:42 +0800, joeyli wrote: > > > Hi Mimi, > > > > > > Thank you for reviewing. > > > > > > On M

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

Hi Mimi, Thank you for reviewing. On Mon, Oct 23, 2017 at 11:54:43AM -0400, Mimi Zohar wrote: > On Thu, 2017-10-19 at 15:51 +0100, David Howells wrote: > > From: Chun-Yi Lee > > > > When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image > > through

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

Hi Mimi, Thank you for reviewing. On Mon, Oct 23, 2017 at 11:54:43AM -0400, Mimi Zohar wrote: > On Thu, 2017-10-19 at 15:51 +0100, David Howells wrote: > > From: Chun-Yi Lee > > > > When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image > > through kexec_file systemcall if

Re: [PATCH 12/27] x86/msr: Restrict MSR access when the kernel is locked down

Hi David, On Mon, Oct 23, 2017 at 03:49:44PM +0100, David Howells wrote: > Alan Cox wrote: > > > There are a load of standard tools that use this so I think you are going > > to need a whitelist. Can you at least log *which* MSR in the failing case > > so a

Re: [PATCH 12/27] x86/msr: Restrict MSR access when the kernel is locked down

Hi David, On Mon, Oct 23, 2017 at 03:49:44PM +0100, David Howells wrote: > Alan Cox wrote: > > > There are a load of standard tools that use this so I think you are going > > to need a whitelist. Can you at least log *which* MSR in the failing case > > so a whitelist can be built over time ? >

Re: [PATCH 18/27] bpf: Restrict kernel image access functions when the kernel is locked down

On Mon, Oct 23, 2017 at 03:53:00PM +0100, David Howells wrote: > j...@suse.com wrote: > > > hm... patch 4 only prevents write_mem() but not read_mem(). > > Or I missed anything? > > Actually, yes, as it happens, patch 11 prevents you from even opening /dev/mem > and /dev/kmem by locking down

Re: [PATCH 18/27] bpf: Restrict kernel image access functions when the kernel is locked down

On Mon, Oct 23, 2017 at 03:53:00PM +0100, David Howells wrote: > j...@suse.com wrote: > > > hm... patch 4 only prevents write_mem() but not read_mem(). > > Or I missed anything? > > Actually, yes, as it happens, patch 11 prevents you from even opening /dev/mem > and /dev/kmem by locking down

Re: [PATCH 12/27] x86/msr: Restrict MSR access when the kernel is locked down

On Fri, Oct 20, 2017 at 09:48:16PM +0100, David Howells wrote: > Alan Cox wrote: > > > There are a load of standard tools that use this so I think you are going > > to need a whitelist. Can you at least log *which* MSR in the failing case > > so a whitelist can be

Re: [PATCH 12/27] x86/msr: Restrict MSR access when the kernel is locked down

On Fri, Oct 20, 2017 at 09:48:16PM +0100, David Howells wrote: > Alan Cox wrote: > > > There are a load of standard tools that use this so I think you are going > > to need a whitelist. Can you at least log *which* MSR in the failing case > > so a whitelist can be built over time ? > [...snip]

Re: [PATCH 17/27] acpi: Disable APEI error injection if the kernel is locked down

On Thu, Oct 19, 2017 at 03:52:41PM +0100, David Howells wrote: > From: Linn Crosetto > > ACPI provides an error injection mechanism, EINJ, for debugging and testing > the ACPI Platform Error Interface (APEI) and other RAS features. If > supported by the firmware, ACPI

Re: [PATCH 17/27] acpi: Disable APEI error injection if the kernel is locked down

On Thu, Oct 19, 2017 at 03:52:41PM +0100, David Howells wrote: > From: Linn Crosetto > > ACPI provides an error injection mechanism, EINJ, for debugging and testing > the ACPI Platform Error Interface (APEI) and other RAS features. If > supported by the firmware, ACPI specification 5.0 and

Re: [PATCH 16/27] acpi: Disable ACPI table override if the kernel is locked down

On Thu, Oct 19, 2017 at 03:52:34PM +0100, David Howells wrote: > From: Linn Crosetto > > >From the kernel documentation (initrd_table_override.txt): > > If the ACPI_INITRD_TABLE_OVERRIDE compile option is true, it is possible > to override nearly any ACPI table provided by the

Re: [PATCH 16/27] acpi: Disable ACPI table override if the kernel is locked down

On Thu, Oct 19, 2017 at 03:52:34PM +0100, David Howells wrote: > From: Linn Crosetto > > >From the kernel documentation (initrd_table_override.txt): > > If the ACPI_INITRD_TABLE_OVERRIDE compile option is true, it is possible > to override nearly any ACPI table provided by the BIOS with an

Re: [PATCH 15/27] acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down

On Thu, Oct 19, 2017 at 03:52:27PM +0100, David Howells wrote: > From: Josh Boyer > > This option allows userspace to pass the RSDP address to the kernel, which > makes it possible for a user to modify the workings of hardware . Reject > the option when the kernel is locked

Re: [PATCH 15/27] acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down

On Thu, Oct 19, 2017 at 03:52:27PM +0100, David Howells wrote: > From: Josh Boyer > > This option allows userspace to pass the RSDP address to the kernel, which > makes it possible for a user to modify the workings of hardware . Reject > the option when the kernel is locked down. > >

Re: [PATCH 14/27] ACPI: Limit access to custom_method when the kernel is locked down

On Thu, Oct 19, 2017 at 03:52:19PM +0100, David Howells wrote: > From: Matthew Garrett > > custom_method effectively allows arbitrary access to system memory, making > it possible for an attacker to circumvent restrictions on module loading. > Disable it if the kernel

Re: [PATCH 14/27] ACPI: Limit access to custom_method when the kernel is locked down

On Thu, Oct 19, 2017 at 03:52:19PM +0100, David Howells wrote: > From: Matthew Garrett > > custom_method effectively allows arbitrary access to system memory, making > it possible for an attacker to circumvent restrictions on module loading. > Disable it if the kernel is locked down. > >

Re: [PATCH 13/27] asus-wmi: Restrict debugfs interface when the kernel is locked down

On Thu, Oct 19, 2017 at 03:52:11PM +0100, David Howells wrote: > From: Matthew Garrett > > We have no way of validating what all of the Asus WMI methods do on a given > machine - and there's a risk that some will allow hardware state to be > manipulated in such a way

Re: [PATCH 13/27] asus-wmi: Restrict debugfs interface when the kernel is locked down

On Thu, Oct 19, 2017 at 03:52:11PM +0100, David Howells wrote: > From: Matthew Garrett > > We have no way of validating what all of the Asus WMI methods do on a given > machine - and there's a risk that some will allow hardware state to be > manipulated in such a way that arbitrary code can be

Re: [PATCH 12/27] x86/msr: Restrict MSR access when the kernel is locked down

On Thu, Oct 19, 2017 at 03:52:04PM +0100, David Howells wrote: > From: Matthew Garrett > > Writing to MSRs should not be allowed if the kernel is locked down, since > it could lead to execution of arbitrary code in kernel mode. Based on a > patch by Kees Cook. > >

Re: [PATCH 12/27] x86/msr: Restrict MSR access when the kernel is locked down

On Thu, Oct 19, 2017 at 03:52:04PM +0100, David Howells wrote: > From: Matthew Garrett > > Writing to MSRs should not be allowed if the kernel is locked down, since > it could lead to execution of arbitrary code in kernel mode. Based on a > patch by Kees Cook. > > Signed-off-by: Matthew

Re: [PATCH 11/27] x86: Lock down IO port access when the kernel is locked down

On Thu, Oct 19, 2017 at 03:51:56PM +0100, David Howells wrote: > From: Matthew Garrett > > IO port access would permit users to gain access to PCI configuration > registers, which in turn (on a lot of hardware) give access to MMIO > register space. This would

Re: [PATCH 11/27] x86: Lock down IO port access when the kernel is locked down

On Thu, Oct 19, 2017 at 03:51:56PM +0100, David Howells wrote: > From: Matthew Garrett > > IO port access would permit users to gain access to PCI configuration > registers, which in turn (on a lot of hardware) give access to MMIO > register space. This would potentially permit root to trigger

Re: [PATCH 10/27] PCI: Lock down BAR access when the kernel is locked down

On Thu, Oct 19, 2017 at 03:51:49PM +0100, David Howells wrote: > From: Matthew Garrett > > Any hardware that can potentially generate DMA has to be locked down in > order to avoid it being possible for an attacker to modify kernel code, > allowing them to circumvent

Re: [PATCH 10/27] PCI: Lock down BAR access when the kernel is locked down

On Thu, Oct 19, 2017 at 03:51:49PM +0100, David Howells wrote: > From: Matthew Garrett > > Any hardware that can potentially generate DMA has to be locked down in > order to avoid it being possible for an attacker to modify kernel code, > allowing them to circumvent disabled module loading or

Re: [PATCH 09/27] uswsusp: Disable when the kernel is locked down

On Thu, Oct 19, 2017 at 03:51:42PM +0100, David Howells wrote: > From: Matthew Garrett > > uswsusp allows a user process to dump and then restore kernel state, which > makes it possible to modify the running kernel. Disable this if the kernel > is locked down. > >

Re: [PATCH 09/27] uswsusp: Disable when the kernel is locked down

On Thu, Oct 19, 2017 at 03:51:42PM +0100, David Howells wrote: > From: Matthew Garrett > > uswsusp allows a user process to dump and then restore kernel state, which > makes it possible to modify the running kernel. Disable this if the kernel > is locked down. > > Signed-off-by: Matthew

Re: [PATCH 08/27] hibernate: Disable when the kernel is locked down

On Thu, Oct 19, 2017 at 03:51:34PM +0100, David Howells wrote: > From: Josh Boyer > > There is currently no way to verify the resume image when returning > from hibernate. This might compromise the signed modules trust model, > so until we can work with signed

Re: [PATCH 08/27] hibernate: Disable when the kernel is locked down

On Thu, Oct 19, 2017 at 03:51:34PM +0100, David Howells wrote: > From: Josh Boyer > > There is currently no way to verify the resume image when returning > from hibernate. This might compromise the signed modules trust model, > so until we can work with signed hibernate images we disable it

Re: [PATCH 06/27] Copy secure_boot flag in boot params across kexec reboot

On Thu, Oct 19, 2017 at 03:51:20PM +0100, David Howells wrote: > From: Dave Young > > Kexec reboot in case secure boot being enabled does not keep the secure > boot mode in new kernel, so later one can load unsigned kernel via legacy > kexec_load. In this state, the system is

Re: [PATCH 06/27] Copy secure_boot flag in boot params across kexec reboot

On Thu, Oct 19, 2017 at 03:51:20PM +0100, David Howells wrote: > From: Dave Young > > Kexec reboot in case secure boot being enabled does not keep the secure > boot mode in new kernel, so later one can load unsigned kernel via legacy > kexec_load. In this state, the system is missing the

Re: [PATCH 05/27] kexec: Disable at runtime if the kernel is locked down

On Thu, Oct 19, 2017 at 03:51:09PM +0100, David Howells wrote: > From: Matthew Garrett > > kexec permits the loading and execution of arbitrary code in ring 0, which > is something that lock-down is meant to prevent. It makes sense to disable > kexec in this

Re: [PATCH 05/27] kexec: Disable at runtime if the kernel is locked down

On Thu, Oct 19, 2017 at 03:51:09PM +0100, David Howells wrote: > From: Matthew Garrett > > kexec permits the loading and execution of arbitrary code in ring 0, which > is something that lock-down is meant to prevent. It makes sense to disable > kexec in this situation. > > This does not affect

Re: [PATCH 04/27] Restrict /dev/mem and /dev/kmem when the kernel is locked down

Hi David, Thanks for you send out this series. On Thu, Oct 19, 2017 at 03:51:02PM +0100, David Howells wrote: > From: Matthew Garrett > > Allowing users to write to address space makes it possible for the kernel to > be subverted, avoiding module loading

Re: [PATCH 04/27] Restrict /dev/mem and /dev/kmem when the kernel is locked down

Hi David, Thanks for you send out this series. On Thu, Oct 19, 2017 at 03:51:02PM +0100, David Howells wrote: > From: Matthew Garrett > > Allowing users to write to address space makes it possible for the kernel to > be subverted, avoiding module loading restrictions. Prevent this when the >

Re: [PATCH 03/27] Enforce module signatures if the kernel is locked down

Hi David, Thanks for you send our this series. On Thu, Oct 19, 2017 at 03:50:55PM +0100, David Howells wrote: > If the kernel is locked down, require that all modules have valid > signatures that we can verify. > > Signed-off-by: David Howells I have reviewed and tested

Re: [PATCH 03/27] Enforce module signatures if the kernel is locked down

Hi David, Thanks for you send our this series. On Thu, Oct 19, 2017 at 03:50:55PM +0100, David Howells wrote: > If the kernel is locked down, require that all modules have valid > signatures that we can verify. > > Signed-off-by: David Howells I have reviewed and tested this patch. Please

Re: [PATCH 18/27] bpf: Restrict kernel image access functions when the kernel is locked down

Hi Alexei, Thanks for your review! On Thu, Oct 19, 2017 at 03:18:30PM -0700, Alexei Starovoitov wrote: > On Thu, Oct 19, 2017 at 03:52:49PM +0100, David Howells wrote: > > From: Chun-Yi Lee > > > > There are some bpf functions can be used to read kernel memory: > >

Re: [PATCH 18/27] bpf: Restrict kernel image access functions when the kernel is locked down

Hi Alexei, Thanks for your review! On Thu, Oct 19, 2017 at 03:18:30PM -0700, Alexei Starovoitov wrote: > On Thu, Oct 19, 2017 at 03:52:49PM +0100, David Howells wrote: > > From: Chun-Yi Lee > > > > There are some bpf functions can be used to read kernel memory: > > bpf_probe_read,

Re: Draft manpage explaining kernel lockdown

Hi David, On Thu, Oct 05, 2017 at 12:00:24PM +0100, David Howells wrote: > Hi Ard, Michael, > > Attached is a draft for a manual page (kernel_lockdown.7) that I intend to > point at from messages emitted when the kernel prohibits something because the > kernel is in 'lockdown' mode, typically

Re: Draft manpage explaining kernel lockdown

Hi David, On Thu, Oct 05, 2017 at 12:00:24PM +0100, David Howells wrote: > Hi Ard, Michael, > > Attached is a draft for a manual page (kernel_lockdown.7) that I intend to > point at from messages emitted when the kernel prohibits something because the > kernel is in 'lockdown' mode, typically

Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

Hi, On Mon, Jul 10, 2017 at 11:24:44AM +0800, Gary Lin wrote: > A new section, secdata, in the setup header is introduced to store the > distro-specific security version which is designed to help the > bootloader to warn the user when loading a less secure or vulnerable > kernel. The secdata

Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

Hi, On Mon, Jul 10, 2017 at 11:24:44AM +0800, Gary Lin wrote: > A new section, secdata, in the setup header is introduced to store the > distro-specific security version which is designed to help the > bootloader to warn the user when loading a less secure or vulnerable > kernel. The secdata

Re: A udev rule to serve the change event of ACPI container?

On Fri, Aug 04, 2017 at 05:06:19PM +0200, Michal Hocko wrote: > On Thu 03-08-17 11:37:37, YASUAKI ISHIMATSU wrote: > > > > > > On 08/02/2017 01:49 AM, joeyli wrote: > > > Hi YASUAKI, > > > > > > On Tue, Aug 01, 2017 at 03:21:38P

Re: A udev rule to serve the change event of ACPI container?

On Fri, Aug 04, 2017 at 05:06:19PM +0200, Michal Hocko wrote: > On Thu 03-08-17 11:37:37, YASUAKI ISHIMATSU wrote: > > > > > > On 08/02/2017 01:49 AM, joeyli wrote: > > > Hi YASUAKI, > > > > > > On Tue, Aug 01, 2017 at 03:21:38P

Re: A udev rule to serve the change event of ACPI container?

On Thu, Aug 03, 2017 at 11:31:53AM +0200, Michal Hocko wrote: > On Thu 03-08-17 17:22:37, Joey Lee wrote: > > On Wed, Aug 02, 2017 at 11:01:43AM +0200, Michal Hocko wrote: > > > On Mon 31-07-17 15:38:45, Joey Lee wrote: > [...] > > > > So, the behavior is: > > > > > > > > Kernel received ejection

Re: A udev rule to serve the change event of ACPI container?

On Thu, Aug 03, 2017 at 11:31:53AM +0200, Michal Hocko wrote: > On Thu 03-08-17 17:22:37, Joey Lee wrote: > > On Wed, Aug 02, 2017 at 11:01:43AM +0200, Michal Hocko wrote: > > > On Mon 31-07-17 15:38:45, Joey Lee wrote: > [...] > > > > So, the behavior is: > > > > > > > > Kernel received ejection

Re: A udev rule to serve the change event of ACPI container?

On Wed, Aug 02, 2017 at 11:01:43AM +0200, Michal Hocko wrote: > On Mon 31-07-17 15:38:45, Joey Lee wrote: > > Hi Michal, > > > > Sorry for my delay... > > > > On Tue, Jul 25, 2017 at 02:48:37PM +0200, Michal Hocko wrote: > > > On Mon 24-07-17 17:29:21, Joey Lee wrote: > [...] > > > > For the

Re: A udev rule to serve the change event of ACPI container?

On Wed, Aug 02, 2017 at 11:01:43AM +0200, Michal Hocko wrote: > On Mon 31-07-17 15:38:45, Joey Lee wrote: > > Hi Michal, > > > > Sorry for my delay... > > > > On Tue, Jul 25, 2017 at 02:48:37PM +0200, Michal Hocko wrote: > > > On Mon 24-07-17 17:29:21, Joey Lee wrote: > [...] > > > > For the

Re: A udev rule to serve the change event of ACPI container?

Hi YASUAKI, On Tue, Aug 01, 2017 at 03:21:38PM -0400, YASUAKI ISHIMATSU wrote: > Hi Joey, > > On 07/23/2017 05:18 AM, joeyli wrote: [...snip] > >>> > >> > >> At least Yasuaki raised similar behavior for container in 2013. > >> It's similar to t

Re: A udev rule to serve the change event of ACPI container?

Hi YASUAKI, On Tue, Aug 01, 2017 at 03:21:38PM -0400, YASUAKI ISHIMATSU wrote: > Hi Joey, > > On 07/23/2017 05:18 AM, joeyli wrote: [...snip] > >>> > >> > >> At least Yasuaki raised similar behavior for container in 2013. > >> It's similar to t

Re: A udev rule to serve the change event of ACPI container?

Hi Michal, Sorry for my delay... On Tue, Jul 25, 2017 at 02:48:37PM +0200, Michal Hocko wrote: > On Mon 24-07-17 17:29:21, Joey Lee wrote: > > On Mon, Jul 24, 2017 at 10:57:02AM +0200, Michal Hocko wrote: > > > On Wed 19-07-17 17:09:10, Joey Lee wrote: > > > > On Mon, Jul 17, 2017 at 11:05:25AM

Re: A udev rule to serve the change event of ACPI container?

Hi Michal, Sorry for my delay... On Tue, Jul 25, 2017 at 02:48:37PM +0200, Michal Hocko wrote: > On Mon 24-07-17 17:29:21, Joey Lee wrote: > > On Mon, Jul 24, 2017 at 10:57:02AM +0200, Michal Hocko wrote: > > > On Wed 19-07-17 17:09:10, Joey Lee wrote: > > > > On Mon, Jul 17, 2017 at 11:05:25AM

Re: A udev rule to serve the change event of ACPI container?

On Mon, Jul 24, 2017 at 10:57:02AM +0200, Michal Hocko wrote: > On Wed 19-07-17 17:09:10, Joey Lee wrote: > > On Mon, Jul 17, 2017 at 11:05:25AM +0200, Michal Hocko wrote: > [...] > > > The problem I have with this expectation is that userspace will never > > > have a good atomic view of the whole

Re: A udev rule to serve the change event of ACPI container?

On Mon, Jul 24, 2017 at 10:57:02AM +0200, Michal Hocko wrote: > On Wed 19-07-17 17:09:10, Joey Lee wrote: > > On Mon, Jul 17, 2017 at 11:05:25AM +0200, Michal Hocko wrote: > [...] > > > The problem I have with this expectation is that userspace will never > > > have a good atomic view of the whole

Re: A udev rule to serve the change event of ACPI container?

Hi Yasuaki, On Fri, Jul 14, 2017 at 10:44:14PM +0800, joeyli wrote: > On Fri, Jul 14, 2017 at 10:37:13AM +0200, Michal Hocko wrote: > > On Thu 13-07-17 20:45:21, Joey Lee wrote: > > > On Thu, Jul 13, 2017 at 09:06:19AM +0200, Michal Hocko wrote: > > > > On Thu 13-

Re: A udev rule to serve the change event of ACPI container?

Hi Yasuaki, On Fri, Jul 14, 2017 at 10:44:14PM +0800, joeyli wrote: > On Fri, Jul 14, 2017 at 10:37:13AM +0200, Michal Hocko wrote: > > On Thu 13-07-17 20:45:21, Joey Lee wrote: > > > On Thu, Jul 13, 2017 at 09:06:19AM +0200, Michal Hocko wrote: > > > > On Thu 13-

Re: A udev rule to serve the change event of ACPI container?

On Mon, Jul 17, 2017 at 11:05:25AM +0200, Michal Hocko wrote: > On Fri 14-07-17 22:44:14, Joey Lee wrote: > > On Fri, Jul 14, 2017 at 10:37:13AM +0200, Michal Hocko wrote: > > > On Thu 13-07-17 20:45:21, Joey Lee wrote: > > > > On Thu, Jul 13, 2017 at 09:06:19AM +0200, Michal Hocko wrote: > > > >

Re: A udev rule to serve the change event of ACPI container?

On Mon, Jul 17, 2017 at 11:05:25AM +0200, Michal Hocko wrote: > On Fri 14-07-17 22:44:14, Joey Lee wrote: > > On Fri, Jul 14, 2017 at 10:37:13AM +0200, Michal Hocko wrote: > > > On Thu 13-07-17 20:45:21, Joey Lee wrote: > > > > On Thu, Jul 13, 2017 at 09:06:19AM +0200, Michal Hocko wrote: > > > >

Re: A udev rule to serve the change event of ACPI container?

On Fri, Jul 14, 2017 at 10:37:13AM +0200, Michal Hocko wrote: > On Thu 13-07-17 20:45:21, Joey Lee wrote: > > On Thu, Jul 13, 2017 at 09:06:19AM +0200, Michal Hocko wrote: > > > On Thu 13-07-17 14:58:06, Joey Lee wrote: > [...] > > > > If BIOS emits ejection event for a ACPI0004 container, someone

Re: A udev rule to serve the change event of ACPI container?

On Fri, Jul 14, 2017 at 10:37:13AM +0200, Michal Hocko wrote: > On Thu 13-07-17 20:45:21, Joey Lee wrote: > > On Thu, Jul 13, 2017 at 09:06:19AM +0200, Michal Hocko wrote: > > > On Thu 13-07-17 14:58:06, Joey Lee wrote: > [...] > > > > If BIOS emits ejection event for a ACPI0004 container, someone

Re: A udev rule to serve the change event of ACPI container?

On Thu, Jul 13, 2017 at 09:06:19AM +0200, Michal Hocko wrote: > On Thu 13-07-17 14:58:06, Joey Lee wrote: > > Hi Michal, > > > > Sorry for my delay. > > > > On Tue, Jul 11, 2017 at 10:25:32AM +0200, Michal Hocko wrote: > > > On Mon 26-06-17 10:59:07, Michal Hocko wrote: > > > > On Mon 26-06-17

Re: A udev rule to serve the change event of ACPI container?

On Thu, Jul 13, 2017 at 09:06:19AM +0200, Michal Hocko wrote: > On Thu 13-07-17 14:58:06, Joey Lee wrote: > > Hi Michal, > > > > Sorry for my delay. > > > > On Tue, Jul 11, 2017 at 10:25:32AM +0200, Michal Hocko wrote: > > > On Mon 26-06-17 10:59:07, Michal Hocko wrote: > > > > On Mon 26-06-17

Re: A udev rule to serve the change event of ACPI container?

Hi Michal, Sorry for my delay. On Tue, Jul 11, 2017 at 10:25:32AM +0200, Michal Hocko wrote: > On Mon 26-06-17 10:59:07, Michal Hocko wrote: > > On Mon 26-06-17 14:26:57, Joey Lee wrote: > > > Hi all, > > > > > > If ACPI received ejection request for a ACPI container, kernel > > > emits

Re: A udev rule to serve the change event of ACPI container?

Hi Michal, Sorry for my delay. On Tue, Jul 11, 2017 at 10:25:32AM +0200, Michal Hocko wrote: > On Mon 26-06-17 10:59:07, Michal Hocko wrote: > > On Mon 26-06-17 14:26:57, Joey Lee wrote: > > > Hi all, > > > > > > If ACPI received ejection request for a ACPI container, kernel > > > emits

Re: [RFC PATCH v3] acpi: indicate to platform when hot remove returns busy

On Fri, Jun 30, 2017 at 01:49:07PM +0800, joeyli wrote: > Hi Rafael, > > On Thu, Jun 29, 2017 at 12:13:18AM +0200, Rafael J. Wysocki wrote: > > On Wednesday, June 21, 2017 03:45:44 PM Lee, Chun-Yi wrote: > > > In hotplug logic, it always indicates non-specific failure t

Re: [RFC PATCH v3] acpi: indicate to platform when hot remove returns busy

On Fri, Jun 30, 2017 at 01:49:07PM +0800, joeyli wrote: > Hi Rafael, > > On Thu, Jun 29, 2017 at 12:13:18AM +0200, Rafael J. Wysocki wrote: > > On Wednesday, June 21, 2017 03:45:44 PM Lee, Chun-Yi wrote: > > > In hotplug logic, it always indicates non-specific failure t

Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

Hi Ard, On Thu, Jun 01, 2017 at 08:46:26AM +, Ard Biesheuvel wrote: > On 1 June 2017 at 08:11, Gary Lin wrote: > > On Fri, May 12, 2017 at 04:05:34PM +0800, Gary Lin wrote: > >> A new section, secdata, in the setup header is introduced to store the > >> distro-specific

Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

Hi Ard, On Thu, Jun 01, 2017 at 08:46:26AM +, Ard Biesheuvel wrote: > On 1 June 2017 at 08:11, Gary Lin wrote: > > On Fri, May 12, 2017 at 04:05:34PM +0800, Gary Lin wrote: > >> A new section, secdata, in the setup header is introduced to store the > >> distro-specific security version which

Re: [RFC PATCH v3] acpi: indicate to platform when hot remove returns busy

Hi Rafael, On Thu, Jun 29, 2017 at 12:13:18AM +0200, Rafael J. Wysocki wrote: > On Wednesday, June 21, 2017 03:45:44 PM Lee, Chun-Yi wrote: > > In hotplug logic, it always indicates non-specific failure to > > platform through _OST when handing acpi hot-remove event failed. Then > > platform

Re: [RFC PATCH v3] acpi: indicate to platform when hot remove returns busy

Hi Rafael, On Thu, Jun 29, 2017 at 12:13:18AM +0200, Rafael J. Wysocki wrote: > On Wednesday, June 21, 2017 03:45:44 PM Lee, Chun-Yi wrote: > > In hotplug logic, it always indicates non-specific failure to > > platform through _OST when handing acpi hot-remove event failed. Then > > platform

Re: [PATCH v2] acpi: handle the acpi hotplug schedule error

Hi Rafael, Thanks for your review. On Thu, Jun 29, 2017 at 12:06:20AM +0200, Rafael J. Wysocki wrote: > On Wednesday, June 21, 2017 03:04:34 PM Lee, Chun-Yi wrote: > > Kernel should decrements the reference count of acpi device > > when the scheduling of acpi hotplug work is failed, and > >

Re: [PATCH v2] acpi: handle the acpi hotplug schedule error

Hi Rafael, Thanks for your review. On Thu, Jun 29, 2017 at 12:06:20AM +0200, Rafael J. Wysocki wrote: > On Wednesday, June 21, 2017 03:04:34 PM Lee, Chun-Yi wrote: > > Kernel should decrements the reference count of acpi device > > when the scheduling of acpi hotplug work is failed, and > >

Re: A udev rule to serve the change event of ACPI container?

Hi YASUAKI, Thanks for your response. On Wed, Jun 28, 2017 at 03:53:16PM -0400, YASUAKI ISHIMATSU wrote: > > On 06/26/2017 02:26 AM, joeyli wrote: > > Hi all, > > > > If ACPI received ejection request for a ACPI container, kernel > > emits KOBJ_CHANGE uevent

Re: A udev rule to serve the change event of ACPI container?

Hi YASUAKI, Thanks for your response. On Wed, Jun 28, 2017 at 03:53:16PM -0400, YASUAKI ISHIMATSU wrote: > > On 06/26/2017 02:26 AM, joeyli wrote: > > Hi all, > > > > If ACPI received ejection request for a ACPI container, kernel > > emits KOBJ_CHANGE uevent

A udev rule to serve the change event of ACPI container?

Hi all, If ACPI received ejection request for a ACPI container, kernel emits KOBJ_CHANGE uevent when it found online children devices below the acpi container. Base on the description of caa73ea15 kernel patch, user space is expected to offline all devices below the container and the container

A udev rule to serve the change event of ACPI container?

Hi all, If ACPI received ejection request for a ACPI container, kernel emits KOBJ_CHANGE uevent when it found online children devices below the acpi container. Base on the description of caa73ea15 kernel patch, user space is expected to offline all devices below the container and the container

Re: [PATCH] acer-wmi: Using zero as the first WMI instance number

On Tue, Jun 20, 2017 at 02:45:56PM -0700, Darren Hart wrote: > On Tue, Jun 20, 2017 at 10:46:12PM +0200, Pali Rohár wrote: > > On Tuesday 20 June 2017 19:22:46 Andy Shevchenko wrote: > > > On Tue, Jun 20, 2017 at 7:48 PM, Pali Rohár > > > wrote: > > > > On Tuesday 20 June

Re: [PATCH] acer-wmi: Using zero as the first WMI instance number

On Tue, Jun 20, 2017 at 02:45:56PM -0700, Darren Hart wrote: > On Tue, Jun 20, 2017 at 10:46:12PM +0200, Pali Rohár wrote: > > On Tuesday 20 June 2017 19:22:46 Andy Shevchenko wrote: > > > On Tue, Jun 20, 2017 at 7:48 PM, Pali Rohár > > > wrote: > > > > On Tuesday 20 June 2017 17:06:23 Lee,

Re: [PATCH] RFC: platform/x86: wmi: Fix check for method instance number

Hi Pali, On Sat, Jun 17, 2017 at 06:47:54PM +0200, Pali Rohár wrote: > > So problematic drivers which use instance=1 without any comments are: > > > > acer-wmi > > asus-wmi > > mxm-wmi > > Adding authors & maintainers of those drivers in loop. > > WMI instance number is indexed from zero

Re: [PATCH] RFC: platform/x86: wmi: Fix check for method instance number

Hi Pali, On Sat, Jun 17, 2017 at 06:47:54PM +0200, Pali Rohár wrote: > > So problematic drivers which use instance=1 without any comments are: > > > > acer-wmi > > asus-wmi > > mxm-wmi > > Adding authors & maintainers of those drivers in loop. > > WMI instance number is indexed from zero

Re: [PATCH v2] acpi: indicate to platform when hot remove returns busy

On Fri, Jun 09, 2017 at 06:36:32PM +0300, Andy Shevchenko wrote: > On Fri, Jun 9, 2017 at 1:54 PM, Lee, Chun-Yi wrote: > > In hotplug logic, it always indicates non-specific failure to > > platform through _OST when handing acpi hot-remove event failed. Then > > platform

Re: [PATCH v2] acpi: indicate to platform when hot remove returns busy

On Fri, Jun 09, 2017 at 06:36:32PM +0300, Andy Shevchenko wrote: > On Fri, Jun 9, 2017 at 1:54 PM, Lee, Chun-Yi wrote: > > In hotplug logic, it always indicates non-specific failure to > > platform through _OST when handing acpi hot-remove event failed. Then > > platform terminates the hot-remove

Re: [PATCH] platform/x86/acer-wmi: Detect RF Button capability

On Tue, Jun 06, 2017 at 01:07:22PM -0700, João Paulo Rechi Vita wrote: > If a machine reports a RF Button in the communication button device > bitmap, we need to remove it before calling Get Device Status otherwise > it will return the "Undefined device" (0xE2) error code. > > Although this may

Re: [PATCH] platform/x86/acer-wmi: Detect RF Button capability

On Tue, Jun 06, 2017 at 01:07:22PM -0700, João Paulo Rechi Vita wrote: > If a machine reports a RF Button in the communication button device > bitmap, we need to remove it before calling Get Device Status otherwise > it will return the "Undefined device" (0xE2) error code. > > Although this may

Re: [PATCH] acpi: handle the acpi hotplug schedule error

On Wed, Jun 07, 2017 at 01:46:37PM +0300, Andy Shevchenko wrote: > On Wed, Jun 7, 2017 at 1:18 PM, joeyli <j...@suse.com> wrote: > > On Wed, Jun 07, 2017 at 11:36:55AM +0300, Andy Shevchenko wrote: > >> On Wed, Jun 7, 2017 at 9:05 AM, Lee, Chun-Yi <joeyli.ke

Re: [PATCH] acpi: handle the acpi hotplug schedule error

On Wed, Jun 07, 2017 at 01:46:37PM +0300, Andy Shevchenko wrote: > On Wed, Jun 7, 2017 at 1:18 PM, joeyli wrote: > > On Wed, Jun 07, 2017 at 11:36:55AM +0300, Andy Shevchenko wrote: > >> On Wed, Jun 7, 2017 at 9:05 AM, Lee, Chun-Yi > >> wrote: > >> > Kerne

Re: [RFC PATCH] acpi: indicate to platform when hot remove returns busy

On Wed, Jun 07, 2017 at 11:50:13AM +0300, Andy Shevchenko wrote: > On Wed, Jun 7, 2017 at 9:07 AM, Lee, Chun-Yi wrote: > > In hotplug logic, it always indicates non-specific failure to > > platform through _OST when handing acpi hot-remove event failed. Then > > platform

Re: [RFC PATCH] acpi: indicate to platform when hot remove returns busy

On Wed, Jun 07, 2017 at 11:50:13AM +0300, Andy Shevchenko wrote: > On Wed, Jun 7, 2017 at 9:07 AM, Lee, Chun-Yi wrote: > > In hotplug logic, it always indicates non-specific failure to > > platform through _OST when handing acpi hot-remove event failed. Then > > platform terminates the hot-remove

Re: [PATCH] acpi: handle the acpi hotplug schedule error

Hi Andy, Thanks for your help to review my patch. On Wed, Jun 07, 2017 at 11:36:55AM +0300, Andy Shevchenko wrote: > On Wed, Jun 7, 2017 at 9:05 AM, Lee, Chun-Yi wrote: > > Kernel should decrements the reference count of acpi device > > when scheduling acpi hotplug

Re: [PATCH] acpi: handle the acpi hotplug schedule error

Hi Andy, Thanks for your help to review my patch. On Wed, Jun 07, 2017 at 11:36:55AM +0300, Andy Shevchenko wrote: > On Wed, Jun 7, 2017 at 9:05 AM, Lee, Chun-Yi wrote: > > Kernel should decrements the reference count of acpi device > > when scheduling acpi hotplug work is failed, and also

Re: [RFC PATCH] acpi: indicate to platform when hot remove returns busy

On Sun, Jun 04, 2017 at 06:04:53PM +0800, joeyli wrote: > Hi Andy, > > Thanks for your help to review my patch. > > On Sat, Jun 03, 2017 at 08:37:51PM +0300, Andy Shevchenko wrote: > > On Sat, Jun 3, 2017 at 8:20 PM, Lee, Chun-Yi <joeyli.ker...@gmail.com> > &

Re: [RFC PATCH] acpi: indicate to platform when hot remove returns busy

On Sun, Jun 04, 2017 at 06:04:53PM +0800, joeyli wrote: > Hi Andy, > > Thanks for your help to review my patch. > > On Sat, Jun 03, 2017 at 08:37:51PM +0300, Andy Shevchenko wrote: > > On Sat, Jun 3, 2017 at 8:20 PM, Lee, Chun-Yi > > wrote: > > > In ho

<    1   2   3   4   5   6   7   8   >