linux-um archives
 help / color / mirror / Atom feed
From: Hajime Tazaki<thehajime@gmail.com>
To: johannes@sipsolutions.net
Cc: rrs@debian.org, anton.ivanov@kot-begemot.co.uk,
	chris.obbard@collabora.com, linux-um@lists.infradead.org,
	983379@bugs.debian.org
Subject: Re: linux uml segfault
Date: Thu, 04 Mar 2021 14:38:10 +0900	[thread overview]
Message-ID: <m21rcv5vi5.wl-thehajime@gmail.com> (raw)
In-Reply-To: <01a1b3551284a39a3c06ab2ec0222cbf6099a537.camel@sipsolutions.net>


On Thu, 04 Mar 2021 07:40:00 +0900,
Johannes Berg wrote:
> 
> I think the problem is here:
> 
> > #24 0x000000006080f234 in ipc_init_ids (ids=0x60c60de8 <init_ipc_ns+8>)
> > at ipc/util.c:119
> > #25 0x0000000060813c6d in sem_init_ns (ns=0x60d895bb <textbuf+91>) at
> > ipc/sem.c:254
> > #26 0x0000000060015b5d in sem_init () at ipc/sem.c:268
> > #27 0x00007f89906d92f7 in ?? () from /lib/x86_64-linux-
> > gnu/libcom_err.so.2
> 
> You're in the init of libcom_err.so.2, which is loaded by
> 
> > "libnss_nis.so.2"
> 
> which is loaded by normal NSS code (getgrnam):
> 
> > #40 0x00007f89909bf3a6 in nss_load_library (ni=ni@entry=0x61497db0) at
> > nsswitch.c:359
> > #41 0x00007f89909bfc39 in __GI___nss_lookup_function (ni=0x61497db0,
> > fct_name=<optimized out>, fct_name@entry=0x7f899089b020 "setgrent") at
> > nsswitch.c:467
> > #42 0x00007f899089554b in init_nss_interface () at nss_compat/compat-
> > grp.c:83
> > #43 init_nss_interface () at nss_compat/compat-grp.c:79
> > #44 0x00007f8990895e35 in _nss_compat_getgrnam_r (name=0x7f8990a2a1e0
> > "tty", grp=0x7ffe3e7a2910, buffer=0x7ffe3e7a24e0 "", buflen=1024,
> > errnop=0x7f899089eb00) at nss_compat/compat-grp.c:486
> > #45 0x00007f8990968b85 in __getgrnam_r (name=name@entry=0x7f8990a2a1e0
> > "tty", resbuf=resbuf@entry=0x7ffe3e7a2910,
> > buffer=buffer@entry=0x7ffe3e7a24e0 "", buflen=1024,
> > result=result@entry=0x7ffe3e7a2908)
> >     at ../nss/getXXbyYY_r.c:315
> 
> 
> You have a strange nsswitch configuration that causes all of this
> (libnss_nis.so.2 -> libcom_err.so.2) to get loaded.
> 
> Now libcom_err.so.2 is trying to call sem_init(), and that gets ... tada
> ... Linux's sem_init() instead of libpthread's.
> 
> And then the crash.
> 
> Now, I don't know how to fix it (short of changing your nsswitch
> configuration) - maybe we could somehow rename sem_init()? Or maybe we
> can somehow give the kernel binary a lower symbol resolution than the
> libc/libpthread.

objcopy (from binutils) can localize symbols (i.e., objcopy -L
sem_init $orig_file $new_file).  It also does renaming symbols.  But
not sure this is the ideal solution.

How does UML handle symbol conflicts between userspace code and Linux
kernel (like this case sem_init) ?  AFAIK, libnl has a same symbol as
Linux kernel (genlmsg_put) and others can possibly do as well.


-- Hajime

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um


  reply	other threads:[~2021-03-04  5:39 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-23  8:06 linux uml segfault Ritesh Raj Sarraf
2021-02-23 10:50 ` Anton Ivanov
2021-02-23 12:12   ` Christopher Obbard
2021-02-23 12:24     ` Anton Ivanov
2021-02-23 17:19     ` Anton Ivanov
2021-02-23 17:26       ` Ritesh Raj Sarraf
2021-02-23 18:02         ` Anton Ivanov
2021-02-24 11:44         ` Anton Ivanov
2021-03-02  9:09           ` Ritesh Raj Sarraf
2021-03-02 11:34             ` Anton Ivanov
2021-03-02 14:23               ` Ritesh Raj Sarraf
2021-03-02 17:05                 ` Anton Ivanov
2021-03-02 17:27                   ` Ritesh Raj Sarraf
2021-03-03  9:30                     ` Anton Ivanov
2021-03-03 10:45                       ` Bug#983379: " Ritesh Raj Sarraf
2021-03-03 10:53                         ` Anton Ivanov
2021-03-03 22:40                     ` Johannes Berg
2021-03-04  5:38                       ` Hajime Tazaki [this message]
2021-03-04  7:45                         ` Anton Ivanov
2021-03-04  7:47                         ` Johannes Berg
2021-03-04  8:05                           ` Benjamin Berg
2021-03-04 18:41                             ` Anton Ivanov
2021-03-05  9:59                               ` Anton Ivanov
2021-03-05 10:07                                 ` Johannes Berg
2021-03-05 17:39                           ` Anton Ivanov
2021-03-05 18:32                             ` Johannes Berg
2021-03-05 19:03                               ` Anton Ivanov
2021-03-05 20:06                                 ` Johannes Berg
2021-03-05 20:07                             ` Johannes Berg
2021-03-05 20:22                         ` Johannes Berg
2021-03-05 22:25                           ` Hajime Tazaki
2021-03-07 12:22                           ` Hajime Tazaki
2021-03-07 12:56                             ` Johannes Berg
2021-03-04  7:28                       ` Anton Ivanov
2021-03-04  7:43                         ` Johannes Berg
2021-03-05 19:54                       ` Johannes Berg
2021-03-05 20:43 ` [PATCH] um: mark all kernel symbols as local Johannes Berg
2021-03-05 20:54   ` Anton Ivanov
2021-03-06 10:51     ` Ritesh Raj Sarraf
2021-03-08 10:29       ` Bug#983379: " Ritesh Raj Sarraf
2021-03-08 10:33         ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m21rcv5vi5.wl-thehajime@gmail.com \
    --to=thehajime@gmail.com \
    --cc=983379@bugs.debian.org \
    --cc=anton.ivanov@kot-begemot.co.uk \
    --cc=chris.obbard@collabora.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-um@lists.infradead.org \
    --cc=rrs@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox