From: Dan Kegel <dank@kegel.com>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Vitaly Luban <vitaly@luban.org>
Subject: Re: [PATCH][RFC] Signal-per-fd for RT signals
Date: Fri, 14 Sep 2001 18:33:51 -0700 [thread overview]
Message-ID: <3BA2AFFF.C7B8C4DF@kegel.com> (raw)
Vitaly Luban <vitaly@luban.org> wrote:
> Attached patch is an implementation of "signal-per-fd"
> enhancement to kernel RT signal mechanism, AFAIK first
> proposed by A. Chandra and D. Mosberger ...
> which should dramatically increase linux based network
> servers scalability.
> [ Patch lives at http://www.luban.org/GPL/gpl.html ]
I have been using variations on this patch while trying
to benchmark an FTP server at a load of 10000 simultaneous
sessions (at 1 kilobyte/sec each), and noticed a few issues:
1. If a SIGINT comes in, t->files may be null, so where
send_signal() says
if( (info->si_fd < files->max_fds) &&
it should say
if( files && (info->si_fd < files->max_fds) &&
otherwise there will be a null pointer oops.
2. If a signal has come in, and a reference to it is left
in filp->f_infoptr, and for some reason the signal is
removed from the queue without going through collect_signal(),
a stale pointer may be left in filp->f_infoptr, which could
cause a wild pointer oops. There are two places this can happen:
a. if send_signal() returns -EAGAIN because we're out of memory or queue space
b. if user sets the signal handler to SIG_IGN, triggering a call
to rm_sig_from_queue()
I have seen the above problems in the field in my version of the patch,
and written and tested fixes for them. (Ah, the joys of ksymoops.)
3. Any reference to t->files probably needs to be protected by
acquiring t->files->file_lock, else when the file table is
expanded, any filp in use will become stale.
I have seen this problem in my version of the patch, but have not yet tackled it.
Is there any good guidance out there for how the various spinlocks
interact? Documentation/spinlocks.txt and Documentation/DocBook/kernel-locking.tmpl
are the best I've seen so far, but they don't get into specifics about, say,
files->file_lock and task->sigmask_lock. Guess I'll just have to read the source.
Also, while I have verified that the patch significantly reduces
reliable signal queue usage, I have not yet been able to measure
a reduction in CPU time in a real app. Presumably the benefits
are in response time, which I am not set up to measure yet.
This is my first excursion into the kernel, so please be gentle.
- Dan
next reply other threads:[~2001-09-15 1:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-15 1:33 Dan Kegel [this message]
2001-09-15 5:04 ` [PATCH][RFC] Signal-per-fd for RT signals Vitaly Luban
2001-09-15 5:39 ` Dan Kegel
2001-09-15 12:59 ` spin_lock_bh() usage check, please (was: [PATCH][RFC] Signal-per-fd for RT signals) Dan Kegel
2001-09-15 21:20 ` Vitaly Luban
2001-09-15 22:07 ` Dan Kegel
2001-09-16 2:35 ` [PATCH][RFC] Signal-per-fd for RT signals Vitaly Luban
2001-09-16 3:51 ` Dan Kegel
2001-09-22 23:30 ` [PATCH][RFC] Signal-per-fd for RT signals; write_lock_bh(file_lock)? Dan Kegel
-- strict thread matches above, loose matches on Subject: below --
2001-05-19 2:04 [PATCH][RFC] Signal-per-fd for RT signals Vitaly Luban
2001-05-19 21:38 ` Gerold Jury
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3BA2AFFF.C7B8C4DF@kegel.com \
--to=dank@kegel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=vitaly@luban.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).