Re: amd64 host + i386 jail + ls -l = core dumped

From: Kostik Belousov <kostikbel_at_gmail.com>
Date: Fri, 4 Dec 2009 19:35:02 +0200
On Fri, Dec 04, 2009 at 06:36:49PM +0300, Boris Samorodov wrote:
> Hello List,
> 
> I'm using an amd64 system (r200095):
> -----
> % uname -srm
> FreeBSD 9.0-CURRENT amd64
> -----
> 
> The i386 jail was build with the same sources. There is a problem
> in the jail:
> -----
> % sudo jail -c path=/export/diskless_root host.hostname=testhostname ip4.addr=127.0.0.10 command=/bin/csh
> %uname -m
> amd64
> %setenv UNAME_m i386
> %uname -m
> i386
> %cd /root
> %ls
> ls.core         test.txt
> %ls -l
> total 8191
> Bad system call (core dumped)
> % %gdb /bin/ls ls.core 
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)...
> Core was generated by `ls'.
> Program terminated with signal 12, Bad system call.
> Reading symbols from /lib/libutil.so.8...(no debugging symbols found)...done.
> Loaded symbols for /lib/libutil.so.8
> Reading symbols from /lib/libncurses.so.8...(no debugging symbols found)...done.
> Loaded symbols for /lib/libncurses.so.8
> Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
> Loaded symbols for /lib/libc.so.7
> Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done.
> Loaded symbols for /libexec/ld-elf.so.1
> #0  0x2814316f in __sys___acl_get_link () from /lib/libc.so.7
> (gdb) bt
> #0  0x2814316f in __sys___acl_get_link () from /lib/libc.so.7
> #1  0x2814303c in acl_get_link_np () from /lib/libc.so.7
> #2  0x0804c2f9 in ?? ()
> #3  0xffffcb83 in ?? ()
> #4  0x00000004 in ?? ()
> [...]

It seems that struct acl does not need translation. And another block
of acl-related syscalls do not touch it.

Please try the patch below. After application of the patch, cd to
sys/compat/freebsd32 directory and do make sysent. Then, rebuild
the kernel as usual.

diff --git a/sys/compat/freebsd32/syscalls.master b/sys/compat/freebsd32/syscalls.master
index 865f0c1..485f7a6 100644
--- a/sys/compat/freebsd32/syscalls.master
+++ b/sys/compat/freebsd32/syscalls.master
_at__at_ -740,10 +740,14 _at__at_
 				    struct freebsd32_ucontext *oucp, \
 				    const struct freebsd32_ucontext *ucp); }
 424	AUE_SWAPOFF	UNIMPL	swapoff
-425	AUE_NULL	UNIMPL	__acl_get_link
-426	AUE_NULL	UNIMPL	__acl_set_link
-427	AUE_NULL	UNIMPL	__acl_delete_link
-428	AUE_NULL	UNIMPL	__acl_aclcheck_link
+425	AUE_NULL	NOPROTO	{ int __acl_get_link(const char *path, \
+				    acl_type_t type, struct acl *aclp); }
+426	AUE_NULL	NOPROTO	{ int __acl_set_link(const char *path, \
+				    acl_type_t type, struct acl *aclp); }
+427	AUE_NULL	NOPROTO	{ int __acl_delete_link(const char *path, \
+				    acl_type_t type); }
+428	AUE_NULL	NOPROTO	{ int __acl_aclcheck_link(const char *path, \
+				    acl_type_t type, struct acl *aclp); }
 429	AUE_SIGWAIT	NOPROTO	{ int sigwait(const sigset_t *set, \
 				    int *sig); }
 430	AUE_NULL	UNIMPL	thr_create;

Received on Fri Dec 04 2009 - 16:35:07 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:58 UTC