linux-kernel - Re: [RESEND] [PATCH] ACPI - change GFP_ATOMIC to GFP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20060807135836.d766c50e.akpm@osdl.org>
Date:	Mon, 7 Aug 2006 13:58:36 -0700
From:	Andrew Morton <akpm@...l.org>
To:	Jiri Kosina <jikos@...os.cz>
Cc:	Len Brown <len.brown@...el.com>, linux-acpi@...el.com,
	linux-kernel@...r.kernel.org
Subject: Re: [RESEND] [PATCH] ACPI - change GFP_ATOMIC to GFP_KERNEL for
 non-atomic allocation

On Mon, 7 Aug 2006 16:30:43 +0200 (CEST)
Jiri Kosina <jikos@...os.cz> wrote:

> acpi_pci_link_set() allocates with GFP_ATOMIC. On resume from suspend,
> this is called with interrupts off, otherwise GFP_KERNEL is safe.
> 
> On the other hand, when resuming from suspend with interrupts off, the 
> following callchain allocates with GFP_KERNEL, which is wrong:
> 
> acpi_pci_link_resume -> acpi_pci_link_set -> acpi_set_current_resources ->
> acpi_rs_set_srs_method_data -> acpi_ut_create_internal_object_dbg ->
> acpi_ut_allocate_object_desc_dbg -> acpi_os_acquire_object ->
> kmem_cache_alloc(GFP_KERNEL) flag.
> 
> Resending patch, which didn't make it into -rc4, to fix both issues. The
> patch is intentionally using irqs_disabled() and does not check in_resume
> flag, as this is marked for removal (which is for example how
> acpi_os_allocate() checks whether it should perform GFP_KERNEL or
> GFP_ATOMIC allocation).

acpi_os_acquire_object() is fixed in -rc4.  I queued the
acpi_pci_link_set() improvement for sending on to Len, thanks.  
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/