Hi,
On Fri, Nov 04, 2016 at 12:14:27PM -1000, Brent W. Baccala wrote:
> How do we want to handle fixed bugs, like this gsync problem? Should we
> open and close a bug report, just so it's documented in the bug database?
> I can open the bug, of course, but I don't have permission to close it...
On Fri, Nov 4, 2016 at 12:00 AM, Samuel Thibault
wrote:
> Brent W. Baccala, on Thu 03 Nov 2016 15:51:04 -1000, wrote:
> > I see... so there must be fallback code (option 2 on my list); I just
> haven't
> > found it.
> >
> > Where is KERN_FAILURE handled in user space?
>
> It's not. Gsync_wait jus
Brent W. Baccala, on Thu 03 Nov 2016 15:51:04 -1000, wrote:
> I see... so there must be fallback code (option 2 on my list); I just haven't
> found it.
>
> Where is KERN_FAILURE handled in user space?
It's not. Gsync_wait just returns, and the while loop just tries to take
the lock again.
Samuel
On Thu, Nov 3, 2016 at 2:18 PM, Samuel Thibault
wrote:
> Brent W. Baccala, on Thu 03 Nov 2016 14:12:41 -1000, wrote:
> > I suspect that this ultimately affects just about every program on a
> > Hurd system.
>
> Sure, it's used internally by glibc. But see the commit I made to
> gnumach: that make
Brent W. Baccala, on Thu 03 Nov 2016 14:12:41 -1000, wrote:
> I suspect that this ultimately affects just about every program on a
> Hurd system.
Sure, it's used internally by glibc. But see the commit I made to
gnumach: that makes gnumach return an error. glibc thus doesn't actually
wait, just sp
Hi -
I've been trying to figure what to do with the gsync code. It causes
undefined behavior and occasional kernel panics when rpctrace is used on
gsync_wait and gsync_wake calls. I suspect that this ultimately affects
just about every program on a Hurd system. Even if a program doesn't call
lo
"Brent W. Baccala" writes:
> My new and improved rpctrace is generating kernel panics when run on
> ext2fs. This happens when rpctrace calls gsync_wait, with ext2fs as the
> 'task' argument.
Could gsync_wait be removed from gnumach.defs and replaced with
only a trap that does not take a task_t
Hi -
My new and improved rpctrace is generating kernel panics when run on
ext2fs. This happens when rpctrace calls gsync_wait, with ext2fs as the
'task' argument.
Could you guys look at gnumach's kern/gsync.c, at line 212? It looks to me
like that code tacitly assumes that the 'addr' it's acces
