On a 32-bit kernel, this has no effect, since there are no IST stacks.
On a 64-bit kernel, #SS can only happen in user code, on a failed iret
to user space, a canonical violation on access via RSP or RBP, or a
genuine stack segment violation in 32-bit kernel code. The first two
cases don't need IST, and the latter two cases are unlikely fatal bugs,
and promoting them to double faults would be fine.
This fixes a bug in which the espfix64 code mishandles a stack segment
violation.
This saves 4k of memory per CPU and a tiny bit of code.
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There's nothing special enough about the espfix64 double fault fixup to
justify writing it in assembly. Move it to C.
This also fixes a bug: if the double fault came from an IST stack, the
old asm code would return to a partially uninitialized stack frame.
Fixes: 3891a04aaf
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
A collection of fixes this week:
- A set of clock fixes for shmobile platforms
- A fix for tegra that moves serial port labels to be per board.
We're choosing to merge this for 3.18 because the labels will start
being parsed in 3.19, and without this change serial port numbers that
used to be stable since the dawn of time will change numbers.
- A few other DT tweaks for Tegra.
- A fix for multi_v7_defconfig that makes it stop spewing cpufreq errors on
Arndale (Exynos).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUciiGAAoJEIwa5zzehBx3jwgQAIHjp02NcGah/8TYwQr9TqW9
PGRvByKshSCQz8Q/MldSKyp1Ni86m/ZAR27KcPXuPs4Jp7Wuur88PuHOfijO4AvE
z5s92TIZUaj74emlBbUAT5og8iG5h8+EwzRkcemobgKwTS6xHv6Wch1bBWQbu0Vc
Zm2/z8ByYD17jCD8Nu6hnBZNs64SjYZixt+DAvRoW0nCm/N7mXajYesCbr/EWt7S
WtHKcRQwWwr6XixDhCjsgCpsdba6HqX0dvPb4HRUDOCL5jLj8vc65cZZgMOBRsU/
XSHixBbtSvMiFzfrqppMMjeqp/eo0vcyAi86RpGWRC+t9iqrqCfqysGyfed/tYgc
t4DAaRC5JBdLSjznuQMSTyexJhVmsxqoByCJcsc/pnaRKXJ2/xlOgTtVNdx70ckf
w2wrYjCafj/PprOqjUdrvcXDwkzDvvG05Ma4kbhyvmV0fbWqc5DmGVr8VNS0urWZ
oLpI5R2/A7XpA8n8prfAgzJRhK3qZEwvhYBsSW4JzfnVL0p+LrxnWmfKecl3iizK
t50vDbcvr/yo9Te08t+iJQGm0Sb2AzXG4dfQgBeIj9rmI892ikBwUKeeusp/XprA
SOvyZk28rqWRsfPIEJD16vEYFFt2EEWHcQoonf/Dsu62v4i1+goAxoWY6G8NHbA9
gTaItn0wA+Hv5msYs4HJ
=FXz0
-----END PGP SIGNATURE-----
Merge tag 'armsoc-for-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Olof Johansson:
"A collection of fixes this week:
- A set of clock fixes for shmobile platforms
- A fix for tegra that moves serial port labels to be per board.
We're choosing to merge this for 3.18 because the labels will start
being parsed in 3.19, and without this change serial port numbers
that used to be stable since the dawn of time will change numbers.
- A few other DT tweaks for Tegra.
- A fix for multi_v7_defconfig that makes it stop spewing cpufreq
errors on Arndale (Exynos)"
* tag 'armsoc-for-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: multi_v7_defconfig: fix failure setting CPU voltage by enabling dependent I2C controller
ARM: tegra: roth: Fix SD card VDD_IO regulator
ARM: tegra: Remove eMMC vmmc property for roth/tn7
ARM: dts: tegra: move serial aliases to per-board
ARM: tegra: Add serial port labels to Tegra124 DT
ARM: shmobile: kzm9g legacy: Set i2c clks_per_count to 2
ARM: shmobile: r8a7740 dtsi: Correct IIC0 parent clock
ARM: shmobile: r8a7790: Fix SD3CKCR address to device tree
ARM: shmobile: r8a7740 legacy: Correct IIC0 parent clock
ARM: shmobile: r8a7740 legacy: Add missing INTCA clock for irqpin module
ARM: shmobile: r8a7790: Fix SD3CKCR address
ARM: dts: sun6i: Re-parent ahb1_mux to pll6 as required by dma controller
Pull percpu fix from Tejun Heo:
"This contains one patch to fix a race condition which can lead to
percpu_ref using a percpu pointer which is corrupted with a set DEAD
bit. The bug was introduced while separating out the ATOMIC mode flag
from the DEAD flag. The fix is pretty straight forward.
I just committed the patch to the percpu tree but am sending out the
pull request early as I'll be on vacation for a week. The patch
should be fairly safe and while the latency will be higher I'll be
checking emails"
* 'for-3.18-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu:
percpu-ref: fix DEAD flag contamination of percpu pointer
Pull btrfs deadlock fix from Chris Mason:
"This has a fix for a long standing deadlock that we've been trying to
nail down for a while. It ended up being a bad interaction with the
fair reader/writer locks and the order btrfs reacquires locks in the
btree"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
btrfs: fix lockups from btrfs_clear_path_blocking
While decoupling ATOMIC and DEAD flags, f47ad45784 ("percpu_ref:
decouple switching to percpu mode and reinit") updated
__ref_is_percpu() so that it only tests ATOMIC flag to determine
whether the ref is in percpu mode or not; however, while DEAD implies
ATOMIC, the two flags are set separately during percpu_ref_kill() and
if __ref_is_percpu() races percpu_ref_kill(), it may see DEAD w/o
ATOMIC. Because __ref_is_percpu() returns @ref->percpu_count_ptr
value verbatim as the percpu pointer after testing ATOMIC, the pointer
may now be contaminated with the DEAD flag.
This can be fixed by clearing the flag bits before returning the
pointer which was the fix proposed by Shaohua; however, as DEAD
implies ATOMIC, we can just test for both flags at once and avoid the
explicit masking.
Update __ref_is_percpu() so that it tests that both ATOMIC and DEAD
are clear before returning @ref->percpu_count_ptr as the percpu
pointer.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-Reviewed-by: Shaohua Li <shli@kernel.org>
Link: http://lkml.kernel.org/r/995deb699f5b873c45d667df4add3b06f73c2c25.1416638887.git.shli@kernel.org
Fixes: f47ad45784 ("percpu_ref: decouple switching to percpu mode and reinit")
Pull timer fix from Thomas Gleixner:
"A single bugfix for an init order problem in the sun4i subarch
clockevents code"
* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
clockevent: sun4i: Fix race condition in the probe code
Pull vfs fixes from Al Viro:
"Assorted fixes, most in overlayfs land"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
ovl: ovl_dir_fsync() cleanup
ovl: update MAINTAINERS
ovl: pass dentry into ovl_dir_read_merged()
ovl: use lockless_dereference() for upperdentry
ovl: allow filenames with comma
ovl: fix race in private xattr checks
ovl: fix remove/copy-up race
ovl: rename filesystem type to "overlay"
isofs: avoid unused function warning
vfs: fix reference leak in d_prune_aliases()
Pull networking fixes from David Miller:
1) Fix BUG when decrypting empty packets in mac80211, from Ronald Wahl.
2) nf_nat_range is not fully initialized and this is copied back to
userspace, from Daniel Borkmann.
3) Fix read past end of b uffer in netfilter ipset, also from Dan
Carpenter.
4) Signed integer overflow in ipv4 address mask creation helper
inet_make_mask(), from Vincent BENAYOUN.
5) VXLAN, be2net, mlx4_en, and qlcnic need ->ndo_gso_check() methods to
properly describe the device's capabilities, from Joe Stringer.
6) Fix memory leaks and checksum miscalculations in openvswitch, from
Pravin B SHelar and Jesse Gross.
7) FIB rules passes back ambiguous error code for unreachable routes,
making behavior confusing for userspace. Fix from Panu Matilainen.
8) ieee802154fake_probe() doesn't release resources properly on error,
from Alexey Khoroshilov.
9) Fix skb_over_panic in add_grhead(), from Daniel Borkmann.
10) Fix access of stale slave pointers in bonding code, from Nikolay
Aleksandrov.
11) Fix stack info leak in PPP pptp code, from Mathias Krause.
12) Cure locking bug in IPX stack, from Jiri Bohac.
13) Revert SKB fclone memory freeing optimization that is racey and can
allow accesses to freed up memory, from Eric Dumazet.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (71 commits)
tcp: Restore RFC5961-compliant behavior for SYN packets
net: Revert "net: avoid one atomic operation in skb_clone()"
virtio-net: validate features during probe
cxgb4 : Fix DCB priority groups being returned in wrong order
ipx: fix locking regression in ipx_sendmsg and ipx_recvmsg
openvswitch: Don't validate IPv6 label masks.
pptp: fix stack info leak in pptp_getname()
brcmfmac: don't include linux/unaligned/access_ok.h
cxgb4i : Don't block unload/cxgb4 unload when remote closes TCP connection
ipv6: delete protocol and unregister rtnetlink when cleanup
net/mlx4_en: Add VXLAN ndo calls to the PF net device ops too
bonding: fix curr_active_slave/carrier with loadbalance arp monitoring
mac80211: minstrel_ht: fix a crash in rate sorting
vxlan: Inline vxlan_gso_check().
can: m_can: update to support CAN FD features
can: m_can: fix incorrect error messages
can: m_can: add missing delay after setting CCCR_INIT bit
can: m_can: fix not set can_dlc for remote frame
can: m_can: fix possible sleep in napi poll
can: m_can: add missing message RAM initialization
...
Pull drm fixes from Dave Airlie:
"Just two radeon and two intel fixes: endian and regression fixes"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/radeon: fix endian swapping in vbios fetch for tdp table
drm/radeon: disable native backlight control on pre-r6xx asics (v2)
drm/i915: Kick fbdev before vgacon
drm/i915: drop WaSetupGtModeTdRowDispatch:snb
This batch ended up as a relatively high volume due to pending
ASoC fixes. But most of fixes there are trivial and/or device-
specific fixes and quirks, so safe to apply. The only (ASoC)
core fixes are the DPCM race fix and the machine-driver matching
fix for componentization.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJUbMUBAAoJEGwxgFQ9KSmkM7MQALi2oHeu089YX0nl2aJr/LeU
R55yuOCiKmkvikJIccInWbtwAW57K41CbLK9lDZx+6iSfpzAs7Nd554VdACDhtP1
wnnBGKhUZHF3NMim8UMjXRX/IAwJS1DvTKfULdLyAdG+ptNrmeCA2xBVPSCU+5Fb
q6QPSuM0A5qP//Ufsi4gHJsTZpe/S42PIh46XK5Z2nOO7Y/J+Ytwi/g6TaauYjDU
GZK3XNa7vjtZIw42nNyjn8qIIByhji591uHJpizIPVjbVKxhqm3wM1lU5xCYj/cd
fi1uWOOQ1Gp+DYTScfu0DZj1BaoBCqeQ27pvnDU15+yqDJHmmKvtQbBbETtbba9t
ajZvg+1J6ONf/wYkNqaSAkSFEMyOQ1NpSRsGMri28ahndkC72h6NBmH5FFEwIg1X
3XcxEf1BKw3oQXvaoeL8Qin6d+zWBjWHzNSmVeft4MYMf+AxnoXoD0+HmRIGQhVK
qFFtcuPVnIDHLUHsiVTNvMi7kejzgl8NUW3lGzbaWSSPKdUFHK2lE60uKzvQ5yHm
0K4CD2H4FVrMM3iqwSsDmUDk+++HOr7LjvC9jMZM5KobZQ9t25Imkt+ZdypQfzJC
wKz480viZcu3VimEdHYNivM2RLh2kxZtUB26O8DodEI28wr6b4PYlX/4Nzt+rXwu
YMf3SOUNdPEoAqlcEi9l
=oc6T
-----END PGP SIGNATURE-----
Merge tag 'sound-3.18-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"This batch ended up as a relatively high volume due to pending ASoC
fixes. But most of fixes there are trivial and/or device- specific
fixes and quirks, so safe to apply. The only (ASoC) core fixes are
the DPCM race fix and the machine-driver matching fix for
componentization"
* tag 'sound-3.18-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda - fix the mic mute led problem for Latitude E5550
ALSA: hda - move DELL_WMI_MIC_MUTE_LED to the tail in the quirk chain
ASoC: wm_adsp: Avoid attempt to free buffers that might still be in use
ALSA: usb-audio: Set the Control Selector to SU_SELECTOR_CONTROL for UAC2
ALSA: usb-audio: Add ctrl message delay quirk for Marantz/Denon devices
ASoC: sgtl5000: Fix SMALL_POP bit definition
ASoC: cs42l51: re-hook of_match_table pointer
ASoC: rt5670: change dapm routes of PLL connection
ASoC: rt5670: correct the incorrect default values
ASoC: samsung: Add MODULE_DEVICE_TABLE for Snow
ASoC: max98090: Correct pclk divisor settings
ASoC: dpcm: Fix race between FE/BE updates and trigger
ASoC: Fix snd_soc_find_dai() matching component by name
ASoC: rsnd: remove unsupported PAUSE flag
ASoC: fsi: remove unsupported PAUSE flag
ASoC: rt5645: Mark RT5645_TDM_CTRL_3 as readable
ASoC: rockchip-i2s: fix infinite loop in rockchip_snd_rxctrl
ASoC: es8328-i2c: Fix i2c_device_id name field in es8328_id
ASoC: fsl_asrc: Add reg_defaults for regmap to fix kernel dump
This is just a one-liner fixing a regression introduced in 3.13 that
broke system suspend on some Chromebooks.
On those machines there are ACPI device objects for some I2C devices
that can wake up the system from sleep states, but that is done via
a platform-specific mechanism and the ACPI objects don't contain any
wakeup-related information. When we started to use ACPI power
management with those devices (which happened during the 3.13 cycle),
their configuration confused the ACPI PM layer that returned error
codes from suspend callbacks for them causing system suspend to fail.
However, the ACPI PM layer can safely ignore the wakeup setting from
a device driver if the ACPI object corresponding to the device in
question doesn't contain wakeup information in which case the driver
itself is responsible for setting up the device for system wakeup.
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJUb0/DAAoJEILEb/54YlRxBKcQAIsQBoP6ogxC5DcOiOqCOF9t
fQyUfrwgltGt8GDbbEeHWrDSBrgIVfZmtK2lm+ak8rkU66k3foD2BDDWv5f1cgDz
H+Y/aQotkt2RbY67V7ga4HP+2CfWnGVL1E0MN2fcn0DrBei4fPoYfanfUj6dSTg+
fdXnY5YmSgSfdmnN8MFde13uTxzkwe6bfMwi+PhFk7fp7j6d5+T8rc7Dd9OWRePJ
+OYW/jrYCxixnIDQGbeaSVzTlunL+Q3mIB2D+Kj6Sy9s9jyEadXPy/bQRCeIdv3v
Q6Ryi/tsGrs0XVSVy5uNusJcWDOcTcvXA1srwx6Rm8D4+nRAcwYxGyX4n5dew5L/
uy9PcCLMP1PhI7aIkhZxkIvk+Rp8H2En3QdzqjFbk5YEo003Mq6Lj04pFpWl9W7u
6wDTRm2eKPzPVyihs4G8gPGeu9CfkTTmLX7HX41FmczIFoMOANNMgF0COmGpgHzu
v4QKwNsfRl+KPLQZHQlwZkm9RFVc2s6BVLS1//l7d6AGIeQx86WVBEr6qr86OQ/t
NIPg2W9PsPuzT2SynYjtPnoRb1Mik/78ltx2WR05/yxtOgsOFxjJozdV0QHc7dc0
Mt1xSqHbgg1fxcwM86QzY1cqaPSmjJQhi4Jk6B/SGFIf14VbCJP/PjYt8wqprIWB
Ib4Ykw+oswhEtKHUnWNB
=2pxa
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-3.18-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI power management fix from Rafael Wysocki:
"This is just a one-liner fixing a regression introduced in 3.13 that
broke system suspend on some Chromebooks.
On those machines there are ACPI device objects for some I2C devices
that can wake up the system from sleep states, but that is done via a
platform-specific mechanism and the ACPI objects don't contain any
wakeup-related information. When we started to use ACPI power
management with those devices (which happened during the 3.13 cycle),
their configuration confused the ACPI PM layer that returned error
codes from suspend callbacks for them causing system suspend to fail.
However, the ACPI PM layer can safely ignore the wakeup setting from a
device driver if the ACPI object corresponding to the device in
question doesn't contain wakeup information in which case the driver
itself is responsible for setting up the device for system wakeup"
* tag 'pm+acpi-3.18-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI / PM: Ignore wakeup setting if the ACPI companion can't wake up
- 2 fixes for OF selftest code
- Fix for PowerPC address parsing to disable work-around except on old
PowerMACs
- Fix a crash when earlycon is enabled, but no device is found
- DT documentation fixes and missing vendor prefixes
All but the doc updates are also for stable.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJUbqAVAAoJEMhvYp4jgsXiNLUH/A5cpNKcs2D0GCpDxxkZa6X/
o5vwuECwd7dFH83lkFWdNFCNJ6B7hUUG3RDO63SgzZch2auQR1yETJrXSbUNeDKM
HMp3CVvVjqFz7h86H2x+mijxUPJl7YWtFuC1RQUJkMGULC16BnYLSVGrrqHI37BJ
E5hdmfJtARUGcmZO291JB9bdfuR5gAfIR4GIYsAQHn0RbiuST/L1DyL2QFkh69eW
yyeB9elIw+xYBUlEVMkq5LmH12l0VA1eSIofBWEfj40cCax1CblL1nzV1+s7oHpv
JrATuyfxlTjs/tdUeeV/lMT4Vg/ICWsbPJKWb4UaJv0nH+u+oGiKSCyl5X4DH4c=
=M65+
-----END PGP SIGNATURE-----
Merge tag 'devicetree-fixes-for-3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
Pull devicetree fixes from Rob Herring:
"DeviceTree fixes for 3.18:
- two fixes for OF selftest code
- fix for PowerPC address parsing to disable work-around except on
old PowerMACs
- fix a crash when earlycon is enabled, but no device is found
- DT documentation fixes and missing vendor prefixes
All but the doc updates are also for stable"
* tag 'devicetree-fixes-for-3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux:
of/selftest: Fix testing when /aliases is missing
of/selftest: Fix off-by-one error in removal path
documentation: pinctrl bindings: Fix trivial typo 'abitrary'
devicetree: bindings: Add vendor prefix for Micron Technology, Inc.
of: Add vendor prefix for Chips&Media, Inc.
of/base: Fix PowerPC address parsing hack
devicetree: vendor-prefixes.txt: fix whitespace
of: Fix crash if an earlycon driver is not found
of/irq: Drop obsolete 'interrupts' vs 'interrupts-extended' text
of: Spelling s/stucture/structure/
devicetree: bindings: add sandisk to the vendor prefixes
Resource management
- Support 64-bit bridge windows if we have 64-bit dma_addr_t (Yinghai Lu)
PCI device hotplug
- Apply _HPX Link Control settings to all devices with a link (Yinghai Lu)
Generic host bridge driver
- Add DT binding for "linux,pci-domain" property (Lucas Stach)
APM X-Gene
- Assign resources to bus before adding new devices (Duc Dang)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUbkCkAAoJEFmIoMA60/r8HHcQAMBeaF4pbUYotzpd8kwjFQ2x
d9DPU3bAfeMY3U4qKRkp/GXV1F1ueVP2KgwaKlV9ytrILFwVYlsy2DZ/JIS3ggw2
BfjPTVB6rADzhfZB0HNSQQGOcGbKezd4sM45E6hsZqxzlgnVJQ5oL0u/PL5fuvC1
+1goznoJwOhLMn9bsSS+b/2bgmPG1HYonFu1ehiSTt/g9e0Q2YsMkCZDo8R3i6nl
W25g93m1yP7KO3AnPsnE9dm9oDEcbqVbfSu+Z8X2NllN8/+e6+z7CtDZx5OfMpRI
GBQrLuPXi0NxFeFcj+gbAfhV8ZsFDdqNXPHuqC7pOKlveCmyk8tBhXcIr9gTnGQF
/UjxgWDekH6Cb8DjFVQCj84D5f1U7RNRbpkeEr6gXtoM7vPDfQaCROC5qhBKGV+P
XAQ4ujGkCe3A9ve2XNsgHzLQgRoRopfI6aN2VZxQYaxvobm+QzuMW7BtKJ72dUKJ
LIPnlc+X1ccwg+ZyWFvgLByMKCriklTjeFA2UMP6WI7xD3r5N+Y0QP0no4zVPIMN
no5RAx7sv71yE97Y/SSosirfjQ3YlJ55KJRJY2+j2obD9wLCCEwJuiNnrYU+EB6c
Z/cPmZhGKZnBcDJMazjULe2gldVDRokIRk069ySob4iUdZ4n/vIdCbNR5Z0f6dAr
w7SfdPXK2ARn0ulqzdT1
=smv9
-----END PGP SIGNATURE-----
Merge tag 'pci-v3.18-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
Pull PCI fixes from Bjorn Helgaas:
"These are fixes for an issue with 64-bit PCI bus addresses on 32-bit
PAE kernels, an APM X-Gene problem (it depended on a generic change we
removed before merging), a fix for my hotplug device configuration
changes, and a devicetree documentation update.
Resource management:
- Support 64-bit bridge windows if we have 64-bit dma_addr_t (Yinghai Lu)
PCI device hotplug:
- Apply _HPX Link Control settings to all devices with a link (Yinghai Lu)
Generic host bridge driver:
- Add DT binding for "linux,pci-domain" property (Lucas Stach)
APM X-Gene:
- Assign resources to bus before adding new devices (Duc Dang)"
* tag 'pci-v3.18-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
PCI: Support 64-bit bridge windows if we have 64-bit dma_addr_t
PCI: Apply _HPX Link Control settings to all devices with a link
PCI: Add missing DT binding for "linux,pci-domain" property
PCI: xgene: Assign resources to bus before adding new devices
Pull SCSI target fixes from Nicholas Bellinger:
"Here are the target-pending fixes queued for v3.18-rc6.
The highlights include:
- target-core OOPs fix with tcm_qla2xxx + vxworks FC initiators +
zero length SCSI commands having a transfer direction set. (Roland
+ Craig Watson)
- vhost-scsi OOPs fix to explicitly prevent WWPN endpoint configfs
group removal while qemu still has an active reference. (Paolo +
nab)
- ib_srpt fix for RDMA hardware with lower srp_sq_size limits.
(Bart)
- two ib_isert work-arounds for running on ocrdma hardware (Or + Sagi
+ Chris)
- iscsi-target discovery portal typo + SPC-3 PR Preempt SA key
matching fix (Steve)"
* git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
IB/isert: Adjust CQ size to HW limits
target: return CONFLICT only when SA key unmatched
iser-target: Handle DEVICE_REMOVAL event on network portal listener correctly
ib_isert: Add max_send_sge=2 minimum for control PDU responses
srp-target: Retry when QP creation fails with ENOMEM
iscsi-target: return the correct port in SendTargets
vhost-scsi: Take configfs group dependency during VHOST_SCSI_SET_ENDPOINT
target: Don't call TFO->write_pending if data_length == 0
Pull dmaengine fixes from Vinod Koul:
"We have couple of fixes for dmaengine queued up:
- dma mempcy fix for dma configuration of sun6i by Maxime
- pl330 fixes: First the fixing allocation for data buffers by Liviu
and then Jon's fixe for fifo width and usage"
* 'fixes' of git://git.infradead.org/users/vkoul/slave-dma:
dmaengine: Fix allocation size for PL330 data buffer depth.
dmaengine: pl330: Limit MFIFO usage for memcpy to avoid exhausting entries
dmaengine: pl330: Align DMA memcpy operations to MFIFO width
dmaengine: sun6i: Fix memcpy operation
Pull MIPS fixes from Ralf Baechle:
"More 3.18 fixes for MIPS:
- backtraces were not quite working on on 64-bit kernels
- loongson needs a different cache coherency setting
- Loongson 3 is a MIPS64 R2 version but due to erratum we treat is an
older architecture revision.
- fix build errors due to undefined references to __node_distances
for certain configurations.
- fix instruction decodig in the jump label code.
- for certain configurations copy_{from,to}_user destroy the content
of $3 so that register needs to be marked as clobbed by the calling
code.
- Hardware Table Walker fixes.
- fill the delay slot of the last instruction of memcpy otherwise
whatever ends up there randomly might have undesirable effects.
- ensure get_user/__get_user always zero the variable to be read even
in case of an error"
* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
MIPS: jump_label.c: Handle the microMIPS J instruction encoding
MIPS: jump_label.c: Correct the span of the J instruction
MIPS: Zero variable read by get_user / __get_user in case of an error.
MIPS: lib: memcpy: Restore NOP on delay slot before returning to caller
MIPS: tlb-r4k: Add missing HTW stop/start sequences
MIPS: asm: uaccess: Add v1 register to clobber list on EVA
MIPS: oprofile: Fix backtrace on 64-bit kernel
MIPS: Loongson: Set Loongson-3's ISA level to MIPS64R1
MIPS: Loongson: Fix the write-combine CCA value setting
MIPS: IP27: Fix __node_distances undefined error
MIPS: Loongson3: Fix __node_distances undefined error
Pull powerpc fix from Michael Ellerman:
"One fix from Scott, he says:
This patch fixes a crash (introduced in v3.18-rc1) in the FSL MSI driver
when threaded IRQs are enabled"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux:
powerpc/fsl_msi: mark the msi cascade handler IRQF_NO_THREAD
Pull x86 fixes from Thomas Gleixner:
"Misc fixes:
- gold linker build fix
- noxsave command line parsing fix
- bugfix for NX setup
- microcode resume path bug fix
- _TIF_NOHZ versus TIF_NOHZ bugfix as discussed in the mysterious
lockup thread"
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86, syscall: Fix _TIF_NOHZ handling in syscall_trace_enter_phase1
x86, kaslr: Handle Gold linker for finding bss/brk
x86, mm: Set NX across entire PMD at boot
x86, microcode: Update BSPs microcode on resume
x86: Require exact match for 'noxsave' command line option
Pull scheduler fixes from Ingo Molnar:
"Misc fixes: two NUMA fixes, two cputime fixes and an RCU/lockdep fix"
* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/cputime: Fix clock_nanosleep()/clock_gettime() inconsistency
sched/cputime: Fix cpu_timer_sample_group() double accounting
sched/numa: Avoid selecting oneself as swap target
sched/numa: Fix out of bounds read in sched_init_numa()
sched: Remove lockdep check in sched_move_task()
Pull perf fixes from Ingo Molnar:
"Misc fixes: two Intel uncore driver fixes, a CPU-hotplug fix and a
build dependencies fix"
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf/x86/intel/uncore: Fix boot crash on SBOX PMU on Haswell-EP
perf/x86/intel/uncore: Fix IRP uncore register offsets on Haswell EP
perf: Fix corruption of sibling list with hotplug
perf/x86: Fix embarrasing typo
Pull core fix from Ingo Molnar:
"Fix GENMASK macro shift overflow"
Nobody seems to currently use GENMASK() to fill every single last bit
(which is what overflows) in-tree, and gcc would warn about it, so we
have that going for us. But apparently there are pending changes that
want this.
* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
bitops: Fix shift overflow in GENMASK macros
Commit c3ae62af8e ("tcp: should drop incoming frames without ACK
flag set") was created to mitigate a security vulnerability in which a
local attacker is able to inject data into locally-opened sockets by
using TCP protocol statistics in procfs to quickly find the correct
sequence number.
This broke the RFC5961 requirement to send a challenge ACK in response
to spurious RST packets, which was subsequently fixed by commit
7b514a886b ("tcp: accept RST without ACK flag").
Unfortunately, the RFC5961 requirement that spurious SYN packets be
handled in a similar manner remains broken.
RFC5961 section 4 states that:
... the handling of the SYN in the synchronized state SHOULD be
performed as follows:
1) If the SYN bit is set, irrespective of the sequence number, TCP
MUST send an ACK (also referred to as challenge ACK) to the remote
peer:
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
After sending the acknowledgment, TCP MUST drop the unacceptable
segment and stop processing further.
By sending an ACK, the remote peer is challenged to confirm the loss
of the previous connection and the request to start a new connection.
A legitimate peer, after restart, would not have a TCB in the
synchronized state. Thus, when the ACK arrives, the peer should send
a RST segment back with the sequence number derived from the ACK
field that caused the RST.
This RST will confirm that the remote peer has indeed closed the
previous connection. Upon receipt of a valid RST, the local TCP
endpoint MUST terminate its connection. The local TCP endpoint
should then rely on SYN retransmission from the remote end to
re-establish the connection.
This patch lets SYN packets through the discard added in c3ae62af8e,
so that spurious SYN packets are properly dealt with as per the RFC.
The challenge ACK is sent unconditionally and is rate-limited, so the
original vulnerability is not reintroduced by this patch.
Signed-off-by: Calvin Owens <calvinowens@fb.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Not sure what I was thinking, but doing anything after
releasing a refcount is suicidal or/and embarrassing.
By the time we set skb->fclone to SKB_FCLONE_FREE, another cpu
could have released last reference and freed whole skb.
We potentially corrupt memory or trap if CONFIG_DEBUG_PAGEALLOC is set.
Reported-by: Chris Mason <clm@fb.com>
Fixes: ce1a4ea3f1 ("net: avoid one atomic operation in skb_clone()")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
When doing a fsync with a fast path we have a time window where we can miss
the fact that writeback of some file data failed, and therefore we endup
returning success (0) from fsync when we should return an error.
The steps that lead to this are the following:
1) We start all ordered extents by calling filemap_fdatawrite_range();
2) We do some other work like locking the inode's i_mutex, start a transaction,
start a log transaction, etc;
3) We enter btrfs_log_inode(), acquire the inode's log_mutex and collect all the
ordered extents from inode's ordered tree into a list;
4) But by the time we do ordered extent collection, some ordered extents we started
at step 1) might have already completed with an error, and therefore we didn't
found them in the ordered tree and had no idea they finished with an error. This
makes our fsync return success (0) to userspace, but has no bad effects on the log
like for example insertion of file extent items into the log that point to unwritten
extents, because the invalid extent maps were removed before the ordered extent
completed (in inode.c:btrfs_finish_ordered_io).
So after collecting the ordered extents just check if the inode's i_mapping has any
error flags set (AS_EIO or AS_ENOSPC) and leave with an error if it does. Whenever
writeback fails for a page of an ordered extent, we call mapping_set_error (done in
extent_io.c:end_extent_writepage, called by extent_io.c:end_bio_extent_writepage)
that sets one of those error flags in the inode's i_mapping flags.
This change also has the side effect of fixing the issue where for fast fsyncs we
never checked/cleared the error flags from the inode's i_mapping flags, which means
that a full fsync performed after a fast fsync could get such errors that belonged
to the fast fsync - because the full fsync calls btrfs_wait_ordered_range() which
calls filemap_fdatawait_range(), and the later checks for and clears those flags,
while for fast fsyncs we never call filemap_fdatawait_range() or anything else
that checks for and clears the error flags from the inode's i_mapping.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
Instead of collecting all ordered extents from the inode's ordered tree
and then wait for all of them to complete, just collect the ones that
overlap the fsync range.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
If an error happens during writeback of log btree extents, make sure the
error is returned to the caller (fsync), so that it takes proper action
(commit current transaction) instead of writing a superblock that points
to log btrees with all or some nodes that weren't durably persisted.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
We use the modified list to keep track of which extents have been modified so we
know which ones are candidates for logging at fsync() time. Newly modified
extents are added to the list at modification time, around the same time the
ordered extent is created. We do this so that we don't have to wait for ordered
extents to complete before we know what we need to log. The problem is when
something like this happens
log extent 0-4k on inode 1
copy csum for 0-4k from ordered extent into log
sync log
commit transaction
log some other extent on inode 1
ordered extent for 0-4k completes and adds itself onto modified list again
log changed extents
see ordered extent for 0-4k has already been logged
at this point we assume the csum has been copied
sync log
crash
On replay we will see the extent 0-4k in the log, drop the original 0-4k extent
which is the same one that we are replaying which also drops the csum, and then
we won't find the csum in the log for that bytenr. This of course causes us to
have errors about not having csums for certain ranges of our inode. So remove
the modified list manipulation in unpin_extent_cache, any modified extents
should have been added well before now, and we don't want them re-logged. This
fixes my test that I could reliably reproduce this problem with. Thanks,
cc: stable@vger.kernel.org
Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
Liu Bo pointed out that my previous fix would lose the generation update in the
scenario I described. It is actually much worse than that, we could lose the
entire extent if we lose power right after the transaction commits. Consider
the following
write extent 0-4k
log extent in log tree
commit transaction
< power fail happens here
ordered extent completes
We would lose the 0-4k extent because it hasn't updated the actual fs tree, and
the transaction commit will reset the log so it isn't replayed. If we lose
power before the transaction commit we are save, otherwise we are not.
Fix this by keeping track of all extents we logged in this transaction. Then
when we go to commit the transaction make sure we wait for all of those ordered
extents to complete before proceeding. This will make sure that if we lose
power after the transaction commit we still have our data. This also fixes the
problem of the improperly updated extent generation. Thanks,
cc: stable@vger.kernel.org
Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
"The biggest change is to rename the filesystem from "overlayfs" to "overlay".
This will allow legacy overlayfs to be easily carried by distros alongside the
new mainline one. Also fix a couple of copy-up races and allow escaping comma
character in filenames."
The last bit is about commas in pathname mount options...
We currently trigger BUG when VIRTIO_NET_F_CTRL_VQ
is not set but one of features depending on it is.
That's not a friendly way to report errors to
hypervisors.
Let's check, and fail probe instead.
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pablo Neira Ayuso says:
====================
Netfilter fixes for net
The following patchset contains two bugfixes for your net tree, they are:
1) Validate netlink group from nfnetlink to avoid an out of bound array
access. This should only happen with superuser priviledges though.
Discovered by Andrey Ryabinin using trinity.
2) Don't push ethernet header before calling the netfilter output hook
for multicast traffic, this breaks ebtables since it expects to see
skb->data pointing to the network header, patch from Linus Luessing.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
John W. Linville says:
====================
pull request: wireless 2014-11-20
Please full this little batch of fixes intended for the 3.18 stream!
For the mac80211 patch, Johannes says:
"Here's another last minute fix, for minstrel HT crashing
depending on the value of some uninitialised stack."
On top of that...
Ben Greear fixes an ath9k regression in which a BSSID mask is
miscalculated.
Dmitry Torokhov corrects an error handling routing in brcmfmac which
was checking an unsigned variable for a negative value.
Johannes Berg avoids a build problem in brcmfmac for arches where
linux/unaligned/access_ok.h and asm/unaligned.h conflict.
Mathy Vanhoef addresses another brcmfmac issue so as to eliminate a
use-after-free of the URB transfer buffer if a timeout occurs.
Please let me know if there are problems!
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Peer priority groups were being reversed, but this was missed in the previous
fix sent out for this issue.
v2 : Previous patch was doing extra unnecessary work, result is the same.
Please ignore previous patch
Fixes : ee7bc3cdc2 ('cxgb4 : dcb open-lldp interop fixes')
Signed-off-by: Anish Bhatt <anish@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This fixes an old regression introduced by commit
b0d0d915 (ipx: remove the BKL).
When a recvmsg syscall blocks waiting for new data, no data can be sent on the
same socket with sendmsg because ipx_recvmsg() sleeps with the socket locked.
This breaks mars-nwe (NetWare emulator):
- the ncpserv process reads the request using recvmsg
- ncpserv forks and spawns nwconn
- ncpserv calls a (blocking) recvmsg and waits for new requests
- nwconn deadlocks in sendmsg on the same socket
Commit b0d0d915 has simply replaced BKL locking with
lock_sock/release_sock. Unlike now, BKL got unlocked while
sleeping, so a blocking recvmsg did not block a concurrent
sendmsg.
Only keep the socket locked while actually working with the socket data and
release it prior to calling skb_recv_datagram().
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
When userspace doesn't provide a mask, OVS datapath generates a fully
unwildcarded mask for the flow by copying the flow and setting all bits
in all fields. For IPv6 label, this creates a mask that matches on the
upper 12 bits, causing the following error:
openvswitch: netlink: Invalid IPv6 flow label value (value=ffffffff, max=fffff)
This patch ignores the label validation check for masks, avoiding this
error.
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
pptp_getname() only partially initializes the stack variable sa,
particularly only fills the pptp part of the sa_addr union. The code
thereby discloses 16 bytes of kernel stack memory via getsockname().
Fix this by memset(0)'ing the union before.
Cc: Dmitry Kozlov <xeb@mail.ru>
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
fix one regression and one endian issue.
* 'drm-fixes-3.18' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: fix endian swapping in vbios fetch for tdp table
drm/radeon: disable native backlight control on pre-r6xx asics (v2)
If we have two fsync()'s race on different subvols one will do all of its work
to get into the log_tree, wait on it's outstanding IO, and then allow the
log_tree to finish it's commit. The problem is we were just free'ing that
subvols logged extents instead of waiting on them, so whoever lost the race
wouldn't really have their data on disk. Fix this by waiting properly instead
of freeing the logged extents. Thanks,
cc: stable@vger.kernel.org
Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
The sizes that are obtained from space infos are in raw units and have
to be adjusted according to the raid factor. This was missing for
f_bavail and df reported doubled size for raid1.
Reported-by: Martin Steigerwald <Martin@lichtvoll.de>
Fixes: ba7b6e62f4 ("btrfs: adjust statfs calculations according to raid profiles")
CC: stable@vger.kernel.org
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
This can be reproduced by fstests: btrfs/070
The scenario is like the following:
replace worker thread defrag thread
--------------------- -------------
copy_nocow_pages_worker btrfs_defrag_file
copy_nocow_pages_for_inode ...
btrfs_writepages
|A| lock_extent_bits extent_write_cache_pages
|B| lock_page
__extent_writepage
... writepage_delalloc
find_lock_delalloc_range
|B| lock_extent_bits
find_or_create_page
pagecache_get_page
|A| lock_page
This leads to an ABBA pattern deadlock. To fix it,
o we just change it to an AABB pattern which means to @unlock_extent_bits()
before we @lock_page(), and in this way the @extent_read_full_page_nolock()
is no longer in an locked context, so change it back to @extent_read_full_page()
to regain protection.
o Since we @unlock_extent_bits() earlier, then before @write_page_nocow(),
the extent may not really point at the physical block we want, so we
have to check it before write.
Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com>
Tested-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
Replacing a xattr consists of doing a lookup for its existing value, delete
the current value from the respective leaf, release the search path and then
finally insert the new value. This leaves a time window where readers (getxattr,
listxattrs) won't see any value for the xattr. Xattrs are used to store ACLs,
so this has security implications.
This change also fixes 2 other existing issues which were:
*) Deleting the old xattr value without verifying first if the new xattr will
fit in the existing leaf item (in case multiple xattrs are packed in the
same item due to name hash collision);
*) Returning -EEXIST when the flag XATTR_CREATE is given and the xattr doesn't
exist but we have have an existing item that packs muliple xattrs with
the same name hash as the input xattr. In this case we should return ENOSPC.
A test case for xfstests follows soon.
Thanks to Alexandre Oliva for reporting the non-atomicity of the xattr replace
implementation.
Reported-by: Alexandre Oliva <oliva@gnu.org>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
We try to allocate an extent state structure before acquiring the extent
state tree's spinlock as we might need a new one later and therefore avoid
doing later an atomic allocation while holding the tree's spinlock. However
we returned -ENOMEM if that initial non-atomic allocation failed, which is
a bit excessive since we might end up not needing the pre-allocated extent
state at all - for the case where the tree doesn't have any extent states
that cover the input range and cover too any other range. Therefore don't
return -ENOMEM if that pre-allocation fails.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
Our gluster boxes get several thousand statfs() calls per second, which begins
to suck hardcore with all of the lock contention on the chunk mutex and dev list
mutex. We don't really need to hold these things, if we have transient
weirdness with statfs() because of the chunk allocator we don't care, so remove
this locking.
We still need the dev_list lock if you mount with -o alloc_start however, which
is a good argument for nuking that thing from orbit, but that's a patch for
another day. Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
Our gluster boxes were spending lots of time in statfs because our fs'es are
huge. The problem is statfs loops through all of the block groups looking for
read only block groups, and when you have several terabytes worth of data that
ends up being a lot of block groups. Move the read only block groups onto a
read only list and only proces that list in
btrfs_account_ro_block_groups_free_space to reduce the amount of churn. Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Chris Mason <clm@fb.com>
Copy&paste errors in some messages and add few more missing macro
accessors.
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
The xfstest btrfs/014 which tests the balance operation caused that the
check_int module complained that known blocks changed their physical
location. Since this is not an error in this case, only print such
message if the verbose mode was enabled.
Reported-by: Wang Shilong <wangshilong1991@gmail.com>
Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Tested-by: Wang Shilong <wangshilong1991@gmail.com>
Signed-off-by: Chris Mason <clm@fb.com>
The xfstest btrfs/014 which tests the balance operation caused issues with
the check_int module. The attempt was made to use btrfs_map_block() to
find the physical location for a written block. However, this was not
at all needed since the location of the written block was known since
a hook to submit_bio() was the reason for entering the check_int module.
Additionally, after a block relocation it happened that btrfs_map_block()
failed causing misleading error messages afterwards.
This patch changes the check_int module to use the known information of
the physical location from the bio.
Reported-by: Wang Shilong <wangshilong1991@gmail.com>
Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Tested-by: Wang Shilong <wangshilong1991@gmail.com>
Signed-off-by: Chris Mason <clm@fb.com>
We try to allocate an extent state before acquiring the tree's spinlock
just in case we end up needing to split an existing extent state into two.
If that allocation failed, we would return -ENOMEM.
However, our only single caller (transaction/log commit code), passes in
an extent state that was cached from a call to find_first_extent_bit() and
that has a very high chance to match exactly the input range (always true
for a transaction commit and very often, but not always, true for a log
commit) - in this case we end up not needing at all that initial extent
state used for an eventual split. Therefore just don't return -ENOMEM if
we can't allocate the temporary extent state, since we might not need it
at all, and if we end up needing one, we'll do it later anyway.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
Right now the only caller of find_first_extent_bit() that is interested
in caching extent states (transaction or log commit), never gets an extent
state cached. This is because find_first_extent_bit() only caches states
that have at least one of the flags EXTENT_IOBITS or EXTENT_BOUNDARY, and
the transaction/log commit caller always passes a tree that doesn't have
ever extent states with any of those flags (they can only have one of the
following flags: EXTENT_DIRTY, EXTENT_NEW or EXTENT_NEED_WAIT).
This change together with the following one in the patch series (titled
"Btrfs: avoid returning -ENOMEM in convert_extent_bit() too early") will
help reduce significantly the chances of calls to convert_extent_bit()
fail with -ENOMEM when called from the transaction/log commit code.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
