e is given. So, either the
code was inconsistent already are these tests are really not needed.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGkSHa2ijCOnn/RHQRAp0RAJ9ouvOd52feTPuFurxj8LzHZuGZsACgwxA8
ybEo1xm
test can be skipped since the VFS
isn't involved. We got the inode etc from a file descriptor.
Signed-Off-By: Ulrich Drepper <[EMAIL PROTECTED]>
diff --git a/fs/utimes.c b/fs/utimes.c
index 480f7c8..873edcb 100644
- --- a/fs/utimes.c
+++ b/fs/utimes.c
@@ -106,7 +106,8 @@ long do_utimes(int d
be skipped since the VFS
isn't involved. We got the inode etc from a file descriptor.
Signed-Off-By: Ulrich Drepper [EMAIL PROTECTED]
diff --git a/fs/utimes.c b/fs/utimes.c
index 480f7c8..873edcb 100644
- --- a/fs/utimes.c
+++ b/fs/utimes.c
@@ -106,7 +106,8 @@ long do_utimes(int dfd, char __user
already are these tests are really not needed.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGkSHa2ijCOnn/RHQRAp0RAJ9ouvOd52feTPuFurxj8LzHZuGZsACgwxA8
ybEo1xmvakkKVenWc07PYhs=
=5DBy
-END PGP
)) {
if (current-fsuid != inode-i_uid !capable(CAP_FOWNER))
goto error;
}
in inode_change_ok. This seems to me exactly like the check needed.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7
On 7/2/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
Never be usable? I made you a concrete example that is like 8 months old.
And *that* could not have been cleanly handled with the flat structure
idea.
First of all, sigmasks are not widely needed. Second, why on earth
shouldn't it be
On 7/2/07, Rik van Riel <[EMAIL PROTECTED]> wrote:
That should not happen. The default SELinux configuration
in Fedora (and Debian?) runs a few daemons in their own
restricted modes and has most of the system running in
unconfined_t, including the majority of user programs.
This is the state
On 7/1/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
With the current API design you'd able to easily confine the "pre" code
inside the "set" function, and the "post" code inside the "unset"
function. It looks pretty clean to me, and allows to limit the knowledge
of sys_indirect, the more as
On 7/1/07, Davide Libenzi [EMAIL PROTECTED] wrote:
With the current API design you'd able to easily confine the pre code
inside the set function, and the post code inside the unset
function. It looks pretty clean to me, and allows to limit the knowledge
of sys_indirect, the more as possible
On 7/2/07, Rik van Riel [EMAIL PROTECTED] wrote:
That should not happen. The default SELinux configuration
in Fedora (and Debian?) runs a few daemons in their own
restricted modes and has most of the system running in
unconfined_t, including the majority of user programs.
This is the state as
On 7/2/07, Davide Libenzi [EMAIL PROTECTED] wrote:
Never be usable? I made you a concrete example that is like 8 months old.
And *that* could not have been cleanly handled with the flat structure
idea.
First of all, sigmasks are not widely needed. Second, why on earth
shouldn't it be possible
On 6/30/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
This is how all those overloaded syscalls looks like, BTW:
[...]
How would you do that with a single shared strcture, w/out adding in all
signal paths the knowledge of the structure?
You said it yourself: each individual wrapper would look
On 6/30/07, Davide Libenzi [EMAIL PROTECTED] wrote:
This is how all those overloaded syscalls looks like, BTW:
[...]
How would you do that with a single shared strcture, w/out adding in all
signal paths the knowledge of the structure?
You said it yourself: each individual wrapper would look
On 6/30/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
But, a __get_user(), once you scrap off all the gcc wrapping, is bacially
a move. That could even be removed, but really I don't see the reason
since it allows for a cleaner strcture definition in userland.
Don't generalize. The 4G/4G
On 6/30/07, Davide Libenzi [EMAIL PROTECTED] wrote:
But, a __get_user(), once you scrap off all the gcc wrapping, is bacially
a move. That could even be removed, but really I don't see the reason
since it allows for a cleaner strcture definition in userland.
Don't generalize. The 4G/4G
On 6/29/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
+int indirect_set_context(struct fsa_context *ator,
+const struct indirect_ctx __user * __user *ctxs,
+unsigned int nctxs, struct indirect_op **first)
+{
+ unsigned int i;
+ int
On 6/29/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
[include/linux/indirect.h]
#define SYSIND_CTX_OPENFLAGS0
struct sysind_ctx_OPENFLAGS {
__u32 ctx;
__u32 flags;
I agree that this interface is more than any other in danger of
needing an
On 6/29/07, Davide Libenzi [EMAIL PROTECTED] wrote:
[include/linux/indirect.h]
#define SYSIND_CTX_OPENFLAGS0
struct sysind_ctx_OPENFLAGS {
__u32 ctx;
__u32 flags;
I agree that this interface is more than any other in danger of
needing an
On 6/29/07, Davide Libenzi [EMAIL PROTECTED] wrote:
+int indirect_set_context(struct fsa_context *ator,
+const struct indirect_ctx __user * __user *ctxs,
+unsigned int nctxs, struct indirect_op **first)
+{
+ unsigned int i;
+ int error;
On 6/28/07, Rik van Riel <[EMAIL PROTECTED]> wrote:
That wants MAP_PRIVATE so that the kernel can also decide to not
swap these pages out to an unencrypted swap area.
That's not what MAP_PRIVATE means. MAP_PRIVATE is the opposite of
MAP_SHARED. It's meaningless for anonymous memory (which is
On 6/28/07, Rik van Riel [EMAIL PROTECTED] wrote:
That wants MAP_PRIVATE so that the kernel can also decide to not
swap these pages out to an unencrypted swap area.
That's not what MAP_PRIVATE means. MAP_PRIVATE is the opposite of
MAP_SHARED. It's meaningless for anonymous memory (which is
On 6/27/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
The absolute virtual addresses are randomized, yes; but do a sequence
of mmaps and they come back adjacent to each other, and so mergable.
Or does your distro include a kernel patch to randomize them relative
to each other?
Each individual
On 6/27/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
Not so: if an mmap can be done by extending either adjacent vma (prot
and flags and file and offset all match up), that's what's done and no
separate vma is created. (And adjacent vmas get merged when mprotect
removes the difference in
On 6/27/07, Hugh Dickins [EMAIL PROTECTED] wrote:
Not so: if an mmap can be done by extending either adjacent vma (prot
and flags and file and offset all match up), that's what's done and no
separate vma is created. (And adjacent vmas get merged when mprotect
removes the difference in
On 6/27/07, Hugh Dickins [EMAIL PROTECTED] wrote:
The absolute virtual addresses are randomized, yes; but do a sequence
of mmaps and they come back adjacent to each other, and so mergable.
Or does your distro include a kernel patch to randomize them relative
to each other?
Each individual mmap
On 6/26/07, Rik van Riel <[EMAIL PROTECTED]> wrote:
After going through the first malloc()/free() cycle, surely
the memory will no longer be zeroed on the second malloc() ?
If returned to the system, sure.
What makes the first brk malloc so special?
If the memory is zeroed it needs not be
On 6/26/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
I acutally have the code for it, but I never posted it since it did not
receive a too warm review (and the only user was the fdmap thingy).
Only user of sys_indirect? There will be quite a few right away.
Every syscall that returns a file
On 6/26/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
The following patch implements the sys_brk2() syscall, that nothing is
other than a sys_brk() with an extra "flags" parameter.
Shouldn't we wait for Linus' sys_indirect to arrive and make this
another syscall which takes advantage of it?
-
On 6/26/07, Rik van Riel <[EMAIL PROTECTED]> wrote:
Since programs can get back free()d memory after a malloc(),
with the old contents of the memory intact, surely your
MAP_NONZERO behavior could be the default for programs that
can get away with it?
Maybe we could use some magic ELF header,
On 6/26/07, Rik van Riel [EMAIL PROTECTED] wrote:
Since programs can get back free()d memory after a malloc(),
with the old contents of the memory intact, surely your
MAP_NONZERO behavior could be the default for programs that
can get away with it?
Maybe we could use some magic ELF header,
On 6/26/07, Davide Libenzi [EMAIL PROTECTED] wrote:
The following patch implements the sys_brk2() syscall, that nothing is
other than a sys_brk() with an extra flags parameter.
Shouldn't we wait for Linus' sys_indirect to arrive and make this
another syscall which takes advantage of it?
-
To
On 6/26/07, Davide Libenzi [EMAIL PROTECTED] wrote:
I acutally have the code for it, but I never posted it since it did not
receive a too warm review (and the only user was the fdmap thingy).
Only user of sys_indirect? There will be quite a few right away.
Every syscall that returns a file
On 6/26/07, Rik van Riel [EMAIL PROTECTED] wrote:
After going through the first malloc()/free() cycle, surely
the memory will no longer be zeroed on the second malloc() ?
If returned to the system, sure.
What makes the first brk malloc so special?
If the memory is zeroed it needs not be
g used. This is what the
current model allows: we find problems and since the development cycle
requires changes to be added at the beginning we have time to back
changes out again. No harm done.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
V
. This is what the
current model allows: we find problems and since the development cycle
requires changes to be added at the beginning we have time to back
changes out again. No harm done.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version
emoval is no problem.
> Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Ulrich Drepper <[EMAIL PROTECTED]>
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNAT
is no problem.
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Signed-off-by: Ulrich Drepper [EMAIL PROTECTED]
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux
PI futex. It cannot be, the semantics
is different. This is no locking futex. The kernel will have to deal
with this. The requeue operation is meaningless if this is not done
since it's only use is for this situation.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View,
re two interface to use: open + fcntl. This is racy. And
don't tell me this doesn't matter.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGat6r2ijCOnn/RHQRAiatAKCs7RLZmpgAU5NyT58c8ueJum4fgw
n do
even more.
In whatever way you look at it, there currently is a problem which
cannot be solved except with truly horrible, horrible hack (open N
descriptors and randomly select one to use; yep, horrible, I said so).
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
.
In whatever way you look at it, there currently is a problem which
cannot be solved except with truly horrible, horrible hack (open N
descriptors and randomly select one to use; yep, horrible, I said so).
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP
interface to use: open + fcntl. This is racy. And
don't tell me this doesn't matter.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGat6r2ijCOnn/RHQRAiatAKCs7RLZmpgAU5NyT58c8ueJum4fgwCgjqP0
. It cannot be, the semantics
is different. This is no locking futex. The kernel will have to deal
with this. The requeue operation is meaningless if this is not done
since it's only use is for this situation.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA
ever guarantee that descriptors are allocated sequentially. Linus
already showed a code sequence:
close(0);
.. something else ..
if (open("myfile", O_RDONLY) < 0)
exit(1);
This occurs in the real world and it is guaranteed to work.
- --
➧ Ul
; #define NR_FILES
>
> for (i = 0; i < NR_FILES; i++)
> close(i);
You're confusing the problems. This is not the argument for having a
separate file descriptor set. It is the argument to have hidden file
descriptors. Randomization has nothing whatsoever to do with this ex
ile descriptors cannot be
used as indeces and the randomization makes sure that no program by some
fluke happens to work.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGaaZ02ijC
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alan Cox wrote:
> Why does he want an unpredictable algorithm
To avoid exactly the kind of problem we have now in future: programs
relying on specific patterns.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alan Cox wrote:
Why does he want an unpredictable algorithm
To avoid exactly the kind of problem we have now in future: programs
relying on specific patterns.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN
descriptors cannot be
used as indeces and the randomization makes sure that no program by some
fluke happens to work.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGaaZ02ijCOnn
NR_FILES some constant
for (i = 0; i NR_FILES; i++)
close(i);
You're confusing the problems. This is not the argument for having a
separate file descriptor set. It is the argument to have hidden file
descriptors. Randomization has nothing whatsoever to do with this example.
- --
➧ Ulrich
sequentially. Linus
already showed a code sequence:
close(0);
.. something else ..
if (open(myfile, O_RDONLY) 0)
exit(1);
This occurs in the real world and it is guaranteed to work.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA
xed up. No need to rely on hacks if we can still fix up the interfaces.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGaMU42ijCOnn/RHQRAm0MAJ9pprTVUD/2YvDsL6CPL21WvZSkEACeN3r8
TT8a5FyF2rCct+8gB
ng would be done in two places: after fork and after execve?
That would be enough. Programs should clean after themselves.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGaICk2ijCOnn/RHQRAqq5AJwIDmKdsL
ork. Yes, this might expand the
region in which descriptors are allocated due to inherited descriptors.
But I consider this the application's problem and it usually is not
really an issue. Apps have to explicitly request using the new
descriptors and they can use CLOEXEC (CLOFORK) correctly.
- --
too different from this.
If all this is unwanted then go with what you proposed. Otherwise think
about a more generic approach.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
i
ght might be enough. Maybe that's too specific for
people's taste.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGaGRP2ijCOnn/RHQRAv2qAJ0WzyKvOPx01PviCp4L/mUmNaehtQCfdKF5
4Qc7Uj47zY8jdqUZf+Ht3gs=
=jRfN
lly:
The problem is O_CLOEXEC. They are all racy and if we add a variant
with flags then we might as well support O_NONSEQFD as well.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (G
*utmr, int oflags) ...
These aren't released yet, so, change them now before it's too late.
And to add to your list:
epoll_create(). Important if you think that's the interface people
should use.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version:
code is the answer but iff
Davide's unified code does not perform worse than the current code I
don't see the harm since, for instance, extending socket() is in any
case necessary. I mentioned that close_on_exit must be set on open,
else leaks are risked. This will come naturally with a flags pa
. No need to rely on hacks if we can still fix up the interfaces.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGaMU42ijCOnn/RHQRAm0MAJ9pprTVUD/2YvDsL6CPL21WvZSkEACeN3r8
TT8a5FyF2rCct+8gBKyWF/s=
=fs4f
than the current code I
don't see the harm since, for instance, extending socket() is in any
case necessary. I mentioned that close_on_exit must be set on open,
else leaks are risked. This will come naturally with a flags parameter
which already takes O_NONSEQFD.
- --
➧ Ulrich Drepper ➧ Red Hat
released yet, so, change them now before it's too late.
And to add to your list:
epoll_create(). Important if you think that's the interface people
should use.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux
racy and if we add a variant
with flags then we might as well support O_NONSEQFD as well.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGaFTO2ijCOnn/RHQRAm7uAJ9NsP6FegpO3cAnCe83eZ8awtkHawCgzKK4
be enough. Maybe that's too specific for
people's taste.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGaGRP2ijCOnn/RHQRAv2qAJ0WzyKvOPx01PviCp4L/mUmNaehtQCfdKF5
4Qc7Uj47zY8jdqUZf+Ht3gs=
=jRfN
-END PGP
this.
If all this is unwanted then go with what you proposed. Otherwise think
about a more generic approach.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGaHkj2ijCOnn/RHQRAhWoAJ4loMzrYJQDCU4e6jdOfjL4LG
, this might expand the
region in which descriptors are allocated due to inherited descriptors.
But I consider this the application's problem and it usually is not
really an issue. Apps have to explicitly request using the new
descriptors and they can use CLOEXEC (CLOFORK) correctly.
- --
➧ Ulrich
places: after fork and after execve?
That would be enough. Programs should clean after themselves.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGaICk2ijCOnn/RHQRAqq5AJwIDmKdsL71ecQVd6PoDI2oOL
this,
before or after the new version controlled symbol is introduced, will
break it. Policies or stateful behavior, however yo want to call it, is
just plain wrong for this (and most other things).
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alan Cox wrote:
> prctl(PR_SPARSEFD, 1);
>
> to turn on sparse fd allocation for a process ?
Yes, there is. Go back and read the archives. It has been discussed in
depth.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Moun
ng in this area at
userlevel would involve a new interface. Programs also need new
definitions from headers files. This means a recent enough glibc will
be needed in any case. Unless programs use their own definitions in
which case they might as well use the syscall() function.
- --
➧ Ulrich D
involve a new interface. Programs also need new
definitions from headers files. This means a recent enough glibc will
be needed in any case. Unless programs use their own definitions in
which case they might as well use the syscall() function.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alan Cox wrote:
prctl(PR_SPARSEFD, 1);
to turn on sparse fd allocation for a process ?
Yes, there is. Go back and read the archives. It has been discussed in
depth.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View
or after the new version controlled symbol is introduced, will
break it. Policies or stateful behavior, however yo want to call it, is
just plain wrong for this (and most other things).
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version
On 6/4/07, Jeff Dike <[EMAIL PROTECTED]> wrote:
First, there are signals. If the app has an interval timer enabled,
every thread will inherit it and you will have 32 threads getting
alarms, which seems surprising and wasteful.
Not only that. IIRC the current code does nothing about blocking
On 6/4/07, Jeff Dike [EMAIL PROTECTED] wrote:
First, there are signals. If the app has an interval timer enabled,
every thread will inherit it and you will have 32 threads getting
alarms, which seems surprising and wasteful.
Not only that. IIRC the current code does nothing about blocking
propriating dup2.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGY6GA2ijCOnn/RHQRAtQ1AJ4+dDIgeBKlggt4U+lyZnDfQJZ/VQCfRbG4
0FtGWqlLOWFlspMJ9S3xQ7E=
=jrG1
-END PGP SIGNATURE-
-
To unsubscribe from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Davide Libenzi wrote:
> Randomizing the base is not a problem. Should this be always, or flag
> driven?
I would say all the time. I don't think it's a problem with
reproducibility in any reasonable code.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc.
implement these extra security measures. The cost of a randomized star
base (offset from 2^30) should be zero.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGYyid2ijCOnn/RHQRAjRoAJ9XsAazZtc9V3A
/fcntl functionality. But removing functionality is harder.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGYxnb2ijCOnn/RHQRAkyoAJ4+L3W/aVYaQ/IG0HPm0tt5PKPcRACgoJYF
bChz20uicqD9tBbDtU1yruM=
=4vNd
uld be better but the new RLIMIT_NOFILE semantics is
certainly also correct according to POSIX.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGYwZ82ijCOnn/RHQRAsvGAJ4jXamjOJVq4ImmVYT3/ghBXTB1bgCdGF0O
is
certainly also correct according to POSIX.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGYwZ82ijCOnn/RHQRAsvGAJ4jXamjOJVq4ImmVYT3/ghBXTB1bgCdGF0O
Y4nv9i7L98UEDEKc09Wt0VU=
=OS4+
-END PGP
.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGYxnb2ijCOnn/RHQRAkyoAJ4+L3W/aVYaQ/IG0HPm0tt5PKPcRACgoJYF
bChz20uicqD9tBbDtU1yruM=
=4vNd
-END PGP SIGNATURE-
-
To unsubscribe from this list: send
measures. The cost of a randomized star
base (offset from 2^30) should be zero.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGYyid2ijCOnn/RHQRAjRoAJ9XsAazZtc9V3AxaPjiNMjK8jPUZgCdG/Eg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Davide Libenzi wrote:
Randomizing the base is not a problem. Should this be always, or flag
driven?
I would say all the time. I don't think it's a problem with
reproducibility in any reasonable code.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444
.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGY6GA2ijCOnn/RHQRAtQ1AJ4+dDIgeBKlggt4U+lyZnDfQJZ/VQCfRbG4
0FtGWqlLOWFlspMJ9S3xQ7E=
=jrG1
-END PGP SIGNATURE-
-
To unsubscribe from this list: send
Take two: I forgot to change the compat code. This has now happened. Only one
additional line changed.
Everything else from the first patch remains the same. I try to avoid clogging
the list unnecessarily by not resending the test program.
Signed-off-by: Ulrich Drepper <[EMAIL PROTEC
Take two: I forgot to change the compat code. This has now happened. Only one
additional line changed.
Everything else from the first patch remains the same. I try to avoid clogging
the list unnecessarily by not resending the test program.
Signed-off-by: Ulrich Drepper <[EMAIL PROTEC
= -1)
error (1, 0, "no descriptor received");
char fdname[20];
snprintf (fdname, sizeof (fdname), "%d", fd);
execl ("/proc/self/exe", argv[0], fdname, NULL);
puts ("execl failed");
return 1;
}
Signed-off-by: Ulrich Drepper <[EMAIL P
/self/exe, argv[0], fdname, NULL);
puts (execl failed);
return 1;
}
Signed-off-by: Ulrich Drepper [EMAIL PROTECTED]
--- a/fs/open.c
+++ b/fs/open.c
@@ -855,7 +855,7 @@
/*
* Find an empty file descriptor entry, and mark it busy.
*/
-static int get_unused_fd_flags(int flags)
+int
Take two: I forgot to change the compat code. This has now happened. Only one
additional line changed.
Everything else from the first patch remains the same. I try to avoid clogging
the list unnecessarily by not resending the test program.
Signed-off-by: Ulrich Drepper [EMAIL PROTECTED
Take two: I forgot to change the compat code. This has now happened. Only one
additional line changed.
Everything else from the first patch remains the same. I try to avoid clogging
the list unnecessarily by not resending the test program.
Signed-off-by: Ulrich Drepper [EMAIL PROTECTED
w what the runtime libraries need
(not just libc, libstdc++, libxml, whatever) and vice versa. Policies
are always wrong for somebody and changing the standardized behavior is
not acceptable.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
V
ight just as well break assumptions in the
same program.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGXxm/2ijCOnn/RHQRAm+wAJ9YD6KsS6T96xChZvS/3yCwCo6+0gCgl0IY
y6OxxUcuQ8yGJsiYebkuIMY=
=tkxV
---
access to the
functionality. I cannot set the policy to default to close-on-exit in
glibc all the while the application assumes this is not the case.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGXxcK2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nicholas Miell wrote:
> O_CLOSEONEXEC, perhaps?
Then nobody would know this is equivalent to FD_CLOEXEC. I think the
name I propose is fine.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNAT
return 0;
}
fd = open ("/proc/self/exe", O_RDONLY | O_CLOEXEC);
printf ("in parent: new fd = %d\n", fd);
char buf[20];
snprintf (buf, sizeof (buf), "%d", fd);
execl ("/proc/self/exe", argv[0], buf, NULL);
puts ("execl failed");
return
On 5/30/07, Steven Rostedt <[EMAIL PROTECTED]> wrote:
But, the -rt kernel has pretty much the same code for the
futex_unlock_pi64, and it has the same bug.
Why would you use futex_unlock_pi64?
In fact, the whole 64-bit futex patch should be reviewed and cut down
to the bare minimum. I know, I
On 5/30/07, Steven Rostedt <[EMAIL PROTECTED]> wrote:
> if (!(uval & FUTEX_OWNER_DIED)) {
> pagefault_disable();
> uval = futex_atomic_cmpxchg_inatomic(uaddr, current->pid, 0);
> pagefault_enable();
> }
[...]
This code is in futex_unlock_pi.
On 5/30/07, Steven Rostedt [EMAIL PROTECTED] wrote:
if (!(uval FUTEX_OWNER_DIED)) {
pagefault_disable();
uval = futex_atomic_cmpxchg_inatomic(uaddr, current-pid, 0);
pagefault_enable();
}
[...]
This code is in futex_unlock_pi. Can the
On 5/30/07, Steven Rostedt [EMAIL PROTECTED] wrote:
But, the -rt kernel has pretty much the same code for the
futex_unlock_pi64, and it has the same bug.
Why would you use futex_unlock_pi64?
In fact, the whole 64-bit futex patch should be reviewed and cut down
to the bare minimum. I know, I
201 - 300 of 743 matches
Mail list logo
