linux-kernel - Re: [PATCH 0/5] Persist printk buffer across reboots.

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: <CAHqTa-2c7pOTicWO8stNJfVfep4gSPHwKdr3kv_Jk-oi=dU5bw@mail.gmail.com>
Date:	Tue, 13 Mar 2012 04:10:42 -0400
From:	Avery Pennarun <apenwarr@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	akpm@...ux-foundation.org, josh@...htriplett.org,
	paulmck@...ux.vnet.ibm.com, mingo@...e.hu, a.p.zijlstra@...llo.nl,
	fdinitto@...hat.com, hannes@...xchg.org, olaf@...fle.de,
	paul.gortmaker@...driver.com, tj@...nel.org, hpa@...ux.intel.com,
	yinghai@...nel.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [PATCH 0/5] Persist printk buffer across reboots.

On Tue, Mar 13, 2012 at 3:18 AM, David Miller <davem@...emloft.net> wrote:
> I'm only saying that you should design your stuff such that an
> architecture with such features could easily hook into it using this
> kind facility.

How about this?


diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index a6bb102..7335cf7 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -59,6 +59,8 @@ int memblock_add(phys_addr_t base, phys_addr_t size);
 int memblock_remove(phys_addr_t base, phys_addr_t size);
 int memblock_free(phys_addr_t base, phys_addr_t size);
 int memblock_reserve(phys_addr_t base, phys_addr_t size);
+phys_addr_t memblock_reserve_by_name(const char *name,
+	phys_addr_t size, phys_addr_t align);

 #ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
 void __next_mem_pfn_range(int *idx, int nid, unsigned long *out_start_pfn,
@@ -246,6 +248,11 @@ static inline phys_addr_t
memblock_alloc(phys_addr_t size, phys_addr_t align)
 	return 0;
 }

+phys_addr_t memblock_reserve_by_name(const char *name,
+	phys_addr_t size, phys_addr_t align)
+{
+	return 0;
+}
 #endif /* CONFIG_HAVE_MEMBLOCK */

 #endif /* __KERNEL__ */
diff --git a/mm/memblock.c b/mm/memblock.c
index 99f2855..2ab4559 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -519,6 +519,38 @@ int __init_memblock memblock_reserve(phys_addr_t
base, phys_addr_t size)
 	return memblock_add_region(_rgn, base, size, MAX_NUMNODES);
 }

+#define RESERVE_SEARCH_END 0xfe000000
+#define RESERVE_SEARCH_JUMP (16*1024*1024)
+
+/**
+ * Find a well-defined location for the given memory area and reserve it.
+ * The generic version just scans through memory looking for an available
+ * area, and ignores the name.  An arch-specific version could request a
+ * named area from the bootloader (eg.  prom_retain()) in the hopes of
+ * getting a region guaranteed not to be messed up by the bootloader.
+ */
+phys_addr_t __init_memblock memblock_reserve_by_name(const char *name,
+	phys_addr_t size, phys_addr_t align)
+{
+	unsigned long where;
+
+	for (where = RESERVE_SEARCH_END - align;
+			where >= RESERVE_SEARCH_JUMP;
+			where -= RESERVE_SEARCH_JUMP) {
+		where &= ~(roundup_pow_of_two(align) - 1);
+		if (memblock_find_in_range(where, where + size,
+					size, align) != 0) {
+			memblock_reserve(where, size);
+			printk(KERN_INFO "memblock(%s): "
+				"reserved %lu @ 0x%08lx\n",
+				name, (unsigned long)size,
+				(unsigned long)where);
+			return where;
+		}
+	}
+	return 0;
+}
+
 /**
  * __next_free_mem_range - next function for for_each_free_mem_range()
  * @idx: pointer to u64 loop variable
-- 
1.7.7.3
--
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/