All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kingsley Cheung <kingsley@aurema.com>
To: Tom Zanussi <zanussi@us.ibm.com>
Cc: Karim Yaghmour <karim@opersys.com>, linux-kernel@vger.kernel.org
Subject: Relayfs Question: Use of relay_reset().  Potential race?
Date: Mon, 18 Apr 2005 11:29:51 +1000	[thread overview]
Message-ID: <20050418012951.GC4846@aurema.com> (raw)
In-Reply-To: <20050323090254.GA10630@aurema.com>

On Wed, Mar 23, 2005 at 08:02:54PM +1100, kingsley@aurema.com wrote:
> Hi 
> 
> I'm using relayfs to relay data from a kernel module to user space on
> a SuSE 2.6.5 kernel.  I'm not absolutely sure what version of relayfs
> has been back ported to it.

Hi Tom,

Could you please have a look at the following use of relay_reset() in
a kernel module as follows (compiled against pre-redux relayfs):

static int
exec_fileop_notify(int rchan_id, struct file *filp, enum relay_fileop op)
{
        if (unlikely(rchan_id != exec_cid)) {
                printk(KERN_ERR "%s - bad file number\n", __FUNCTION__);
                return -EBADF;
        }

        switch (op) {
        case RELAY_FILE_OPEN:
                atomic_inc(&exec_client_cnt);
                break;
        case RELAY_FILE_CLOSE:
                if (atomic_dec_and_test(&exec_client_cnt) == 0)
                        relay_reset(exec_cid); <---
                break;
        default:
                /* do nothing */
                break;
        }

        return 0;
}

Is that legitimate?  The reason I ask is because I've been seeing
garbled oopses with keventd and I've narrowed it to two things:

1) Inadequate locking on my part in the kernel module, which I have
addressed separately.

2) A race with relay_reset() and keventd, which is probably of
interest to you if you're still maintaining the pre-redux patches.

The race is due to the use of INIT_WORK in _reset_relay():

INIT_WORK(&rchan->wake_readers, NULL, NULL);
INIT_WORK(&rchan->wake_writers, NULL, NULL);

However, at the time relay_reset() is called, it is possible that
these work structures are still being used by keventd when under heavy
loads.  The workaround I've used to fix this is to call
flush_scheduled_work() before calling reset_relay() in the kernel
module.  Perhaps that needs to be called in relay_reset() or
_relay_reset()?

As well I'm not sure about the uses of INIT_WORK in
_relay_realloc_buffer() and relay_release() - perhaps they need
attention too.  I understand, however, that flush_schedule_work()
blocks and thus it probably shouldn't be used in certain areas of the
relayfs code.

My thanks,
-- 
		Kingsley

  parent reply	other threads:[~2005-04-18  1:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-23  9:02 read() on relayfs channel returns premature 0 kingsley
2005-03-23 15:29 ` Tom Zanussi
2005-03-24  1:29   ` Kingsley Cheung
2005-03-24  6:56     ` Jan Engelhardt
2005-03-24 19:11     ` Tom Zanussi
2005-03-24 19:45       ` Jan Engelhardt
2005-03-25 12:27         ` Karim Yaghmour
2005-03-28 23:43       ` Kingsley Cheung
2005-04-18  1:29 ` Kingsley Cheung [this message]
2005-04-18 15:56   ` Relayfs Question: Use of relay_reset(). Potential race? Tom Zanussi
2005-04-19  0:40     ` Kingsley Cheung
2005-05-04  9:04       ` kingsley

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=20050418012951.GC4846@aurema.com \
    --to=kingsley@aurema.com \
    --cc=karim@opersys.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zanussi@us.ibm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.