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
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, NICE_T
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, NICE_TO_MAC
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: Permissi
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, I
Svante Signell, on Wed 31 Aug 2016 13:42:58 +0200, wrote:
> 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
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 permissi
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 fix,
Samuel Thibault, on Tue 16 Aug 2016 22:57:04 +0200, wrote:
> Thomas Schwinge, on Fri 05 Aug 2016 09:27:00 +0200, wrote:
> > On Mon, 30 May 2016 23:59:33 +0200, Samuel Thibault
> > wrote:
> > > Justus Winter, on Wed 18 May 2016 13:27:13 +0200, wrote:
> > > > As Richard said in #hurd, implement mlo
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 call
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
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 486's.
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
13 matches
Mail list logo
