linux-kernel - Re: [PATCH v2 0/5] IB/hfi1: Remove write() and use ioctl() for user access

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 May 2016 15:07:38 -0400
From:	Dennis Dalessandro <dennis.dalessandro@...el.com>
To:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Cc:	dledford@...hat.com, linux-rdma@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/5] IB/hfi1: Remove write() and use ioctl() for user access

On Thu, May 12, 2016 at 11:34:45AM -0600, Jason Gunthorpe wrote:
>On Thu, May 12, 2016 at 10:18:27AM -0700, Dennis Dalessandro wrote:
>
>> There is also a driver software version being exported via a sysfs
>> file. This is needed so that user space applications (psm) can
>> determine if it needs to do ioctl() or write().
>
>Why? Don't do this, just call ioctl() and if it fails then use write().

Is it really that big of a deal to export a version number?

There are cases where psm could be built with a different kernel (depends on  
a header file) than the currently running one.  This allows psm to check the 
current running version with what it was built against. This could be useful 
for other scenarios in the future as well. Not just the write vs ioctl.

>> This does not add anything for compat_ioctl() as it is my understanding that
>> 32 bit applications that attempt to call the ioctl() will just fail. Which is
>> the intended behavior.
>
>qib works fine with a 64 bit kernel and 32 bit user space, don't
>break it.

We will handle this issue when we get to the qib patches. I want to hammer 
out what the solution for hfi1 looks like first.

>> There is also a question of if we need to set kobj.parent [1], I'm
>
>It is needed, you need to audit this stuff, there might be more wrong
>than that.

>> not sure this is the case since the cdev in question lives
>> in /dev, not /dev/infiniband.
>
>Irrelevant. kobj.parent is needed because the cdev is embedded within
>another reference counted structure. You need to consider how all this
>works when the driver is removed while the cdev is still open (or
>driver remove is racing with the cdev release).

The driver can't be removed while the cdev is still open. I tested with a
test code that opens /dev/hfi1_0 and spins. The use count as reported by 
lsmod ticks up and the driver can not be unloaded until I ctrl+c the test 
program.

Are you saying the driver's cdev release function could race with the 
drivers moudle_exit()? I don't think this happens. I put a sleep in the 
release function and ctrl+c my test program and it hangs until the sleep 
expires.  I tried to rmmod the driver (during the window)  and it fails as 
in use.

-Denny