;s
> not true, proc doesn't set a thread timeout, and thus some threads can
> stay indefinitely stuck in receiving messages. And thus the deferred
> dereferencing used by ports_destroy_right never gets achieved.
>
> I'll push a fix.
Very nice catch.
--
Richard Braun
be a good thing to add whole program optimizations like LTOs,
although this requires the code quality to be excellent, but that should
eventually be the case anyway.
--
Richard Braun
---
libps/procstat.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libps/procstat.c b/libps/procstat.c
index d0423410..131d3a4b 100644
--- a/libps/procstat.c
+++ b/libps/procstat.c
@@ -1097,6 +1097,7 @@ _proc_stat_free (ps)
0, &ps->task_events_info_buf, char);
MFREEMEM (PSTAT_
I'm happy to report it's been a long time since I've seen this indeed.
Thanks !
--
Richard Braun
On Tue, Aug 17, 2021 at 10:29:42AM +0200, Richard Braun wrote:
> On Mon, Aug 16, 2021 at 11:23:23PM +0200, Denis 'GNUtoo' Carikli wrote:
> > While it's relatively easy to create an account on the Hurd wiki[1] and
> > to edit it, everything is in http.
> >
>
On Wed, Aug 25, 2021 at 04:23:23PM +0200, Samuel Thibault wrote:
> Richard Braun, le mer. 25 août 2021 15:59:12 +0200, a ecrit:
> > I can't recall exactly, but that's why we write comments, right ?
> > See [1].
> >
> > Fixing this requires changing all
s changing all callers to not assume that allocated
memory can always be directly mapped, in particular some kvtophys calls.
--
Richard Braun
[1]
https://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/vm/vm_resident.c?id=4dbaa718038fadc51d9b95d2383868a229d91457#n776
probably transmitted in clear.
>
> Would it be possible to fix that?
On vacation right now, but I'll get to it eventually.
--
Richard Braun
x27;t looked at the work, but if Samuel merged it, I trust it's
good. Thanks :).
--
Richard Braun
st an optimization,
so it should be completely safe to just comment it out on systems where
the macro doesn't exist (assuming it's a macro).
--
Richard Braun
On Tue, Sep 22, 2020 at 01:28:42PM +0200, Richard Braun wrote:
> On Fri, Aug 28, 2020 at 06:39:29PM +0200, Samuel Thibault wrote:
> > One way to avoid the bug is to use the e1000 hardware network type. I
> > guess the rtl8139 driver that we ship in netdde has a bug in its irq
>
erver
> does, and couldn't reproduce the exec hang at boot. This is now in
> debian as gnumach version 2:1.8+git20201007-1.
Very nice.
--
Richard Braun
; IDE driver). Moving to rump-based network drivers will probably help
> fixing this kind of issue long-term :)
It does seem to help. Thanks.
For information, the virtual machines were using the pcnet device,
not the rtl8139 one.
--
Richard Braun
y that website is so often unreachable is
netdde freezing. I've restored an old trick I used in the past to mitigate
the problem, which is merely a cron script that kills it every hour.
If you want that to improve, someone will have to hunt that bug down.
--
Richard Braun
On Fri, Aug 21, 2020 at 01:28:42AM +0200, Richard Braun wrote:
> On Thu, Aug 20, 2020 at 11:10:53PM +0200, Almudena Garcia wrote:
> > We have to leave the 90s ideas, and think as younger people thinks nowadays
I mean, really, you have to keep in mind that the Hurd originated in the
80s
not to turn it into
something that it shouldn't be for all kinds of stupid reasons. I
personally like what you wrote so far about your intentions.
--
Richard Braun
project like, say, Linux. Finally, it's not about merit, it's
about who can make the project progress well and who can't. I claim that,
for the most part, people who are not willing to make serious efforts
should just stay away. The Hurd is already buggy enough as it is and
this is not a school.
--
Richard Braun
s few cognitive
biases as possible, so call me prejudiced against the others if you want,
at least I have a strong argument for my case.
--
Richard Braun
rrently is, or could be without too much effort) and then it'll
attract people.
To all who whine about information not being easy to find : sure, it
could be better, but it's there, so if people give up that quickly, I
believe it says more about our current culture, or even the character
of these people, than it says about the project itself. Grow up and
focus on what matters.
--
Richard Braun
Ps).
Not really. You can build a CPU ID table on the BSP, and associate CPU IDs
with all local APIC IDs discovered, and use that look-up table later
to obtain a CPU ID from the local APIC ID of the CPU running the code.
It's just too slow compared to using a segment register.
--
Richard Braun
. All systems I know use a scheme
similar to TLS, i.e. using the fs or gs segment register, to fetch
a per-CPU structure and from it, per-CPU data. This avoids relying on
hardware running at a lower frequency than the CPU.
--
Richard Braun
e there.
The people who didn't know those times couldnt't have forgotten them.
Also, it's not the 90s any more :).
--
Richard Braun
On Wed, Jun 10, 2020 at 11:34:55AM +0200, Riccardo Mottola wrote:
> Put HD back in old laptop.
> Boot halts at:
> Hurd server bootstrap: ext2fs[defice:hd0s1] exec
>
> Tried rebooting, it is stuck twice,
This is an old race that definitely needs fixing.
--
Richard Braun
a lot more time doing stuff
> than they have. Everything is relative :)
I completely agree. While I appreciate the compliments, I'm worried
about the excessive aspect of it. Calm down, we're not gods, we're just
decent developers.
--
Richard Braun
day,
Likewise.
--
Richard Braun
s also important to make it easy for
other people to work on that code.
I wouldn't be insisting so much on these points if I didn't think they
were critically important. All this is not new. You're a student, so
learn from it.
--
Richard Braun
>
> what do you think?
I think any work that is meant to last and ends up in a form that
isn't fit for long term maintenance isn't serious work.
--
Richard Braun
ant
> concepts and solving my questions about this, probably I'm able to do this
> task
That's not exactly what I mean. Let's talk on IRC to sort this out.
I'm braunr@Freenode.
--
Richard Braun
o this, you need to make sure you are able to
commit to the task.
--
Richard Braun
tive of someone who
can give them. They've just become a regular source of annoyance.
--
Richard Braun
n.
With GCC and Clang, __LP64__ is the most reliable one. Note that this
is specific to the ILP32 and LP64 data models though. On Windows,
which uses the LLP64 data model, it wouldn't work.
--
Richard Braun
lock
> device without worrying about being "aliased" from the file itself. Ditto
> if the file is accessed/mmap'ed uncompressed, but stored in a compressed
> form on the block device.
You could take a look at the ext2fs translator.
Although I don't see the difficulty here. The file system should be
the only server to cache file data in the page cache, and should
merely use direct access to the block device.
--
Richard Braun
hich are the most
common memory managers) run from kernel space, whereas on a
microkernel-based system, they normally run outside.
The two main classes of memory managers are file systems and device
drivers, with the exception of the default pager for anonymous memory
and swapping.
--
Richard Braun
recommend the NetBSD UVM paper, which extensively describes the BSD
VM, and in turn much of the Mach VM.
What's not described, obviously, is external memory managers, but it's
similar to how kernel memory managers (file systems) interface with
the VM.
--
Richard Braun
y're undefined in the kernel (correct me if
I'm wrong about this). But when a symbol is undefined in both the kernel
and the C library, the link just fails. The symbol in question here is
APIC_LOCAL_APIC_ID. The fix should be obvious.
--
Richard Braun
on this list, even if those particular ones are
obvious.
--
Richard Braun
r in the
hope those pages get freed
< braunr> but sending to the default pager is now impossible because its map is
locked on the never-ending fault
--
Richard Braun
On Thu, Aug 30, 2018 at 06:15:28PM +0200, Almudena Garcia wrote:
> It's not only a test. Obviously, It must start as a test, but I want to add
> this to Hurd if runs.
>
>
>
> El jue., 30 ago. 2018 a las 18:02, Richard Braun ()
> escribió:
>
> > On Th
-developer-vol-3a-part-1-manual.html
Oh, so it's merely runtime probing.
--
Richard Braun
.
>
> https://c9x.me/x86/html/file_module_x86_id_45.html
>
> https://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.html
What is "a newer implementation via hardware" ? Can you be very specific
about what you're referring to ?
--
Richard Braun
On Thu, Aug 30, 2018 at 04:52:28PM +0200, Almudena Garcia wrote:
> > But this solution would be specific to Intel chips? ie: this method of
> > SMP wouldn't work on AMD or POWER right
>
> All x86 architecture, I think
What on Earth are you talking about ?
--
Richard Braun
're doing, and set yourself real-world goals
like developing a project doing something that actually interests you.
--
Richard Braun
On Wed, Aug 01, 2018 at 09:53:59AM +0200, Samuel Thibault wrote:
> NEWS for version 2.28
> =
>
> [...]
>
> * Building and running on GNU/Hurd systems now works without out-of-tree
> patches.
I didn't think it would actually happen. Great work :).
--
Richard Braun
bject from it,
we use protected payloads, which are merely user-assigned arbitrary
values associated to ports, to store the address of the associated
object directly, and that's what you receive instead of the port
name.
--
Richard Braun
matching the one inside
> the payload.
>
> Anyone has a hint on what could be happening here? I'm lost :(
>
> Reproducing this bug is easy: just install the liblwip0 package and
> try to open a ssh connection to our lwip translator.
Just to be sure, do you see what protected payloads are ?
--
Richard Braun
efer to a per-processor area in memory, where the ID of the
current processor can be found, among other things. See the cpu_id()
function at [1] for a reasonably simple (but not naive) implementation.
--
Richard Braun
[1]
https://git.sceen.net/rbraun/x15.git/tr
On Fri, Jun 15, 2018 at 07:18:55PM +0200, Richard Braun wrote:
> On Fri, Jun 15, 2018 at 06:27:21PM +0200, Almudena Garcia wrote:
> > I'm trying to define the cpu_number() in multiprocessor.
> >
> > To do this, I tried to use CPUID assembly x86 instruction, to get the C
mily. The idea is to create an eax variable with the
value 1 in C, pass that to the inline assembly expression with the
appropriate constraint, and do something similar for the returned
value in ebx, and then extract bh from it.
--
Richard Braun
[1]
https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Machine-Constraints.html#Machine-Constraints
7;re normally really interested
in is releasing this parent object, including destroying the mutex, which
means you also have to wait for all threads to unlock it. One common way
to deal with this is reference counters on the parent object.
--
Richard Braun
On Thu, Nov 09, 2017 at 10:34:33AM +0100, Samuel Thibault wrote:
> Jens Arm, on jeu. 09 nov. 2017 08:56:21 +0100, wrote:
> > Sorry for the late answer.
> > This fix fixes the crashes.
>
> Cool :)
Nice catch :).
--
Richard Braun
linux/dev/glue/block.c:device_write, where the
local vm_map_copy object may be discarded while still uninitialized.
Probably unrelated but still noteworthy.
--
Richard Braun
On Sat, Aug 26, 2017 at 09:38:39AM +0200, Joan Lledó wrote:
> The Google Summer of Code is about to end and it is time to summarize my work
> on the lwip translator.
Excellent work, one of the best GSoC projects I've seen.
--
Richard Braun
k isn't trivial, IOW it really
needs careful review.
--
Richard Braun
e thread.
Cancellability and interruptibility are two different things. In
particular, note how POSIX explicitely mentions that "These functions
shall not return an error code of [EINTR]."
--
Richard Braun
h kernels as packaged by Debian.
This was fixed by 1aa4ed6aaf69002b3bb7daed49cea8fa71536b66.
--
Richard Braun
t another Svante screw up.
--
Richard Braun
a severe bug that made
it very slow [1]. What would I have done ? Well I fixed it [2], a work
of over a year because it required the Hurd code to switch from its
native cthreads to pthreads [3]. I dare you to do the same.
--
Richard Braun
[1] https://www.gnu.org/softw
t is
likely to fix the issue soon. Unless you really want to work on those
red-black trees, stop pinging about this issue.
--
Richard Braun
[1] https://lwn.net/Articles/673724/
[2]
https://git.sceen.net/hurd/gnumach.git/commit/?id=1db202eb8406785500f1bc3ceef7868566e416a1
On Fri, Dec 02, 2016 at 10:43:04AM +0100, Samuel Thibault wrote:
> Or simply
>
> (d[i].reply_port != MACH_PORT_NULL))
Aren't there cases where an entry could remain uninitialized ?
--
Richard Braun
hose, add
deb http://ftp.sceen.net/debian sid main
to sources.list, and add the GPG key D50E6AD4 to APT.
--
Richard Braun
he problem is caused by the lack
of threshold on the number of dirty pages.
--
Richard Braun
ble to correctly reclaim
these pages in the past, but now there are a lot more of them.
--
Richard Braun
, it quits and I see the on the console.
> >I've seen this on Virtualbox, but now i have it on qemu with the same
> >behavior.
>
> the behaviour is similar to mine then.
I never use the curse based interface of aptitude.
--
Richard Braun
On Mon, Nov 14, 2016 at 04:52:25PM +0100, Richard Braun wrote:
> > (btw: can you read out these values later on, with a command similar to
> > dmesg? pausing VirtualBOX and typing out things is boring)
Ah, by the way, practically none of us run the Hurd on VirtualBox, and
it'
e default
mach console, with a single terminal only.
--
Richard Braun
something wrong, I guess it is not in the usage of aptitude
> itself, but more in something in my HURD setup?
I don't think you're doing something "wrong", I think we (the developers)
know the system enough to avoid most of the caveats. But yes, it's
probably caused by a Hurd defect.
--
Richard Braun
d upgrade without too much trouble with aptitude. I
use it on all my machines, Linux and Hurd, and never have such issues.
--
Richard Braun
e) was very recently
fixed [1] with regard to paging.
--
Richard Braun
[1]
https://git.sceen.net/hurd/hurd.git/commit/?id=81fb68fee81769d81c373e3af5a508d706b7e3d6
here is
> nothing to download and it will hang again.
Are you logged in locally or through SSH ?
--
Richard Braun
On Mon, Nov 07, 2016 at 02:49:35PM +0100, Richard Braun wrote:
> So, what's your version of GNU Mach ? And how much memory do you have
> on your system ?
We also know network can just randomly hang because of bugs in the
netdde server.
--
Richard Braun
such problem. On the other hand, the Hurd
may be hanging. Using aptitude can lead to large memory usage, which
can increase swap usage, and fill kernel memory (in older kernels at
least).
So, what's your version of GNU Mach ? And how much memory do you have
on your system ?
--
Richard Braun
On Thu, Oct 27, 2016 at 05:49:17PM +0200, Samuel Thibault wrote:
> Richard, in 5ab5d98fa515cd19a64e8d5868fcbae85eec9dc5 ('libdiskfs: fix
> removal of socket nodes') you patched diskfs_nput. Doesn't the fix need
> to be done on diskfs_nrele too?
I'd say so, yes.
--
Richard Braun
be OK to move the
> release date towards end of November? (Yay, one more month for getting
> stuff finished for inclusion...) ;'-\
Congratulations :-).
--
Richard Braun
aying it's not that hard.
--
Richard Braun
lexity in
understanding and following the code. You should either go with C for
excellent control, or another higher level langguage for e.g. user
interfaces and tasks that don't require the highest performance.
I really don't think the problem you describe would be so hard to solve
in
ltimate recipient can see which one
> was used.)
This seems overly complicated and error-prone.
Besides, I still don't understand the issue that MACH_SEND_LIFO
would solve...
--
Richard Braun
nd GNU/Hurd, modulo the
> Hurd-specific patches.
The real problem is that we still have nothing about mlockall... Until
we have, there is really not much to talk about.
--
Richard Braun
rtainly very limited and local. The design of the system simply
doesn't need that feature. I completely understand the hassle you'd
have to go through for this and I don't really see the benefit, so
my opinion would be go ahead.
--
Richard Braun
vers --
> including auth -- rather than separate ones for each node?...
I would think it best to make that a distributed process.
--
Richard Braun
don't know if that's already the case or not since Justus' work on
/proc/mounts. The work required here is to rely on the parent to report
whether a node is a separate file system. This could also break programs
assuming a file system is a directory if the attached translator
presents itself as something else.
--
Richard Braun
of his own processes? Something like adding
> directories to your own PATH, but this would apply to translators running
> under different UIDs, and not just programs that you started yourself?
My current idea is something like Plan9 factotum, an agent that would
be used by any program, client or server, to validate that it's safe to
communicate through a given port.
--
Richard Braun
of
it. What I want is to safely extend that trust to other users (root and
self should be default), and again, to other properties (like POSIX
style capabilities). And I'd like to merely avoid contact with servers
that aren't part of this trust computing base.
We'd also have to make sure that remove()/unlink()/rmdir() don't cross
the file system into the untrusted translator.
--
Richard Braun
;passive translators" to more
accurately reflect what they truely are.
The solution, whatever it is, should focus only on determining whether
a server can be trusted or not. This should affect everything (servers,
(active) translators and translator records).
--
Richard Braun
authentication issue.
>
> Comments?
I'm not completely familiar with the inner workings of the auth
server but they look easy enough to imagine. Still, an opinion
from someone more familiar with it like Olaf would be great.
>From what I've read, it looks good. I can't imagine a scenario that
would defeat your assertions.
--
Richard Braun
ing back to the idea of using a thread pool. If a
mach_msg call succeeds, good for you, grab the next message. If not,
at least you're not affecting other users, except maybe through a
denial of service, the only kind of security issue inevitable with
a design where servers allocate from their own resources on behalf
of their clients. That's when you get to things like quotas and
resource limits.
--
Richard Braun
On Fri, Sep 02, 2016 at 01:18:26AM +0200, Richard Braun wrote:
> In my opinion, your network server should do what all servers do,
> i.e. dedicate a thread to the processing of a complete RPC and spawn
> as many as necessary when receiving messages.
At least for RPCs. Is there a wa
e
passing, not the server operation itself. In this case, the server is
the kernel, and the vm_map call itself has no associated timeout.
In my opinion, your network server should do what all servers do,
i.e. dedicate a thread to the processing of a complete RPC and spawn
as many as necessary when receiving messages.
--
Richard Braun
On Thu, Sep 01, 2016 at 11:54:20AM -1000, Brent W. Baccala wrote:
> On Thu, Sep 1, 2016 at 10:28 AM, Richard Braun wrote:
> > I completely disagree.
>
> Thank you, Richard. Really! Thank you for disagreeing. Now we can have a
> good discussion about this!
This is how it
lowing the
transaction to be interrupted (usually with a - hardcoded ? check
how glibc handles Ctrl-C/SIGINT during an RPC - 3 seconds grace
delay before brutal interruption) may be the only things required
to make the behaviour comply with "Hurdish expectations".
--
Richard Braun
p-less case more
efficient by carefully copying the data. I didn't insist on
COW zero-copy for no reason.
--
Richard Braun
On Mon, Aug 29, 2016 at 03:58:29PM -1000, Brent W. Baccala wrote:
> On Sun, Aug 28, 2016 at 11:15 PM, Richard Braun wrote:
> > OK, this comes from the fact that io_map directly provides memory
> > objects indeed... Do we actually want to pass them around ? How
>
On Mon, Aug 29, 2016 at 11:20:47AM +0200, Richard Braun wrote:
> In addition, I've just thought about something else : if we handle
> multiple clients, how do we make sure that two kernels, caching the
> same file, don't just completely corrupt its content ? We'd need
>
he file being mapped more than
once I suppose, right ?
--
Richard Braun
a good
thing that any unprivileged client is allowed to perform memory
object management calls...
--
Richard Braun
_avoid_ mmap, and copy the data in instead,
possibly (and in this case probably) with zero-copy.
Finally, I fail to see how making libpager handle multiple clients
will solve that issue. The only client should be the local kernel,
right ?
--
Richard Braun
On Thu, Aug 25, 2016 at 12:20:45PM +0200, Richard Braun wrote:
> I started thinking about these only a couple of weeks ago, and so far
> the only solutions my limited brain can come up with is to either use
> the client context (by perhaps passing its root) but that could cause
> sec
behaviour.
I started thinking about these only a couple of weeks ago, and so far
the only solutions my limited brain can come up with is to either use
the client context (by perhaps passing its root) but that could cause
security issues, or have a third-party like auth (or proc or whatever)
store enough of this context that the server can use it.
--
Richard Braun
iew and merge it.
Congratulations :)
--
Richard Braun
uthenticate.
That's a very interesting problem indeed, not sure how to fix it.
--
Richard Braun
mory compiler barrier at the
> function call anyway).
My thinking was rather to let gcc know that memory is being read so
that it wouldn't generate instructions that might change it in
parallel, although I don't think it's possible considering the
instructions actually used.
--
Richard Braun
1 - 100 of 595 matches
Mail list logo
