Re: problems with a subhurd

Hello, Brent W. Baccala, on Wed 31 Aug 2016 13:35:07 -1000, wrote: >   Also, after fixing bug #1, this screws up startup's attempt to start a new > shell if the old one dies. Note that even on success, "try" is incremented, i.e. /bin/shd is tried instead of the shell. > Maybe startup shouldn't

Re: [PATCH] i386: Omit pmap workaround on i486 or later.

Hello, Masanori Ogino, on Sat 09 Jul 2016 17:00:35 +0900, wrote: > (I couldn't find any page describing the i386 bug, though. Probably > there were certain revisions with the bug but the others worked fine.) See test_wp_bit() on Linux: “It isn't supported on 386's and also on some strange

problems with a subhurd

Aloha - While testing the exec server, I setup a very minimalist subhurd using just the most essential files, as opposed to copying the entire filesystem, and uncovered a number of bugs. I've refined the process into a shell script (attached) which creates the subhurd on a ramdisk and then boots

[bug #48456] mig-generated user code does not destroy invalid reply

Follow-up Comment #1, bug #48456 (project hurd): I wrote: "This could perhaps be used for denial of service, if a long-lived process calls a less-trusted one." The exec server is a long-lived process, and it calls several RPC routines on the FILE and OLDTASK passed to exec_exec, which can be

Re: RFC: [PATCH] Fix setpriority calling __task_priority() for processes instead of threads.

Svante Signell, on Wed 31 Aug 2016 14:10:22 +0200, wrote: > On Wed, 2016-08-31 at 13:51 +0200, Samuel Thibault wrote: > > Svante Signell, on Wed 31 Aug 2016 13:42:58 +0200, wrote: > > > > > >  > > > Which is the original bug then? > > You didn't say what application you are actually trying to

Re: RFC: [PATCH] Fix setpriority calling __task_priority() for processes instead of threads.

On Wed, 2016-08-31 at 13:51 +0200, Samuel Thibault wrote: > Svante Signell, on Wed 31 Aug 2016 13:42:58 +0200, wrote: > > > >  > > Which is the original bug then? > You didn't say what application you are actually trying to fix, but the > issue you have shown is that task_priority returns

Re: RFC: [PATCH] Fix setpriority calling __task_priority() for processes instead of threads.

On Wed, 2016-08-31 at 13:28 +0200, Samuel Thibault wrote: > Svante Signell, on Wed 31 Aug 2016 13:24:34 +0200, wrote: > >  > > > > > > Re-read your test again: it requests nice -19, i.e. something which is > > > reserved to root. No wonder you are getting a permission denied. > > Explain please,

Re: RFC: [PATCH] Fix setpriority calling __task_priority() for processes instead of threads.

Svante Signell, on Wed 31 Aug 2016 13:24:34 +0200, wrote: > On Wed, 2016-08-31 at 12:58 +0200, Samuel Thibault wrote: > > Svante Signell, on Wed 31 Aug 2016 12:35:26 +0200, wrote: > > > > > > The attached patch changes this fixing the previous: > > > check_setpriority: can't set priority:

Re: RFC: [PATCH] Fix setpriority calling __task_priority() for processes instead of threads.

On Wed, 2016-08-31 at 12:58 +0200, Samuel Thibault wrote: > Svante Signell, on Wed 31 Aug 2016 12:35:26 +0200, wrote: > > > > The attached patch changes this fixing the previous: > > check_setpriority: can't set priority: Permission denied > > > > -   prierr = __task_priority (task,

Re: RFC: [PATCH] Fix setpriority calling __task_priority() for processes instead of threads.

Svante Signell, on Wed 31 Aug 2016 12:35:26 +0200, wrote: > The attached patch changes this fixing the previous: > check_setpriority: can't set priority: Permission denied > > - prierr = __task_priority (task, NICE_TO_MACH_PRIORITY (prio), 1); > + prierr = __task_priority (task,

RFC: [PATCH] Fix setpriority calling __task_priority() for processes instead of threads.

Hi, Attached is a patch for the call of __task_priority() in sysdeps/mach/hurd/setpriority.c. According to setpriority(2) and POSIX the nice value should be per-process not per-thread. According to: http://pubs.opengroup.org/onlinepubs/009695399/functions/getpriori ty.html The nice value set with