summaryrefslogtreecommitdiffstats
path: root/drivers/md
AgeCommit message (Collapse)AuthorFilesLines
2012-05-22md/bitmap: add bitmap_resize function to allow bitmap resizing.NeilBrown2-30/+172
This function will allocate the new data structures and copy bits across from old to new, allowing for the possibility that the chunksize has changed. Use the same function for performing the initial allocation of the structures. This improves test coverage. When bitmap_resize is used to resize an existing bitmap, it only copies '1' bits in, not '0' bits. So when allocating the bitmap, ensure everything is initialised to ZERO. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22md/bitmap: use DIV_ROUND_UP instead of open-codeNeilBrown1-3/+2
Also take the opportunity to simplify CHUNK_BLOCK_RATIO. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22md/bitmap: create a 'struct bitmap_counts' substructure of 'struct bitmap'NeilBrown2-77/+84
The new "struct bitmap_counts" contains all the fields that are related to counting the number of active writes in each bitmap chunk. Having this separate will make it easier to change the chunksize or overall size of a bitmap atomically. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22md/bitmap: make bitmap bitops atomic.NeilBrown1-4/+2
This allows us to remove spinlock protection which is more heavy-weight than simple atomics. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22md/bitmap: make _page_attr bitops atomic.NeilBrown1-32/+23
Using e.g. set_bit instead of __set_bit and using test_and_clear_bit allow us to remove some locking and contract other locked ranges. It is rare that we set or clear a lot of these bits, so gain should outweigh any cost. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22md/bitmap: merge bitmap_file_unmap and bitmap_file_put.NeilBrown1-24/+10
There functions really do one thing together: release the 'bitmap_storage'. So make them just one function. Since we removed the locking (previous patch), we don't need to zero any fields before freeing them, so it all becomes a bit simpler. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22md/bitmap: remove async freeing of bitmap file.NeilBrown1-12/+6
There is no real value in freeing things the moment there is an error. It is just as good to free the bitmap file and pages when the bitmap is explicitly removed (and replaced?) or at shutdown. With this gone, the bitmap will only disappear when the array is quiescent, so we can remove some locking. As the 'filemap' doesn't disappear now, include extra checks before trying to write any of it out. Also remove the check for "has it disappeared" in bitmap_daemon_write(). Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22md/bitmap: convert some spin_lock_irqsave to spin_lock_irqNeilBrown1-18/+14
All of these sites can only be called from process context with irqs enabled, so using irqsave/irqrestore just adds noise. Remove it. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22md/bitmap: use set_bit, test_bit, etc for operation on bitmap->flags.NeilBrown2-28/+24
We currently use '&' and '|' which isn't the norm in the kernel and doesn't allow easy atomicity. So change to bit numbers and {set,clear,test}_bit. This allows us to remove a spinlock/unlock (which was dubious anyway) and some other simplifications. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22md/bitmap: remove single-bit manipulation on sb->stateNeilBrown1-2/+2
Just do single-bit manipulations on bitmap->flags and copy whole value between that and sb->state. This will allow next patch which changes how bit manipulations are performed on bitmap->flags. This does result in BITMAP_STALE not being set in sb by bitmap_read_sb, however as the setting is determined by other information in the 'sb' we do not lose information this way. Normally, bitmap_load will be called shortly which will clear BITMAP_STALE anyway. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22md/bitmap: remove bitmap_mask_stateNeilBrown1-34/+3
This function isn't really needed. It sets or clears a flag in both bitmap->flags and sb->state. However both times it is called, bitmap_update_sb is called soon afterwards which copies bitmap->flags to sb->state. So just make changes to bitmap->flags, and open-code those rather than hiding in a function. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22md/bitmap: move storage allocation from bitmap_load to bitmap_create.NeilBrown1-5/+6
We should allocate memory for the storage-bitmap at create-time, not load time. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22md/bitmap: separate bitmap file allocation to its own function.NeilBrown1-46/+67
This will allow allocation before swapping in a new bitmap. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22md/bitmap: store bytes in file rather than just in last page.NeilBrown2-8/+10
This number is more generally useful, and bytes-in-last-page is easily extracted from it. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22md/bitmap: move some fields of 'struct bitmap' into a 'storage' substruct.NeilBrown3-96/+110
This new 'struct bitmap_storage' reflects the external storage of the bitmap. Having this clearly defined will make it easier to change the storage used while the array is active. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22md/bitmap: change *_page_attr() to take a page number, not a page.NeilBrown1-29/+26
Most often we have the page number, not the page. And that is what the *_page_attr() functions really want. So change the arguments to take that number. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22md/bitmap: centralise allocation of bitmap file pages.NeilBrown1-81/+68
Instead of allocating pages in read_sb_page, read_page and bitmap_read_sb, allocate them all in bitmap_init_from disk. Also replace the hack of calling "attach_page_buffers(page, NULL)" to ensure that free_buffer() won't complain, by putting a test for PagePrivate in free_buffer(). Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22md/bitmap: allow a bitmap with no backing storage.NeilBrown2-62/+79
An md bitmap comprises two parts - internal counting of active writes per 'chunk'. - external storage of whether there are any active writes on each chunk The second requires the first, but the first doesn't require the second. Not having backing storage means that the bitmap cannot expedite resync after a crash, but it still allows us to expedite the recovery of a recently-removed device. So: allow a bitmap to exist even if there is no backing device. In that case we default to 128M chunks. A particular value of this is that we can remove and re-add a bitmap (possibly of a different granularity) on a degraded array, and not lose the information needed to fast-recover the missing device. We don't actually activate these bitmaps yet - that will come in a later patch. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22md/bitmap: add new 'space' attribute for bitmaps.NeilBrown3-2/+73
If we are to allow bitmaps to be resized when the array is resized, we need to know how much space there is. So create an attribute to store this information and set appropriate defaults. It can be set more precisely via sysfs, or future metadata extensions may allow it to be recorded. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22md/bitmap: disentangle two different 'pending' flags.NeilBrown2-102/+118
There are two different 'pending' concepts in the handling of the write intent bitmap. Firstly, a 'page' from the bitmap (which container PAGE_SIZE*8 bits) may have changes (bits cleared) that should be written in due course. There is no hurry for these and the page will transition from PENDING to NEEDWRITE and will then be written, though if it ever becomes DIRTY it will be written much sooner and PENDING will be cleared. Secondly, a page of counters - which contains PAGE_SIZE/2 counters, one for each bit, can usefully have a 'pending' flag which indicates if any of the counters are low (2 or 1) and ready to be processed by bitmap_daemon_work(). If this flag is clear we can skip the whole page. These two concepts are currently combined in the bitmap-file flag. This causes a tighter connection between the counters and the bitmap file than I would like - as I want to add some flexibility to the bitmap file. So introduce a new flag with the page-of-counters, and rewrite bitmap_daemon_work() so that it handles the two different 'pending' concepts separately. This also allows us to clear BITMAP_PAGE_PENDING when we write out a dirty page, which may occasionally reduce the number of times we write a page. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22raid5: support sync requestShaohua Li2-2/+11
REQ_SYNC is ignored in current raid5 code. Block layer does use it to do policy, for example ioscheduler. This patch adds it. Signed-off-by: Shaohua Li <shli@fusionio.com> Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22raid5: remove unused variablesShaohua Li1-4/+0
The two variables are useless. Signed-off-by: Shaohua Li <shli@fusionio.com> Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22md/raid10: Fix memleak in r10buf_pool_allocmajianpeng1-3/+4
If the allocation of rep1_bio fails, we currently don't free the 'bio' of the same dev. Reported by kmemleak. Signed-off-by: majianpeng <majianpeng@gmail.com> Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22md/raid1: allow fix_read_error to read from recovering device.majianpeng1-1/+3
When attempting to fix a read error, it is acceptable to read from a device that is recovering, provided the recovery has got past the place we are reading from. This makes the test for "can we read from here" the same as the test in read_balance. Signed-off-by: majianpeng <majianpeng@gmail.com> Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22md: move freeing of badblocks.page into md_rdev_clearNeilBrown1-3/+2
This ensures that it is always freed - there were case where we failed to free the page. Reported-by: majianpeng <majianpeng@gmail.com> Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22md: dm-raid should call helper function to clear rdev.NeilBrown3-8/+6
dm-raid currently open-codes the freeing of some members of and rdev. It is more maintainable to have it call common code from md.c which does this for all call-sites. So remove free_disk_sb to md_rdev_clear, export it, and use it in dm-raid.c Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-22md/raid10: add reshape supportNeilBrown2-23/+872
A 'near' or 'offset' lay RAID10 array can be reshaped to a different 'near' or 'offset' layout, a different chunk size, and a different number of devices. However the number of copies cannot change. Unlike RAID5/6, we do not support having user-space backup data that is being relocated during a 'critical section'. Rather, the data_offset of each device must change so that when writing any block to a new location, it will not over-write any data that is still 'live'. This means that RAID10 reshape is not supportable on v0.90 metadata. The different between the old data_offset and the new_offset must be at least the larger of the chunksize multiplied by offset copies of each of the old and new layout. (for 'near' mode, offset_copies == 1). A larger difference of around 64M seems useful for in-place reshapes as more data can be moved between metadata updates. Very large differences (e.g. 512M) seem to slow the process down due to lots of long seeks (on oldish consumer graded devices at least). Metadata needs to be updated whenever the place we are about to write to is considered - by the current metadata - to still contain data in the old layout. [unbalanced locking fix from Dan Carpenter <dan.carpenter@oracle.com>] Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-21md/raid10: split out interpretation of layout to separate function.NeilBrown1-18/+49
We will soon be interpreting the layout (and chunksize etc) from multiple places to support reshape. So split it out into separate function. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-21md/raid10: Introduce 'prev' geometry to support reshape.NeilBrown2-23/+92
When RAID10 supports reshape it will need a 'previous' and a 'current' geometry, so introduce that here. Use the 'prev' geometry when before the reshape_position, and the current 'geo' when beyond it. At other times, use both as appropriate. For now, both are identical (And reshape_position is never set). When we use the 'prev' geometry, we must use the old data_offset. When we use the current (And a reshape is happening) we must use the new_data_offset. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-21md: use resync_max_sectors for reshape as well as resync.NeilBrown1-3/+5
Some resync type operations need to act on the address space of the device, others on the address space of the array. This only affects RAID10, so it sets resync_max_sectors to the array size (it defaults to the device size), and that is currently used for resync only. However reshape of a RAID10 must be done against the array size, not device size, so change code to use resync_max_sectors for both the resync and the reshape cases. This does not affect RAID5 or RAID1, just RAID10. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-21md: teach sync_page_io about new_data_offset.NeilBrown1-0/+4
Some code in raid1 and raid10 use sync_page_io to read/write pages when responding to read errors. As we will shortly support changing data_offset for raid10, this function must understand new_data_offset. So add that understanding. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-21md/raid10: collect some geometry fields into a dedicated structure.NeilBrown2-108/+115
We will shortly be adding reshape support for RAID10 which will require it having 2 concurrent geometries (before and after). To make that easier, collect most geometry fields into 'struct geom' and access them from there. Then we will more easily be able to add a second set of fields. Note that 'copies' is not in this struct and so cannot be changed. There is little need to change this number and doing so is a lot more difficult as it requires reallocating more things. So leave it out for now. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-21md/raid5: allow for change in data_offset while managing a reshape.NeilBrown2-33/+82
The important issue here is incorporating the different in data_offset into calculations concerning when we might need to over-write data that is still thought to be valid. To this end we find the minimum offset difference across all devices and add that where appropriate. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-21md/raid5: Use correct data_offset for all IO.NeilBrown1-13/+59
As there can now be two different data_offsets - an 'old' and a 'new' - we need to carefully choose between them. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-21md: add possibility to change data-offset for devices.NeilBrown5-32/+214
When reshaping we can avoid costly intermediate backup by changing the 'start' address of the array on the device (if there is enough room). So as a first step, allow such a change to be requested through sysfs, and recorded in v1.x metadata. (As we didn't previous check that all 'pad' fields were zero, we need a new FEATURE flag for this. A (belatedly) check that all remaining 'pad' fields are zero to avoid a repeat of this) The new data offset must be requested separately for each device. This allows each to have a different change in the data offset. This is not likely to be used often but as data_offset can be set per-device, new_data_offset should be too. This patch also removes the 'acknowledged' arg to rdev_set_badblocks as it is never used and never will be. At the same time we add a new arg ('in_new') which is currently always zero but will be used more soon. When a reshape finishes we will need to update the data_offset and rdev->sectors. So provide an exported function to do that. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-21md: allow a reshape operation to be reversed.NeilBrown3-13/+78
Currently a reshape operation always progresses from the start of the array to the end unless the number of devices is being reduced, in which case it progressed in the opposite direction. To reverse a partial reshape which changes the number of devices you can stop the array and re-assemble with the raid-disks numbers reversed and it will undo. However for a reshape that does not change the number of devices it is not possible to reverse the reshape in the middle - you have to wait until it completes. So add a 'reshape_direction' attribute with is either 'forwards' or 'backwards' and can be explicitly set when delta_disks is zero. This will become more important when we allow the data_offset to change in a reshape. Then the explicit statement of what direction is being used will be more useful. This can be enabled in raid5 trivially as it already supports reverse reshape and just needs to use a different trigger to request it. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-21md: using GFP_NOIO to allocate bio for flush requestShaohua Li1-1/+1
A flush request is usually issued in transaction commit code path, so using GFP_KERNEL to allocate memory for flush request bio falls into the classic deadlock issue. This is suitable for any -stable kernel to which it applies as it avoids a possible deadlock. Cc: stable@vger.kernel.org Signed-off-by: Shaohua Li <shli@fusionio.com> Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-18Merge tag 'dm-3.4-fixes-2' of ↵Linus Torvalds1-15/+17
git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm Pull a dm fix from Alasdair G Kergon: "A fix to the thin provisioning userspace interface." * tag 'dm-3.4-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm: dm thin: fix table output when pool target disables discard passdown internally
2012-05-19dm thin: fix table output when pool target disables discard passdown internallyMike Snitzer1-15/+17
When the thin pool target clears the discard_passdown parameter internally, it incorrectly changes the table line reported to userspace. This breaks dumb string comparisons on these table lines in generic userspace device-mapper library code and leads to tables being reloaded repeatedly when nothing is actually meant to be changing. This patch corrects this by no longer changing the table line when discard passdown was disabled. We can still tell when discard passdown is overridden by looking for the message "Discard unsupported by data device (sdX): Disabling discard passdown." This automatic detection is also moved from the 'load' to the 'resume' so that it is re-evaluated should the properties of underlying devices change. Signed-off-by: Mike Snitzer <snitzer@redhat.com> Acked-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2012-05-18Merge tag 'md-3.4-fixes' of git://neil.brown.name/mdLinus Torvalds1-1/+1
Pull one more md bugfix from NeilBrown: "Fix bug in recent fix to RAID10. Without this patch, recovery will crash" * tag 'md-3.4-fixes' of git://neil.brown.name/md: md/raid10: fix transcription error in calc_sectors conversion.
2012-05-19md/raid10: fix transcription error in calc_sectors conversion.NeilBrown1-1/+1
The old code was sector_div(stride, fc); the new code was sector_dir(size, conf->near_copies); 'size' is right (the stride various wasn't really needed), but 'fc' means 'far_copies', and that is an important difference. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-17Merge tag 'md-3.4-fixes' of git://neil.brown.name/mdLinus Torvalds2-24/+34
Pull two md fixes from NeilBrown: "One fixes a bug in the new raid10 resize code so is relevant to 3.4 only. The other fixes a bug in the use of md by dm-raid, so is relevant to any kernel with dm-raid support" * tag 'md-3.4-fixes' of git://neil.brown.name/md: MD: Add del_timer_sync to mddev_suspend (fix nasty panic) md/raid10: set dev_sectors properly when resizing devices in array.
2012-05-17MD: Add del_timer_sync to mddev_suspend (fix nasty panic)Jonathan Brassow1-0/+2
Use del_timer_sync to remove timer before mddev_suspend finishes. We don't want a timer going off after an mddev_suspend is called. This is especially true with device-mapper, since it can call the destructor function immediately following a suspend. This results in the removal (kfree) of the structures upon which the timer depends - resulting in a very ugly panic. Therefore, we add a del_timer_sync to mddev_suspend to prevent this. Cc: stable@vger.kernel.org Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-17md/raid10: set dev_sectors properly when resizing devices in array.NeilBrown1-24/+32
raid10 stores dev_sectors in 'conf' separately from the one in 'mddev' because it can have a very significant effect on block addressing and so need to be updated carefully. However raid10_resize isn't updating it at all! To update it correctly, we need to make sure it is a proper multiple of the chunksize taking various details of the layout in to account. This calculation is currently done in setup_conf. So split it out from there and call it from raid10_resize as well. Then set conf->dev_sectors properly. Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-12Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds1-1/+1
Pull networking fixes from David S. Miller: 1) Since we do RCU lookups on ipv4 FIB entries, we have to test if the entry is dead before returning it to our caller. 2) openvswitch locking and packet validation fixes from Ansis Atteka, Jesse Gross, and Pravin B Shelar. 3) Fix PM resume locking in IGB driver, from Benjamin Poirier. 4) Fix VLAN header handling in vhost-net and macvtap, from Basil Gor. 5) Revert a bogus network namespace isolation change that was causing regressions on S390 networking devices. 6) If bonding decides to process and handle a LACPDU frame, we shouldn't bump the rx_dropped counter. From Jiri Bohac. 7) Fix mis-calculation of available TX space in r8169 driver when doing TSO, which can lead to crashes and/or hung device. From Julien Ducourthial. 8) SCTP does not validate cached routes properly in all cases, from Nicolas Dichtel. 9) Link status interrupt needs to be handled in ks8851 driver, from Stephen Boyd. 10) Use capable(), not cap_raised(), in connector/userns netlink code. From Eric W. Biederman via Andrew Morton. 11) Fix pktgen OOPS on module unload, from Eric Dumazet. 12) iwlwifi under-estimates SKB truesizes, also from Eric Dumazet. 13) Cure division by zero in SFC driver, from Ben Hutchings. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (26 commits) ks8851: Update link status during link change interrupt macvtap: restore vlan header on user read vhost-net: fix handle_rx buffer size bonding: don't increase rx_dropped after processing LACPDUs connector/userns: replace netlink uses of cap_raised() with capable() sctp: check cached dst before using it pktgen: fix crash at module unload Revert "net: maintain namespace isolation between vlan and real device" ehea: fix losing of NEQ events when one event occurred early igb: fix rtnl race in PM resume path ipv4: Do not use dead fib_info entries. r8169: fix unsigned int wraparound with TSO sfc: Fix division by zero when using one RX channel and no SR-IOV openvswitch: Validation of IPv6 set port action uses IPv4 header net: compare_ether_addr[_64bits]() has no ordering cdc_ether: Ignore bogus union descriptor for RNDIS devices bnx2x: bug fix when loading after SAN boot e1000: Silence sparse warnings by correcting type igb, ixgbe: netdev_tx_reset_queue incorrectly called from tx init path openvswitch: Release rtnl_lock if ovs_vport_cmd_build_info() failed. ...
2012-05-12dm mpath: check if scsi_dh module already loaded before trying to loadMike Snitzer1-2/+2
If the requested scsi_dh module is already loaded then skip request_module(). Multipath table loads can hang in an unnecessary __request_module. Reported-by: Ben Marzinski <bmarzins@redhat.com> Cc: stable@kernel.org Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2012-05-12dm thin: correct module descriptionAlasdair G Kergon1-1/+1
Remove duplicate copy of string "device-mapper" (DM_NAME) from MODULE_DESCRIPTION. Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2012-05-12dm thin: fix unprotected use of prepared_discards listMike Snitzer1-0/+5
Fix two places in commit 104655fd4dce ("dm thin: support discards") that didn't use pool->lock to protect against concurrent changes to the prepared_discards list. Without this fix, thin_endio() can race with process_discard(), leading to concurrent list_add()s that result in the processes locking up with an error like the following: WARNING: at lib/list_debug.c:32 __list_add+0x8f/0xa0() ... list_add corruption. next->prev should be prev (ffff880323b96140), but was ffff8801d2c48440. (next=ffff8801d2c485c0). ... Pid: 17205, comm: kworker/u:1 Tainted: G W O 3.4.0-rc3.snitm+ #1 Call Trace: [<ffffffff8103ca1f>] warn_slowpath_common+0x7f/0xc0 [<ffffffff8103cb16>] warn_slowpath_fmt+0x46/0x50 [<ffffffffa04f6ce6>] ? bio_detain+0xc6/0x210 [dm_thin_pool] [<ffffffff8124ff3f>] __list_add+0x8f/0xa0 [<ffffffffa04f70d2>] process_discard+0x2a2/0x2d0 [dm_thin_pool] [<ffffffffa04f6a78>] ? remap_and_issue+0x38/0x50 [dm_thin_pool] [<ffffffffa04f7c3b>] process_deferred_bios+0x7b/0x230 [dm_thin_pool] [<ffffffffa04f7df0>] ? process_deferred_bios+0x230/0x230 [dm_thin_pool] [<ffffffffa04f7e42>] do_worker+0x52/0x60 [dm_thin_pool] [<ffffffff81056fa9>] process_one_work+0x129/0x450 [<ffffffff81059b9c>] worker_thread+0x17c/0x3c0 [<ffffffff81059a20>] ? manage_workers+0x120/0x120 [<ffffffff8105eabe>] kthread+0x9e/0xb0 [<ffffffff814ceda4>] kernel_thread_helper+0x4/0x10 [<ffffffff8105ea20>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff814ceda0>] ? gs_change+0x13/0x13 ---[ end trace 7e0a523bc5e52692 ]--- Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2012-05-12dm thin: reinstate missing mempool_free in cell_release_singletonMike Snitzer1-3/+6
Fix a significant memory leak inadvertently introduced during simplification of cell_release_singleton() in commit 6f94a4c45a6f744383f9f695dde019998db3df55 ("dm thin: fix stacked bi_next usage"). A cell's hlist_del() must be accompanied by a mempool_free(). Use __cell_release() to do this, like before. Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2012-05-10connector/userns: replace netlink uses of cap_raised() with capable()Eric W. Biederman1-1/+1
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 <ebiederm@xmission.com> Cc: Patrick McHardy <kaber@trash.net> Cc: Philipp Reisner <philipp.reisner@linbit.com> Acked-by: Serge E. Hallyn <serge.hallyn@canonical.com> Acked-by: Andrew G. Morgan <morgan@kernel.org> Cc: Vasiliy Kulikov <segoon@openwall.com> Cc: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <james.l.morris@oracle.com> Cc: David Miller <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>