On Thursday 08 March 2007 18:28, Linus Torvalds wrote:
> The sad part is that there really is no reason why the BSD crowd couldn't
> have done recvmsg() as an "extended read with per-system call flags",
> which would have made things like O_NONBLOCK etc unnecessary, because you
> could do it
On Thursday 08 March 2007 18:28, Linus Torvalds wrote:
The sad part is that there really is no reason why the BSD crowd couldn't
have done recvmsg() as an extended read with per-system call flags,
which would have made things like O_NONBLOCK etc unnecessary, because you
could do it just
On Thu, 8 Mar 2007, David M. Lloyd wrote:
> On Wed, 2007-03-07 at 17:21 -0800, Davide Libenzi wrote:
> > int signalfd_dequeue(int fd, siginfo_t *info, long timeo);
> >
> > The "fd" parameter must ba a signalfd file descriptor. The "info" parameter
> > is a pointer to the siginfo that will
On 3/8/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
Which is why you introduced a new system call, but that leads to all the
problems with the file descriptor no longer being *usable*.
Think scripts. It's easy to do reads in perl scripts, and parse the
output. In contrast, making perl use a
On 3/8/07, Linus Torvalds [EMAIL PROTECTED] wrote:
Which is why you introduced a new system call, but that leads to all the
problems with the file descriptor no longer being *usable*.
Think scripts. It's easy to do reads in perl scripts, and parse the
output. In contrast, making perl use a new
On Thu, 8 Mar 2007, David M. Lloyd wrote:
On Wed, 2007-03-07 at 17:21 -0800, Davide Libenzi wrote:
int signalfd_dequeue(int fd, siginfo_t *info, long timeo);
The fd parameter must ba a signalfd file descriptor. The info parameter
is a pointer to the siginfo that will receive the
On Fri, 9 Mar 2007, Oleg Nesterov wrote:
> Ugh. Still can't understand, probably I missed something or misread this
> patch.
>
> If we shift signalfd_notify() from
> specific_send_sig_info/__group_send_sig_info
> to send_signal(), we have the same "list_empty()" fastpath if no signalfds are
>
On 03/08, Davide Libenzi wrote:
>
> On Fri, 9 Mar 2007, Oleg Nesterov wrote:
>
> > > Logic is, if it's not an RT signal, queue only one, otherwise multiple.
> > > The bit on the ->pending mask is clealer only when the queue slot becomes
> > > empty.
> >
> > Yes, I see what the code does, but I
On Thu, 8 Mar 2007, Jeremy Fitzhardinge wrote:
>
> The difficulty is that there are 4 different formats of signal structure
> you could get: (traditional|siginfo) x (32bit|64bit).
See my suggestion of a fixed-format (and much cleaned up) pseudo-siginfo
thing earlier in this thread, and also
Linus Torvalds wrote:
> So I think you should get rid of signalfd_dequeue(), and just replace it
> with a "read()" function.
>
The difficulty is that there are 4 different formats of signal structure
you could get: (traditional|siginfo) x (32bit|64bit).
What happens if you're a 32 bit
On Fri, 9 Mar 2007, Oleg Nesterov wrote:
> > Logic is, if it's not an RT signal, queue only one, otherwise multiple.
> > The bit on the ->pending mask is clealer only when the queue slot becomes
> > empty.
>
> Yes, I see what the code does, but I don't undestand why. For example,
> SIGCHLD was
On Thu, 8 Mar 2007, Linus Torvalds wrote:
>
>
> On Fri, 9 Mar 2007, Oleg Nesterov wrote:
> >
> > Also. A malicious user can eat all memory,
> > signalfd_deliver()->kmem_cache_alloc()
> > doesn't check any limits.
>
> This, btw, is one reason I *really* think signalfd() should just use the
>
On Fri, 9 Mar 2007, Oleg Nesterov wrote:
>
> Also. A malicious user can eat all memory,
> signalfd_deliver()->kmem_cache_alloc()
> doesn't check any limits.
This, btw, is one reason I *really* think signalfd() should just use the
same old signal queue, and not try to make its own.
Signal
On 03/08, Davide Libenzi wrote:
>
> On Thu, 8 Mar 2007, Oleg Nesterov wrote:
>
> > Davide Libenzi wrote:
> > >
> > > +int signalfd_deliver(struct sighand_struct *sighand, int sig, struct
> > > siginfo *info)
> > > +{
> > > + int nsig = 0;
> > > + struct list_head *pos;
> > > + struct
Linus Torvalds wrote:
On Thu, 8 Mar 2007, Davide Libenzi wrote:
So, to cut it short, I can do the pseudo-siginfo read(2), but I don't
like it too much (little, actually). The siginfo, as bad as it is, is a
standard used in many POSIX APIs (hence even in kernel), and IMO if we
want to send
On Thu, 8 Mar 2007, Oleg Nesterov wrote:
> Davide Libenzi wrote:
> >
> > +int signalfd_deliver(struct sighand_struct *sighand, int sig, struct
> > siginfo *info)
> > +{
> > + int nsig = 0;
> > + struct list_head *pos;
> > + struct signalfd_ctx *ctx;
> > + struct signalfd_sq *sq;
> > +
>
Linus Torvalds wrote:
On Thu, 8 Mar 2007, Davide Libenzi wrote:
So, to cut it short, I can do the pseudo-siginfo read(2), but I don't
like it too much (little, actually). The siginfo, as bad as it is, is a
standard used in many POSIX APIs (hence even in kernel), and IMO if we
want to send
On 3/8/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
So anybody who would "go with the Berkeley crowd" really shows a lot of
bad taste, I'm afraid. The Berkeley crowd really messed up here, and it's
so long ago that I don't think there is any point in us trying to fix it
any more.
Well, they
Davide Libenzi wrote:
>
> +int signalfd_deliver(struct sighand_struct *sighand, int sig, struct siginfo
> *info)
> +{
> + int nsig = 0;
> + struct list_head *pos;
> + struct signalfd_ctx *ctx;
> + struct signalfd_sq *sq;
> +
> + list_for_each(pos, >sfdlist) {
> +
On Thu, 8 Mar 2007, Avi Kivity wrote:
> Davide Libenzi wrote:
> > So, to cut it short, I can do the pseudo-siginfo read(2), but I don't like
> > it too much (little, actually). The siginfo, as bad as it is, is a standard
> > used in many POSIX APIs (hence even in kernel), and IMO if we want to
Davide Libenzi wrote:
So, to cut it short, I can do the pseudo-siginfo read(2), but I don't
like it too much (little, actually). The siginfo, as bad as it is, is a
standard used in many POSIX APIs (hence even in kernel), and IMO if we
want to send that back, a struct siginfo should be.
On Thu, 8 Mar 2007, Linus Torvalds wrote:
>
>
> On Thu, 8 Mar 2007, Davide Libenzi wrote:
> >
> > So, to cut it short, I can do the pseudo-siginfo read(2), but I don't
> > like it too much (little, actually). The siginfo, as bad as it is, is a
> > standard used in many POSIX APIs (hence even
On Thu, 8 Mar 2007, Davide Libenzi wrote:
>
> So, to cut it short, I can do the pseudo-siginfo read(2), but I don't
> like it too much (little, actually). The siginfo, as bad as it is, is a
> standard used in many POSIX APIs (hence even in kernel), and IMO if we
> want to send that back, a
On Thu, 8 Mar 2007, Linus Torvalds wrote:
>
>
> On Thu, 8 Mar 2007, Davide Libenzi wrote:
> >
> > The reason for the special function, was not to provide a non-blocking
> > behaviour with zero timeout (that just a side effect), but to read the
> > siginfo. I was all about using read(2) (and
On Thu, 8 Mar 2007, Michael K. Edwards wrote:
>
> Make it a netlink socket and fetch your structures using recvmsg().
> siginfo_t belongs in ancillary data.
Gaah. That interface is horrible.
> The UNIX philosophy is "everything's a file". The Berkeley philosophy
> is "everything's a socket,
On Thu, 8 Mar 2007, Davide Libenzi wrote:
>
> The reason for the special function, was not to provide a non-blocking
> behaviour with zero timeout (that just a side effect), but to read the
> siginfo. I was all about using read(2) (and v1 used it), but when you have
> to transfer complex
On 3/8/07, Davide Libenzi wrote:
The reason for the special function, was not to provide a non-blocking
behaviour with zero timeout (that just a side effect), but to read the
siginfo. I was all about using read(2) (and v1 used it), but when you have
to transfer complex structures over it, it
On Thu, 8 Mar 2007, Linus Torvalds wrote:
> You missed David's worry, I think.
>
> Not only is POLLIN potentially an edge event (depending on the interface
> you use to fetch it), but even as a level-triggered one you generally want
> to read as much as possible per POLLIN event, and go back
On Thu, 8 Mar 2007, Davide Libenzi wrote:
>
> This patch, if you get a POLLIN, you have a signal to read for sure (well,
> unless you another thread/task reads it before you - but that's just
> somthing you have to take care). There is not explicit check for
> O_NONBLOCK now, but a zero
On Thu, 8 Mar 2007, David M. Lloyd wrote:
> On Wed, 2007-03-07 at 17:21 -0800, Davide Libenzi wrote:
> > int signalfd_dequeue(int fd, siginfo_t *info, long timeo);
> >
> > The "fd" parameter must ba a signalfd file descriptor. The "info" parameter
> > is a pointer to the siginfo that will
On Wed, 2007-03-07 at 17:21 -0800, Davide Libenzi wrote:
> int signalfd_dequeue(int fd, siginfo_t *info, long timeo);
>
> The "fd" parameter must ba a signalfd file descriptor. The "info" parameter
> is a pointer to the siginfo that will receive the dequeued signal, and
> "timeo" is a timeout in
On Thu, 8 Mar 2007, David M. Lloyd wrote:
On Wed, 2007-03-07 at 17:21 -0800, Davide Libenzi wrote:
int signalfd_dequeue(int fd, siginfo_t *info, long timeo);
The fd parameter must ba a signalfd file descriptor. The info parameter
is a pointer to the siginfo that will receive the
On Thu, 8 Mar 2007, Davide Libenzi wrote:
This patch, if you get a POLLIN, you have a signal to read for sure (well,
unless you another thread/task reads it before you - but that's just
somthing you have to take care). There is not explicit check for
O_NONBLOCK now, but a zero timeout
On Thu, 8 Mar 2007, Linus Torvalds wrote:
You missed David's worry, I think.
Not only is POLLIN potentially an edge event (depending on the interface
you use to fetch it), but even as a level-triggered one you generally want
to read as much as possible per POLLIN event, and go back to the
On 3/8/07, Davide Libenzi davidel@xmailserver.org wrote:
The reason for the special function, was not to provide a non-blocking
behaviour with zero timeout (that just a side effect), but to read the
siginfo. I was all about using read(2) (and v1 used it), but when you have
to transfer complex
On Thu, 8 Mar 2007, Davide Libenzi wrote:
The reason for the special function, was not to provide a non-blocking
behaviour with zero timeout (that just a side effect), but to read the
siginfo. I was all about using read(2) (and v1 used it), but when you have
to transfer complex
On Thu, 8 Mar 2007, Michael K. Edwards wrote:
Make it a netlink socket and fetch your structures using recvmsg().
siginfo_t belongs in ancillary data.
Gaah. That interface is horrible.
The UNIX philosophy is everything's a file. The Berkeley philosophy
is everything's a socket, except
On Thu, 8 Mar 2007, Linus Torvalds wrote:
On Thu, 8 Mar 2007, Davide Libenzi wrote:
The reason for the special function, was not to provide a non-blocking
behaviour with zero timeout (that just a side effect), but to read the
siginfo. I was all about using read(2) (and v1 used
On Thu, 8 Mar 2007, Davide Libenzi wrote:
So, to cut it short, I can do the pseudo-siginfo read(2), but I don't
like it too much (little, actually). The siginfo, as bad as it is, is a
standard used in many POSIX APIs (hence even in kernel), and IMO if we
want to send that back, a struct
On Thu, 8 Mar 2007, Linus Torvalds wrote:
On Thu, 8 Mar 2007, Davide Libenzi wrote:
So, to cut it short, I can do the pseudo-siginfo read(2), but I don't
like it too much (little, actually). The siginfo, as bad as it is, is a
standard used in many POSIX APIs (hence even in kernel),
Davide Libenzi wrote:
So, to cut it short, I can do the pseudo-siginfo read(2), but I don't
like it too much (little, actually). The siginfo, as bad as it is, is a
standard used in many POSIX APIs (hence even in kernel), and IMO if we
want to send that back, a struct siginfo should be.
On Thu, 8 Mar 2007, Avi Kivity wrote:
Davide Libenzi wrote:
So, to cut it short, I can do the pseudo-siginfo read(2), but I don't like
it too much (little, actually). The siginfo, as bad as it is, is a standard
used in many POSIX APIs (hence even in kernel), and IMO if we want to send
Davide Libenzi wrote:
+int signalfd_deliver(struct sighand_struct *sighand, int sig, struct siginfo
*info)
+{
+ int nsig = 0;
+ struct list_head *pos;
+ struct signalfd_ctx *ctx;
+ struct signalfd_sq *sq;
+
+ list_for_each(pos, sighand-sfdlist) {
+ ctx =
On 3/8/07, Linus Torvalds [EMAIL PROTECTED] wrote:
So anybody who would go with the Berkeley crowd really shows a lot of
bad taste, I'm afraid. The Berkeley crowd really messed up here, and it's
so long ago that I don't think there is any point in us trying to fix it
any more.
Well, they did
Linus Torvalds wrote:
On Thu, 8 Mar 2007, Davide Libenzi wrote:
So, to cut it short, I can do the pseudo-siginfo read(2), but I don't
like it too much (little, actually). The siginfo, as bad as it is, is a
standard used in many POSIX APIs (hence even in kernel), and IMO if we
want to send
On Thu, 8 Mar 2007, Oleg Nesterov wrote:
Davide Libenzi wrote:
+int signalfd_deliver(struct sighand_struct *sighand, int sig, struct
siginfo *info)
+{
+ int nsig = 0;
+ struct list_head *pos;
+ struct signalfd_ctx *ctx;
+ struct signalfd_sq *sq;
+
+
Linus Torvalds wrote:
On Thu, 8 Mar 2007, Davide Libenzi wrote:
So, to cut it short, I can do the pseudo-siginfo read(2), but I don't
like it too much (little, actually). The siginfo, as bad as it is, is a
standard used in many POSIX APIs (hence even in kernel), and IMO if we
want to send
On 03/08, Davide Libenzi wrote:
On Thu, 8 Mar 2007, Oleg Nesterov wrote:
Davide Libenzi wrote:
+int signalfd_deliver(struct sighand_struct *sighand, int sig, struct
siginfo *info)
+{
+ int nsig = 0;
+ struct list_head *pos;
+ struct signalfd_ctx *ctx;
+ struct
On Fri, 9 Mar 2007, Oleg Nesterov wrote:
Also. A malicious user can eat all memory,
signalfd_deliver()-kmem_cache_alloc()
doesn't check any limits.
This, btw, is one reason I *really* think signalfd() should just use the
same old signal queue, and not try to make its own.
Signal
On Thu, 8 Mar 2007, Linus Torvalds wrote:
On Fri, 9 Mar 2007, Oleg Nesterov wrote:
Also. A malicious user can eat all memory,
signalfd_deliver()-kmem_cache_alloc()
doesn't check any limits.
This, btw, is one reason I *really* think signalfd() should just use the
same old
On Fri, 9 Mar 2007, Oleg Nesterov wrote:
Logic is, if it's not an RT signal, queue only one, otherwise multiple.
The bit on the -pending mask is clealer only when the queue slot becomes
empty.
Yes, I see what the code does, but I don't undestand why. For example,
SIGCHLD was
Linus Torvalds wrote:
So I think you should get rid of signalfd_dequeue(), and just replace it
with a read() function.
The difficulty is that there are 4 different formats of signal structure
you could get: (traditional|siginfo) x (32bit|64bit).
What happens if you're a 32 bit process,
On Thu, 8 Mar 2007, Jeremy Fitzhardinge wrote:
The difficulty is that there are 4 different formats of signal structure
you could get: (traditional|siginfo) x (32bit|64bit).
See my suggestion of a fixed-format (and much cleaned up) pseudo-siginfo
thing earlier in this thread, and also
On 03/08, Davide Libenzi wrote:
On Fri, 9 Mar 2007, Oleg Nesterov wrote:
Logic is, if it's not an RT signal, queue only one, otherwise multiple.
The bit on the -pending mask is clealer only when the queue slot becomes
empty.
Yes, I see what the code does, but I don't undestand
On Fri, 9 Mar 2007, Oleg Nesterov wrote:
Ugh. Still can't understand, probably I missed something or misread this
patch.
If we shift signalfd_notify() from
specific_send_sig_info/__group_send_sig_info
to send_signal(), we have the same list_empty() fastpath if no signalfds are
attached
On Wed, 2007-03-07 at 17:21 -0800, Davide Libenzi wrote:
int signalfd_dequeue(int fd, siginfo_t *info, long timeo);
The fd parameter must ba a signalfd file descriptor. The info parameter
is a pointer to the siginfo that will receive the dequeued signal, and
timeo is a timeout in
56 matches
Mail list logo
