aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-03-03Linux 4.0-rc2Linus Torvalds1-1/+1
2015-03-03drm/i915: Fix modeset state confusion in the load detect codeDaniel Vetter1-0/+1
This is a tricky story of the new atomic state handling and the legacy code fighting over each another. The bug at hand is an underrun of the framebuffer reference with subsequent hilarity caused by the load detect code. Which is peculiar since the the exact same code works fine as the implementation of the legacy setcrtc ioctl. Let's look at the ingredients: - Currently our code is a crazy mix of legacy modeset interfaces to set the parameters and half-baked atomic state tracking underneath. While this transition is going we're using the transitional plane helpers to update the atomic side (drm_plane_helper_disable/update and friends), i.e. plane->state->fb. Since the state structure owns the fb those functions take care of that themselves. The legacy state (specifically crtc->primary->fb) is still managed by the old code (and mostly by the drm core), with the fb reference counting done by callers (core drm for the ioctl or the i915 load detect code). The relevant commit is commit ea2c67bb4affa84080c616920f3899f123786e56 Author: Matt Roper <[email protected]> Date: Tue Dec 23 10:41:52 2014 -0800 drm/i915: Move to atomic plane helpers (v9) - drm_plane_helper_disable has special code to handle multiple calls in a row - it checks plane->crtc == NULL and bails out. This is to match the proper atomic implementation which needs the crtc to get at the implied locking context atomic updates always need. See commit acf24a395c5a9290189b080383564437101d411c Author: Daniel Vetter <[email protected]> Date: Tue Jul 29 15:33:05 2014 +0200 drm/plane-helper: transitional atomic plane helpers - The universal plane code split out the implicit primary plane from the CRTC into it's own full-blown drm_plane object. As part of that the setcrtc ioctl (which updated both the crtc mode and primary plane) learned to set crtc->primary->crtc on modeset to make sure the plane->crtc assignments statate up to date in commit e13161af80c185ecd8dc4641d0f5df58f9e3e0af Author: Matt Roper <[email protected]> Date: Tue Apr 1 15:22:38 2014 -0700 drm: Add drm_crtc_init_with_planes() (v2) Unfortunately we've forgotten to update the load detect code. Which wasn't a problem since the load detect modeset is temporary and always undone before we drop the locks. - Finally there is a organically grown history (i.e. don't ask) around who sets the legacy plane->fb for the various driver entry points. Originally updating that was the drivers duty, but for almost all places we've moved that (plus updating the refcounts) into the core. Again the exception is the load detect code. Taking all together the following happens: - The load detect code doesn't set crtc->primary->crtc. This is only really an issue on crtcs never before used or when userspace explicitly disabled the primary plane. - The plane helper glue code short-circuits because of that and leaves a non-NULL fb behind in plane->state->fb and plane->fb. The state fb isn't a real problem (it's properly refcounted on its own), it's just the canary. - Load detect code drops the reference for that fb, but doesn't set plane->fb = NULL. This is ok since it's still living in that old world where drivers had to clear the pointer but the core/callers handled the refcounting. - On the next modeset the drm core notices plane->fb and takes care of refcounting it properly by doing another unref. This drops the refcount to zero, leaving state->plane now pointing at freed memory. - intel_plane_duplicate_state still assume it owns a reference to that very state->fb and bad things start to happen. Fix this all by applying the same duct-tape as for the legacy setcrtc ioctl code and set crtc->primary->crtc properly. Cc: Matt Roper <[email protected]> Cc: Paul Bolle <[email protected]> Cc: Rob Clark <[email protected]> Cc: Paulo Zanoni <[email protected]> Cc: Sean Paul <[email protected]> Cc: Matt Roper <[email protected]> Reported-and-tested-by: Linus Torvalds <[email protected]> Reported-by: Paul Bolle <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-03-03ASoC: simple-card: Add a NULL pointer check in asoc_simple_card_dai_link_ofVishal Thanki1-0/+5
Make sure devm_kzalloc() succeeds. Signed-off-by: Vishal Thanki <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2015-03-03Revert "drm/rockchip: Flip select/depends in Kconfig"Dave Airlie1-1/+1
This reverts commit 9c58e8dbd3bfe7197323c88a784617afeffa9f87. This doesn't seem to fully fix this, Kbuild who knows. Signed-off-by: Dave Airlie <[email protected]>
2015-03-03drm/rockchip: Flip select/depends in KconfigDaniel Vetter1-1/+1
Otherwise Kconfig gets confused and somehow ends up creating a 2nd drm submenu. I couldn't find i915 because of this any more at first. Cc: Andy Yan <[email protected]> Cc: Russell King <[email protected]> Cc: Philipp Zabel <[email protected]> Cc: "Yann E. MORIN" <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2015-03-03Merge tag 'imx-drm-fixes-2015-02-24' of ↵Dave Airlie4-21/+50
git://git.pengutronix.de/git/pza/linux into drm-fixes imx-drm fixes for mode fixup, dw_hdmi/imx, and parallel-display - A clock fix for too large pixel clocks depending on the DI clock flag simplification patch - Pruning of unsupported modes and a missing end of array element for dw_hdmi-imx - LVDS modeset fix for mode fixup - Fix parallel-display deferred probing if drm_panel is used * tag 'imx-drm-fixes-2015-02-24' of git://git.pengutronix.de/git/pza/linux: DRM: i.MX: parallel display: Support probe deferral for finding DRM panel drm/imx: imx-ldb: enable DI clock in encoder_mode_set drm/imx: dw_hdmi-imx: add end of array element to current control array drm/imx: dw_hdmi-imx: add mode_valid callback prune unsupported modes gpu: ipu-v3: do not divide by zero if the pixel clock is too large
2015-03-03eCryptfs: don't pass fs-specific ioctl commands throughTyler Hicks1-4/+30
eCryptfs can't be aware of what to expect when after passing an arbitrary ioctl command through to the lower filesystem. The ioctl command may trigger an action in the lower filesystem that is incompatible with eCryptfs. One specific example is when one attempts to use the Btrfs clone ioctl command when the source file is in the Btrfs filesystem that eCryptfs is mounted on top of and the destination fd is from a new file created in the eCryptfs mount. The ioctl syscall incorrectly returns success because the command is passed down to Btrfs which thinks that it was able to do the clone operation. However, the result is an empty eCryptfs file. This patch allows the trim, {g,s}etflags, and {g,s}etversion ioctl commands through and then copies up the inode metadata from the lower inode to the eCryptfs inode to catch any changes made to the lower inode's metadata. Those five ioctl commands are mostly common across all filesystems but the whitelist may need to be further pruned in the future. https://bugzilla.kernel.org/show_bug.cgi?id=93691 https://launchpad.net/bugs/1305335 Signed-off-by: Tyler Hicks <[email protected]> Cc: Rocko <[email protected]> Cc: Colin Ian King <[email protected]> Cc: [email protected] # v2.6.36+: c43f7b8 eCryptfs: Handle ioctl calls with unlocked and compat functions
2015-03-03usb: ftdi_sio: Add jtag quirk support for Cyber Cortex AV boardsMax Mansfield2-0/+5
This patch integrates Cyber Cortex AV boards with the existing ftdi_jtag_quirk in order to use serial port 0 with JTAG which is required by the manufacturers' software. Steps: 2 [ftdi_sio_ids.h] 1. Defined the device PID [ftdi_sio.c] 2. Added a macro declaration to the ids array, in order to enable the jtag quirk for the device. Signed-off-by: Max Mansfield <[email protected]> Cc: stable <[email protected]> Signed-off-by: Johan Hovold <[email protected]>
2015-03-02udp: only allow UFO for packets from SOCK_DGRAM socketsMichal Kubeček2-2/+4
If an over-MTU UDP datagram is sent through a SOCK_RAW socket to a UFO-capable device, ip_ufo_append_data() sets skb->ip_summed to CHECKSUM_PARTIAL unconditionally as all GSO code assumes transport layer checksum is to be computed on segmentation. However, in this case, skb->csum_start and skb->csum_offset are never set as raw socket transmit path bypasses udp_send_skb() where they are usually set. As a result, driver may access invalid memory when trying to calculate the checksum and store the result (as observed in virtio_net driver). Moreover, the very idea of modifying the userspace provided UDP header is IMHO against raw socket semantics (I wasn't able to find a document clearly stating this or the opposite, though). And while allowing CHECKSUM_NONE in the UFO case would be more efficient, it would be a bit too intrusive change just to handle a corner case like this. Therefore disallowing UFO for packets from SOCK_DGRAM seems to be the best option. Signed-off-by: Michal Kubecek <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-03-02Merge branch 'sh_eth'David S. Miller1-5/+10
Ben Hutchings says: ==================== Fixes for sh_eth #4 v2 I'm continuing review and testing of Ethernet support on the R-Car H2 chip, with help from a colleague. This series fixes a few more issues. These are not tested on any of the other supported chips. v2: Add note that the revert is not a pure revert. ==================== Signed-off-by: David S. Miller <[email protected]>
2015-03-02sh_eth: Really fix padding of short frames on TXBen Hutchings1-1/+1
My previous fix to clear padding of short frames used skb->len as the DMA length, assuming that skb_padto() extended skb->len to include the padding. That isn't the case; we need to use skb_put_padto() instead. (This wasn't immediately obvious because software padding isn't actually needed on the R-Car H2. We could make it conditional on which chip is being driven, but it's probably not worth the effort.) Reported-by: "Violeta Menéndez González" <[email protected]> Fixes: 612a17a54b50 ("sh_eth: Fix padding of short frames on TX") Signed-off-by: Ben Hutchings <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-03-02Revert "sh_eth: Enable Rx descriptor word 0 shift for r8a7790"Ben Hutchings1-3/+2
This reverts commit fd9af07c3404ac9ecbd0d859563360f51ce1ffde. The hardware manual states that the frame error and multicast bits are copied to bits 9:0 of RD0, not bits 25:16. I've tested that this is true for RFS1 (CRC error), RFS3 (frame too short), RFS4 (frame too long) and RFS8 (multicast). Also adjust a comment to agree with this. Signed-off-by: Ben Hutchings <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-03-02sh_eth: Fix RX recovery on R-Car in case of RX ring underrunBen Hutchings1-1/+1
In case of RX ring underrun (RDE), we attempt to reset the software descriptor pointers (dirty_rx and cur_rx) to match where the hardware will read the next descriptor from, as that might not be the first dirty descriptor. This relies on reading RDFAR, but that register doesn't exist on all supported chips - specifically, not on the R-Car chips. This will result in unpredictable behaviour on those chips after an RDE. Make this pointer reset conditional and assume that it isn't needed on the R-Car chips. This fix also assumes that RDFAR is never exposed at offset 0 in the memory map - this is currently true, and a subsequent commit will fix the ambiguity between offset 0 and no-offset in the register offset maps. Fixes: 79fba9f51755 ("net: sh_eth: fix the rxdesc pointer when rx ...") Signed-off-by: Ben Hutchings <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-03-02sh_eth: Ensure proper ordering of descriptor active bit write/readBen Hutchings1-0/+6
When submitting a DMA descriptor, the active bit must be written last. When reading a completed DMA descriptor, the active bit must be read first. Add memory barriers to ensure that this ordering is maintained. Signed-off-by: Ben Hutchings <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-03-02Merge branch 'fixes' of github.com:lmajewski/linux-samsung-thermal into ↵Eduardo Valentin3-16/+16
work-fixes Pull samsung thermal fixes from Lukasz Majewski: "Changes: - Exynos7 power down detection mode fix - Fix for cpufreq cooling device regression - Updating MAINTAINER's entry for Samsung Exynos Thermal" Signed-off-by: Eduardo Valentin <[email protected]>
2015-03-03livepatch: fix RCU usage in klp_find_external_symbol()Peter Zijlstra1-1/+2
While one must hold RCU-sched (aka. preempt_disable) for find_symbol() one must equally hold it over the use of the object returned. The moment you release the RCU-sched read lock, the object can be dead and gone. [[email protected]: change subject line to be aligned with other patches] Cc: Seth Jennings <[email protected]> Cc: Josh Poimboeuf <[email protected]> Cc: Masami Hiramatsu <[email protected]> Cc: Miroslav Benes <[email protected]> Cc: Petr Mladek <[email protected]> Cc: Jiri Kosina <[email protected]> Cc: "Paul E. McKenney" <[email protected]> Cc: Rusty Russell <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Masami Hiramatsu <[email protected]> Acked-by: Paul E. McKenney <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2015-03-02NFSv4: Ensure we skip delegations that are already being returnedTrond Myklebust1-0/+6
In nfs_client_return_marked_delegations() and nfs_delegation_reap_unclaimed() we want to optimise the loop traversal by skipping delegations that are already in the process of being returned. Signed-off-by: Trond Myklebust <[email protected]>
2015-03-02NFSv4: Pin the superblock while we're returning the delegationTrond Myklebust1-4/+16
This patch ensures that the superblock doesn't go ahead and disappear underneath us while the state manager thread is returning delegations. Signed-off-by: Trond Myklebust <[email protected]>
2015-03-02NFSv4: Ensure we honour NFS_DELEGATION_RETURNING in nfs_inode_set_delegation()Trond Myklebust1-1/+4
Ensure that nfs_inode_set_delegation() doesn't inadvertently detach a delegation that is already in the process of being returned. Signed-off-by: Trond Myklebust <[email protected]>
2015-03-02NFSv4: Ensure that we don't reap a delegation that is being returnedTrond Myklebust1-5/+7
Signed-off-by: Trond Myklebust <[email protected]>
2015-03-02NFS: Fix stateid used for NFS v4 closesAnna Schumaker1-2/+2
After 566fcec60 the client uses the "current stateid" from the nfs4_state structure to close a file. This could potentially contain a delegation stateid, which is disallowed by the protocol and causes servers to return NFS4ERR_BAD_STATEID. This patch restores the (correct) behavior of sending the open stateid to close a file. Reported-by: Olga Kornievskaia <[email protected]> Fixes: 566fcec60 (NFSv4: Fix an atomicity problem in CLOSE) Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Trond Myklebust <[email protected]>
2015-03-02KVM: MIPS: Enable after disabling interruptTapasweni Pathak1-0/+1
Enable disabled interrupt, on unsuccessful operation. Found by Coccinelle. Signed-off-by: Tapasweni Pathak <[email protected]> Acked-by: Julia Lawall <[email protected]> Reviewed-by: James Hogan <[email protected]> Signed-off-by: Marcelo Tosatti <[email protected]>
2015-03-02KVM: MIPS: Fix trace event to save PC directlyJames Hogan1-3/+3
Currently the guest exit trace event saves the VCPU pointer to the structure, and the guest PC is retrieved by dereferencing it when the event is printed rather than directly from the trace record. This isn't safe as the printing may occur long afterwards, after the PC has changed and potentially after the VCPU has been freed. Usually this results in the same (wrong) PC being printed for multiple trace events. It also isn't portable as userland has no way to access the VCPU data structure when interpreting the trace record itself. Lets save the actual PC in the structure so that the correct value is accessible later. Fixes: 669e846e6c4e ("KVM/MIPS32: MIPS arch specific APIs for KVM") Signed-off-by: James Hogan <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: Ralf Baechle <[email protected]> Cc: Marcelo Tosatti <[email protected]> Cc: Gleb Natapov <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: [email protected] Cc: [email protected] Cc: <[email protected]> # v3.10+ Acked-by: Steven Rostedt <[email protected]> Signed-off-by: Marcelo Tosatti <[email protected]>
2015-03-02Merge tag 'gpio-v4.0-2' of ↵Linus Torvalds2-8/+15
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO fixes from Linus Walleij: "Two GPIO fixes: - Fix a translation problem in of_get_named_gpiod_flags() - Fix a long standing container_of() mistake in the TPS65912 driver" * tag 'gpio-v4.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpio: tps65912: fix wrong container_of arguments gpiolib: of: allow of_gpiochip_find_and_xlate to find more than one chip per node
2015-03-02Merge branch 'fixes-for-4.0-rc2' of ↵Linus Torvalds12-67/+145
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal Pull thermal management fixes from Eduardo Valentin: "Specifics: - Several fixes in tmon tool. - Fixes in intel int340x for _ART and _TRT tables. - Add id for Avoton SoC into powerclamp driver. - Fixes in RCAR thermal driver to remove race conditions and fix fail path - Fixes in TI thermal driver: removal of unnecessary code and build fix if !CONFIG_PM_SLEEP - Cleanups in exynos thermal driver - Add stubs for include/linux/thermal.h. Now drivers using thermal calls but that also work without CONFIG_THERMAL will be able to compile for systems that don't care about thermal. Note: I am sending this pull on Rui's behalf while he fixes issues in his Linux box" * 'fixes-for-4.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal: thermal: int340x_thermal: Ignore missing _ART, _TRT tables thermal/intel_powerclamp: add id for Avoton SoC tools/thermal: tmon: silence 'set but not used' warnings tools/thermal: tmon: use pkg-config to determine library dependencies tools/thermal: tmon: support cross-compiling tools/thermal: tmon: add .gitignore tools/thermal: tmon: fixup tui windowing calculations tools/thermal: tmon: tui: don't hard-code dialog window size assumptions tools/thermal: tmon: add min/max macros tools/thermal: tmon: add --target-temp parameter thermal: exynos: Clean-up code to use oneline entry for exynos compatible table thermal: rcar: Make error and remove paths symmetrical with init thermal: rcar: Fix race condition between init and interrupt thermal: Introduce dummy functions when thermal is not defined ti-soc-thermal: Delete an unnecessary check before the function call "cpufreq_cooling_unregister" thermal: ti-soc-thermal: bandgap: Fix build warning if !CONFIG_PM_SLEEP
2015-03-02Btrfs: incremental send, don't rename a directory too soonFilipe Manana1-15/+156
There's one more case where we can't issue a rename operation for a directory as soon as we process it. We used to delay directory renames only if they have some ancestor directory with a higher inode number that got renamed too, but there's another case where we need to delay the rename too - when a directory A is renamed to the old name of a directory B but that directory B has its rename delayed because it has now (in the send root) an ancestor with a higher inode number that was renamed. If we don't delay the directory rename in this case, the receiving end of the send stream will attempt to rename A to the old name of B before B got renamed to its new name, which results in a "directory not empty" error. So fix this by delaying directory renames for this case too. Steps to reproduce: $ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /mnt $ mkdir /mnt/a $ mkdir /mnt/b $ mkdir /mnt/c $ touch /mnt/a/file $ btrfs subvolume snapshot -r /mnt /mnt/snap1 $ mv /mnt/c /mnt/x $ mv /mnt/a /mnt/x/y $ mv /mnt/b /mnt/a $ btrfs subvolume snapshot -r /mnt /mnt/snap2 $ btrfs send /mnt/snap1 -f /tmp/1.send $ btrfs send -p /mnt/snap1 /mnt/snap2 -f /tmp/2.send $ mkfs.btrfs -f /dev/sdc $ mount /dev/sdc /mnt2 $ btrfs receive /mnt2 -f /tmp/1.send $ btrfs receive /mnt2 -f /tmp/2.send ERROR: rename b -> a failed. Directory not empty A test case for xfstests follows soon. Reported-by: Ames Cornish <[email protected]> Signed-off-by: Filipe Manana <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2015-03-02btrfs: fix lost return value due to variable shadowingDavid Sterba1-1/+0
A block-local variable stores error code but btrfs_get_blocks_direct may not return it in the end as there's a ret defined in the function scope. CC: <[email protected]> # 3.6+ Fixes: d187663ef24c ("Btrfs: lock extents as we map them in DIO") Signed-off-by: David Sterba <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2015-03-02Btrfs: do not ignore errors from btrfs_lookup_xattr in do_setxattrFilipe Manana1-2/+6
The return value from btrfs_lookup_xattr() can be a pointer encoding an error, therefore deal with it. This fixes commit 5f5bc6b1e2d5 ("Btrfs: make xattr replace operations atomic"). Signed-off-by: Filipe Manana <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2015-03-02Btrfs: fix off-by-one logic error in btrfs_realloc_nodeFilipe Manana1-4/+4
The end_slot variable actually matches the number of pointers in the node and not the last slot (which is 'nritems - 1'). Therefore in order to check that the current slot in the for loop doesn't match the last one, the correct logic is to check if 'i' is less than 'end_slot - 1' and not 'end_slot - 2'. Fix this and set end_slot to be 'nritems - 1', as it's less confusing since the variable name implies it's inclusive rather then exclusive. Signed-off-by: Filipe Manana <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2015-03-02Btrfs: add missing inode update when punching holeFilipe Manana1-3/+28
When punching a file hole if we endup only zeroing parts of a page, because the start offset isn't a multiple of the sector size or the start offset and length fall within the same page, we were not updating the inode item. This prevented an fsync from doing anything, if no other file changes happened in the current transaction, because the fields in btrfs_inode used to check if the inode needs to be fsync'ed weren't updated. This issue is easy to reproduce and the following excerpt from the xfstest case I made shows how to trigger it: _scratch_mkfs >> $seqres.full 2>&1 _init_flakey _mount_flakey # Create our test file. $XFS_IO_PROG -f -c "pwrite -S 0x22 -b 16K 0 16K" \ $SCRATCH_MNT/foo | _filter_xfs_io # Fsync the file, this makes btrfs update some btrfs inode specific fields # that are used to track if the inode needs to be written/updated to the fsync # log or not. After this fsync, the new values for those fields indicate that # a subsequent fsync does not need to touch the fsync log. $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foo # Force a commit of the current transaction. After this point, any operation # that modifies the data or metadata of our file, should update those fields in # the btrfs inode with values that make the next fsync operation write to the # fsync log. sync # Punch a hole in our file. This small range affects only 1 page. # This made the btrfs hole punching implementation write only some zeroes in # one page, but it did not update the btrfs inode fields used to determine if # the next fsync needs to write to the fsync log. $XFS_IO_PROG -c "fpunch 8000 4K" $SCRATCH_MNT/foo # Another variation of the previously mentioned case. $XFS_IO_PROG -c "fpunch 15000 100" $SCRATCH_MNT/foo # Now fsync the file. This was a no-operation because the previous hole punch # operation didn't update the inode's fields mentioned before, so they remained # with the values they had after the first fsync - that is, they indicate that # it is not needed to write to fsync log. $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foo echo "File content before:" od -t x1 $SCRATCH_MNT/foo # Simulate a crash/power loss. _load_flakey_table $FLAKEY_DROP_WRITES _unmount_flakey # Enable writes and mount the fs. This makes the fsync log replay code run. _load_flakey_table $FLAKEY_ALLOW_WRITES _mount_flakey # Because the last fsync didn't do anything, here the file content matched what # it was after the first fsync, before the holes were punched, and not what it # was after the holes were punched. echo "File content after:" od -t x1 $SCRATCH_MNT/foo This issue has been around since 2012, when the punch hole implementation was added, commit 2aaa66558172 ("Btrfs: add hole punching"). A test case for xfstests follows soon. Signed-off-by: Filipe Manana <[email protected]> Reviewed-by: Liu Bo <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2015-03-02Btrfs: abort the transaction if we fail to update the free space cache inodeJosef Bacik1-0/+16
Our gluster boxes were hitting a problem where they'd run out of space when updating the block group cache and therefore wouldn't be able to update the free space inode. This is a problem because this is how we invalidate the cache and protect ourselves from errors further down the stack, so if this fails we have to abort the transaction so we make sure we don't end up with stale free space cache. Thanks, Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2015-03-02Btrfs: fix fsync race leading to ordered extent memory leaksFilipe Manana1-5/+2
We can have multiple fsync operations against the same file during the same transaction and they can collect the same ordered extents while they don't complete (still accessible from the inode's ordered tree). If this happens, those ordered extents will never get their reference counts decremented to 0, leading to memory leaks and inode leaks (an iput for an ordered extent's inode is scheduled only when the ordered extent's refcount drops to 0). The following sequence diagram explains this race: CPU 1 CPU 2 btrfs_sync_file() btrfs_sync_file() mutex_lock(inode->i_mutex) btrfs_log_inode() btrfs_get_logged_extents() --> collects ordered extent X --> increments ordered extent X's refcount btrfs_submit_logged_extents() mutex_unlock(inode->i_mutex) mutex_lock(inode->i_mutex) btrfs_sync_log() btrfs_wait_logged_extents() --> list_del_init(&ordered->log_list) btrfs_log_inode() btrfs_get_logged_extents() --> Adds ordered extent X to logged_list because at this point: list_empty(&ordered->log_list) && test_bit(BTRFS_ORDERED_LOGGED, &ordered->flags) == 0 --> Increments ordered extent X's refcount --> check if ordered extent's io is finished or not, start it if necessary and wait for it to finish --> sets bit BTRFS_ORDERED_LOGGED on ordered extent X's flags and adds it to trans->ordered btrfs_sync_log() finishes btrfs_submit_logged_extents() btrfs_log_inode() finishes mutex_unlock(inode->i_mutex) btrfs_sync_file() finishes btrfs_sync_log() btrfs_wait_logged_extents() --> Sees ordered extent X has the bit BTRFS_ORDERED_LOGGED set in its flags --> X's refcount is untouched btrfs_sync_log() finishes btrfs_sync_file() finishes btrfs_commit_transaction() --> called by transaction kthread for e.g. btrfs_wait_pending_ordered() --> waits for ordered extent X to complete --> decrements ordered extent X's refcount by 1 only, corresponding to the increment done by the fsync task ran by CPU 1 In the scenario of the above diagram, after the transaction commit, the ordered extent will remain with a refcount of 1 forever, leaking the ordered extent structure and preventing the i_count of its inode from ever decreasing to 0, since the delayed iput is scheduled only when the ordered extent's refcount drops to 0, preventing the inode from ever being evicted by the VFS. Fix this by using the flag BTRFS_ORDERED_LOGGED differently. Use it to mean that an ordered extent is already being processed by an fsync call, which will attach it to the current transaction, preventing it from being collected by subsequent fsync operations against the same inode. This race was introduced with the following change (added in 3.19 and backported to stable 3.18 and 3.17): Btrfs: make sure logged extents complete in the current transaction V3 commit 50d9aa99bd35c77200e0e3dd7a72274f8304701f I ran into this issue while running xfstests/generic/113 in a loop, which failed about 1 out of 10 runs with the following warning in dmesg: [ 2612.440038] WARNING: CPU: 4 PID: 22057 at fs/btrfs/disk-io.c:3558 free_fs_root+0x36/0x133 [btrfs]() [ 2612.442810] Modules linked in: btrfs crc32c_generic xor raid6_pq nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc loop processor parport_pc parport psmouse therma l_sys i2c_piix4 serio_raw pcspkr evdev microcode button i2c_core ext4 crc16 jbd2 mbcache sd_mod sg sr_mod cdrom virtio_scsi ata_generic virtio_pci ata_piix virtio_ring libata virtio flo ppy e1000 scsi_mod [last unloaded: btrfs] [ 2612.452711] CPU: 4 PID: 22057 Comm: umount Tainted: G W 3.19.0-rc5-btrfs-next-4+ #1 [ 2612.454921] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 [ 2612.457709] 0000000000000009 ffff8801342c3c78 ffffffff8142425e ffff88023ec8f2d8 [ 2612.459829] 0000000000000000 ffff8801342c3cb8 ffffffff81045308 ffff880046460000 [ 2612.461564] ffffffffa036da56 ffff88003d07b000 ffff880046460000 ffff880046460068 [ 2612.463163] Call Trace: [ 2612.463719] [<ffffffff8142425e>] dump_stack+0x4c/0x65 [ 2612.464789] [<ffffffff81045308>] warn_slowpath_common+0xa1/0xbb [ 2612.466026] [<ffffffffa036da56>] ? free_fs_root+0x36/0x133 [btrfs] [ 2612.467247] [<ffffffff810453c5>] warn_slowpath_null+0x1a/0x1c [ 2612.468416] [<ffffffffa036da56>] free_fs_root+0x36/0x133 [btrfs] [ 2612.469625] [<ffffffffa036f2a7>] btrfs_drop_and_free_fs_root+0x93/0x9b [btrfs] [ 2612.471251] [<ffffffffa036f353>] btrfs_free_fs_roots+0xa4/0xd6 [btrfs] [ 2612.472536] [<ffffffff8142612e>] ? wait_for_completion+0x24/0x26 [ 2612.473742] [<ffffffffa0370bbc>] close_ctree+0x1f3/0x33c [btrfs] [ 2612.475477] [<ffffffff81059d1d>] ? destroy_workqueue+0x148/0x1ba [ 2612.476695] [<ffffffffa034e3da>] btrfs_put_super+0x19/0x1b [btrfs] [ 2612.477911] [<ffffffff81153e53>] generic_shutdown_super+0x73/0xef [ 2612.479106] [<ffffffff811540e2>] kill_anon_super+0x13/0x1e [ 2612.480226] [<ffffffffa034e1e3>] btrfs_kill_super+0x17/0x23 [btrfs] [ 2612.481471] [<ffffffff81154307>] deactivate_locked_super+0x3b/0x50 [ 2612.482686] [<ffffffff811547a7>] deactivate_super+0x3f/0x43 [ 2612.483791] [<ffffffff8116b3ed>] cleanup_mnt+0x59/0x78 [ 2612.484842] [<ffffffff8116b44c>] __cleanup_mnt+0x12/0x14 [ 2612.485900] [<ffffffff8105d019>] task_work_run+0x8f/0xbc [ 2612.486960] [<ffffffff810028d8>] do_notify_resume+0x5a/0x6b [ 2612.488083] [<ffffffff81236e5b>] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 2612.489333] [<ffffffff8142a17f>] int_signal+0x12/0x17 [ 2612.490353] ---[ end trace 54a960a6bdcb8d93 ]--- [ 2612.557253] VFS: Busy inodes after unmount of sdb. Self-destruct in 5 seconds. Have a nice day... Kmemleak confirmed the ordered extent leak (and btrfs inode specific structures such as delayed nodes): $ cat /sys/kernel/debug/kmemleak unreferenced object 0xffff880154290db0 (size 576): comm "btrfsck", pid 21980, jiffies 4295542503 (age 1273.412s) hex dump (first 32 bytes): 01 40 00 00 01 00 00 00 b0 1d f1 4e 01 88 ff ff [email protected].... 00 00 00 00 00 00 00 00 c8 0d 29 54 01 88 ff ff ..........)T.... backtrace: [<ffffffff8141d74d>] kmemleak_update_trace+0x4c/0x6a [<ffffffff8122f2c0>] radix_tree_node_alloc+0x6d/0x83 [<ffffffff8122fb26>] __radix_tree_create+0x109/0x190 [<ffffffff8122fbdd>] radix_tree_insert+0x30/0xac [<ffffffffa03b9bde>] btrfs_get_or_create_delayed_node+0x130/0x187 [btrfs] [<ffffffffa03bb82d>] btrfs_delayed_delete_inode_ref+0x32/0xac [btrfs] [<ffffffffa0379dae>] __btrfs_unlink_inode+0xee/0x288 [btrfs] [<ffffffffa037c715>] btrfs_unlink_inode+0x1e/0x40 [btrfs] [<ffffffffa037c797>] btrfs_unlink+0x60/0x9b [btrfs] [<ffffffff8115d7f0>] vfs_unlink+0x9c/0xed [<ffffffff8115f5de>] do_unlinkat+0x12c/0x1fa [<ffffffff811601a7>] SyS_unlinkat+0x29/0x2b [<ffffffff81429e92>] system_call_fastpath+0x12/0x17 [<ffffffffffffffff>] 0xffffffffffffffff unreferenced object 0xffff88014ef11db0 (size 576): comm "rm", pid 22009, jiffies 4295542593 (age 1273.052s) hex dump (first 32 bytes): 02 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 c8 1d f1 4e 01 88 ff ff ...........N.... backtrace: [<ffffffff8141d74d>] kmemleak_update_trace+0x4c/0x6a [<ffffffff8122f2c0>] radix_tree_node_alloc+0x6d/0x83 [<ffffffff8122fb26>] __radix_tree_create+0x109/0x190 [<ffffffff8122fbdd>] radix_tree_insert+0x30/0xac [<ffffffffa03b9bde>] btrfs_get_or_create_delayed_node+0x130/0x187 [btrfs] [<ffffffffa03bb82d>] btrfs_delayed_delete_inode_ref+0x32/0xac [btrfs] [<ffffffffa0379dae>] __btrfs_unlink_inode+0xee/0x288 [btrfs] [<ffffffffa037c715>] btrfs_unlink_inode+0x1e/0x40 [btrfs] [<ffffffffa037c797>] btrfs_unlink+0x60/0x9b [btrfs] [<ffffffff8115d7f0>] vfs_unlink+0x9c/0xed [<ffffffff8115f5de>] do_unlinkat+0x12c/0x1fa [<ffffffff811601a7>] SyS_unlinkat+0x29/0x2b [<ffffffff81429e92>] system_call_fastpath+0x12/0x17 [<ffffffffffffffff>] 0xffffffffffffffff unreferenced object 0xffff8800336feda8 (size 584): comm "aio-stress", pid 22031, jiffies 4295543006 (age 1271.400s) hex dump (first 32 bytes): 00 40 3e 00 00 00 00 00 00 00 8f 42 00 00 00 00 .@>........B.... 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00 ................ backtrace: [<ffffffff8114eb34>] create_object+0x172/0x29a [<ffffffff8141d790>] kmemleak_alloc+0x25/0x41 [<ffffffff81141ae6>] kmemleak_alloc_recursive.constprop.52+0x16/0x18 [<ffffffff81145288>] kmem_cache_alloc+0xf7/0x198 [<ffffffffa0389243>] __btrfs_add_ordered_extent+0x43/0x309 [btrfs] [<ffffffffa038968b>] btrfs_add_ordered_extent_dio+0x12/0x14 [btrfs] [<ffffffffa03810e2>] btrfs_get_blocks_direct+0x3ef/0x571 [btrfs] [<ffffffff81181349>] do_blockdev_direct_IO+0x62a/0xb47 [<ffffffff8118189a>] __blockdev_direct_IO+0x34/0x36 [<ffffffffa03776e5>] btrfs_direct_IO+0x16a/0x1e8 [btrfs] [<ffffffff81100373>] generic_file_direct_write+0xb8/0x12d [<ffffffffa038615c>] btrfs_file_write_iter+0x24b/0x42f [btrfs] [<ffffffff8118bb0d>] aio_run_iocb+0x2b7/0x32e [<ffffffff8118c99a>] do_io_submit+0x26e/0x2ff [<ffffffff8118ca3b>] SyS_io_submit+0x10/0x12 [<ffffffff81429e92>] system_call_fastpath+0x12/0x17 CC: <[email protected]> # 3.19, 3.18 and 3.17 Signed-off-by: Filipe Manana <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2015-03-02KVM: SVM: fix interrupt injection (apic->isr_count always 0)Radim Krčmář2-8/+2
In commit b4eef9b36db4, we started to use hwapic_isr_update() != NULL instead of kvm_apic_vid_enabled(vcpu->kvm). This didn't work because SVM had it defined and "apicv" path in apic_{set,clear}_isr() does not change apic->isr_count, because it should always be 1. The initial value of apic->isr_count was based on kvm_apic_vid_enabled(vcpu->kvm), which is always 0 for SVM, so KVM could have injected interrupts when it shouldn't. Fix it by implicitly setting SVM's hwapic_isr_update to NULL and make the initial isr_count depend on hwapic_isr_update() for good measure. Fixes: b4eef9b36db4 ("kvm: x86: vmx: NULL out hwapic_isr_update() in case of !enable_apicv") Reported-and-tested-by: Borislav Petkov <[email protected]> Signed-off-by: Radim Krčmář <[email protected]> Signed-off-by: Marcelo Tosatti <[email protected]>
2015-03-02Merge tag 'md/4.0-fixes' of git://neil.brown.name/mdLinus Torvalds3-12/+20
Pull md fixes from Neil Brown: "Three md fixes: - fix a read-balance problem that was reported 2 years ago, but that I never noticed the report :-( - fix for rare RAID6 problem causing incorrect bitmap updates when two devices fail. - add __ATTR_PREALLOC annotation now that it is possible" * tag 'md/4.0-fixes' of git://neil.brown.name/md: md: mark some attributes as pre-alloc raid5: check faulty flag for array status during recovery. md/raid1: fix read balance when a drive is write-mostly.
2015-03-02Merge tag 'metag-fixes-v4.0-1' of ↵Linus Torvalds1-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/metag Pull arch/metag fix from James Hogan: "This is just a single patch to fix the KSTK_EIP() and KSTK_ESP() macros for metag which have always been erronously returning the PC and stack pointer of the task's kernel context rather than from its user context saved at entry from userland into the kernel, which affects the contents of /proc/<pid>/maps and /proc/<pid>/stat" * tag 'metag-fixes-v4.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/metag: metag: Fix KSTK_EIP() and KSTK_ESP() macros
2015-03-02cpuidle: Clean up fallback handling in cpuidle_idle_call()Rafael J. Wysocki1-14/+15
Move the fallback code path in cpuidle_idle_call() to the end of the function to avoid jumping to a label in an if () branch. Signed-off-by: Rafael J. Wysocki <[email protected]>
2015-03-02Merge branch 'mlx4'David S. Miller4-6/+14
Or Gerlitz says: ==================== Mellanox driver fixes Two small fixes, please apply to net. Both patches should go to 3.19.y too. ==================== Signed-off-by: David S. Miller <[email protected]>
2015-03-02net/mlx4_en: Disbale GRO for incoming loopback/selftest packetsIdo Shamay1-1/+7
Packets which are sent from the selftest (ethtool) flow, should not be passed to GRO stack but rather dropped by the driver after validation. To achieve that, we disable GRO for the duration of the selftest. Fixes: dd65beac48a5 ("net/mlx4_en: Extend usage of napi_gro_frags") Reported-by: Carol Soto <[email protected]> Signed-off-by: Ido Shamay <[email protected]> Signed-off-by: Or Gerlitz <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-03-02net/mlx4_core: Fix wrong mask and error flow for the update-qp commandOr Gerlitz3-5/+7
The bit mask for currently supported driver features (MLX4_UPDATE_QP_SUPPORTED_ATTRS) of the update-qp command was defined twice (using enum value and pre-processor define directive) and wrong. The return value of the call to mlx4_update_qp() from within the SRIOV resource-tracker was wrongly voided down. Fix both issues. issue: none Fixes: 09e05c3f78e9 ('net/mlx4: Set vlan stripping policy by the right command') Fixes: ce8d9e0d6746 ('net/mlx4_core: Add UPDATE_QP SRIOV wrapper support') Signed-off-by: Matan Barak <[email protected]> Signed-off-by: Or Gerlitz <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-03-02dmaengine: shdma: Move DMA stop to (runtime) suspend callbacksGeert Uytterhoeven1-8/+7
During system reboot, the sh-dma-engine device may be runtime-suspended, causing a crash: Unhandled fault: imprecise external abort (0x1406) at 0x0002c02c Internal error: : 1406 [#1] SMP ARM ... PC is at sh_dmae_ctl_stop+0x28/0x64 LR is at sh_dmae_ctl_stop+0x24/0x64 If the sh-dma-engine is runtime-suspended, its module clock is turned off, and its registers cannot be accessed. To fix this, move the call to sh_dmae_ctl_stop(), which touches the DMAOR register, to the sh_dmae_suspend() and sh_dmae_runtime_suspend() callbacks. This makes PM operations more symmetric, as both sh_dmae_resume() and sh_dmae_runtime_resume() already call sh_dmae_rst() to re-initialize the DMAOR register. Remove sh_dmae_shutdown(), as it became empty. Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Ulf Hansson <[email protected]> Signed-off-by: Vinod Koul <[email protected]>
2015-03-02ASoC: sam9g20_wm8731: drop machine_is_xxxAlexandre Belloni1-37/+31
Atmel based boards can now only be used with device tree. Drop non DT initialization. Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2015-03-02Merge tag 'efi-urgent' of ↵Ingo Molnar2-12/+13
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into x86/urgent Pull EFI fixes from Matt Fleming: " - Fix regression in DMI sysfs code for handling "End of Table" entry and a type bug that could lead to integer overflow. (Ivan Khoronzhuk) - Fix boundary checking in efi_high_alloc() which can lead to memory corruption in the EFI boot stubs. (Yinghai Lu)" Signed-off-by: Ingo Molnar <[email protected]>
2015-03-02MAINTAINERS: Add entry for SAMSUNG THERMAL DRIVERLukasz Majewski1-0/+8
This patch adds entry for SAMSUNG THERMAL DRIVER in the MAINTAINERS file. It has been agreed, that pull request are going to be sent to Eduardo Valentin. Signed-off-by: Lukasz Majewski <[email protected]> Acked-by: Eduardo Valentin <[email protected]>
2015-03-02cpufreq: exynos: Use simple approach to asses if cpu cooling can be usedLukasz Majewski1-15/+6
Commit: e725d26c4857e5e41975b5e74e64ce6ab09a7121 provided possibility to use device tree to asses if cpu can be used as cooling device. Since the code was somewhat awkward, simpler approach has been proposed. Test HW: Exynos 4412 - Odroid U3. Suggested-by: Viresh Kumar <[email protected]> Signed-off-by: Lukasz Majewski <[email protected]> Acked-by: Viresh Kumar <[email protected]>
2015-03-02thermal: exynos: Fix wrong control of power down detection mode for Exynos7Chanwoo Choi1-1/+2
This patch fixes the wrong control of PD_DET_EN (power down detection mode) for Exynos7 because exynos7_tmu_control() always enables the power down detection mode regardless 'on' parameter. Cc: Zhang Rui <[email protected]> Cc: Eduardo Valentin <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]> Tested-by: Abhilash Kesavan <[email protected]> Signed-off-by: Lukasz Majewski <[email protected]>
2015-03-02USB: ch341: set tty baud speed according to tty structNicolas PLANEL1-9/+6
The ch341_set_baudrate() function initialize the device baud speed according to the value on priv->baud_rate. By default the ch341_open() set it to a hardcoded value (DEFAULT_BAUD_RATE 9600). Unfortunately, the tty_struct is not initialized with the same default value. (usually 56700) This means that the tty_struct and the device baud rate generator are not synchronized after opening the port. Fixup is done by calling ch341_set_termios() if tty exist. Remove unnecessary variable priv->baud_rate setup as it's already done by ch341_port_probe(). Remove unnecessary call to ch341_set_{handshake,baudrate}() in ch341_open() as there already called in ch341_configure() and ch341_set_termios() Signed-off-by: Nicolas PLANEL <[email protected]> Signed-off-by: Johan Hovold <[email protected]>
2015-03-01NFSv4: Don't call put_rpccred() under the rcu_read_lock()Trond Myklebust1-1/+1
put_rpccred() can sleep. Fixes: 8f649c3762547 ("NFSv4: Fix the locking in nfs_inode_reclaim_delegation()") Cc: [email protected] # 2.6.35+ Signed-off-by: Trond Myklebust <[email protected]>
2015-03-01NFS: Don't require a filehandle to refresh the inode in nfs_prime_dcache()Trond Myklebust1-3/+13
If the server does not return a valid set of attributes that we can use to either create a file or refresh the inode, then there is no value in calling nfs_prime_dcache(). However if we're just refreshing the inode using the attributes that the server returned, then it shouldn't matter whether or not we have a filehandle, as long as we check the fsid+fileid combination. Signed-off-by: Trond Myklebust <[email protected]>
2015-03-01NFSv3: Use the readdir fileid as the mounted-on-fileidTrond Myklebust1-0/+5
When we call readdirplus, set the fileid normally returned by readdir as the mounted-on-fileid, since that is commonly the case if there is a mountpoint. To ensure that we get it right, we only set the flag if the readdir fileid differs from the one returned in the readdirplus attributes. This again means that we can avoid the issues described in commit 2ef47eb1aee17 ("NFS: Fix use of nfs_attr_use_mounted_on_fileid()"), which only fixed NFSv4. Signed-off-by: Trond Myklebust <[email protected]>
2015-03-01NFS: Don't invalidate a submounted dentry in nfs_prime_dcache()Trond Myklebust1-0/+6
If we're traversing a directory which contains a submounted filesystem, or one that has a referral, the NFS server that is processing the READDIR request will often return information for the underlying (mounted-on) directory. It may, or may not, also return filehandle information. If this happens, and the lookup in nfs_prime_dcache() returns the dentry for the submounted directory, the filehandle comparison will fail, and we call d_invalidate(). Post-commit 8ed936b5671bf ("vfs: Lazily remove mounts on unlinked files and directories."), this means the entire subtree is unmounted. The following minimal patch addresses this problem by punting on the invalidation if there is a submount. Kudos to Neil Brown <[email protected]> for having tracked down this issue (see link). Reported-by: Nix <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Cc: [email protected] # 3.18+ Signed-off-by: Trond Myklebust <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.