kernel.git/drivers/infiniband/core, branch linux-2.6.25.y

IB/umem: Avoid sign problems when demoting npages to integer

2008-06-16T20:20:03Z

commit 8079ffa0e18baaf2940e52e0c118eef420a473a4 upstream On a 64-bit architecture, if ib_umem_get() is called with a size value that is so big that npages is negative when cast to int, then the length of the page list passed to get_user_pages(), namely min_t(int, npages, PAGE_SIZE / sizeof (struct page *)) will be negative, and get_user_pages() will immediately return 0 (at least since 900cf086, "Be more robust about bad arguments in get_user_pages()"). This leads to an infinite loop in ib_umem_get(), since the code boils down to: while (npages) { ret = get_user_pages(...); npages -= ret; } Fix this by taking the minimum as unsigned longs, so that the value of npages is never truncated. The impact of this bug isn't too severe, since the value of npages is checked against RLIMIT_MEMLOCK, so a process would need to have an astronomical limit or have CAP_IPC_LOCK to be able to trigger this, and such a process could already cause lots of mischief. But it does let buggy userspace code cause a kernel lock-up; for example I hit this with code that passes a negative value into a memory registartion function where it is promoted to a huge u64 value. Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman

trivial endianness annotations: infiniband core

2008-03-30T21:20:24Z

Signed-off-by: Al Viro Signed-off-by: Linus Torvalds

RDMA/iwcm: Don't access a cm_id after dropping reference

2008-03-11T04:22:22Z

cm_work_handler() can access cm_id_priv after it drops its reference by calling iwch_deref_id(), which might cause it to be freed. The fix is to look at whether IWCM_F_CALLBACK_DESTROY is set _before_ dropping the reference. Then if it was set, free the cm_id on this thread. Signed-off-by: Steve Wise Signed-off-by: Roland Dreier

IB/fmr_pool: Flush all dirty FMRs from ib_fmr_pool_flush()

2008-02-29T21:31:48Z

Commit a3cd7d90 ("IB/fmr_pool: ib_fmr_pool_flush() should flush all dirty FMRs") caused a regression for iSER and was reverted in e5507736. This change attempts to redo the original patch so that all used FMR entries are flushed when ib_flush_fmr_pool() is called without affecting the normal FMR pool cleaning thread. Simply move used entries from the clean list onto the dirty list in ib_flush_fmr_pool() before letting the cleanup thread do its job. Signed-off-by: Pete Wyckoff Signed-off-by: Roland Dreier

Revert "IB/fmr_pool: ib_fmr_pool_flush() should flush all dirty FMRs"

2008-02-29T21:29:19Z

This reverts commit a3cd7d9070be417a21905c997ee32d756d999b38. The original commit breaks iSER reliably, making it complain: iser: iser_reg_page_vec:ib_fmr_pool_map_phys failed: -11 The FMR cleanup thread runs ib_fmr_batch_release() as dirty entries build up. This commit causes clean but used FMR entries also to be purged. During that process, another thread can see that there are no free FMRs and fail, even though there should always have been enough available. Signed-off-by: Pete Wyckoff Signed-off-by: Roland Dreier

IB/cm: Flush workqueue when removing device

2008-02-29T21:27:52Z

When a CM MAD is received, it is queued to a CM workqueue for processing. The queued work item references the port and device on which the MAD was received. If that device is removed from the system before the work item can execute, the work item will reference freed memory. To fix this, flush the workqueue after unregistering to receive MAD, and before the device is be freed. Signed-off-by: Sean Hefty Signed-off-by: Roland Dreier

IB: Fix return value in ib_device_register_sysfs()

2008-02-15T23:05:05Z

If kobject_create_and_add() fails and returns NULL, the current code in ib_device_register_sysfs() does not set ret and hence returns 0. Set ret to -ENOMEM for this failure, so that the caller knows that ib_device_register_sysfs() actually failed. Signed-off-by: Li Zefan Signed-off-by: Roland Dreier

RDMA/cma: Do not issue MRA if user rejects connection request

2008-02-14T23:30:41Z

There's an undesirable interaction with issuing MRA requests to increase connection timeouts and the listen backlog. When the rdma_cm receives a connection request, it queues an MRA with the ib_cm. (The ib_cm will send an MRA if it receives a duplicate REQ.) The rdma_cm will then create a new rdma_cm_id and give that to the user, which in this case is the rdma_user_cm. If the listen backlog maintained in the rdma_user_cm is full, it destroys the rdma_cm_id, which in turns destroys the ib_cm_id. The ib_cm_id generates a REJ because the state of the ib_cm_id has changed to MRA sent, versus REQ received. When the backlog is full, we just want to drop the REQ so that it is retried later. Fix this by deferring queuing the MRA until after the user of the rdma_cm has examined the connection request. Signed-off-by: Sean Hefty Signed-off-by: Roland Dreier

IB/cm: Fix infiniband_cm class kobject ref counting

2008-02-12T22:38:27Z

Commit 9af57b7a ("IB/cm: Add basic performance counters") introduced a bug in how the reference count for cm_class.subsys.kobj was handled: the path that released a device did a kobject_put() on that kobject, but there was no kobject_get() in the path the handles adding a device. So the reference count ended up too low, which leads to bad things. Fix up and simplify the reference counting to avoid this. (Actually, I introduced the bug when fixing the patch up to match some of Greg's kobject changes, but who's counting) Signed-off-by: Roland Dreier

IB/cm: Remove debug printk()s that snuck upstream

2008-02-12T22:38:27Z

Pesky little devils, sneaking around... Signed-off-by: Roland Dreier