From: Luca Barbieri <ldb@ldb.ods.org>
To: Ulrich Drepper <drepper@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>,
Linus Torvalds <torvalds@transmeta.com>,
Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [patch] threading fix, tid-2.5.47-A3
Date: 17 Nov 2002 21:49:03 +0100 [thread overview]
Message-ID: <1037566143.1597.133.camel@ldb> (raw)
In-Reply-To: <3DD7FD86.7000407@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]
> It's all encapsulated in the libpthread which is used. No apps need to
> be recompiled so it is OK to make this incompatible change.
My point was that aesthetical reasons do not justify breaking anything
(aka forcing people to figure out what happened and spend time
recompiling).
Anyway, I'll need to recompile anyway, so I don't really care.
> I cannot see any reasonable way out if any of the put_user calls fail?
> Do you want the clone() call to fail if the parent's receiving address
> is wrong? You'd have to go and kill the child again since it's already
> created.
>
> Instead let the user initialize the memory location the clone call is
> supposed to write in with zero. if the value didn't change the
> user-level code can detect the error and handle appropriately. So,
> ignore the put_user errors. Maybe say so explicitly and add (void) in
> front.
I proposed to fail in put_user for the parent tid simply because the old
code did it.
I'm not completely sure whether we should fail or not, but if put_user
fails something bad is happening, so it may be better to signal the
error rather than just continuing since it can be done easily (for the
parent tid).
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2002-11-17 20:42 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3DD7E3E7.6040403@redhat.com>
2002-11-17 18:54 ` [patch] threading fix, tid-2.5.47-A3 Linus Torvalds
2002-11-17 20:18 ` Ingo Molnar
2002-11-17 20:37 ` Ingo Molnar
2002-11-17 19:54 ` Luca Barbieri
2002-11-17 21:17 ` Ingo Molnar
2002-11-17 20:16 ` Luca Barbieri
2002-11-17 21:45 ` Ingo Molnar
2002-11-17 20:35 ` Ulrich Drepper
2002-11-17 20:44 ` Jamie Lokier
2002-11-17 20:49 ` Luca Barbieri [this message]
2002-11-17 22:08 ` Ingo Molnar
2002-11-17 23:00 ` Linus Torvalds
2002-11-17 23:23 ` Ulrich Drepper
2002-11-18 1:33 ` Linus Torvalds
2002-11-18 3:33 ` Ulrich Drepper
2002-11-18 3:43 ` Linus Torvalds
2002-11-18 3:58 ` Ulrich Drepper
2002-11-18 4:11 ` Linus Torvalds
2002-11-18 4:31 ` Ulrich Drepper
2002-11-18 6:46 ` Ulrich Drepper
2002-11-18 16:00 ` Linus Torvalds
2002-11-18 8:07 ` Luca Barbieri
2002-11-18 8:21 ` Ulrich Drepper
2002-11-18 8:27 ` Luca Barbieri
2002-11-18 9:30 ` [patch] threading enhancements, tid-2.5.47-C0 Ingo Molnar
2002-11-18 8:29 ` Luca Barbieri
2002-11-18 12:12 ` Ingo Molnar
2002-11-18 12:11 ` Luca Barbieri
2002-11-20 1:40 ` Ulrich Drepper
2002-11-20 1:59 ` Linus Torvalds
2002-11-20 3:37 ` Jamie Lokier
2002-11-20 4:04 ` Ulrich Drepper
2002-11-20 21:55 ` Jamie Lokier
2002-11-20 22:11 ` Ulrich Drepper
2002-11-20 23:26 ` Jamie Lokier
2002-11-20 23:28 ` Ulrich Drepper
2002-11-21 0:18 ` Jamie Lokier
2002-11-21 9:13 ` Ingo Molnar
2002-11-21 12:07 ` Jamie Lokier
2002-11-21 0:37 ` Jamie Lokier
2002-11-20 8:50 ` Ingo Molnar
2002-11-20 9:51 ` [patch] threading enhancements, tid-2.5.48-A1 Ingo Molnar
2002-11-20 8:41 ` Ulrich Drepper
2002-11-20 20:20 ` Luca Barbieri
2002-11-21 18:03 ` [patch] threading enhancements, tid-2.5.48-C0 Ingo Molnar
2002-11-21 19:30 ` Luca Barbieri
2002-11-18 8:30 ` [patch] threading fix, tid-2.5.47-A3 Luca Barbieri
2002-11-18 12:21 ` Ingo Molnar
2002-11-18 12:50 ` Luca Barbieri
2002-11-18 12:26 ` Ingo Molnar
2002-11-18 13:20 ` Alan Cox
2002-11-18 13:03 ` Luca Barbieri
2002-11-18 16:24 ` Linus Torvalds
2002-11-18 16:42 ` Ingo Molnar
2002-11-18 1:46 ` Jamie Lokier
2002-11-18 3:40 ` Ulrich Drepper
2002-11-18 22:22 ` Jamie Lokier
2002-11-17 23:37 ` Ulrich Drepper
2002-11-17 12:40 Ingo Molnar
2002-11-17 11:57 ` Luca Barbieri
2002-11-17 13:36 ` Ingo Molnar
2002-11-17 13:49 ` Ingo Molnar
2002-11-17 13:29 ` Luca Barbieri
2002-11-17 17:28 ` Linus Torvalds
2002-11-17 19:03 ` Ulrich Drepper
2002-11-17 19:19 ` Ingo Molnar
2002-11-17 19:31 ` Ingo Molnar
2002-11-17 18:27 ` Linus Torvalds
2002-11-17 20:13 ` Ingo Molnar
2002-11-17 20:01 ` Jamie Lokier
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=1037566143.1597.133.camel@ldb \
--to=ldb@ldb.ods.org \
--cc=drepper@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=torvalds@transmeta.com \
/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