linux-kernel - question regarding the -stable patch queue ?

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 20 Apr 2009 18:26:53 -0700
From:	Abhijit Karmarkar <awk@...gle.com>
To:	stable@...nel.org, linux-kernel@...r.kernel.org
Subject: question regarding the -stable patch queue ?

hi,

i am trying to find if a particular upstream commit [1] will appear in
the next -stable release of 2.6.28 kernel.

i see this commit being marked as "-stable candidate". does that mean
it will automatically make it to the next stable release? or should i
submit a patch against the latest 2.6.28 stable series, to have this
patch queued up for next stable release (2.6.28.10). can someone
please advice?

what is the recommend way to do this search ("will upstream patch X be
included in the next stable release")? so i don't bug this list in
future with similar queries.

finally, talking of this particular commit, we have quite a few
machines with such BIOSes and it will be really nice to have this
included in the next stable (2.6.28.10) release. Without this patch,
machines panic in early boot.

thanks!
abhijit

[1] the commit i am specifically interested in is:
===
[upstream commit: 01522df346f846906eaf6ca57148641476209909]

x86, setup: mark %esi as clobbered in E820 BIOS call

Jordan Hargrave diagnosed a BIOS clobbering %esi in the E820 call.
That particular BIOS has been fixed, but there is a possibility that
this is responsible for other occasional reports of early boot
failure, and it does not hurt to add %esi to the clobbers.

-stable candidate patch.

Cc: Justin Forbes <jmforbes@...uxtx.org>
Signed-off-by: Michael K Johnson <johnsonm@...th.com>
Signed-off-by: H. Peter Anvin <hpa@...or.com>
Cc: stable@...nel.org
---

diff --git a/arch/x86/boot/memory.c b/arch/x86/boot/memory.c
index 8c3c25f..a99dbbe 100644
--- a/arch/x86/boot/memory.c
+++ b/arch/x86/boot/memory.c
@@ -27,13 +27,14 @@ static int detect_memory_e820(void)
 	do {
 		size = sizeof(struct e820entry);

-		/* Important: %edx is clobbered by some BIOSes,
-		   so it must be either used for the error output
+		/* Important: %edx and %esi are clobbered by some BIOSes,
+		   so they must be either used for the error output
 		   or explicitly marked clobbered. */
 		asm("int $0x15; setc %0"
 		    : "=d" (err), "+b" (next), "=a" (id), "+c" (size),
 		      "=m" (*desc)
-		    : "D" (desc), "d" (SMAP), "a" (0xe820));
+		    : "D" (desc), "d" (SMAP), "a" (0xe820)
+		    : "esi");

 		/* BIOSes which terminate the chain with CF = 1 as opposed
 		   to %ebx = 0 don't always report the SMAP signature on
--
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/