kernel.git/drivers/block/drbd/drbd_nl.c, branch linux-3.4.y

connector/userns: replace netlink uses of cap_raised() with capable()

2012-05-11T03:21:39Z

In 2009 Philip Reiser notied that a few users of netlink connector interface needed a capability check and added the idiom cap_raised(nsp->eff_cap, CAP_SYS_ADMIN) to a few of them, on the premise that netlink was asynchronous. In 2011 Patrick McHardy noticed we were being silly because netlink is synchronous and removed eff_cap from the netlink_skb_params and changed the idiom to cap_raised(current_cap(), CAP_SYS_ADMIN). Looking at those spots with a fresh eye we should be calling capable(CAP_SYS_ADMIN). The only reason I can see for not calling capable is that it once appeared we were not in the same task as the caller which would have made calling capable() impossible. In the initial user_namespace the only difference between between cap_raised(current_cap(), CAP_SYS_ADMIN) and capable(CAP_SYS_ADMIN) are a few sanity checks and the fact that capable(CAP_SYS_ADMIN) sets PF_SUPERPRIV if we use the capability. Since we are going to be using root privilege setting PF_SUPERPRIV seems the right thing to do. The motivation for this that patch is that in a child user namespace cap_raised(current_cap(),...) tests your capabilities with respect to that child user namespace not capabilities in the initial user namespace and thus will allow processes that should be unprivielged to use the kernel services that are only protected with cap_raised(current_cap(),..). To fix possible user_namespace issues and to just clean up the code replace cap_raised(current_cap(), CAP_SYS_ADMIN) with capable(CAP_SYS_ADMIN). Signed-off-by: Eric W. Biederman Cc: Patrick McHardy Cc: Philipp Reisner Acked-by: Serge E. Hallyn Acked-by: Andrew G. Morgan Cc: Vasiliy Kulikov Cc: David Howells Reviewed-by: James Morris Cc: David Miller Signed-off-by: Andrew Morton Signed-off-by: David S. Miller

usermodehelper: use UMH_WAIT_PROC consistently

2012-03-23T23:58:41Z

A few call_usermodehelper() callers use the hardcoded constant instead of the proper UMH_WAIT_PROC, fix them. Reported-by: Tetsuo Handa Signed-off-by: Oleg Nesterov Cc: Lars Ellenberg Cc: Greg Kroah-Hartman Cc: Michal Januszewski Cc: Florian Tobias Schandinat Cc: Kentaro Takeda Cc: Tetsuo Handa Cc: James Morris Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

block: remove the second argument of k[un]map_atomic()

2012-03-20T13:48:16Z

Signed-off-by: Cong Wang

Merge branch 'master' into for-next

2011-09-15T13:08:18Z

Fast-forward merge with Linus to be able to merge patches based on more recent version of the tree.

drbd: Use angle brackets for system includes

2011-09-15T12:02:57Z

Use the normal include style. Signed-off-by: Joe Perches Signed-off-by: Jiri Kosina

drivers/block/drbd/drbd_nl.c: use bitmap_parse instead of __bitmap_parse

2011-08-02T10:43:49Z

The buffer 'sc.cpu_mask' is a kernel buffer. If bitmap_parse is used instead of __bitmap_parse the extra parameter that indicates a kernel buffer is not needed. Signed-off-by: H Hartley Sweeten Cc: Lars Ellenberg Cc: Philipp Reisner Cc: Jens Axboe Signed-off-by: Andrew Morton Signed-off-by: Jens Axboe

drbd: fix warning

2011-05-24T08:38:32Z

Signed-off-by: Philipp Reisner

drbd: Fix spelling

2011-05-24T08:21:29Z

Found these with the help of ispell -l. Signed-off-by: Bart Van Assche Signed-off-by: Lars Ellenberg Signed-off-by: Philipp Reisner

drbd: fix schedule in atomic

2011-05-24T08:14:32Z

An administrative detach used to request a state change directly to D_DISKLESS, first suspending IO to avoid the last put_ldev() occuring from an endio handler, potentially in irq context. This is not enough on the receiving side (typically secondary), we may miss some peer_req on the way to local disk, which then may do the last put_ldev() from their drbd_peer_request_endio(). This patch makes the detach always go through the intermediate D_FAILED state. We may consider to rename it D_DETACHING. Alternative approach would be to create yet an other work item to be scheduled on the worker, do the destructor work from there, and get the timing right. manually picked commit 564040f from the drbd 8.4 branch. Signed-off-by: Philipp Reisner Signed-off-by: Lars Ellenberg

drbd: Take a more conservative approach when deciding max_bio_size

2011-05-24T08:08:58Z

The old (optimistic) implementation could shrink the bio size on an primary device. Shrinking the bio size on a primary device is bad. Since there we might get BIOs with the old (bigger) size shortly after we published the new size. The new implementation is more conservative, and eventually increases the max_bio_size on a primary device (which is valid). It does so, when it knows the local limit AND the remote limit. We cache the last seen max_bio_size of the peer in the meta data, and rely on that, to make the operation of single nodes more efficient. Signed-off-by: Philipp Reisner Signed-off-by: Lars Ellenberg