On Sun, 2021-03-07 at 21:22 +0900, Hajime Tazaki wrote:
> Sorry that this email is going to be long. In summary, what Johannes
> said is right: what objcopy does is not sufficient, and with ld it
> transforms as we expected.
>
> More goes to below.
[snip]
Interesting, thanks for looking into th
Sorry that this email is going to be long. In summary, what Johannes
said is right: what objcopy does is not sufficient, and with ld it
transforms as we expected.
More goes to below.
On Sat, 06 Mar 2021 05:22:19 +0900,
Johannes Berg wrote:
>
> On Thu, 2021-03-04 at 14:38 +0900, Hajime Tazaki
might be late, but I'll give it a try with your dlopen reproducer.
-- Hajime
On Sat, 06 Mar 2021 05:22:19 +0900,
Johannes Berg wrote:
>
> On Thu, 2021-03-04 at 14:38 +0900, Hajime Tazaki wrote:
> >
> > objcopy (from binutils) can localize symbols (i.e., objcopy -L
> > sem_init $orig_file $new
On Thu, 2021-03-04 at 14:38 +0900, Hajime Tazaki wrote:
>
> objcopy (from binutils) can localize symbols (i.e., objcopy -L
> sem_init $orig_file $new_file).
This doesn't seem to be sufficient.
> It also does renaming symbols. But
> not sure this is the ideal solution.
Even that doesn't seem to
> Ritesh, can you give the following a spin - it renames sem_init as
> um_sem_init for UML only?
FWIW, this fixes the issue in my reproducer, so should work here too:
diff --git a/ipc/util.h b/ipc/util.h
index 5766c61aed0e..cfed40ba983c 100644
--- a/ipc/util.h
+++ b/ipc/util.h
@@ -14,6 +14,7 @
On Fri, 2021-03-05 at 19:03 +, Anton Ivanov wrote:
>
> I thought of that, but surrendered to the "dark side" of the quick and ugly
> fix.
:)
> We can do that for the ipc/sem.c - it brings in uaccess.h which
> ultimately pulls uaccess from our asm tree. So if we do it there, it
> will end up
On Wed, 2021-03-03 at 23:40 +0100, Johannes Berg wrote:
> 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.
FWIW, I can trivially reproduce this by simply force-loading
libcom_err.so:
diff --git a/
On 05/03/2021 18:32, Johannes Berg wrote:
On 5 March 2021 18:39:42 CET, Anton Ivanov
wrote:
On 04/03/2021 07:47, Johannes Berg wrote:
On Thu, 2021-03-04 at 14:38 +0900, Hajime Tazaki wrote:
Now, I don't know how to fix it (short of changing your nsswitch
configuration) - maybe we cou
On 5 March 2021 18:39:42 CET, Anton Ivanov
wrote:
>
>
>On 04/03/2021 07:47, Johannes Berg wrote:
>> On Thu, 2021-03-04 at 14:38 +0900, Hajime Tazaki wrote:
>>
Now, I don't know how to fix it (short of changing your nsswitch
configuration) - maybe we could somehow rename sem_init()?
On 04/03/2021 07:47, Johannes Berg wrote:
On Thu, 2021-03-04 at 14:38 +0900, Hajime Tazaki wrote:
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 resoluti
On Fri, 2021-03-05 at 09:59 +, Anton Ivanov wrote:
>
> This is proving very "interesting" to try to chase down, because the
> "picking the wrong library" does not happen every time.
>
> F.E. yesterday my 5.10 builds were picking glibc memcpy and friends.
> Today with the same config and every
On 04/03/2021 18:41, Anton Ivanov wrote:
On 04/03/2021 08:05, Benjamin Berg wrote:
On Thu, 2021-03-04 at 08:47 +0100, Johannes Berg wrote:
On Thu, 2021-03-04 at 14:38 +0900, Hajime Tazaki wrote:
Now, I don't know how to fix it (short of changing your nsswitch
configuration) - maybe we coul
On 04/03/2021 08:05, Benjamin Berg wrote:
On Thu, 2021-03-04 at 08:47 +0100, Johannes Berg wrote:
On Thu, 2021-03-04 at 14:38 +0900, Hajime Tazaki wrote:
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
ca
On Thu, 2021-03-04 at 08:47 +0100, Johannes Berg wrote:
On Thu, 2021-03-04 at 14:38 +0900, Hajime Tazaki wrote:
> > 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
On Thu, 2021-03-04 at 14:38 +0900, Hajime Tazaki wrote:
> > 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.
>
On 04/03/2021 05:38, Hajime Tazaki wrote:
On Thu, 04 Mar 2021 07:40:00 +0900,
Johannes Berg wrote:
I think the problem is here:
#24 0x6080f234 in ipc_init_ids (ids=0x60c60de8 )
at ipc/util.c:119
#25 0x60813c6d in sem_init_ns (ns=0x60d895bb ) at
ipc/sem.c:254
#26 0x600
On Thu, 2021-03-04 at 07:28 +, Anton Ivanov wrote:
>
> > 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.
>
On 03/03/2021 22:40, Johannes Berg wrote:
I think the problem is here:
#24 0x6080f234 in ipc_init_ids (ids=0x60c60de8 )
at ipc/util.c:119
#25 0x60813c6d in sem_init_ns (ns=0x60d895bb ) at
ipc/sem.c:254
#26 0x60015b5d in sem_init () at ipc/sem.c:268
#27 0x7f89906d92f7
On Thu, 04 Mar 2021 07:40:00 +0900,
Johannes Berg wrote:
>
> I think the problem is here:
>
> > #24 0x6080f234 in ipc_init_ids (ids=0x60c60de8 )
> > at ipc/util.c:119
> > #25 0x60813c6d in sem_init_ns (ns=0x60d895bb ) at
> > ipc/sem.c:254
> > #26 0x60015b5d in sem_init (
I think the problem is here:
> #24 0x6080f234 in ipc_init_ids (ids=0x60c60de8 )
> at ipc/util.c:119
> #25 0x60813c6d in sem_init_ns (ns=0x60d895bb ) at
> ipc/sem.c:254
> #26 0x60015b5d in sem_init () at ipc/sem.c:268
> #27 0x7f89906d92f7 in ?? () from /lib/x86_64-linux-
On 03/03/2021 10:45, Ritesh Raj Sarraf wrote:
HI Anton,
On Wed, 2021-03-03 at 09:30 +, Anton Ivanov wrote:
OTOH, I have one more user (other than you) who's not been able to
reproduce the issue.
I will do a dissect the moment I figure out how to reproduce it.
I
will try to do some more
HI Anton,
On Wed, 2021-03-03 at 09:30 +, Anton Ivanov wrote:
>
> >
> > OTOH, I have one more user (other than you) who's not been able to
> > reproduce the issue.
> >
> > > I will do a dissect the moment I figure out how to reproduce it.
> > > I
> > > will try to do some more experiments on
On 02/03/2021 17:27, Ritesh Raj Sarraf wrote:
On Tue, 2021-03-02 at 17:05 +, Anton Ivanov wrote:
So the best I can extract for you is to compile the kernel with as
much
information as possible.
Can you try using one of the older kernels so we can verify if this
is indeed a 5.10 thing.
On Tue, 2021-03-02 at 17:05 +, Anton Ivanov wrote:
> > So the best I can extract for you is to compile the kernel with as
> > much
> > information as possible.
>
> Can you try using one of the older kernels so we can verify if this
> is indeed a 5.10 thing.
>
That was the first thing I tried
On 02/03/2021 14:23, Ritesh Raj Sarraf wrote:
On Tue, 2021-03-02 at 11:34 +, Anton Ivanov wrote:
If gdb gives you the exact lines, that may be helpful.
It doesn't. But it does show drawbacks in my packaging. The debug
symbols packaged are not read/honored by gdb at all.
```
Reading sym
On Tue, 2021-03-02 at 11:34 +, Anton Ivanov wrote:
> If gdb gives you the exact lines, that may be helpful.
It doesn't. But it does show drawbacks in my packaging. The debug
symbols packaged are not read/honored by gdb at all.
```
Reading symbols from /usr/bin/linux.uml...
Reading symbols fro
On 02/03/2021 09:09, Ritesh Raj Sarraf wrote:
On Wed, 2021-02-24 at 11:44 +, Anton Ivanov wrote:
In all cases it boots cleanly and there are no segfaults.
So, frankly, no idea what is causing it to crash - I have run most
combinations of 5.10 on a 5.10, all work fine here.
Is there any
On Wed, 2021-02-24 at 11:44 +, Anton Ivanov wrote:
> In all cases it boots cleanly and there are no segfaults.
>
> So, frankly, no idea what is causing it to crash - I have run most
> combinations of 5.10 on a 5.10, all work fine here.
Is there any other way I can help you with this issue ?
I
On 23/02/2021 17:26, Ritesh Raj Sarraf wrote:
Added the debian bug report in CC.
On Tue, 2021-02-23 at 17:19 +, Anton Ivanov wrote:
The current Debian user-mode-linux package in unstable is based on
the 5.10.5 stable source which includes the mentioned patch, but is
still causing an erro
On 23/02/2021 17:26, Ritesh Raj Sarraf wrote:
Added the debian bug report in CC.
On Tue, 2021-02-23 at 17:19 +, Anton Ivanov wrote:
The current Debian user-mode-linux package in unstable is based on
the 5.10.5 stable source which includes the mentioned patch, but is
still causing an error f
Added the debian bug report in CC.
On Tue, 2021-02-23 at 17:19 +, Anton Ivanov wrote:
> > The current Debian user-mode-linux package in unstable is based on
> > the 5.10.5 stable source which includes the mentioned patch, but is
> > still causing an error for some users.
>
> After updating th
31 matches
Mail list logo
