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: <20090622085405.GA6499@cr0.nay.redhat.com>
Date:	Mon, 22 Jun 2009 16:54:05 +0800
From:	Amerigo Wang <xiyou.wangcong@...il.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Amerigo Wang <xiyou.wangcong@...il.com>,
	Tao Ma <tao.ma@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Alexey Dobriyan <adobriyan@...il.com>, mtk.manpages@...il.com
Subject: [Patch] kcore: remove its pointless size

On Wed, Jun 17, 2009 at 10:41:32PM -0700, Eric W. Biederman wrote:
>Amerigo Wang <xiyou.wangcong@...il.com> writes:
>>
>> Of course I knew this.
>>
>> Just read the code:
>>
>>      phdr->p_offset = kc_vaddr_to_offset(m->addr) + dataoff;
>>
>> So it should be 0, 'dataoff' is there...
>
>Sorry.  The naming then is horrible.  It is really
>kc_vaddr_to_something_like_the_offset.
>
>I still don't see the need for a flat offset space.
>
>I can see a real point of only having a single kc_vaddr_to_offset
>function.  Instead of the 3 in existence.
>
>No point in cluttering the whole world with the oddities of the kcore
>code.  Especially when it should get cleaned up.
>
>My real point earlier is that kc_vaddr_to_offset and
>kc_offset_to_vaddr actually on x86_64 aren't broken.  They are just
>peculiar.  There is some small point to their oddities, in that if
>something is in the upper half of the address space (like xen) but
>below PAGE_OFFSET you have a chance of accessing it with /proc/kcore.
>But that is a very minor benefit.

It looks like that Linus fixes this in commit 9063c61fd5cbd.

So I will only fix the rest.

Signed-off-by: WANG Cong <amwang@...hat.com>
Cc: mtk.manpages@...il.com

---
diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index 59b43a0..eca5201 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -405,9 +405,6 @@ read_kcore(struct file *file, char __user *buffer, size_t buflen, loff_t *fpos)
 static int __init proc_kcore_init(void)
 {
 	proc_root_kcore = proc_create("kcore", S_IRUSR, NULL, &proc_kcore_operations);
-	if (proc_root_kcore)
-		proc_root_kcore->size =
-				(size_t)high_memory - PAGE_OFFSET + PAGE_SIZE;
 	return 0;
 }
 module_init(proc_kcore_init);

---
diff --git a/man5/proc.5 b/man5/proc.5
index ed47f70..e31aae4 100644
--- a/man5/proc.5
+++ b/man5/proc.5
@@ -1246,8 +1246,6 @@ kernel
 binary, GDB can be used to
 examine the current state of any kernel data structures.
 
-The total length of the file is the size of physical memory (RAM) plus
-4KB.
 .TP
 .I /proc/kmsg
 This file can be used instead of the
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ