aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-04-07btrfs: export global block reserve size as space_infoDavid Sterba2-1/+28
Introduce a block group type bit for a global reserve and fill the space info for SPACE_INFO ioctl. This should replace the newly added ioctl (01e219e8069516cdb98594d417b8bb8d906ed30d) to get just the 'size' part of the global reserve, while the actual usage can be now visible in the 'btrfs fi df' output during ENOSPC stress. The unpatched userspace tools will show the blockgroup as 'unknown'. CC: Jeff Mahoney <[email protected]> CC: Josef Bacik <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2014-04-07btrfs: fix crash in remount(thread_pool=) caseSergei Trofimovich1-0/+2
Reproducer: mount /dev/ubda /mnt mount -oremount,thread_pool=42 /mnt Gives a crash: ? btrfs_workqueue_set_max+0x0/0x70 btrfs_resize_thread_pool+0xe3/0xf0 ? sync_filesystem+0x0/0xc0 ? btrfs_resize_thread_pool+0x0/0xf0 btrfs_remount+0x1d2/0x570 ? kern_path+0x0/0x80 do_remount_sb+0xd9/0x1c0 do_mount+0x26a/0xbf0 ? kfree+0x0/0x1b0 SyS_mount+0xc4/0x110 It's a call btrfs_workqueue_set_max(fs_info->scrub_wr_completion_workers, new_pool_size); with fs_info->scrub_wr_completion_workers = NULL; as scrub wqs get created only on user's demand. Patch skips not-created-yet workqueues. Signed-off-by: Sergei Trofimovich <[email protected]> CC: Qu Wenruo <[email protected]> CC: Chris Mason <[email protected]> CC: Josef Bacik <[email protected]> CC: [email protected] Signed-off-by: Chris Mason <[email protected]>
2014-04-07Merge tag 'mfd-for-linus-3.15' of ↵Linus Torvalds92-1588/+3958
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd Pull MFD updates from Lee Jones: "Changes to existing drivers: - Use of managed resources - omap, twl4030, ti_am335x_tscadc - Advanced error handling - omap - Rework clk management - omap - Device Tree (re-)work - tc3589x, pm8921, da9055, sec - IRC management overhaul and !BROKEN - pm8921 - Convert to regmap - ssbi, pm8921 - Use simple power-management ops - ucb1x00 - Include file clean-up - adp5520, cs5535, janz, lpc_ich, - lpc_sch, max14577, mcp-sa11x0, pcf50633-adc, rc5t583, rdc321x-southbridge, retu, smsc-ece1099, ti-ssp, ti_am335x_tscadc, tps65912, vexpress-config, wm8350, ywm8350 - Various bug fixes across the subsystem - NULL/invalid pointer dereference prevention - Resource leak mitigation, - Variable used initialised - Staticise various containers - Enforce return value checks New drivers/supported devices: - Add support for s2mps14 and s2mpa01 to sec - Add support for da9063 (v5) to da9063 - Add support for atom-c2000 to gpio-ich - Add support for come-{mbt10,cbt6,chl6} to kempld - Add support for da9053 to da9052 - Add support for itco-wdt (v3) and baytrail to lpc_ich - Add new drivers for tps65218, rtsx_usb, bcm590xx (Re-)moved drivers: - twl4030 ==> drivers/iio - ti-ssp ==> /dev/null" * tag 'mfd-for-linus-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (103 commits) mfd: wm5110: Correct default for HEADPHONE_DETECT_1 mfd: arizona: Correct small errors in the DT binding documentation mfd: arizona: Mark DSP clocking register as volatile mfd: devicetree: bindings: Add pm8xxx RTC description mfd: kempld-core: Fix potential hang-up during boot mfd: sec-core: Fix uninitialized 'regmap_rtc' on S2MPA01 mfd: tps65910: Fix regmap_irq_chip_data leak on mfd_add_devices fail mfd: tps65910: Fix possible invalid pointer dereference on regmap_add_irq_chip fail mfd: sec-core: Fix I2C dummy device resource leak on probe failure mfd: sec-core: Add of_compatible strings for clock MFD cells mfd: Remove obsolete ti-ssp driver Documentation: mfd: s2mps11: Describe S5M8767 and S2MPS14 clocks mfd: bcm590xx: Fix type argument for module device table mfd: lpc_ich: Add support for Intel Bay Trail SoC mfd: lpc_ich: Add support for NM10 GPIO mfd: lpc_ich: Change Avoton to iTCO v3 watchdog: iTCO_wdt: Add support for v3 silicon mfd: lpc_ich: Add support for iTCO v3 mfd: lpc_ich: Remove lpc_ich_cfg struct use mfd: lpc_ich: Only configure watchdog or GPIO when present ...
2014-04-07mac802154: fix duplicate #include headersJean Sacren1-1/+0
The commit e6278d92005e ("mac802154: use header operations to create/parse headers") included the header net/ieee802154_netdev.h which had been included by the commit b70ab2e87f17 ("ieee802154: enforce consistent endianness in the 802.15.4 stack"). Fix this duplicate #include by deleting the latter one as the required header has already been in place. Signed-off-by: Jean Sacren <[email protected]> Cc: Alexander Smirnov <[email protected]> Cc: Dmitry Eremin-Solenikov <[email protected]> Cc: Phoebe Buckheister <[email protected]> Cc: [email protected] Signed-off-by: David S. Miller <[email protected]>
2014-04-07sxgbe: fix duplicate #include headersJean Sacren1-1/+0
The commit 1edb9ca69e8a ("net: sxgbe: add basic framework for Samsung 10Gb ethernet driver") added support for Samsung 10Gb ethernet driver(sxgbe) with a minor issue of including linux/io.h header twice in sxgbe_dma.c file. Fix the duplicate #include by deleting the top one so that all the rest good #include headers would be preserved in the alphabetical order. Signed-off-by: Jean Sacren <[email protected]> Cc: Byungho An <[email protected]> Cc: Girish K S <[email protected]> Cc: Siva Reddy Kallam <[email protected]> Cc: Vipul Pandya <[email protected]> Acked-by: Byungho An <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-04-07Merge tag 'for-linus-20140405' of git://git.infradead.org/linux-mtdLinus Torvalds83-647/+3181
Pull MTD updates from Brian Norris: - A few SPI NOR ID definitions - Kill the NAND "max pagesize" restriction - Fix some x16 bus-width NAND support - Add NAND JEDEC parameter page support - DT bindings for NAND ECC - GPMI NAND updates (subpage reads) - More OMAP NAND refactoring - New STMicro SPI NOR driver (now in 40 patches!) - A few other random bugfixes * tag 'for-linus-20140405' of git://git.infradead.org/linux-mtd: (120 commits) Fix index regression in nand_read_subpage mtd: diskonchip: mem resource name is not optional mtd: nand: fix mention to CONFIG_MTD_NAND_ECC_BCH mtd: nand: fix GET/SET_FEATURES address on 16-bit devices mtd: omap2: Use devm_ioremap_resource() mtd: denali_dt: Use devm_ioremap_resource() mtd: devices: elm: update DRIVER_NAME as "omap-elm" mtd: devices: elm: configure parallel channels based on ecc_steps mtd: devices: elm: clean elm_load_syndrome mtd: devices: elm: check for hardware engine's design constraints mtd: st_spi_fsm: Succinctly reorganise .remove() mtd: st_spi_fsm: Allow loop to run at least once before giving up CPU mtd: st_spi_fsm: Correct vendor name spelling issue - missing "M" mtd: st_spi_fsm: Avoid duplicating MTD core code mtd: st_spi_fsm: Remove useless consts from function arguments mtd: st_spi_fsm: Convert ST SPI FSM (NOR) Flash driver to new DT partitions mtd: st_spi_fsm: Move runtime configurable msg sequences into device's struct mtd: st_spi_fsm: Supply the W25Qxxx chip specific configuration call-back mtd: st_spi_fsm: Supply the S25FLxxx chip specific configuration call-back mtd: st_spi_fsm: Supply the MX25xxx chip specific configuration call-back ...
2014-04-07net: filter: be more defensive on div/mod by X==0Daniel Borkmann1-16/+16
The old interpreter behaviour was that we returned with 0 whenever we found a division by 0 would take place. In the new interpreter we would currently just skip that instead and continue execution. It's true that a value of 0 as return might not be appropriate in all cases, but current users (socket filters -> drop packet, seccomp -> SECCOMP_RET_KILL, cls_bpf -> unclassified, etc) seem fine with that behaviour. Better this than undefined BPF program behaviour as it's expected that A contains the result of the division. In future, as more use cases open up, we could further adapt this return value to our needs, if necessary. So reintroduce return of 0 for division by 0 as in the old interpreter. Also in case of K which is guaranteed to be 32bit wide, sk_chk_filter() already takes care of preventing division by 0 invoked through K, so we can generally spare us these tests. Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: Alexei Starovoitov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-04-07arm64: Add missing Kconfig for CONFIG_STRICT_DEVMEMLaura Abbott1-0/+14
The Kconfig for CONFIG_STRICT_DEVMEM is missing despite being used in mmap.c. Add it. Signed-off-by: Laura Abbott <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2014-04-07Btrfs: abort the transaction when we don't find our extent refJosef Bacik1-0/+2
I'm not sure why we weren't aborting here in the first place, it is obviously a bad time from the fact that we print the leaf and yell loudly about it. Fix this up, otherwise we panic because our path could be pointing into oblivion. Thanks, Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2014-04-07Btrfs: fix EINVAL checks in btrfs_cloneChris Mason1-2/+3
btrfs_drop_extents can now return -EINVAL, but only one caller in btrfs_clone was checking for it. This adds it to the caller for inline extents, which is where we really need it. Signed-off-by: Chris Mason <[email protected]>
2014-04-07Btrfs: fix unlock in __start_delalloc_inodes()Wang Shilong1-2/+3
This patch fix a regression caused by the following patch: Btrfs: don't flush all delalloc inodes when we doesn't get s_umount lock break while loop will make us call @spin_unlock() without calling @spin_lock() before, fix it. Signed-off-by: Wang Shilong <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2014-04-07Btrfs: scrub raid56 stripes in the right wayWang Shilong1-19/+89
Steps to reproduce: # mkfs.btrfs -f /dev/sda[8-11] -m raid5 -d raid5 # mount /dev/sda8 /mnt # btrfs scrub start -BR /mnt # echo $? <--unverified errors make return value be 3 This is because we don't setup right mapping between physical and logical address for raid56, which makes checksum mismatch. But we will find everthing is fine later when rechecking using btrfs_map_block(). This patch fixed the problem by settuping right mappings and we only verify data stripes' checksums. Signed-off-by: Wang Shilong <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2014-04-07Btrfs: don't compress for a small writeWang Shilong1-0/+8
To compress a small file range(<=blocksize) that is not an inline extent can not save disk space at all. skip it can save us some cpu time. This patch can also fix wrong setting nocompression flag for inode, say a case when @total_in is 4096, and then we get @total_compressed 52,because we do aligment to page cache size firstly, and then we get into conclusion @total_in=@total_compressed thus we will clear this inode's compression flag. An exception comes from inserting inline extent failure but we still have @total_compressed < @total_in,so we will still reset inode's flag, this is ok, because we don't have good compression effect. Signed-off-by: Wang Shilong <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2014-04-07Btrfs: more efficient io tree navigation on wait_extent_bitFilipe Manana1-1/+5
If we don't reschedule use rb_next to find the next extent state instead of a full tree search, which is more efficient and safe since we didn't release the io tree's lock. Signed-off-by: Filipe David Borba Manana <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2014-04-07Btrfs: send, build path string only once in send_holeFilipe Manana1-3/+3
There's no point building the path string in each iteration of the send_hole loop, as it produces always the same string. Signed-off-by: Filipe David Borba Manana <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2014-04-07btrfs: filter invalid arg for btrfs resizeGui Hecheng1-2/+3
Originally following cmds will work: # btrfs fi resize -10A <mnt> # btrfs fi resize -10Gaha <mnt> Filter the arg by checking the return pointer of memparse. Signed-off-by: Gui Hecheng <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2014-04-07Btrfs: send, fix data corruption due to incorrect hole detectionFilipe Manana1-1/+3
During an incremental send, when we finish processing an inode (corresponding to a regular file) we would assume the gap between the end of the last processed file extent and the file's size corresponded to a file hole, and therefore incorrectly send a bunch of zero bytes to overwrite that region in the file. This affects only kernel 3.14. Reproducer: mkfs.btrfs -f /dev/sdc mount /dev/sdc /mnt xfs_io -f -c "falloc -k 0 268435456" /mnt/foo btrfs subvolume snapshot -r /mnt /mnt/mysnap0 xfs_io -c "pwrite -S 0x01 -b 9216 16190218 9216" /mnt/foo xfs_io -c "pwrite -S 0x02 -b 1121 198720104 1121" /mnt/foo xfs_io -c "pwrite -S 0x05 -b 9216 107887439 9216" /mnt/foo xfs_io -c "pwrite -S 0x06 -b 9216 225520207 9216" /mnt/foo xfs_io -c "pwrite -S 0x07 -b 67584 102138300 67584" /mnt/foo xfs_io -c "pwrite -S 0x08 -b 7000 94897484 7000" /mnt/foo xfs_io -c "pwrite -S 0x09 -b 113664 245083212 113664" /mnt/foo xfs_io -c "pwrite -S 0x10 -b 123 17937788 123" /mnt/foo xfs_io -c "pwrite -S 0x11 -b 39936 229573311 39936" /mnt/foo xfs_io -c "pwrite -S 0x12 -b 67584 174792222 67584" /mnt/foo xfs_io -c "pwrite -S 0x13 -b 9216 249253213 9216" /mnt/foo xfs_io -c "pwrite -S 0x16 -b 67584 150046083 67584" /mnt/foo xfs_io -c "pwrite -S 0x17 -b 39936 118246040 39936" /mnt/foo xfs_io -c "pwrite -S 0x18 -b 67584 215965442 67584" /mnt/foo xfs_io -c "pwrite -S 0x19 -b 33792 97096725 33792" /mnt/foo xfs_io -c "pwrite -S 0x20 -b 125952 166300596 125952" /mnt/foo xfs_io -c "pwrite -S 0x21 -b 123 1078957 123" /mnt/foo xfs_io -c "pwrite -S 0x25 -b 9216 212044492 9216" /mnt/foo xfs_io -c "pwrite -S 0x26 -b 7000 265037146 7000" /mnt/foo xfs_io -c "pwrite -S 0x27 -b 42757 215922685 42757" /mnt/foo xfs_io -c "pwrite -S 0x28 -b 7000 69865411 7000" /mnt/foo xfs_io -c "pwrite -S 0x29 -b 67584 67948958 67584" /mnt/foo xfs_io -c "pwrite -S 0x30 -b 39936 266967019 39936" /mnt/foo xfs_io -c "pwrite -S 0x31 -b 1121 19582453 1121" /mnt/foo xfs_io -c "pwrite -S 0x32 -b 17408 257710255 17408" /mnt/foo xfs_io -c "pwrite -S 0x33 -b 39936 3895518 39936" /mnt/foo xfs_io -c "pwrite -S 0x34 -b 125952 12045847 125952" /mnt/foo xfs_io -c "pwrite -S 0x35 -b 17408 19156379 17408" /mnt/foo xfs_io -c "pwrite -S 0x36 -b 39936 50160066 39936" /mnt/foo xfs_io -c "pwrite -S 0x37 -b 113664 9549793 113664" /mnt/foo xfs_io -c "pwrite -S 0x38 -b 105472 94391506 105472" /mnt/foo xfs_io -c "pwrite -S 0x39 -b 23552 143632863 23552" /mnt/foo xfs_io -c "pwrite -S 0x40 -b 39936 241283845 39936" /mnt/foo xfs_io -c "pwrite -S 0x41 -b 113664 199937606 113664" /mnt/foo xfs_io -c "pwrite -S 0x42 -b 67584 67380093 67584" /mnt/foo xfs_io -c "pwrite -S 0x43 -b 67584 26793129 67584" /mnt/foo xfs_io -c "pwrite -S 0x44 -b 39936 14421913 39936" /mnt/foo xfs_io -c "pwrite -S 0x45 -b 123 253097405 123" /mnt/foo xfs_io -c "pwrite -S 0x46 -b 1121 128233424 1121" /mnt/foo xfs_io -c "pwrite -S 0x47 -b 105472 91577959 105472" /mnt/foo xfs_io -c "pwrite -S 0x48 -b 1121 7245381 1121" /mnt/foo xfs_io -c "pwrite -S 0x49 -b 113664 182414694 113664" /mnt/foo xfs_io -c "pwrite -S 0x50 -b 9216 32750608 9216" /mnt/foo xfs_io -c "pwrite -S 0x51 -b 67584 266546049 67584" /mnt/foo xfs_io -c "pwrite -S 0x52 -b 67584 87969398 67584" /mnt/foo xfs_io -c "pwrite -S 0x53 -b 9216 260848797 9216" /mnt/foo xfs_io -c "pwrite -S 0x54 -b 39936 119461243 39936" /mnt/foo xfs_io -c "pwrite -S 0x55 -b 7000 200178693 7000" /mnt/foo xfs_io -c "pwrite -S 0x56 -b 9216 243316029 9216" /mnt/foo xfs_io -c "pwrite -S 0x57 -b 7000 209658229 7000" /mnt/foo xfs_io -c "pwrite -S 0x58 -b 101376 179745192 101376" /mnt/foo xfs_io -c "pwrite -S 0x59 -b 9216 64012300 9216" /mnt/foo xfs_io -c "pwrite -S 0x60 -b 125952 181705139 125952" /mnt/foo xfs_io -c "pwrite -S 0x61 -b 23552 235737348 23552" /mnt/foo xfs_io -c "pwrite -S 0x62 -b 113664 106021355 113664" /mnt/foo xfs_io -c "pwrite -S 0x63 -b 67584 135753552 67584" /mnt/foo xfs_io -c "pwrite -S 0x64 -b 23552 95730888 23552" /mnt/foo xfs_io -c "pwrite -S 0x65 -b 11 17311415 11" /mnt/foo xfs_io -c "pwrite -S 0x66 -b 33792 120695553 33792" /mnt/foo xfs_io -c "pwrite -S 0x67 -b 9216 17164631 9216" /mnt/foo xfs_io -c "pwrite -S 0x68 -b 9216 136065853 9216" /mnt/foo xfs_io -c "pwrite -S 0x69 -b 67584 37752198 67584" /mnt/foo xfs_io -c "pwrite -S 0x70 -b 101376 189717473 101376" /mnt/foo xfs_io -c "pwrite -S 0x71 -b 7000 227463698 7000" /mnt/foo xfs_io -c "pwrite -S 0x72 -b 9216 12655137 9216" /mnt/foo xfs_io -c "pwrite -S 0x73 -b 7000 7488866 7000" /mnt/foo xfs_io -c "pwrite -S 0x74 -b 113664 87813649 113664" /mnt/foo xfs_io -c "pwrite -S 0x75 -b 33792 25802183 33792" /mnt/foo xfs_io -c "pwrite -S 0x76 -b 39936 93524024 39936" /mnt/foo xfs_io -c "pwrite -S 0x77 -b 33792 113336388 33792" /mnt/foo xfs_io -c "pwrite -S 0x78 -b 105472 184955320 105472" /mnt/foo xfs_io -c "pwrite -S 0x79 -b 101376 225691598 101376" /mnt/foo xfs_io -c "pwrite -S 0x80 -b 23552 77023155 23552" /mnt/foo xfs_io -c "pwrite -S 0x81 -b 11 201888192 11" /mnt/foo xfs_io -c "pwrite -S 0x82 -b 11 115332492 11" /mnt/foo xfs_io -c "pwrite -S 0x83 -b 67584 230278015 67584" /mnt/foo xfs_io -c "pwrite -S 0x84 -b 11 120589073 11" /mnt/foo xfs_io -c "pwrite -S 0x85 -b 125952 202207819 125952" /mnt/foo xfs_io -c "pwrite -S 0x86 -b 113664 86672080 113664" /mnt/foo xfs_io -c "pwrite -S 0x87 -b 17408 208459603 17408" /mnt/foo xfs_io -c "pwrite -S 0x88 -b 7000 73372211 7000" /mnt/foo xfs_io -c "pwrite -S 0x89 -b 7000 42252122 7000" /mnt/foo xfs_io -c "pwrite -S 0x90 -b 23552 46784881 23552" /mnt/foo xfs_io -c "pwrite -S 0x91 -b 101376 63172351 101376" /mnt/foo xfs_io -c "pwrite -S 0x92 -b 23552 59341931 23552" /mnt/foo xfs_io -c "pwrite -S 0x93 -b 39936 239599283 39936" /mnt/foo xfs_io -c "pwrite -S 0x94 -b 67584 175643105 67584" /mnt/foo xfs_io -c "pwrite -S 0x97 -b 23552 105534880 23552" /mnt/foo xfs_io -c "pwrite -S 0x98 -b 113664 8236844 113664" /mnt/foo xfs_io -c "pwrite -S 0x99 -b 125952 144489686 125952" /mnt/foo xfs_io -c "pwrite -S 0xa0 -b 7000 73273112 7000" /mnt/foo xfs_io -c "pwrite -S 0xa1 -b 125952 194580243 125952" /mnt/foo xfs_io -c "pwrite -S 0xa2 -b 123 56296779 123" /mnt/foo xfs_io -c "pwrite -S 0xa3 -b 11 233066845 11" /mnt/foo xfs_io -c "pwrite -S 0xa4 -b 39936 197727090 39936" /mnt/foo xfs_io -c "pwrite -S 0xa5 -b 101376 53579812 101376" /mnt/foo xfs_io -c "pwrite -S 0xa6 -b 9216 85669738 9216" /mnt/foo xfs_io -c "pwrite -S 0xa7 -b 125952 21266322 125952" /mnt/foo xfs_io -c "pwrite -S 0xa8 -b 23552 125726568 23552" /mnt/foo xfs_io -c "pwrite -S 0xa9 -b 9216 18423680 9216" /mnt/foo xfs_io -c "pwrite -S 0xb0 -b 1121 165901483 1121" /mnt/foo btrfs subvolume snapshot -r /mnt /mnt/mysnap1 xfs_io -c "pwrite -S 0xff -b 10 16190218 10" /mnt/foo btrfs subvolume snapshot -r /mnt /mnt/mysnap2 md5sum /mnt/foo # returns 79e53f1466bfc09fd82b450689e6119e md5sum /mnt/mysnap2/foo # returns 79e53f1466bfc09fd82b450689e6119e too btrfs send /mnt/mysnap1 -f /tmp/1.snap btrfs send -p /mnt/mysnap1 /mnt/mysnap2 -f /tmp/2.snap mkfs.btrfs -f /dev/sdc mount /dev/sdc /mnt btrfs receive /mnt -f /tmp/1.snap btrfs receive /mnt -f /tmp/2.snap md5sum /mnt/mysnap2/foo # returns 2bb414c5155767cedccd7063e51beabd !! A testcase for xfstests follows soon too. Signed-off-by: Filipe David Borba Manana <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2014-04-07Btrfs: kmalloc() doesn't return an ERR_PTRDan Carpenter1-3/+2
The error handling was copy and pasted from memdup_user(). It should be checking for NULL obviously. Fixes: abccd00f8af2 ('btrfs: Fix 32/64-bit problem with BTRFS_SET_RECEIVED_SUBVOL ioctl') Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2014-04-07Btrfs: fix snapshot vs nocow writtingWang Shilong1-2/+21
While running fsstress and snapshots concurrently, we will hit something like followings: Thread 1 Thread 2 |->fallocate |->write pages |->join transaction |->add ordered extent |->end transaction |->flushing data |->creating pending snapshots |->write data into src root's fallocated space After above work flows finished, we will get a state that source and snapshot root share same space, but source root have written data into fallocated space, this will make fsck fail to verify checksums for snapshot root's preallocating file extent data.Nocow writting also has this same problem. Fix this problem by syncing snapshots with nocow writting: 1.for nocow writting,if there are pending snapshots, we will fall into COW way. 2.if there are pending nocow writes, snapshots for this root will be blocked until nocow writting finish. Reported-by: Gui Hecheng <[email protected]> Signed-off-by: Wang Shilong <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2014-04-07btrfs: Change the expanding write sequence to fix snapshot related bug.Qu Wenruo1-1/+4
When testing fsstress with snapshot making background, some snapshot following problem. Snapshot 270: inode 323: size 0 Snapshot 271: inode 323: size 349145 |-------Hole---|---------Empty gap-------|-------Hole-----| 0 122880 172032 349145 Snapshot 272: inode 323: size 349145 |-------Hole---|------------Data---------|-------Hole-----| 0 122880 172032 349145 The fsstress operation on inode 323 is the following: write: offset 126832 len 43124 truncate: size 349145 Since the write with offset is consist of 2 operations: 1. punch hole 2. write data Hole punching is faster than data write, so hole punching in write and truncate is done first and then buffered write, so the snapshot 271 got empty gap, which will not pass btrfsck. To fix the bug, this patch will change the write sequence which will first punch a hole covering the write end if a hole is needed. Reported-by: Gui Hecheng <[email protected]> Signed-off-by: Qu Wenruo <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2014-04-07btrfs: make device scan less noisyDavid Sterba1-11/+24
Print the message only when the device is seen for the first time. Signed-off-by: David Sterba <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2014-04-07btrfs: fix lockdep warning with reclaim lock inversionJeff Mahoney1-3/+7
When encountering memory pressure, testers have run into the following lockdep warning. It was caused by __link_block_group calling kobject_add with the groups_sem held. kobject_add calls kvasprintf with GFP_KERNEL, which gets us into reclaim context. The kobject doesn't actually need to be added under the lock -- it just needs to ensure that it's only added for the first block group to be linked. ========================================================= [ INFO: possible irq lock inversion dependency detected ] 3.14.0-rc8-default #1 Not tainted --------------------------------------------------------- kswapd0/169 just changed the state of lock: (&delayed_node->mutex){+.+.-.}, at: [<ffffffffa018baea>] __btrfs_release_delayed_node+0x3a/0x200 [btrfs] but this lock took another, RECLAIM_FS-unsafe lock in the past: (&found->groups_sem){+++++.} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&found->groups_sem); local_irq_disable(); lock(&delayed_node->mutex); lock(&found->groups_sem); <Interrupt> lock(&delayed_node->mutex); *** DEADLOCK *** 2 locks held by kswapd0/169: #0: (shrinker_rwsem){++++..}, at: [<ffffffff81159e8a>] shrink_slab+0x3a/0x160 #1: (&type->s_umount_key#27){++++..}, at: [<ffffffff811bac6f>] grab_super_passive+0x3f/0x90 Signed-off-by: Jeff Mahoney <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2014-04-07Btrfs: hold the commit_root_sem when getting the commit root during sendJosef Bacik3-16/+39
We currently rely too heavily on roots being read-only to save us from just accessing root->commit_root. We can easily balance blocks out from underneath a read only root, so to save us from getting screwed make sure we only access root->commit_root under the commit root sem. Thanks, Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2014-04-07ARM: 8009/1: dcscb.c: remove call to outer_flush_all()Nicolas Pitre1-4/+9
Strictly speaking this call is a no-op on the platform where dcscb.c is used since it only has architected caches. The call was there as a hint to people inspired by this code when writing their own backend, but the hint might not always be correct. For example, if a PL310 were to be used it wouldn't be safe to call the regular outer_flush_all() as atomic instructions for locking are involved in that case and those instructions cannot be assumed to still be operational after v7_exit_coherency_flush() has returned. Given no other CPUs (in the cluster) should be running at that point then standard concurrency concerns wouldn't apply. So let's simply kill this call for now and enhance the existing comment. Signed-off-by: Nicolas Pitre <[email protected]> Signed-off-by: Russell King <[email protected]>
2014-04-07blk-mq: fix potential stall during CPU unplug with IO pendingJens Axboe1-2/+6
When a CPU is unplugged, we move the blk_mq_ctx request entries to the current queue. The current code forgets to remap the blk_mq_hw_ctx before marking the software context pending, which breaks if old-cpu and new-cpu don't map to the same hardware queue. Additionally, if we mark entries as pending in the new hardware queue, then make sure we schedule it for running. Otherwise request could be sitting there until someone else queues IO for that hardware queue. Signed-off-by: Jens Axboe <[email protected]>
2014-04-07percpu_counter: fix bad counter state during suspendJens Axboe1-1/+1
I got a bug report yesterday from Laszlo Ersek <lersek@xxxxxxxxxx>, in which he states that his kvm instance fails to suspend. He Laszlo bisected it down to this commit: commit 1cf7e9c68fe84248174e998922b39e508375e7c1 Author: Jens Axboe <axboe@xxxxxxxxx> Date: Fri Nov 1 10:52:52 2013 -0600 virtio_blk: blk-mq support where virtio-blk is converted to use the blk-mq infrastructure. After digging a bit, it became clear that the issue was with the queue drain. blk-mq tracks queue usage in a percpu counter, which is incremented on request alloc and decremented when the request is freed. The initial hunt was for an inconsistency in blk-mq, but everything seemed fine. In fact, the counter only returned crazy values when suspend was in progress. When a CPU is unplugged, the percpu counters merges that CPU state with the general state. blk-mq takes care to register a hotcpu notifier with the appropriate priority, so we know it runs after the percpu counter notifier. However, the percpu counter notifier only merges the state when the CPU is fully gone. This leaves a state transition where the CPU going away is no longer in the online mask, yet it still holds private values. This means that in this state, percpu_counter_sum() returns invalid results, and the suspend then hangs waiting for abs(dead-cpu-value) requests to complete which of course will never happen. Fix this by clearing the state earlier, so we never have a case where the CPU isn't in online mask but still holds private state. This bug has been there since forever, I guess we don't have a lot of users where percpu counters needs to be reliable during the suspend cycle. Reported-by: <[email protected]> Tested-by: Laszlo Ersek <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2014-04-07Xen: do hv callback accounting only on x86Arnd Bergmann1-1/+1
Patch 99c8b79d3c1 "xen: Add proper irq accounting for HYPERCALL vector" added a call to inc_irq_stat(irq_hv_callback_count) in common Xen code, however both the inc_irq_stat function and the irq_hv_callback_count counter are architecture specific. This makes the code build again on ARM by moving the call into the existing #ifdef CONFIG_X86. We may want to later do the same implementation on ARM that x86 has though. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: David Vrabel <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Konrad Rzeszutek Wilk <[email protected]> Cc: Xen <[email protected]>
2014-04-07Merge commit '683b6c6f82a60fabf47012581c2cfbf1b037ab95' into ↵David Vrabel1493-13637/+25211
stable/for-linus-3.15 This merge of the irq-core-for-linus branch broke the ARM build when Xen is enabled. Conflicts: drivers/xen/events/events_base.c
2014-04-07[media] v4l: ti-vpe: retain v4l2_buffer flags for captured buffersArchit Taneja1-5/+4
The dequed CAPTURE_MPLANE type buffers don't contain the flags that the originally queued OUTPUT_MPLANE type buffers have. This breaks compliance. Copy the source v4l2_buffer flags to the destination v4l2_buffer flags before they are dequed. Reviewed-by: Hans Verkuil <[email protected]> Signed-off-by: Archit Taneja <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2014-04-07[media] v4l: ti-vpe: Set correct field parameter for output and capture buffersArchit Taneja1-1/+12
The vpe driver wasn't setting the correct field parameter for dequed CAPTURE type buffers for the case where the captured output is progressive. Set the field to V4L2_FIELD_NONE for the completed destination buffers when the captured output is progressive. For OUTPUT type buffers, a queued buffer's field is forced to V4L2_FIELD_NONE if the pixel format(configured through s_fmt for the buffer type V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE specifies) the field type isn't interlaced. If the pixel format specified was V4L2_FIELD_ALTERNATE, and the queued buffer's field isn't V4L2_FIELD_TOP or V4L2_FIELD_BOTTOM, the vb2 buf_prepare op returns an error. This ensures compliance, and that the dequeued output and captured buffers contain the field type that the driver used internally. Signed-off-by: Archit Taneja <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2014-04-07cpufreq: create another field .flags in cpufreq_frequency_tableViresh Kumar23-152/+155
Currently cpufreq frequency table has two fields: frequency and driver_data. driver_data is only for drivers' internal use and cpufreq core shouldn't use it at all. But with the introduction of BOOST frequencies, this assumption was broken and we started using it as a flag instead. There are two problems due to this: - It is against the description of this field, as driver's data is used by the core now. - if drivers fill it with -3 for any frequency, then those frequencies are never considered by cpufreq core as it is exactly same as value of CPUFREQ_BOOST_FREQ, i.e. ~2. The best way to get this fixed is by creating another field flags which will be used for such flags. This patch does that. Along with that various drivers need modifications due to the change of struct cpufreq_frequency_table. Reviewed-by: Gautham R Shenoy <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2014-04-07cpufreq: use kzalloc() to allocate memory for cpufreq_frequency_tableViresh Kumar6-13/+9
Few drivers are using kmalloc() to allocate memory for frequency tables and since we will have an additional field '.flags' in 'struct cpufreq_frequency_table', these might become unstable. Better get these fixed by replacing kmalloc() by kzalloc() instead. Along with that we also remove use of .driver_data from SPEAr driver as it doesn't use it at all. Also, writing zero to .driver_data is not required for powernow-k8 as it is already zero. Reported-and-reviewed-by: Gautham R. Shenoy <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2014-04-07cpufreq: don't print value of .driver_data from coreViresh Kumar1-4/+3
CPUFreq core doesn't control value of .driver_data and this field is completely driver specific. This can contain any value and not only indexes. For most of the drivers, which aren't using this field, its value is zero. So, printing this from core doesn't make any sense. Don't print it. Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2014-04-07cpufreq: ia64: don't set .driver_data to indexViresh Kumar1-1/+0
.driver_data field is only required to be filled if drivers want to preserve some data in there which they can use according to the value of .frequency. But this driver isn't using this field at all, but just setting it equal to the index value. Which isn't required. Fix it. Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2014-04-07[media] v4l: ti-vpe: zero out reserved fields in try_fmtArchit Taneja1-0/+3
Zero out the reserved formats in v4l2_pix_format_mplane and v4l2_plane_pix_format members of the returned v4l2_format pointer when passed through TRY_FMT ioctl. This ensures that the user doesn't interpret the non-zero fields as some data passed by the driver, and ensures compliance. Reviewed-by: Hans Verkuil <[email protected]> Signed-off-by: Archit Taneja <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2014-04-07[media] v4l: ti-vpe: Fix initial configuration queue dataArchit Taneja1-2/+4
The vpe output and capture queues are initially configured to default values in vpe_open(). A G_FMT before any S_FMTs will result in these values being populated. The colorspace and bytesperline parameter of this initial configuration are incorrect. This breaks compliance when as we get 'TRY_FMT(G_FMT) != G_FMT'. Fix the initial queue configuration such that it wouldn't need to be fixed by try_fmt. Reviewed-by: Hans Verkuil <[email protected]> Signed-off-by: Archit Taneja <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2014-04-07[media] v4l: ti-vpe: Use correct bus_info name for the device in querycapArchit Taneja1-1/+2
The bus_info parameter in v4l2_capabilities expects a 'platform_' prefix. This wasn't done in the driver and hence was breaking compliance. Update the bus_info parameter accordingly. Reviewed-by: Hans Verkuil <[email protected]> Signed-off-by: Archit Taneja <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2014-04-07[media] v4l: ti-vpe: report correct capabilities in querycapArchit Taneja1-1/+1
querycap currently returns V4L2_CAP_VIDEO_M2M as a capability, this should be V4L2_CAP_VIDEO_M2M_MPLANE instead, as the driver supports multiplanar formats. Reviewed-by: Hans Verkuil <[email protected]> Signed-off-by: Archit Taneja <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2014-04-07[media] v4l: ti-vpe: Allow usage of smaller imagesArchit Taneja1-2/+2
The minimum width and height for VPE input/output was kept as 128 pixels. VPE doesn't have a constraint on the image height, it requires the image width to be at least 16 bytes. Change the minimum supported dimensions to 32x32. This allows us to de-interlace qcif content. A smaller image size than 32x32 didn't make much sense, so stopped at this. Reviewed-by: Hans Verkuil <[email protected]> Signed-off-by: Archit Taneja <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2014-04-07[media] v4l: ti-vpe: Use video_device_release_emptyArchit Taneja1-1/+1
The video_device struct is currently embedded in the driver data struct vpe_dev. A vpe_dev instance is allocated by the driver, and the memory for the vfd is a part of this struct. The v4l2 core, however, manages the removal of the vfd region, through the video_device's .release() op, which currently is the helper video_device_release. This causes memory corruption, and leads to issues when we try to re-insert the vpe module. Use the video_device_release_empty helper function instead. Reviewed-by: Hans Verkuil <[email protected]> Signed-off-by: Archit Taneja <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2014-04-07[media] v4l: ti-vpe: Make sure in job_ready that we have the needed number ↵Archit Taneja1-0/+3
of dst_bufs VPE has a ctrl parameter which decides how many mem to mem transactions the active job from the job queue can perform. The driver's job_ready() made sure that the number of ready source buffers are sufficient for the job to execute successfully. But it didn't make sure if there are sufficient ready destination buffers in the capture queue for the VPE output. If the time taken by VPE to process a single frame is really slow, then it's possible that we don't need to imply such a restriction on the dst queue, but really fast transactions(small resolution, no de-interlacing) may cause us to hit the condition where we don't have any free buffers for the VPE to write on. Add the extra check in job_ready() to make sure we have the sufficient amount of destination buffers. Acked-by: Kamil Debski <[email protected]> Signed-off-by: Archit Taneja <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2014-04-07[media] lgdt3305: include sleep functionality in lgdt3304_opsShuah Khan1-0/+1
Add sleep ops to lgdt3304_ops to invoke lgdt3305_sleep() to be called from dvb_frontend_suspend(). lgdt3305_soft_reset() is called for both 3304 and 3305 devices. soft_reset and sleep touch LGDT3305_GEN_CTRL_3 on 3304 and 3305 devices. Hence, adding sleep to lgdt3304_ops will help suspend 3304 properly from dvb_frontend_suspend(). Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Michael Krufky <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2014-04-07regulator: s5m8767: Fix carried over ena_gpio assignmentKrzysztof Kozlowski1-0/+1
During registration of regulators if external control for regulator was set in DTS the ena_gpio and ena_gpio_flags fields of regulator_config were set to proper values. However the same regulator_config was used in next iterations of loop so the ena_gpio fields carried over to next regulators. The issue was not observed as ena_gpio is supported only for Buck9 regulator which is often the last regulator parsed from DTS. Be sure to clear ena_gpio config fields before registering the regulator. Fixes: ee1e0994ab1bd (regulator: s5m8767: Use GPIO for controlling Buck9/eMMC) Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2014-04-07[media] drx-j: use customise option correctlyPaul Bolle1-1/+1
The Kconfig entry for "Micronas DRX-J demodulator" defaults to modular if DVB_FE_CUSTOMISE is set. But that Kconfig symbol was replaced with MEDIA_SUBDRV_AUTOSELECT as of v3.7. So use the new symbol. And negate the logic, because MEDIA_SUBDRV_AUTOSELECT's logic is the opposite of the former logic. Signed-off-by: Paul Bolle <[email protected]> Signed-off-by: Michael Krufky <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2014-04-07[media] m88rs2000: fix sparse static warningsMalcolm Priestley1-4/+4
fix the following warnings: m88rs2000.c:300:16: warning: symbol 'm88rs2000_setup' was not declared. Should it be static? m88rs2000.c:318:16: warning: symbol 'm88rs2000_shutdown' was not declared. Should it be static? m88rs2000.c:328:16: warning: symbol 'fe_reset' was not declared. Should it be static? m88rs2000.c:366:16: warning: symbol 'fe_trigger' was not declared. Should it be static? Signed-off-by: Michael Krufky <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2014-04-07[media] r820t: fix size and init valuesBenjamin Larsson1-1/+2
Correct the initialization values at the start of the function and use proper variable sizes to prevent overflow. Signed-off-by: Benjamin Larsson <[email protected]> Signed-off-by: Michael Krufky <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2014-04-07cpufreq: powernv: Select CPUFreq related Kconfig options for powernvGautham R. Shenoy3-0/+8
Enable CPUFreq for PowerNV. Select "performance", "powersave", "userspace" and "ondemand" governors. Choose "ondemand" to be the default governor. Signed-off-by: Srivatsa S. Bhat <[email protected]> Signed-off-by: Gautham R. Shenoy <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2014-04-07cpufreq: powernv: Use cpufreq_frequency_table.driver_data to store pstate idsGautham R. Shenoy1-3/+2
The .driver_data field in the cpufreq_frequency_table was supposed to be private to the drivers. However at some later point, it was being used to indicate if the particular frequency in the table is the BOOST_FREQUENCY. After patches [1] and [2], the .driver_data is once again private to the driver. Thus we can safely use cpufreq_frequency_table.driver_data to store pstate_ids instead of having to maintain a separate array powernv_pstate_ids[] for this purpose. [1]: Subject: cpufreq: don't print value of .driver_data from core From : Viresh Kumar <viresh.kumar@ linaro.org> url : http://marc.info/?l=linux-pm&m=139601421504709&w=2 [2]: Subject: cpufreq: create another field .flags in cpufreq_frequency_table From : Viresh Kumar <[email protected]> url : http://marc.info/?l=linux-pm&m=139601416804702&w=2 Signed-off-by: Gautham R. Shenoy <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2014-04-07cpufreq: powernv: cpufreq driver for powernv platformVaidyanathan Srinivasan4-0/+355
Backend driver to dynamically set voltage and frequency on IBM POWER non-virtualized platforms. Power management SPRs are used to set the required PState. This driver works in conjunction with cpufreq governors like 'ondemand' to provide a demand based frequency and voltage setting on IBM POWER non-virtualized platforms. PState table is obtained from OPAL v3 firmware through device tree. powernv_cpufreq back-end driver would parse the relevant device-tree nodes and initialise the cpufreq subsystem on powernv platform. The code was originally written by [email protected]. Over time it was modified to accomodate bug-fixes as well as updates to the the cpu-freq core. Relevant portions of the change logs corresponding to those modifications are noted below: * The policy->cpus needs to be populated in a hotplug-invariant manner instead of using cpu_sibling_mask() which varies with cpu-hotplug. This is because the cpufreq core code copies this content into policy->related_cpus mask which should not vary on cpu-hotplug. [Authored by [email protected]] * Create a helper routine that can return the cpu-frequency for the corresponding pstate_id. Also, cache the values of the pstate_max, pstate_min and pstate_nominal and nr_pstates in a static structure so that they can be reused in the future to perform any validations. [Authored by [email protected]] * Create a driver attribute named cpuinfo_nominal_freq which creates a sysfs read-only file named cpuinfo_nominal_freq. Export the frequency corresponding to the nominal_pstate through this interface. Nominal frequency is the highest non-turbo frequency for the platform. This is generally used for setting governor policies from user space for optimal energy efficiency. [Authored by [email protected]] * Implement a powernv_cpufreq_get(unsigned int cpu) method which will return the current operating frequency. Export this via the sysfs interface cpuinfo_cur_freq by setting powernv_cpufreq_driver.get to powernv_cpufreq_get(). [Authored by [email protected]] [Change log updated by [email protected]] Reviewed-by: Preeti U Murthy <[email protected]> Signed-off-by: Vaidyanathan Srinivasan <[email protected]> Signed-off-by: Srivatsa S. Bhat <[email protected]> Signed-off-by: Anton Blanchard <[email protected]> Signed-off-by: Gautham R. Shenoy <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2014-04-07cpufreq: at32ap: don't declare local variable as staticViresh Kumar1-1/+1
Earlier commit: commit 652ed95d5fa6074b3c4ea245deb0691f1acb6656 Author: Viresh Kumar <[email protected]> Date: Thu Jan 9 20:38:43 2014 +0530 cpufreq: introduce cpufreq_generic_get() routine did some changes to driver and by mistake made cpuclk as a 'static' local variable, which wasn't actually required. Fix it. Fixes: 652ed95d5fa6 (cpufreq: introduce cpufreq_generic_get() routine) Reported-by: Alexandre Oliva <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Acked-by: Hans-Christian Egtvedt <[email protected]> Cc: 3.14+ <[email protected]> # 3.14+ Signed-off-by: Rafael J. Wysocki <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.