The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Roland Dreier <rdreier@cisco.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: infiniband BKL leftovers
Date: Sat, 10 Oct 2009 20:37:20 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LFD.2.00.0910102015400.9428@localhost.localdomain> (raw)

Roland,

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 :)

Thanks,

	tglx



             reply	other threads:[~2009-10-10 18:38 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-10 18:37 Thomas Gleixner [this message]
2009-10-11 17:42 ` infiniband BKL leftovers Roland Dreier
2009-10-11 19:27   ` Roland Dreier
2009-10-11 19:52     ` Thomas Gleixner
2009-10-14 15:51   ` [tip:bkl/drivers] inifiband: Remove BKL from ipath_open() tip-bot for 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=alpine.LFD.2.00.0910102015400.9428@localhost.localdomain \
    --to=tglx@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdreier@cisco.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox