[Linux-ia64] Possible bug in getname32

[Linux-ia64] Possible bug in getname32

[David Engebretsen]

Although I do not work on linux-ia64, I believe we found a bug bringing up
PPC64 that also exists in the IA64 code that someone might want to look
into.

In arch/ia64/ia32/sys_ia32.c, the function getname32 allocates storage via
__get_free_page and then returns it via putname (aka kmem_cache_free).
This mismatch of storage allocation schemes can cause all kinds of subtle
problems as we found in PPC64.

Is this a legitimate bug, or are we missing something here?

Thanks -

Dave Engebretsen
Linux on PowerPC Development, IBM Rochester
Internal  : ibmusm07(engebret), T/L 8-553-2925
External : engebret@us.ibm.com, (507) 253-2925

Re: [Linux-ia64] Possible bug in getname32

[Don Dugger]

Dave-

Thanks for the report.  The simple answer is no, this is not a problem
on IA64.

The more detailed answer is we don't use that code.  If you look up
from `getname32' a little you'll discover that this code is inside
a `#ifdef NOTYET' block and is not compiled into the kernel.  When we
started the IA32 support we used, I believe, `sparc64' code as a
template but ifdef'd out most of the code.  As we discovered system
calls that needed to be translated we pulled the code out of the
ifdef area and made sure it worked properly.  (Because of the way
IA64 passes system call parameters many system calls that would need
to be translated on other architectures don't need to be modified
on IA64 and I didn't want to needlessly translate things that `just
work').  The `getname32' code hasn't been needed yet (and probably 
never will be now that you've pointed out a bug with it :-)

On Fri, Mar 16, 2001 at 10:04:23AM -0600, David Engebretsen wrote:
> Although I do not work on linux-ia64, I believe we found a bug bringing up
> PPC64 that also exists in the IA64 code that someone might want to look
> into.
> 
> In arch/ia64/ia32/sys_ia32.c, the function getname32 allocates storage via
> __get_free_page and then returns it via putname (aka kmem_cache_free).
> This mismatch of storage allocation schemes can cause all kinds of subtle
> problems as we found in PPC64.
> 
> Is this a legitimate bug, or are we missing something here?
> 
> Thanks -
> 
> Dave Engebretsen
> Linux on PowerPC Development, IBM Rochester
> Internal  : ibmusm07(engebret), T/L 8-553-2925
> External : engebret@us.ibm.com, (507) 253-2925
> 
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64

-- 
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano@valinux.com
Ph: 303/938-9838

Re: [Linux-ia64] Possible bug in getname32

[Andreas Schwab]

"David Engebretsen" <engebret@us.ibm.com> writes:

|> Although I do not work on linux-ia64, I believe we found a bug bringing up
|> PPC64 that also exists in the IA64 code that someone might want to look
|> into.
|> 
|> In arch/ia64/ia32/sys_ia32.c, the function getname32 allocates storage via
|> __get_free_page and then returns it via putname (aka kmem_cache_free).
|> This mismatch of storage allocation schemes can cause all kinds of subtle
|> problems as we found in PPC64.
|> 
|> Is this a legitimate bug, or are we missing something here?

Yes, I think that this is a bug.  Here is a patch:

--- sys_ia32.c	2001/03/16 17:08:13	1.1
+++ sys_ia32.c	2001/03/16 17:15:12
@@ -2762,11 +2762,12 @@
 do_getname32(const char *filename, char *page)
 {
 	int retval;
+	unsigned long len = PATH_MAX + 1;
 
 	/* 32bit pointer will be always far below TASK_SIZE :)) */
-	retval = strncpy_from_user((char *)page, (char *)filename, PAGE_SIZE);
+	retval = strncpy_from_user((char *)page, (char *)filename, len);
 	if (retval > 0) {
-		if (retval < PAGE_SIZE)
+		if (retval < len)
 			return 0;
 		return -ENAMETOOLONG;
 	} else if (!retval)
@@ -2780,7 +2781,7 @@
 	char *tmp, *result;
 
 	result = ERR_PTR(-ENOMEM);
-	tmp = (char *)__get_free_page(GFP_KERNEL);
+	tmp = __getname();
 	if (tmp)  {
 		int retval = do_getname32(filename, tmp);
 

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
Andreas.Schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5