Mailing List Archive: Linux: Kernel

[PATCH, RFC] char dev BKL pushdown

Index | Next | Previous | View Threaded

corbet at lwn

May 16, 2008, 8:44 AM

Post #1 of 13 (349 views)
Permalink

[PATCH, RFC] char dev BKL pushdown

Linus said:

> So it literally should be:
> - remove one lock_kernel/unlock_kernel pair in fs/char_dev.c
> - add max 83 pairs in the places that register those things

...and so that's what I've done. My approach was to find every
register_chrdev() and cdev_add() call, look at the associated
file_operations, then go back to the open() function, if any. Unless it
was almost immediately obvious to me that the function was either (1) so
trivial as to not require locking (quite few of them are "return 0;"), or
(2) clearly doing its own locking, I wrapped the code in the BKL.

Finally, I removed the BKL from chrdev_open().

Allmodconfig and allyesconfig makes work here, and this kernel runs on my
dual-core desktop. But, clearly, I don't have all of this hardware.
Actually, I wonder if some of it still exists outside of museums. So
there's probably something stupid in there somewhere.

The result is available at:

git://git.lwn.net/linux-2.6.git cdev

I'll put a shortlog and diffstat at the end of this message. For
completeness, there's also a list of files I examined and did *not* change.

Assuming nobody tells me I'm completely off-base, I guess my next step is
to start running individual patches past maintainers. Some of them,
probably (I hope), will tell me that I've been wasting my time and that
their code doesn't need the BKL. In such cases, I'll gladly drop the
associated patch. But there's a fair amount of stuff here which clearly
*does* need it still. If all seems well, maybe this tree should get into
linux-next at some point too.

Comments?

The changes come out to this:

arch/cris/arch-v10/drivers/gpio.c | 3 ++
arch/cris/arch-v10/drivers/sync_serial.c | 34 ++++++++++++++++----------
arch/cris/arch-v32/drivers/mach-a3/gpio.c | 4 +++
arch/cris/arch-v32/drivers/mach-fs/gpio.c | 5 +++
arch/cris/arch-v32/drivers/sync_serial.c | 33 +++++++++++++++-----------
arch/mips/kernel/rtlx.c | 7 ++++-
arch/mips/kernel/vpe.c | 12 +++++++--
arch/mips/sibyte/common/sb_tbprof.c | 25 ++++++++++++++-----
arch/sh/boards/landisk/gio.c | 10 +++++--
arch/x86/kernel/cpuid.c | 25 +++++++++++++------
arch/x86/kernel/msr.c | 16 +++++++++---
block/bsg.c | 7 ++++-
drivers/block/aoe/aoechr.c | 7 ++++-
drivers/block/paride/pg.c | 22 ++++++++++++-----
drivers/block/paride/pt.c | 8 +++++-
drivers/char/drm/drm_fops.c | 9 +++++--
drivers/char/ipmi/ipmi_devintf.c | 8 ++++--
drivers/char/lp.c | 38 ++++++++++++++++++++----------
drivers/char/mbcs.c | 5 +++
drivers/char/mem.c | 10 ++++++-
drivers/char/misc.c | 3 ++
drivers/char/pcmcia/cm4000_cs.c | 26 +++++++++++++++-----
drivers/char/pcmcia/cm4040_cs.c | 23 +++++++++++++-----
drivers/char/snsc.c | 5 +++
drivers/char/tty_io.c | 27 +++++++++++++++++++--
drivers/char/viotape.c | 3 ++
drivers/firewire/fw-cdev.c | 16 +++++++++---
drivers/hid/hidraw.c | 3 ++
drivers/i2c/i2c-dev.c | 22 ++++++++++++-----
drivers/ide/ide-tape.c | 7 ++++-
drivers/ieee1394/dv1394.c | 6 +++-
drivers/ieee1394/raw1394.c | 3 ++
drivers/ieee1394/video1394.c | 18 ++++++++++----
drivers/input/input.c | 16 +++++++++---
drivers/isdn/i4l/isdn_common.c | 3 +-
drivers/media/dvb/dvb-core/dvbdev.c | 4 +++
drivers/mtd/mtdchar.c | 22 ++++++++++++-----
drivers/mtd/ubi/cdev.c | 7 ++++-
drivers/net/wan/cosa.c | 22 ++++++++++++-----
drivers/pcmcia/pcmcia_ioctl.c | 25 ++++++++++++++-----
drivers/rtc/rtc-dev.c | 12 +++++++--
drivers/s390/char/fs3270.c | 23 ++++++++++++------
drivers/s390/char/tape_char.c | 12 +++++++--
drivers/s390/char/vmlogrdr.c | 8 +++++-
drivers/s390/char/vmur.c | 12 +++++++--
drivers/scsi/aacraid/linit.c | 3 ++
drivers/scsi/gdth.c | 3 ++
drivers/scsi/osst.c | 15 +++++++++++
drivers/scsi/sg.c | 16 ++++++++++--
drivers/scsi/st.c | 11 +++++++-
drivers/telephony/phonedev.c | 3 ++
drivers/uio/uio.c | 17 +++++++++----
drivers/usb/core/file.c | 3 ++
drivers/video/fbmem.c | 15 ++++++++---
fs/char_dev.c | 8 ++----
sound/core/sound.c | 15 +++++++++++
sound/sound_core.c | 5 +++
57 files changed, 554 insertions(+), 176 deletions(-)

The associated shortlog is:

Jonathan Corbet (43):
bsg: cdev lock_kernel() pushdown
cris: cdev lock_kernel() pushdown
mips: cdev lock_kernel() pushdown
sh: cdev lock_kernel() pushdown
x86: cdev lock_kernel() pushdown
i2c: cdev lock_kernel() pushdown
cosa: cdev lock_kernel() pushdown
pcmcia: cdev lock_kernel() pushdown
ieee1394: cdev lock_kernel() pushdown
rtc: cdev lock_kernel() pushdown
drivers/s390: cdev lock_kernel() pushdown
AoE: cdev lock_kernel() pushdown
paride: cdev lock_kernel() pushdown
mtdchar: cdev lock_kernel() pushdown
UBI: cdev lock_kernel() pushdown
firewire: cdev lock_kernel() pushdown
HID: cdev lock_kernel() pushdown
Input: cdev lock_kernel() pushdown
UIO: cdev lock_kernel() pushdown
cm40x0: cdev lock_kernel() pushdown
ipmi: cdev lock_kernel() pushdown
mem: cdev lock_kernel() pushdown
misc: cdev lock_kernel() pushdown
viotape: cdev lock_kernel pushdown
mbcs: cdev lock_kernel() pushdown
lp: cdev lock_kernel() pushdown
drm: cdev lock_kernel() pushdown
phonedev: cdev lock_kernel() pushdown
ide-tape: cdev lock_kernel() pushdown
sg: cdev lock_kernel() pushdown
osst: cdev lock_kernel() pushdown.
aacraid: cdev lock_kernel() pushdown
st: cdev lock_kernel() pushdown
gdth: cdev lock_kernel() pushdown
isdn: cdev lock_kernel() pushdown
usbcore: cdev lock_kernel() pushdown
dvb: cdev lock_kernel() pushdown
fbmem: cdev lock_kernel() pushdown
sound: cdev lock_kernel() pushdown
snsc: cdev lock_kernel() pushdown
tty: cdev lock_kernel() pushdown
Remove the lock_kernel() call from chrdev_open()
Add a comment in chrdev_open()

Char device source files which I did *not* change:

arch/cris/arch-v32/drivers/pcf8563.c (no open function)
arch/cris/arch-v32/drivers/i2c.c (empty open function)
arch/cris/arch-v32/drivers/cryptocop.c (almost-empty open function)
arch/cris/arch-v10/drivers/pcf8563.c (no open function)
arch/cris/arch-v10/drivers/i2c.c (empty open function)
arch/cris/arch-v10/drivers/ds1302.c (no open function)
arch/cris/arch-v10/drivers/eeprom.c (trivial)
drivers/net/ppp_generic.c (trivial)
drivers/ieee1394/ieee1394_core.c (almost-trivial)
drivers/spi/spidev.c (locking looks right)
drivers/char/cs5535_gpio.c (trivial)
drivers/char/dtlk.c (trivial, broken open)
drivers/char/ds1302.c (no open)
drivers/char/pc8736x_gpio.c (trivial)
drivers/char/stallion.c (no open)
drivers/char/tb0219.c (trivial open)
drivers/char/vc_screen.c (trivial open)
drivers/char/ppdev.c (trivial open)
drivers/char/ip2/ip2main.c (trivial open - does not do anything!)
drivers/char/scx200_gpio.c (trivial open)
drivers/char/xilinx_hwicap/xilinx_hwicap.c (locking looks right)
drivers/char/istallion.c (no open)
drivers/char/vr41xx_giu.c (trivial)
drivers/char/tlclk.c (locking looks right)
drivers/char/raw.c (obvious locking w/raw_mutex)
drivers/char/dsp56k.c (single-use locking)
drivers/infiniband/hw/ipath/ipath_file_ops.c (trivial open)
drivers/infiniband/core/user_mad.c (appears to have good locking)
drivers/infiniband/core/uverbs_main.c (ditto)
drivers/infiniband/core/ucm.c (trivial open)
drivers/misc/phantom.c (has locking)
drivers/sbus/char/bpp.c (has locking)
drivers/sbus/char/vfc_dev.c (has locking)
drivers/scsi/dpt_i2o.c (has locking)
drivers/scsi/3w-xxxx.c (trivial open)
drivers/scsi/3w-9xxx.c (trivial open)
drivers/scsi/megaraid/megaraid_sas.c (trivial open)
drivers/scsi/ch.c (has locking)
drivers/scsi/megaraid.c (trivial open)
drivers/isdn/capi/capi.c (semi-trivial open)
drivers/isdn/hardware/eicon/divasi.c (empty open)
drivers/isdn/hardware/eicon/divamnt.c (single-use open)
drivers/isdn/hardware/eicon/divasmain.c (empty open)
drivers/macintosh/adb.c (trivial open)
drivers/usb/gadget/printer.c (has locking)
drivers/usb/mon/mon_bin.c (has locking)
drivers/usb/core/endpoint.c (no opens)
drivers/usb/core/devio.c (has locking)
drivers/media/video/videodev.c (has locking)
fs/coda/psdev.c (already has lock_kernel() calls)

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

hch at infradead

May 16, 2008, 8:49 AM

Post #2 of 13 (346 views)
Permalink

Re: [PATCH, RFC] char dev BKL pushdown [In reply to]

On Fri, May 16, 2008 at 09:44:06AM -0600, Jonathan Corbet wrote:
> trivial as to not require locking (quite few of them are "return 0;"), or

If they literaly are 'return 0' you can just remove them, as a
non-existing open op will just be fine.

> (2) clearly doing its own locking, I wrapped the code in the BKL.

Even if clearly does it's own locking please add the BKL for now and let
the maintainers sort it out later, better be safe then sorry.

Except for that thanks a lot, this is the kind of work that's more
productive than all these discussions here :)

For some reason about 80 instances seem awfully few, but we've move a
lot of device into subsystems from beeing plain chardevs so this
might actually be correct.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

alan at lxorguk

May 16, 2008, 9:22 AM

Post #3 of 13 (349 views)
Permalink

Re: [PATCH, RFC] char dev BKL pushdown [In reply to]

> probably (I hope), will tell me that I've been wasting my time and that
> their code doesn't need the BKL. In such cases, I'll gladly drop the
> associated patch. But there's a fair amount of stuff here which clearly

You have to be careful before assuming but yes - seems sensible.

I'm currently munching my way through the watchdog drivers fixing them up
for unlocked_ioctl/BKL drops and finding various things needing fixing
anyway.

> *does* need it still. If all seems well, maybe this tree should get into
> linux-next at some point too.

Definitely
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

torvalds at linux-foundation

May 16, 2008, 9:30 AM

Post #4 of 13 (350 views)
Permalink

Re: [PATCH, RFC] char dev BKL pushdown [In reply to]

On Fri, 16 May 2008, Jonathan Corbet wrote:
>
> I'll put a shortlog and diffstat at the end of this message. For
> completeness, there's also a list of files I examined and did *not* change.

May I suggest just adding a comment in those files, just saying something
like

/* This does not need the BKL, because .. */

where even the "because" part could be dropped when it's really obvious.

That way that "list of files I examined and did *not* change" would be
obvious in the patch itself, and we also have some documentation that
somebody actually looked at the path.

> Assuming nobody tells me I'm completely off-base, I guess my next step is
> to start running individual patches past maintainers. Some of them,
> probably (I hope), will tell me that I've been wasting my time and that
> their code doesn't need the BKL. In such cases, I'll gladly drop the
> associated patch.

Same deal - just document the fact that the BKL isn't needed.

Yeah, in the long run that kind of documentation is worthless and we may
want to get rid of it again in a year or two, but in the short run it's a
good idea. If only to help people who want to review your patches.

Btw, do you have gitweb running anywhere?

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

corbet at lwn

May 16, 2008, 9:43 AM

Post #5 of 13 (347 views)
Permalink

Re: [PATCH, RFC] char dev BKL pushdown [In reply to]

Linus Torvalds <torvalds [at] linux-foundation> wrote:

> May I suggest just adding a comment in those files, just saying something
> like
>
> /* This does not need the BKL, because .. */

OK, I'll make another pass shortly and fill that in.

> Btw, do you have gitweb running anywhere?

No, I guess I need to figure out how to set it up. Either that or get
one of those kernel.org accounts and put things there.

Thanks,

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

arnd at arndb

May 17, 2008, 2:15 PM

Post #6 of 13 (333 views)
Permalink

Re: [PATCH, RFC] char dev BKL pushdown [In reply to]

On Friday 16 May 2008, Jonathan Corbet wrote:

> ...and so that's what I've done. My approach was to find every
> register_chrdev() and cdev_add() call, look at the associated
> file_operations, then go back to the open() function, if any.

Note that the majority of drivers use (grep suggests up to 165
of them) uses misc_register instead of register_chrdev/cdev_add.
Your patches are still correct, because you pushed the BKL into the
misc_open function, but there is an obvious next step in pushing
it further into the misc drivers.
There are probably a few more subsystems with minor number specific
open() functions, misc is just the obvious one.

> > ...and so that's what I've done. �My approach was to find every
> register_chrdev() and cdev_add() call, look at the associated
> file_operations, then go back to the open() function, if any. �Unless it
> was almost immediately obvious to me that the function was either (1) so
> trivial as to not require locking (quite few of them are "return 0;"), or
> (2) clearly doing its own locking, I wrapped the code in the BKL.
>
> Finally, I removed the BKL from chrdev_open().

In your current git tree, this change is no longer the final one, so
bisecting the series may cause other bugs. You should probably reorder
the patches at some point to avoid this.

Arnd <><
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

torvalds at linux-foundation

May 17, 2008, 2:58 PM

Post #7 of 13 (317 views)
Permalink

Re: [PATCH, RFC] char dev BKL pushdown [In reply to]

Btw, Jonathan, would you be willing to maintain some kind of tree of these
BKL removal patches?

This is different from the work Ingo is doing in the sense that these
things should be (a) safe and reasonably obvious and thus (b) presumably
ready to be merged in the next merge window. Ingo's BKL debugging tree is
likely a good thing to use to find places that need work, but actually
removing the BKL from some subsystem is a different issue.

(And when I say "safe and reasonably obvious" I obviously don't mean that
there can't be bugs. Mistakes happen, and some BKL use might be overly
subtle like the issue that Alan pointed out with an empty ->open routine
almost accidentally serializing with initialization, but that's why I'd
not merge these things after -rc2 anyway, but in the next merge window).

Because if you're willing to maintain a BKL-cleanup tree that gets merged
into linux-next etc, I'd submit my VFAT/MSDOS BKL removal patch to you.
The reason I did that one was that Thomas actually reported that to be a
major source of latency problems on one of his embedded systems (80ms
latency!), so it would be nice to have that patch in some place where it
might get tested.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

corbet at lwn

May 18, 2008, 1:07 PM

Post #8 of 13 (312 views)
Permalink

Re: [PATCH, RFC] char dev BKL pushdown [In reply to]

Linus Torvalds <torvalds [at] linux-foundation> wrote:

> Btw, Jonathan, would you be willing to maintain some kind of tree of these
> BKL removal patches?

Sure, I can do that - as long as people don't mind that committed to
being with the in-laws and off the net for the first couple of weeks in
June. I'll try to get the first version up shortly, after yet another
pass over the chardev pushdown stuff.

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

corbet at lwn

May 18, 2008, 1:26 PM

Post #9 of 13 (317 views)
Permalink

Re: [PATCH, RFC] char dev BKL pushdown [In reply to]

Arnd Bergmann <arnd [at] arndb> wrote:

> Note that the majority of drivers use (grep suggests up to 165
> of them) uses misc_register instead of register_chrdev/cdev_add.
> Your patches are still correct, because you pushed the BKL into the
> misc_open function, but there is an obvious next step in pushing
> it further into the misc drivers.

There's a few intermediate dispatcher levels like this, actually.
Lots of video drivers get called behind video_open(), usb drivers from
usb_open(), etc. Not much to be done but to push things down one level
at a time.

> In your current git tree, this change is no longer the final one, so
> bisecting the series may cause other bugs. You should probably reorder
> the patches at some point to avoid this.

Bisection is going to be problem regardless - if a problem turns up,
it's going to be the chrdev_open() change which gets fingered. I bet,
though, that it will be a rare BKL-related problem which is reproducible
enough to be easily bisectable.

But, yes, I do need to reorganize the patch series once I'm done adding
on changes.

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

arnd at arndb

May 19, 2008, 4:07 PM

Post #10 of 13 (301 views)
Permalink

Re: [PATCH, RFC] char dev BKL pushdown [In reply to]

On Sunday 18 May 2008, Jonathan Corbet wrote:
> There's a few intermediate dispatcher levels like this, actually.
> Lots of video drivers get called behind video_open(), usb drivers from
> usb_open(), etc. �Not much to be done but to push things down one level
> at a time.

I've given it a try for all the misc drivers that have an open() function.
The vast majority of them are actually watchdog drivers, all of which
register as a misc device by themselves. You seem to already have a script
to turn per-file changes into a patch each, so I'm sending you two patches:
one for all the watchdog drivers (maybe Wim can take care of that as well)
and one for all the other misc drivers (this one needs to be split).

Arnd <><

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

corbet at lwn

May 20, 2008, 8:13 AM

Post #11 of 13 (298 views)
Permalink

Re: [PATCH, RFC] char dev BKL pushdown [In reply to]

Arnd Bergmann <arnd [at] arndb> wrote:

> I've given it a try for all the misc drivers that have an open() function.
> The vast majority of them are actually watchdog drivers, all of which
> register as a misc device by themselves.

OK, it looks like the "misc" misc drivers patch can go into the
bkl-removal tree, while the watchdog patches should not. What that
means, I guess, is that the final misc_open() patch cannot go in at this
point; Alan's watchdog stuff needs to find its way in first. Make
sense?

> You seem to already have a script to turn per-file changes into a
> patch each, so I'm sending you two patches: one for all the watchdog
> drivers (maybe Wim can take care of that as well) and one for all the
> other misc drivers (this one needs to be split).

Alas, I have no such script. I just committed each change as I made it
- each one required individual attention anyway. The misc changes look
pretty straightforward, so I could probably hack up such a thing pretty
quickly if you don't have a tree with broken out patches.

Thanks,

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

arnd at arndb

May 20, 2008, 10:21 AM

Post #12 of 13 (291 views)
Permalink

Re: [PATCH, RFC] char dev BKL pushdown [In reply to]

On Tuesday 20 May 2008, Jonathan Corbet wrote:
> Arnd Bergmann <arnd [at] arndb> wrote:
>
> > I've given it a try for all the misc drivers that have an open() function.
> > The vast majority of them are actually watchdog drivers, all of which
> > register as a misc device by themselves.
>
> OK, it looks like the "misc" misc drivers patch can go into the
> bkl-removal tree, while the watchdog patches should not. �What that
> means, I guess, is that the final misc_open() patch cannot go in at this
> point; Alan's watchdog stuff needs to find its way in first. �Make
> sense?

Right, unless Alan or Wim are confident enough that removing the
BKL won't break the drivers (more than they are today).
Almost all of the open functions go along the lines of

int open(struct file *f, struct inode *i)
{
if (wd_is_open)
return -EBUSY;
wd_is_open = 1;

start_wd();

return nonseekable_open(f, i);
}

nonseekable_open doesn't need the BKL by itself, and the wd_is_open
variable is protected by the misc_mtx mutex.
I can't see any scenario in which start_wd() would need the BKL, or
where a watchdog driver needs cycle_kernel_lock(), but I was't confident
enough about that assessment, because I'm not really familiar with
the drivers.

> > You seem to already have a script to turn per-file changes into a
> > patch each, so I'm sending you two patches: one for all the watchdog
> > drivers (maybe Wim can take care of that as well) and one for all the
> > other misc drivers (this one needs to be split).
>
> Alas, I have no such script. �I just committed each change as I made it
> - each one required individual attention anyway. �The misc changes look
> pretty straightforward, so I could probably hack up such a thing pretty
> quickly if you don't have a tree with broken out patches.

I've done a semi-automated split and applied the patches on top of your
tree. You can pull these from

git://git.kernel.org/pub/scm/linux/kernel/git/arnd/cell-2.6 bkl-removal

(I guess I should do a separate tree for it, will do that if more stuff
comes up.)

Arnd <><
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

alan at lxorguk

May 20, 2008, 11:51 AM

Post #13 of 13 (285 views)
Permalink

Re: [PATCH, RFC] char dev BKL pushdown [In reply to]

> Right, unless Alan or Wim are confident enough that removing the
> BKL won't break the drivers (more than they are today).
> Almost all of the open functions go along the lines of
>
> int open(struct file *f, struct inode *i)
> {
> if (wd_is_open)
> return -EBUSY;
> wd_is_open = 1;
>
> start_wd();
>
> return nonseekable_open(f, i);
> }
>
> nonseekable_open doesn't need the BKL by itself, and the wd_is_open
> variable is protected by the misc_mtx mutex.
> I can't see any scenario in which start_wd() would need the BKL, or

You need to review the use of misc_register(). Which is what I did
already and sorted out for each watchdog - the job is done and completed
and the various problem cases fixed. Watchdog has already been made BKL
removal safe in the patch series I sent.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads