linux-kernel - infiniband BKL leftovers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 10 Oct 2009 20:37:20 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Roland Dreier <rdreier@...co.com>
cc:	LKML <linux-kernel@...r.kernel.org>
Subject: infiniband BKL leftovers

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

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