public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Tony Battersby <tonyb@cybernetics.com>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Greg KH <greg@kroah.com>,
	FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	dgilbert@interlog.com, James.Bottomley@HansenPartnership.com,
	hch@infradead.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH 0/2] sg: fix races during device removal (v2)
Date: Thu, 15 Jan 2009 16:43:37 -0500	[thread overview]
Message-ID: <496FAE09.2040207@cybernetics.com> (raw)
In-Reply-To: <496FA001.1000501@s5r6.in-berlin.de>

Stefan Richter wrote:
> What are locks for?
>
> They serialize accesses to data, in order to protect the data from
> invalid modifications due to concurrent accesses.
>   
...
> What are reference counters for?
>
> Well, the name says it.  I'd better ask:  What is reference counting
> for?  Of course to prevent premature destruction of objects; IOW to
> implement lifetime rules.
>
> Locks don't implement lifetime rules.  They only implement serialization
> of accesses.
>
>   
...
> In your case, you want to extend sg_index_lock's purposes to also
> serialize access to a state variable of the sg device objects.  Nothing
> wrong with that, as long as you and, later on, readers of your code are
> aware what is going on.
>
>   

OK, so your argument now seems to be that the code just might in
practice work correctly, but in theory it is not philosophically right,
semantically pure, or politically correct because it uses fundamental
programming constructs in odd ways that are not the "right" ways taught
in CS courses that everyone understands and loves.  That is a valid
viewpoint I suppose, but I tend to be much more pragmatic.  BTW, you
might want to do a quick grep of the kernel source for all users of
atomic_inc_not_zero() and make sure they all follow the established CS
curricula:

net/netfilter/nf_conntrack_expect.c:

struct nf_conntrack_expect *
nf_ct_expect_find_get(struct net *net, const struct nf_conntrack_tuple *tuple)
{
	struct nf_conntrack_expect *i;

	rcu_read_lock();
	i = __nf_ct_expect_find(net, tuple);
	if (i && !atomic_inc_not_zero(&i->use))
		i = NULL;
	rcu_read_unlock();

	return i;
}

void nf_ct_expect_put(struct nf_conntrack_expect *exp)
{
	if (atomic_dec_and_test(&exp->use))
		call_rcu(&exp->rcu, nf_ct_expect_free_rcu);
}


fs/nfs/nfs4state.c:

static struct nfs4_state *
__nfs4_find_state_byowner(struct inode *inode, struct nfs4_state_owner *owner)
{
	struct nfs_inode *nfsi = NFS_I(inode);
	struct nfs4_state *state;

	list_for_each_entry(state, &nfsi->open_states, inode_states) {
		if (state->owner != owner)
			continue;
		if (atomic_inc_not_zero(&state->count))
			return state;
	}
	return NULL;
}

struct nfs4_state *
nfs4_get_open_state(struct inode *inode, struct nfs4_state_owner *owner)
{
	struct nfs4_state *state, *new;
	struct nfs_inode *nfsi = NFS_I(inode);

	spin_lock(&inode->i_lock);
	state = __nfs4_find_state_byowner(inode, owner);
	spin_unlock(&inode->i_lock);
	...
}

void nfs4_put_open_state(struct nfs4_state *state)
{
	struct inode *inode = state->inode;
	struct nfs4_state_owner *owner = state->owner;

	if (!atomic_dec_and_lock(&state->count, &owner->so_lock))
		return;
	spin_lock(&inode->i_lock);
	list_del(&state->inode_states);
	list_del(&state->open_states);
	spin_unlock(&inode->i_lock);
	spin_unlock(&owner->so_lock);
	iput(inode);
	nfs4_free_open_state(state);
	nfs4_put_state_owner(owner);
}


... etc.  But I'm sure all those silly network and RCU developers didn't
understand what they were doing.

I would still like for some other people to weigh in with their opinions
before I spend more effort on another patch or else push forward with
kref_get_not_zero().

Tony

  reply	other threads:[~2009-01-15 21:43 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-05 19:07 [PATCH 0/2] sg: fix races during device removal (v2) Tony Battersby
2009-01-08 23:21 ` Douglas Gilbert
2009-01-10 17:26 ` FUJITA Tomonori
2009-01-12 21:09   ` Tony Battersby
2009-01-13 16:24     ` FUJITA Tomonori
2009-01-14 20:31   ` Tony Battersby
2009-01-14 21:39     ` Greg KH
2009-01-14 21:59       ` Tony Battersby
2009-01-14 22:33       ` Stefan Richter
2009-01-14 22:53         ` Tony Battersby
2009-01-14 23:47           ` Stefan Richter
2009-01-15 14:47             ` Tony Battersby
2009-01-15 16:22               ` Stefan Richter
2009-01-15 16:44                 ` Stefan Richter
2009-01-15 18:17                 ` Tony Battersby
2009-01-15 18:47                   ` Stefan Richter
2009-01-15 19:14                     ` Stefan Richter
2009-01-15 19:20                     ` Tony Battersby
2009-01-15 20:43                       ` Stefan Richter
2009-01-15 21:43                         ` Tony Battersby [this message]
2009-01-15 21:58                           ` Stefan Richter
2009-01-15 22:23                             ` Tony Battersby
2009-01-15 23:24                               ` Stefan Richter
2009-01-16 14:16                                 ` Tony Battersby
2009-01-16  0:53                           ` Stefan Richter
2009-01-16  8:09                 ` Stefan Richter
2009-01-19  6:57     ` FUJITA Tomonori
2009-01-19 15:02       ` Tony Battersby
2009-01-19 23:03       ` [PATCH 1/2] sg: fix races during device removal (v4) Tony Battersby
2009-01-20  1:06         ` FUJITA Tomonori
2009-01-20 21:58           ` [PATCH 1/2] sg: fix races during device removal (v5) Tony Battersby
2009-01-21 18:25             ` Stefan Richter
2009-01-21 19:23               ` Tony Battersby
2009-01-21 19:45             ` [PATCH 1/2] sg: fix races during device removal (v6) Tony Battersby
2009-01-25 12:46               ` FUJITA Tomonori
2009-01-26 13:57               ` Douglas Gilbert
2009-01-28  1:51                 ` FUJITA Tomonori
2009-01-28 15:06                   ` James Bottomley
2009-01-20 22:00           ` [PATCH 2/2] sg: fix races with ioctl(SG_IO) (v2) Tony Battersby
2009-01-25 12:46             ` FUJITA Tomonori
2009-01-19 23:06       ` [PATCH 2/2] sg: fix races with ioctl(SG_IO) Tony Battersby

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=496FAE09.2040207@cybernetics.com \
    --to=tonyb@cybernetics.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=dgilbert@interlog.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=greg@kroah.com \
    --cc=hch@infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=stefanr@s5r6.in-berlin.de \
    /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