I agree that it probably needs to be completely re-written if it were
to be generally useable. But, given that the only real use-case we
have for it so far is make(1) (and even then, only in "meta-mode"), I
think that the re-write effort far out-weighs the benefits.
right, i agree.
it's still
Paul Goyette writes:
> > i don't think that filemon(4) is done properly or at the right
> > layers. it should hook directly into the vfs layer itself, not
> > hijack system calls. it certainly still doesn't work properly
> > for netbds32 binaries or any other binaries.
> >
> > your changes are he
i don't think that filemon(4) is done properly or at the right
layers. it should hook directly into the vfs layer itself, not
hijack system calls. it certainly still doesn't work properly
for netbds32 binaries or any other binaries.
your changes are helpful, but it's still very very broken.
I
> >> - filemon(4) is utterly broken. it literally replaces the sysent
> >> values for the current emulation while active. so it has an ugly
> >> obvious problem with runtime usage (particularly at unload.)
> >> however, a much bigger problem is that it adjusts an emulation
> >> that might
On Sun, 22 Nov 2015, Masao Uebayashi wrote:
On Wed, Nov 18, 2015 at 3:18 PM, matthew green wrote:
there's a fairly significant problem with this implementation.
you're only catching callers who use end up going through sy_call()
and that's not the majority. mostly they're called directly fro
On Wed, Nov 18, 2015 at 3:18 PM, matthew green wrote:
>> >>> there's a fairly significant problem with this implementation.
>> >>>
>> >>> you're only catching callers who use end up going through sy_call()
>> >>> and that's not the majority. mostly they're called directly from
>> >>> MD code. so
On Thu, Nov 19, 2015 at 10:30 PM, Eric Haszlakiewicz wrote:
> On November 19, 2015 4:28:46 AM EST, Paul Goyette
> wrote:
>>And if there's anyone who really understands HOW the initial syscall
>>gets interrupted when the signal is being delivered (and HOW it gets
>>restarted when the handler retu
On Thu, Nov 19, 2015 at 1:43 PM, Paul Goyette wrote:
> On Thu, 19 Nov 2015, Masao Uebayashi wrote:
>
>> On Wed, Nov 18, 2015 at 11:07 AM, Paul Goyette
>> wrote:
>>>
>>> Based on earlier comments, I've come up with a much-less-intrusive
>>> set of changes. This time around, there are no bit masks
On November 19, 2015 4:28:46 AM EST, Paul Goyette
wrote:
>And if there's anyone who really understands HOW the initial syscall
>gets interrupted when the signal is being delivered (and HOW it gets
>restarted when the handler returns) I would love an explanation!
>
Regarding restart, I don't thin
My understanding is that l_sysent is *always* overriden by syscalls
from within signal handlers, right?
It's not a question of "being overwritten". The real situation is
that the _initial_ syscall returns first (with ERESTART), and l_sysent
is reset to NULL. Then when the signal handler calls
On Thu, 19 Nov 2015, Masao Uebayashi wrote:
On Wed, Nov 18, 2015 at 11:07 AM, Paul Goyette wrote:
Based on earlier comments, I've come up with a much-less-intrusive
set of changes. This time around, there are no bit masks and no new
members in any system structures. (I'm pretty sure we won't
On Wed, Nov 18, 2015 at 11:07 AM, Paul Goyette wrote:
> Based on earlier comments, I've come up with a much-less-intrusive
> set of changes. This time around, there are no bit masks and no new
> members in any system structures. (I'm pretty sure we won't even
> need a kernel version bump for thi
> >>> there's a fairly significant problem with this implementation.
> >>>
> >>> you're only catching callers who use end up going through sy_call()
> >>> and that's not the majority. mostly they're called directly from
> >>> MD code. so to fix that, you have to update every platform syscall
> >
Based on earlier comments, I've come up with a much-less-intrusive
set of changes. This time around, there are no bit masks and no new
members in any system structures. (I'm pretty sure we won't even
need a kernel version bump for this.)
Instead, I've modified sy_call() to check the current val
On Tue, 17 Nov 2015, Paul Goyette wrote:
there's a fairly significant problem with this implementation.
you're only catching callers who use end up going through sy_call()
and that's not the majority. mostly they're called directly from
MD code. so to fix that, you have to update every platfo
On Tue, 17 Nov 2015, matthew green wrote:
Martin Husemann writes:
On Tue, Nov 17, 2015 at 05:48:17PM +1100, matthew green wrote:
it also slows down normal operation adding branches and data access
to the call path of every system call. and bloats struct lwp and
more.
At least all operations
On Tue, 17 Nov 2015, matthew green wrote:
additional problems i've realised:
- this should be process specific, not LWP specific.
- we might need some way to copy this across fork().
- as l_sysent seems unreliable, we should just remove it.
l_sysent serves another purpose: it is used to re
On Tue, 17 Nov 2015, Martin Husemann wrote:
On Tue, Nov 17, 2015 at 05:48:17PM +1100, matthew green wrote:
it also slows down normal operation adding branches and data access
to the call path of every system call. and bloats struct lwp and
more.
At least all operations on the syscall pathes
On Tue, 17 Nov 2015, matthew green wrote:
there's a fairly significant problem with this implementation.
you're only catching callers who use end up going through sy_call()
and that's not the majority. mostly they're called directly from
MD code. so to fix that, you have to update every plat
Martin Husemann writes:
> On Tue, Nov 17, 2015 at 05:48:17PM +1100, matthew green wrote:
> > it also slows down normal operation adding branches and data access
> > to the call path of every system call. and bloats struct lwp and
> > more.
>
> At least all operations on the syscall pathes need to
additional problems i've realised:
- this should be process specific, not LWP specific.
- we might need some way to copy this across fork().
- as l_sysent seems unreliable, we should just remove it.
> In a nut-shell, we cannot rely on the struct lwp's l_sysent member
> to determine if a partic
On Tue, Nov 17, 2015 at 05:48:17PM +1100, matthew green wrote:
> it also slows down normal operation adding branches and data access
> to the call path of every system call. and bloats struct lwp and
> more.
At least all operations on the syscall pathes need to be #ifdef MODULAR.
How about just
there's a fairly significant problem with this implementation.
you're only catching callers who use end up going through sy_call()
and that's not the majority. mostly they're called directly from
MD code. so to fix that, you have to update every platform syscall
handler.
it also slows down no
For a detailed discussion of the problem, please read the PR [1]
In a nut-shell, we cannot rely on the struct lwp's l_sysent member
to determine if a particular syscall is "active", since it could be
overwritten during signal handling. As a result, it is possible to
unload modules which have act
24 matches
Mail list logo
