All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Teigland <teigland@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] Cluster Project branch, STABLE2, updated. cluster-2.03.02-7-ga6b6a30
Date: Wed, 14 May 2008 08:33:25 -0500	[thread overview]
Message-ID: <20080514133325.GA27940@redhat.com> (raw)
In-Reply-To: <1210755371.3402.9.camel@localhost.localdomain>

On Wed, May 14, 2008 at 09:56:11AM +0100, Steven Whitehouse wrote:
> Hi,
> 
> On Tue, 2008-05-13 at 15:13 -0500, David Teigland wrote:
> > On Tue, May 13, 2008 at 09:01:13PM +0100, Steven Whitehouse wrote:
> > > Hi,
> > > 
> > > It might be a silly question, but this looks to me like trying to fix a
> > > kernel bug by adding a userland one. Why not simply update the kernel to
> > > return the correct value?
> > 
> > Yes, there's already a kernel fix in dlm.git, see
> >   "dlm: fix plock dev_write return value"
> > 
> > http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/teigland/dlm.git;a=shortlog;h=next
> > 
> > Suppressing the message spamming is a good solution in the mean time, and
> > has a better chance of getting to customers before the kernel patch.
> > 
> I'm afraid you've still not convinced me on this one. Why not just check
> errno as well as the return value, then you can detect both "correct"
> instances and still report errors when they occur.

I really didn't find it worth the time... there are lots of highly
unlikely error conditions that are just not worth logging a message about.
When I'm modifying that code again I'll look at putting back a check.

> Also the kernel fix doesn't look quite right to me. Surely we should be
> reporting the error from dlm_plock_callback() if it occurs, rather than
> just ignoring it?
> 
> In dlm_plock_callback() the return value from "notify()" seems to be
> ignored in one case too.

Errors from notify() are the point where this whole scheme (plocks from
nfs) falls apart.  There's nothing that can be done to recover from an
error there, and the nfs people basically have to wait indefinitely for
the notify to make sure it never causes an error.  Logging the error is
the best we can do.

> I spotted this while looking at the code:
> 
> struct plock_xop {
>         struct plock_op xop;
>         void *callback;
>         void *fl;
>         void *file;
>         struct file_lock flc;
> };
> 
> and I can't see the need for void pointers here, why not just use the
> correct types? It looks like this code could do with some cleanup,

I don't know, it doesn't look like they need to be void.  Marc Eshel
<eshel@almaden.ibm.com> is the one to ask, he added the support for nfs
plocks.



      reply	other threads:[~2008-05-14 13:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-13 19:08 [Cluster-devel] Cluster Project branch, STABLE2, updated. cluster-2.03.02-7-ga6b6a30 teigland
2008-05-13 20:01 ` Steven Whitehouse
2008-05-13 20:13   ` David Teigland
2008-05-14  8:56     ` Steven Whitehouse
2008-05-14 13:33       ` David Teigland [this message]

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=20080514133325.GA27940@redhat.com \
    --to=teigland@redhat.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.