On Wed, Dec 11, 2013 at 05:30:43PM +0100, Marin Ramesa wrote:
- ipc_mqueue_t mqueue;
+ ipc_mqueue_t mqueue = mqueue; /* Quiet GCC warning. */
Don't do that. Instead, tweak simple_unlock and similar functions this
way :
#define simple_unlock(l) ((void)(l))
--
Richard Braun
On Wed, Dec 11, 2013 at 09:07:38PM +0100, Marin Ramesa wrote:
On 11.12.2013 18:02:50, Richard Braun wrote:
On Wed, Dec 11, 2013 at 05:30:43PM +0100, Marin Ramesa wrote:
- ipc_mqueue_t mqueue;
+ ipc_mqueue_t mqueue = mqueue; /* Quiet GCC warning. */
Don't do that. Instead, tweak
does not occur when assuming
that (X - c) = X is always true [-Wstrict-overflow]
Remove your explicit cast, make K_DONE an unsigned.
--
Richard Braun
On Wed, Nov 20, 2013 at 01:18:17PM +0100, Justus Winter wrote:
Quoting Richard Braun (2013-11-20 12:13:20)
I'm not sure to grasp the relation between this patch and deadlock
avoidance. I also don't see what's wrong with generating data at open
time.
Suppose you have
settrans -ac
prefer that indeed.
So there is a good reason for this kind of initialization (int x = x)?
It was done on purpose, yes. It tells GCC to consider the variable
initialized, and is useful to silence warnings when the code is valid.
--
Richard Braun
On Sun, Nov 17, 2013 at 05:13:23PM +0100, Richard Braun wrote:
The following changes actually apply to Debian eglibc 2.17-96 sources,
Binary packages are available for testing on my repository :
deb http://ftp.sceen.net/debian-hurd-i386 experimental/
Install gnumach first, then glibc
On Mon, Nov 18, 2013 at 11:33:55AM +0100, Neal H. Walfield wrote:
Richard Braun wrote:
The current state is to never terminate threads, on the assumption that
they can't both terminate and release their stack on their own. Such
resources are recycled by the threading library. This patch
On Mon, Nov 18, 2013 at 04:22:06PM +0100, Samuel Thibault wrote:
Richard Braun, le Sun 17 Nov 2013 17:13:23 +0100, a écrit :
Two resources are still recycled: the internal pthread structure
(because it makes ID allocation easy), and thread local storage (TLS)
because that's where the reply
The following changes actually apply to Debian eglibc 2.17-96 sources,
and aren't meant to be pushed as such, but rather to review the various
solutions added to support thread termination.
The current state is to never terminate threads, on the assumption that
they can't both terminate and
On Sun, Nov 17, 2013 at 09:41:03PM +0100, Samuel Thibault wrote:
Richard Braun, le Sun 17 Nov 2013 17:13:23 +0100, a écrit :
This patch makes use of a new GNU Mach specific call
(thread_terminate_release [1]) so that threads do terminate themselves
and release their stack, and in addition
to reduce resource usage after peaks, but also to fix those bugs.
I guess we can merge your changes however, since they're not conflicting
at all. With the fix Samuel mentioned, it should be fine.
--
Richard Braun
On Sat, Nov 16, 2013 at 04:39:01PM +0100, Marin Ramesa wrote:
I assumed it's inconvinient for people to suddenly find 32 messages in
We think of it (and our viewers make us see it) as one thread, not 32
messages.
--
Richard Braun
swap.
I'd rather keep it as such, as an expression of the rbtree rotation.
It's not a rotation, merely a variable swap, I would personally simplify
it too. FYI, Justus find it too with Clang if I'm right.
--
Richard Braun
diskfs_startup_diskfs returns).
In the mean time, I was thinking adding simple blocking calls, replacing
pthread_exit with poll. Is anybody uncomfortable with that hack ?
--
Richard Braun
for correcting.
--
Richard Braun
On Tue, Nov 12, 2013 at 02:34:18PM +0100, Richard Braun wrote:
Right, I misread the specification, thanks for correcting.
FYI, this means we currently have a bug with regard to that : after the
main thread calls pthread_exit(), and thread destruction is actually
implemented (as opposed
On Tue, Nov 12, 2013 at 12:39:40PM +0100, Samuel Thibault wrote:
Richard Braun, le Tue 12 Nov 2013 11:56:05 +0100, a écrit :
It's not a rotation, merely a variable swap,
Ok, but below the comment says
/* Node is the left child of its parent. */
If node is not always updated
not a matter of mere numbers. We need consensus, and if we can't
achieve it, the actual maintainer (who currently is Samuel) decides.
--
Richard Braun
by mach_msg_server_timeout,
can't easily be modified to take a generic void * pointer without
breaking the ABI. Those function pointers were intended to be nested
functions from the start.
--
Richard Braun
.
So, how to start with it?
Don't take it wrong, but everything you need is on the wiki. If you
really want to contribute, just do it. How hard is it to just grab the
code, clean it, and send patches ?
--
Richard Braun
The node structure for the `mounts' entry is created and destroyed on
each access, despite the fact a translator is activated on it. Fix the
issue by caching it.
* rootdir.c (rootdir_mounts_node): New variable.
(rootdir_mounts_node_lock): Likewise.
(rootdir_mounts_make_node): New function.
/documentation.html
--
Richard Braun
the critical section.
This really is a beginner mistake, showing that you probably need to
gain experience with concurrency itself first.
--
Richard Braun
On Mon, Sep 23, 2013 at 09:13:25AM +0200, Marin Ramesa wrote:
The idea is to implement a simple mutex using one atomic operation
combined with futex calls.
Use the algorithms presented in Futexes are tricky, I personally won't
accept anything less after 2010...
--
Richard Braun
On Mon, Sep 23, 2013 at 11:34:36AM +0200, Marin Ramesa wrote:
On 23.09.2013 10:35:34, Richard Braun wrote:
Use the algorithms presented in Futexes are tricky, I personally
won't accept anything less after 2010...
I do, it's actually the version from 2011. I just added the lock
On Sun, Sep 22, 2013 at 10:28:47AM +0200, Marin Ramesa wrote:
On 22.09.2013 02:08:41, Richard Braun wrote:
Also, futex_wait_lock looks to be local to futex_wait...
Yes it is. But if I introduce a more global lock that should imply that
there is another operation that is a candidate
futexes are tricky from Ulrich Drepper, for more details.
+ /* Check if there is an existing futex at the address given. */
Better use a hash table :)
Also, futex_wait_lock looks to be local to futex_wait...
--
Richard Braun
the main Hurd repository because it's
not the original procfs server. We could probably merge it in one day
though.
--
Richard Braun
consists of
using object addresses as kernel port names to skip looking up the
object port.
So actually, these hashing functions take both a port name or a device
as argument.
--
Richard Braun
)
Nothing major, I'd simply like this process to be as visible as the rest
of the system.
--
Richard Braun
On Mon, Sep 16, 2013 at 02:58:24AM +0200, Richard Braun wrote:
On Mon, Sep 16, 2013 at 01:50:57AM +0200, Samuel Thibault wrote:
Richard Braun, le Thu 12 Sep 2013 10:57:25 +0200, a écrit :
I suggest we simply disable the trap versions.
Ah, right.
I don't have the time to dive
objects, task grouping should be
done by the kernel too. For me, it looks like this issue is part of
the more general problem of resource accounting in Mach.
--
Richard Braun
On Mon, Sep 16, 2013 at 01:50:57AM +0200, Samuel Thibault wrote:
Richard Braun, le Thu 12 Sep 2013 10:57:25 +0200, a écrit :
I suggest we simply disable the trap versions.
Ah, right.
I don't have the time to dive into the details, but in the end, couldn't
we switch to making task_create
On Thu, Sep 12, 2013 at 08:24:41AM +0200, Samuel Thibault wrote:
Richard Braun, le Thu 12 Sep 2013 01:57:10 +0200, a écrit :
How come it appears in the output of rpctrace then ?
As I said, glibc probably nicely uses the RPC instead of the trap.
Then why are we discussing interposing system
On Thu, Sep 12, 2013 at 10:38:31AM +0200, Samuel Thibault wrote:
Richard Braun, le Thu 12 Sep 2013 10:33:23 +0200, a écrit :
Then why are we discussing interposing system calls ?
Because a malicious program can still use the trap to escape whatever
cgroup system we are setting up.
I
the TASK_KERNEL_PORT of a task.)
Apparently task_create is a kernel trap.
How come it appears in the output of rpctrace then ?
--
Richard Braun
of autonomy.
--
Richard Braun
closely with the Linux one, and that is one of the points of our
procfs, isn't it?
What's the problem with adding support for valid values ?
--
Richard Braun
of guessing.
A better example would be providing an exec server for old a.out static
binaries for example. But for compression, what Justus describes looks
a lot more hurdish to me.
--
Richard Braun
? The filenames should be relative to
the caller's root.
Is that really necessary ? Support for chroot has always been incomplete
and present for compatibility only. In addition, Linux still shows the
paths at mount time in /proc/mounts from a chroot.
--
Richard Braun
functionality ...
--
Richard Braun
[1] http://lists.gnu.org/archive/html/bug-hurd/2013-07/msg00214.html
here.
--
Richard Braun
On Thu, Jul 18, 2013 at 12:22:07AM +0800, Yue Lu wrote:
On Thu, Jul 18, 2013 at 12:13 AM, Richard Braun rbr...@sceen.net wrote:
On Thu, Jul 18, 2013 at 12:07:20AM +0800, Yue Lu wrote:
when I used thread_info() to check the suspend count, they are zero.
But I met a strange thing
that, considering a recursive approach does more
than what we need, a simple registry translator is probably much simpler
and safer than what we're trying to do here.
--
Richard Braun
it has anything to do with the instruction cache. Use the
thread_info() call to determine what the suspend count is, it may have
been incremented implicitely.
--
Richard Braun
does look wrong. Check all the parameters of your call, one
by one, rigorously.
--
Richard Braun
. Or they are just too trivial for that.
This shouldn't be a problem at all.
--
Richard Braun
by itself from a port to the mount
point, much like glibc/sysdeps/mach/hurd/getcwd.c. It'll be slower, but
should be safer. The RPC would thus return an array of ports to the
mount points instead of an array of strings.
Anybody else?
Looks better indeed.
--
Richard Braun
On Thu, Jul 04, 2013 at 03:29:57PM +0200, Justus Winter wrote:
I'm thinking that this might be an opportunity to get rid of the
heuristic in that function. The comment explains the issue:
If you have time, sure, otherwise the heuristic seems to be enough for
the time being.
--
Richard Braun
On Wed, Jul 03, 2013 at 11:35:31AM +0200, Marin Ramesa wrote:
diff -Nurp ../gnumach/ddb/db_break.c ../gnumach1/ddb/db_break.c
Please ease the life of maintainers by providing git-generated patches
with a proper changelog entry.
--
Richard Braun
.
Thanks.
--
Richard Braun
that's the case, see if rpctrace catches the call.
--
Richard Braun
- Forwarded message from Richard Braun rbr...@sceen.net -
Date: Mon, 6 May 2013 21:49:56 +0200
From: Richard Braun rbr...@sceen.net
To: bug-hurd@gnu.org
Subject: [PATCH] Make __getclktck return 100 for the Hurd
X-Mailer: git-send-email 1.7.2.5
While it's true that Mach time values
sysconf(_SC_CLK_TCK).
--
Richard Braun
think the latter is
better for clarity, and also to limit overflows for long running
processes, although that's really secondary.
--
Richard Braun
-ports.org?
I'd like to know as well.
--
Richard Braun
On Mon, Jun 10, 2013 at 07:30:58PM +0200, Justus Winter wrote:
Quoting Richard Braun (2013-06-10 16:28:40)
On Mon, Jun 10, 2013 at 04:10:57PM +0200, Justus Winter wrote:
Awesome, didn't know this one. Still I was hoping to get a git repo
since that way I could plug it into my package
2
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory `/media/scratch/teythoon/packages/hurd-pkg'
make: *** [binary] Error 2
You need more recent sources, i.e. those from debian-ports.
--
Richard Braun
are provided by glibc (and by the libc0.3-dev package on
Debian GNU/Hurd).
--
Richard Braun
. Using
already generated system headers is the intent here. The fact they were
generated doesn't matter at all, they are the interface reference that
applications (and even the Hurd itself) must use.
--
Richard Braun
not sure that's something we want
to do as it can be handy to emulate kernel calls. Another solution is
to restrict these RPCs to kernel objects only.
--
Richard Braun
On Fri, May 10, 2013 at 05:07:52PM +0200, Richard Braun wrote:
On Thu, May 09, 2013 at 07:20:39PM +0200, Samuel Thibault wrote:
Thomas Schwinge, le Thu 09 May 2013 18:42:18 +0200, a écrit :
Then, to what extent are the proposed new RPCs just a specialized
variant of the generic port info
While it's true that Mach time values are returned in microseconds, they
are correctly handled as such, and not as clock ticks, by applications.
On the other hand, tools such as top provide wrong results since values
in /proc are actually provided as true clock ticks.
---
On Sun, Dec 02, 2012 at 11:15:08AM +0100, Richard Braun wrote:
On Sat, Dec 01, 2012 at 12:53:30PM +0100, Thomas Schwinge wrote:
So, switching to a SSD does give a small performance boost, but not the
big one we had hoped for. Using --no-atime improves this further.
Perhaps we should follow
If requested by the user, make libpager call pager_notify_evict when a page
is flushed out by the kernel. Based on work by Ognyan Kulev.
* console/pager.c (pager_notify_evict): New function.
(user_pager_create): Update call to pager_create.
* ext2fs/pager.c: (pager_notify_evict): New function.
This is a revised version of the large store patch for ext2fs, written
by Ognyan Kulev. It provides support for stores larger than 2 GiB.
* ext2fs/balloc.c: Use the new disk_cache_block_ref and disk_cache_block_deref
functions to access blocks from the disk cache.
* ext2fs/ext2fs.c (main): Update
is to free the student from any other time consuming involvment
during the summer. While I understand it can be difficult to plan ahead
without being certain to be selected, it's also a strong hint for us
that the student is more likely to succeed than another who will also be
busy elsewhere.
--
Richard
currently have priority
nonetheless, and the DWARF call frame information data are quite not as
easy to use.
--
Richard Braun
to open issues. I believe it's even more important now that the GSoC is
about to start.
--
Richard Braun
was to permanentely add a link to project ideas, not only
during the duration of the GSoC.
--
Richard Braun
to it, spread over
several years, my proposal is to just feed that amount back into the
general GNU Hurd pool, which is what will happen on Saturday unless
someone intervenes.
Agreed. Thanks for taking care of that.
--
Richard Braun
hilarious, but I
really wouldn't mind the former either. As this issue is a critical one
that currently severely prevents usage of the system and further
development, it should be resolved quickly.
--
Richard Braun
the immediate benefits, vim (actually, when called with another
name such as view or through another program like dch or git) now
reacts properly. The gitk tool magically works again. Iceweasel no
longer suffers from threads randomly spinning in infinite loops.
Feedbacks are welcome.
--
Richard Braun
:
From now on, I'll completely ignore you. System development is obviously
not for you, go do something else (my early apologies to whoever gets
him in his team). Go away from this project.
--
Richard Braun
to libc-alpha anyway...
+1
--
Richard Braun
concentrate on
thinking about the big picture and the details. The second is to reduce
the likeliness of regressions. Please keep that in mind.
--
Richard Braun
, there only are a
few changes, quite simple to understand.
--
Richard Braun
[1]
http://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=youpi/poll_errors_fixes
case there is a bug in the
signal handling code.
See the following glibc files for reference :
- sysdeps/mach/hurd/i386/trampoline.c
- sysdeps/mach/hurd/i386/sigreturn.c
--
Richard Braun
Here is the fixed version of my current work about fixing functions
that block for a limited time (e.g. pthread_cond_timedwait), and
cancellation, with additional description of what it is about.
This patch solves two issues. The first one is cancellation handling
when a cancellation request is
it automatically pass on SIGSEGV signals so that you only catch the
SIGILL you're interested in.
--
Richard Braun
the way the design affects security (making processes
obtain due rights instead of switching from root to a less privileged
user).
--
Richard Braun
On Thu, Jan 24, 2013 at 12:14:44AM +0100, Richard Braun wrote:
diff --git a/pthread/pt-cancel.c b/pthread/pt-cancel.c
index d19c557..3698cce 100644
--- a/pthread/pt-cancel.c
+++ b/pthread/pt-cancel.c
@@ -31,9 +31,31 @@ pthread_cancel (pthread_t t)
if (! p)
return ESRCH
it, the separation of
the three cases you're trying to introduce looks wrong to me. The
amount of change needed to handle each case is small enough to keep them
inline. Please avoid completely reworking _hurd_select just to fix a
small conformance issue ...
--
Richard Braun
and select behave the same when nfds
is 0, i.e. the timeout is not ignored and the call acts as a sleep.
IMHO, our implementation should stick to that common behaviour.
--
Richard Braun
Here is the current state of my work about fixing functions that block
for a limited time (e.g. pthread_cond_timedwait), and cancellation.
---
pthread/pt-alloc.c |3 +
pthread/pt-cancel.c | 26 +-
pthread/pt-internal.h |8 ++
the respective specific code in helper functions.
--
Richard Braun
The fmh function could in some cases mistakenly call vm_map with a null
size. A recent kernel fix made that invalid and return KERN_INVALID_ARGUMENT,
which isn't an expected code here, resulting in the linker not starting.
Avoid calling vm_map when the computed mapping size is null to fix the
* rootdir.c: Include mach/gnumach.h and mach/vm_cache_statistics.h.
(rootdir_gc_meminfo): Call vm_cache_statistics and return the VM cache size.
---
rootdir.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/rootdir.c b/rootdir.c
index 1fa71b0..31e2d8c 100644
---
* utils/vmstat.c: Include mach/gnumach.h and mach/vm_cache_statistics.h.
(vm_state): New `cache_stats` member.
(vm_state_refresh): Call vm_cache_statistics.
(_F): Adjust offset.
(fields): Add entries for new statistics and adjust member names.
---
utils/vmstat.c | 44
On Sun, Dec 23, 2012 at 11:49:25PM +0100, Samuel Thibault wrote:
Other than that, the analysis and the fix look good.
AIUI, with the gnumach fix it is not needed any more, right?
Yes, that's the idea.
--
Richard Braun
is set during page-in or something
like that? Hmm...
The TH_UNINT flag is often set in GNU Mach. The main reason is to prevent
leaving an inconsistent state if a thread never resumes. Legacy task
(process) swapping is a likely reason for the state you're observing.
--
Richard Braun
to explain bugs in your own
work ... This was untested code which was later replaced. See [1].
--
Richard Braun
[1]
http://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/select_timeout_for_one_fd
On Mon, Dec 10, 2012 at 01:45:55AM +0100, Cyril Roelandt wrote:
I attached a patch that fixes the issue, but I can't guarantee that
it doesn't break anything. What do you think ?
Looks fine.
--
Richard Braun
at the same time.
--
Richard Braun
On Sun, Dec 02, 2012 at 11:15:08AM +0100, Richard Braun wrote:
the port to pthreads), I noticed that much of the time spent by the CPU
is actually wasted for two major reasons.
I didn't emphasize enough that, contrary to popular belief, the main
bottleneck is _CPU_ time (well, the suboptimal VM
),
apart from a few style and formatting issues.
As it's a diff from Linux 2.0.40, we probably want to keep it the way it
exists upstream. Concerning the changes themselves, they look fine so
far. Nice job :).
--
Richard Braun
On Tue, Nov 20, 2012 at 04:03:04PM +0100, Richard Braun wrote:
The public Hurd box darnassus.sceen.net suffered a problem (due to human
error when updating kernel/libc/hurd servers), which caused a fatal
corruption of the root file system. The machine needs to be completely
reinstalled
saved a mail roundtrip if you had simply said so in
your mail)
I only see EPIPE in pipe_wait_writable, which is only used in case
SELECT_WRITE is set. I'm not sure how this will fix the behaviour for
the POLLIN case.
--
Richard Braun
On Mon, Nov 26, 2012 at 02:34:04PM +0100, Samuel Thibault wrote:
In the read case, the end of file will be detected by a zero-read, not
an EPIPE.
Right. What about the SELECT_URG/POLLPRI case ? This one looks quite
obscur.
--
Richard Braun
On Mon, Nov 26, 2012 at 02:38:44PM +0100, Samuel Thibault wrote:
Richard Braun, le Mon 26 Nov 2012 14:37:23 +0100, a écrit :
Right. What about the SELECT_URG/POLLPRI case ? This one looks quite
obscur.
It is. IIRC for TCP/IP it's used for out-of-band data. I don't think we
have
301 - 400 of 557 matches
Mail list logo
