public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: Roland Dreier <rdreier-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
To: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Cc: LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Ralph Campbell
	<infinipath-h88ZbnxC6KDQT0dZR+AlfA@public.gmane.org>
Subject: Re: infiniband BKL leftovers
Date: Sun, 11 Oct 2009 10:42:19 -0700	[thread overview]
Message-ID: <adad44tj090.fsf@cisco.com> (raw)
In-Reply-To: <alpine.LFD.2.00.0910102015400.9428-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> (Thomas Gleixner's message of "Sat, 10 Oct 2009 20:37:20 +0200 (CEST)")

[Adding a few CCs]

 > I'm looking into removing cycle_kernel_lock() from
 > drivers/infiniband/hw/ipath/ipath_file_ops.c .
 > 
 > cycle_kernel_lock() was pushed down into open functions to "emulate"
 > the previous BKL protected semantics by "serializing" the open
 > function against driver init in progress. Nobody knows how effective
 > this "serialization" was in reality. :)
 > 
 > This protection is not necessary when everything what might be needed
 > by write/aio_write/poll/mmap should be in place before
 > ipath_user_add() creates the device node.
 > 
 > But looking at the callsite ipath_init_one() I'm not so sure about that.
 > 
 > At the end of ipath_init_one() I see:
 > 
 >         ipath_device_create_group(&pdev->dev, dd);
 >         ipathfs_add_device(dd);
 >         ipath_user_add(dd);
 >         ipath_diag_add(dd);
 >         ipath_register_ib_device(dd);
 > 
 > ipath_user_add() is called before ipath_register_ib_device() which
 > registers the device with the infiniband core. That makes me wonder
 > whether the device node is really ready to use right after it is
 > created.
 > 
 > Aside of that I noticed that all the functions above have elaborate
 > error pathes, but non of the return values of these functions is ever
 > checked. Intersting approach :)

I guess you guys are getting serious about BKL removal.  I think I made
about as much progress on the ipath driver when the BKL pushdown first
happened: I looked at the code with an eye to getting rid of the BKL and
got too confused and scared to proceed.

I'm not sure what the best way to handle this is; as far as I know the
ipath code is abandoned by Qlogic (they have a new driver that also
supports newer hw that they have not tried to get upstream yet) and BKL
issues aside the code looks racy, eg

	if (atomic_inc_return(&user_count) == 1) {
		ret = user_init();

makes sure that only one thread does user_init() but it doesn't make
sure that user_init() finishes before another thread proceeds.

So I guess if the BKL stuff is blocking you in any way, we can just drop
it from ipath and leave it as yet another race condition in a rotting
old driver.

 - R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

       reply	other threads:[~2009-10-11 17:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <alpine.LFD.2.00.0910102015400.9428@localhost.localdomain>
     [not found] ` <alpine.LFD.2.00.0910102015400.9428-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2009-10-11 17:42   ` Roland Dreier [this message]
     [not found]     ` <adad44tj090.fsf-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
2009-10-11 19:27       ` infiniband BKL leftovers Roland Dreier
     [not found]         ` <ada8wfhivdd.fsf-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
2009-10-11 19:52           ` Thomas Gleixner

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=adad44tj090.fsf@cisco.com \
    --to=rdreier-fyb4gu1cfyuavxtiumwx3w@public.gmane.org \
    --cc=infinipath-h88ZbnxC6KDQT0dZR+AlfA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.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