linux-toradex.git/drivers/uio/uio.c, branch v4.9.120

uio: fix incorrect memory leak cleanup

2018-04-13T17:47:59+00:00

[ Upstream commit 0d83539092ddb1ab79b4d65bccb866bf07ea2ccd ]

Commit 75f0aef6220d ("uio: fix memory leak") has fixed up some
memory leaks during the failure paths of the addition of uio
attributes, but still is not correct entirely. A kobject_uevent()
failure still needs a kobject_put() and the kobject container
structure allocation failure before the kobject_init() doesn't
need a kobject_put(). Fix this properly.

Fixes: 75f0aef6220d ("uio: fix memory leak")
Signed-off-by: Suman Anna 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

uio: add missing error codes

2016-05-01T21:11:12+00:00

My static checker complains that "ret" could be uninitialized at the
end, which is true but it's more likely that it would be set to zero.

Signed-off-by: Dan Carpenter 
Signed-off-by: Greg Kroah-Hartman

uio: fix false positive __might_sleep warning splat

2015-10-04T11:32:25+00:00

Andy has reported a __might_sleep warning
[ 5174.883617] WARNING: CPU: 0 PID: 1532 at
/home/agrover/git/kernel/kernel/sched/core.c:7389 __might_sleep+0x7d/0x90()
[ 5174.884407] do not call blocking ops when !TASK_RUNNING; state=1 set at [] uio_read+0x91/0x170 [uio]
[ 5174.885198] Modules linked in: tcm_loop target_core_user uio target_core_pscsi target_core_file target_core_iblock iscsi_target_mod  target_core_mod uinput fuse nfsv3 nfs_acl nfs lockd grace fscache sunrpc microcode i2c_piix4 virtio_balloon i2c_core xfs libcrc32c crc32c_intel  virtio_net virtio_blk
[ 5174.887351] CPU: 0 PID: 1532 Comm: tcmu-runner Not tainted 4.2.0-rc7+
[ 5174.887853] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.8.1-20150318_183358- 04/01/2014
[ 5174.888633]  ffffffff81a3b870 ffff880045393ca8 ffffffff817afaae
0000000000000000
[ 5174.889224]  ffff880045393cf8 ffff880045393ce8 ffffffff8109a846
ffff880045393cd8
[ 5174.889793]  ffffffffa02a7150 00000000000002dc 0000000000000000
ffff880045008000
[ 5174.890375] Call Trace:
[ 5174.890562]  [] dump_stack+0x4c/0x65
[ 5174.890938]  [] warn_slowpath_common+0x86/0xc0
[ 5174.891388]  [] warn_slowpath_fmt+0x46/0x50
[ 5174.891808]  [] ? uio_read+0x91/0x170 [uio]
[ 5174.892237]  [] ? uio_read+0x91/0x170 [uio]
[ 5174.892653]  [] __might_sleep+0x7d/0x90
[ 5174.893055]  [] __might_fault+0x43/0xa0
[ 5174.893448]  [] ? schedule+0x3e/0x90
[ 5174.893820]  [] uio_read+0x132/0x170 [uio]
[ 5174.894240]  [] ? wake_up_q+0x70/0x70
[ 5174.894620]  [] __vfs_read+0x28/0xe0
[ 5174.894993]  [] ? security_file_permission+0xa3/0xc0
[ 5174.895541]  [] ? rw_verify_area+0x4f/0xf0
[ 5174.896006]  [] vfs_read+0x8a/0x140
[ 5174.896391]  [] ? __schedule+0x425/0xcc0
[ 5174.896788]  [] SyS_read+0x49/0xb0

The warning is a false positive because uio_read doesn't depent on
TASK_INTERRUPTIBLE after copy_to_user so it is safe to silence the
warning by an explicit setting the state to TASK_RUNNING in the path
which might call into TASK_RUNNING.

Reported-by: Andy Grover 
Signed-off-by: Michal Hocko 
Signed-off-by: Greg Kroah-Hartman

uio: Destroy uio_idr on module exit

2015-08-05T20:25:59+00:00

Destroy uio_idr on module exit, reclaiming the allocated memory.

This was detected by the following semantic patch (written by Luis Rodriguez
)

@ defines_module_init @
declarer name module_init, module_exit;
declarer name DEFINE_IDR;
identifier init;
@@

module_init(init);

@ defines_module_exit @
identifier exit;
@@

module_exit(exit);

@ declares_idr depends on defines_module_init && defines_module_exit @
identifier idr;
@@

DEFINE_IDR(idr);

@ on_exit_calls_destroy depends on declares_idr && defines_module_exit @
identifier declares_idr.idr, defines_module_exit.exit;
@@

exit(void)
{
 ...
 idr_destroy(&idr);
 ...
}

@ missing_module_idr_destroy depends on declares_idr && defines_module_exit && !on_exit_calls_destroy @
identifier declares_idr.idr, defines_module_exit.exit;
@@

exit(void)
{
 ...
 +idr_destroy(&idr);
}



Signed-off-by: Johannes Thumshirn 
Signed-off-by: Greg Kroah-Hartman

uio: don't free irq that was not requested

2015-05-24T18:55:15+00:00

UIO base driver should only free_irq that it has requested.
UIO supports drivers without interrupts (irq == 0) or custom handlers.

This fixes warnings like:

WARNING: CPU: 1 PID: 5478 at kernel/irq/manage.c:1244 __free_irq+0xa9/0x1e0()
Trying to free already-free IRQ 0

Signed-off-by: Stephen Hemminger 
Signed-off-by: Greg Kroah-Hartman

uio: Request/free irq separate from dev lifecycle

2015-03-20T12:18:16+00:00

Separate irq request/free from the device lifecycle.
After device unregister the parent module can call pci_disable_msi.
>From the PCI MSI how to:

"Before calling this function, a device driver must always call free_irq()
on any interrupt for which it previously called request_irq().
Failure to do so results in a BUG_ON(), leaving the device with
MSI enabled and thus leaking its vector."

So we need to separately free the irq at unregister to allow the device
to be kept around in the case of it still having open FDs.

Signed-off-by: Brian Russell 
Signed-off-by: Greg Kroah-Hartman

uio: support memory sizes larger than 32 bits

2014-11-07T18:09:07+00:00

This is a completion to 27a90700a4275c5178b883b65927affdafa5185c
The size field is also increased to allow values larger than 32 bits
on platforms that have more than 32 bit physical addresses.

Signed-off-by: Cristian Stoica 
Signed-off-by: Greg Kroah-Hartman

uio: Export definition of struct uio_device

2014-10-03T04:35:54+00:00

In order to prevent a O(n) search of the filesystem to link up its uio
node with its target configuration, TCMU needs to know the minor number
that UIO assigned. Expose the definition of this struct so TCMU can
access this field.

Signed-off-by: Andy Grover 
Signed-off-by: Nicholas Bellinger

Revert "uio: fix vma io range check in mmap"

2014-06-17T23:07:08+00:00

This reverts commit ddb09754e6c7239e302c7b675df9bbd415f8de5d.

Linus objected to this originally, I can see why it might be needed, but
given that no one spoke up defending this patch, I'm going to revert it.

If you have hardware that requires this change, please speak up in the
future and defend the patch.

Reported-by: Linus Torvalds 
Cc: Bin Wang 
Cc: Nobuhiro Iwamatsu 
Cc: Norbert Ciosek 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

uio: fix vma io range check in mmap

2014-05-27T21:11:06+00:00

the vma range size is always page size aligned in mmap, while the
real io space range may not be page aligned, thus leading to range
check failure in the uio_mmap_physical().

for example, in a case of io range size "mem->size == 1KB", and we
have (vma->vm_end - vma->vm_start) == 4KB, due to "len" is aligned
to page size in do_mmap_pgoff().

now fix this issue by align mem->size to page size in the check.

Signed-off-by: Bin Wang 
Signed-off-by: Nobuhiro Iwamatsu 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman