aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-05-31fence: add missing descriptions for fenceLuis de Bethencourt1-0/+2
The members child_list and active_list were added to the fence struct without descriptions for the Documentation. Adding these. Fixes: b55b54b5db33 ("staging/android: remove struct sync_pt") Signed-off-by: Luis de Bethencourt <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Gustavo Padovan <[email protected]> Signed-off-by: Sumit Semwal <[email protected]>
2016-05-31doc: update/fixup dma-buf related DocBookRob Clark1-4/+32
Split out dma-buf related parts into their own section, add missing files, and write a bit of overview about how it all fits together. Signed-off-by: Rob Clark <[email protected]> Signed-off-by: Sumit Semwal <[email protected]>
2016-05-31Merge branch 'for-linus' of ↵Linus Torvalds8-68/+103
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Martin Schwidefsky: "Three bugs fixes and an update for the default configuration" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390: fix info leak in do_sigsegv s390/config: update default configuration s390/bpf: fix recache skb->data/hlen for skb_vlan_push/pop s390/bpf: reduce maximum program size to 64 KB
2016-05-31reservation: add headerdoc commentsRob Clark2-4/+121
Signed-off-by: Rob Clark <[email protected]> Signed-off-by: Sumit Semwal <[email protected]>
2016-05-31dma-buf: headerdoc fixesRob Clark1-3/+10
Apparently nobody noticed that dma-buf.h wasn't actually pulled into docbook build. And as a result the headerdoc comments bitrot a bit. Add missing params/fields. Signed-off-by: Rob Clark <[email protected]> Signed-off-by: Sumit Semwal <[email protected]>
2016-05-31Merge tag 'gpio-v4.7-2' of ↵Linus Torvalds2-58/+41
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO fixes from Linus Walleij: "A bunch of GPIO fixes for the v4.7 series: - Drop the lock before reading out the GPIO direction setting in drivers supporting the .get_direction() callback: some of them may be slowpath. - Flush GPIO direction setting before locking a GPIO as an IRQ: some electronics or other poking around in the registers behind our back may have happened, so flush the direction status before trying to lock the line for use by IRQs. - Bail out silently when asked to perform operations on NULL GPIO descriptors. That is what all the get_*_optional() is about: we get optional GPIO handles, if they are not there, we get NULL. - Handle compatible ioctl() correctly: we need to convert the ioctl() pointer using compat_ptr() here like everyone else. - Disable the broken .to_irq() on the LPC32xx platform. The whole irqchip infrastructure was replaced in the last merge window, and a new implementation will be needed" * tag 'gpio-v4.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpio: drop lock before reading GPIO direction gpio: bail out silently on NULL descriptors gpio: handle compatible ioctl() pointers gpio: flush direction status in gpiochip_lock_as_irq() gpio: lpc32xx: disable broken to_irq support
2016-05-31arm64: KVM: vgic-v3: Relax synchronization when SRE==1Marc Zyngier1-7/+16
The GICv3 backend of the vgic is quite barrier heavy, in order to ensure synchronization of the system registers and the memory mapped view for a potential GICv2 guest. But when the guest is using a GICv3 model, there is absolutely no need to execute all these heavy barriers, and it is actually beneficial to avoid them altogether. This patch makes the synchonization conditional, and ensures that we do not change the EL1 SRE settings if we do not need to. Reviewed-by: Christoffer Dall <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Christoffer Dall <[email protected]>
2016-05-31arm64: KVM: vgic-v3: Prevent the guest from messing with ICC_SRE_EL1Marc Zyngier1-4/+2
Both our GIC emulations are "strict", in the sense that we either emulate a GICv2 or a GICv3, and not a GICv3 with GICv2 legacy support. But when running on a GICv3 host, we still allow the guest to tinker with the ICC_SRE_EL1 register during its time slice: it can switch SRE off, observe that it is off, and yet on the next world switch, find the SRE bit to be set again. Not very nice. An obvious solution is to always trap accesses to ICC_SRE_EL1 (by clearing ICC_SRE_EL2.Enable), and to let the handler return the programmed value on a read, or ignore the write. That way, the guest can always observe that our GICv3 is SRE==1 only. Reviewed-by: Christoffer Dall <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Christoffer Dall <[email protected]>
2016-05-31arm64: KVM: Make ICC_SRE_EL1 access return the configured SRE valueMarc Zyngier1-1/+12
When we trap ICC_SRE_EL1, we handle it as RAZ/WI. It would be more correct to actual make it RO, and return the configured value when read. Reviewed-by: Christoffer Dall <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Christoffer Dall <[email protected]>
2016-05-31KVM: arm/arm64: vgic-v3: Always resample level interruptsMarc Zyngier1-5/+9
When reading back from the list registers, we need to perform two actions for level interrupts: 1) clear the soft-pending bit if the interrupt is not pending anymore *in the list register* 2) resample the line level and propagate it to the pending state But these two actions shouldn't be linked, and we should *always* resample the line level, no matter what state is in the list register. Otherwise, we may end-up injecting spurious interrupts that have been already retired. Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Christoffer Dall <[email protected]>
2016-05-31KVM: arm/arm64: vgic-v2: Always resample level interruptsMarc Zyngier1-5/+9
When reading back from the list registers, we need to perform two actions for level interrupts: 1) clear the soft-pending bit if the interrupt is not pending anymore *in the list register* 2) resample the line level and propagate it to the pending state But these two actions shouldn't be linked, and we should *always* resample the line level, no matter what state is in the list register. Otherwise, we may end-up injecting spurious interrupts that have been already retired. Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Christoffer Dall <[email protected]>
2016-05-31KVM: arm/arm64: vgic-v3: Clear all dirty LRsChristoffer Dall1-4/+3
When saving the state of the list registers, it is critical to reset them zero, as we could otherwise leave unexpected EOI interrupts pending for virtual level interrupts. Cc: [email protected] # v4.6+ Signed-off-by: Christoffer Dall <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2016-05-31KVM: arm/arm64: vgic-v2: Clear all dirty LRsChristoffer Dall1-4/+3
When saving the state of the list registers, it is critical to reset them zero, as we could otherwise leave unexpected EOI interrupts pending for virtual level interrupts. Cc: [email protected] # v4.6+ Signed-off-by: Christoffer Dall <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2016-05-31arm64: enable CONFIG_SET_MODULE_RONX by defaultMark Rutland1-12/+13
The SET_MODULE_RONX protections are effectively the same as the DEBUG_RODATA protections we enabled by default back in commit 57efac2f7108e325 ("arm64: enable CONFIG_DEBUG_RODATA by default"). It seems unusual to have one but not the other. As evidenced by the help text, the rationale appears to be that SET_MODULE_RONX interacts poorly with tracing and patching, but both of these make use of the insn framework, which takes SET_MODULE_RONX into account. Any remaining issues are bugs which should be fixed regardless of the default state of the option. This patch enables DEBUG_SET_MODULE_RONX by default, and replaces the help text with a new wording derived from the DEBUG_RODATA help text, which better describes the functionality. Previously, the DEBUG_RODATA entry was inconsistently indented with spaces, which are replaced with tabs as with the other Kconfig entries. Additionally, the wording of recommended defaults is made consistent for all options. These are placed in a new paragraph, unquoted, as a full sentence (with a period/full stop) as this appears to be the most common form per $(git grep 'in doubt'). Cc: Catalin Marinas <[email protected]> Cc: Laura Abbott <[email protected]> Acked-by: Kees Cook <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Mark Rutland <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2016-05-31arm64: Remove orphaned __addr_ok() definitionRobin Murphy1-13/+0
Since commit 12a0ef7b0ac3 ("arm64: use generic strnlen_user and strncpy_from_user functions"), the definition of __addr_ok() has been languishing unused; eradicate the sucker. CC: Catalin Marinas <[email protected]> Signed-off-by: Robin Murphy <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2016-05-31powerpc: Use privileged SPR number for MMCR2Thomas Huth1-1/+1
We are already using the privileged versions of MMCR0, MMCR1 and MMCRA in the kernel, so for MMCR2, we should better use the privileged versions, too, to be consistent. Fixes: 240686c13687 ("powerpc: Initialise PMU related regs on Power8") Cc: [email protected] # v3.10+ Suggested-by: Paul Mackerras <[email protected]> Signed-off-by: Thomas Huth <[email protected]> Acked-by: Paul Mackerras <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2016-05-31powerpc: Fix definition of SIAR and SDAR registersThomas Huth1-2/+2
The SIAR and SDAR registers are available twice, one time as SPRs 780 / 781 (unprivileged, but read-only), and one time as the SPRs 796 / 797 (privileged, but read and write). The Linux kernel code currently uses the unprivileged SPRs - while this is OK for reading, writing to that register of course does not work. Since the KVM code tries to write to this register, too (see the mtspr in book3s_hv_rmhandlers.S), the contents of this register sometimes get lost for the guests, e.g. during migration of a VM. To fix this issue, simply switch to the privileged SPR numbers instead. Cc: [email protected] Signed-off-by: Thomas Huth <[email protected]> Acked-by: Paul Mackerras <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2016-05-31Revert "arm64: hugetlb: partial revert of 66b3923a1a0f"Will Deacon1-0/+14
This reverts commit ff7925848b50050732ac0401e0acf27e8b241d7b. Now that the contiguous-hint hugetlb regression has been debugged and fixed upstream by 66ee95d16a7f ("mm: exclude HugeTLB pages from THP page_mapped() logic"), we can revert the previous partial revert of this feature. Signed-off-by: Will Deacon <[email protected]>
2016-05-31pinctrl: mediatek: fix dual-edge code defecthongkun.cao1-2/+3
When a dual-edge irq is triggered, an incorrect irq will be reported on condition that the external signal is not stable and this incorrect irq has been registered. Correct the register offset. Cc: [email protected] Signed-off-by: Hongkun Cao <[email protected]> Reviewed-by: Matthias Brugger <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2016-05-30Merge branch 'uuid' (lib/uuid fixes from Andy)Linus Torvalds4-2/+139
Merge lib/uuid fixes from Andy Shevchenko. * emailed patches from Andy Shevchenko <[email protected]>: lib/uuid.c: use correct offset in uuid parser lib/uuid: add a test module
2016-05-30lib/uuid.c: use correct offset in uuid parserBjørn Mork1-2/+2
Use '+ 0' and '+ 1' as offsets, like they were intended, instead of adding to the result. Fixes: 2b1b0d66704a ("lib/uuid.c: introduce a few more generic helpers") Signed-off-by: Bjørn Mork <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-05-30lib/uuid: add a test moduleAndy Shevchenko3-0/+137
It appears that somehow I missed a test of the latest UUID rework which landed in the kernel. Present a small test module to avoid such cases in the future. Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-05-30Merge branch 'linus' of ↵Linus Torvalds3-6/+14
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fixes from Herbert Xu: "This fixes the following issues: - missing selection in public_key that may result in a build failure - Potential crash in error path in omap-sham - ccp AES XTS bug that affects requests larger than 4096" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: ccp - Fix AES XTS error for request sizes above 4096 crypto: public_key: select CRYPTO_AKCIPHER crypto: omap-sham - potential Oops on error in probe
2016-05-30gpio: drop lock before reading GPIO directionLinus Walleij1-2/+2
When adding the gpiochip, the GPIO HW drivers' callback get_direction() could get called in atomic context. Some of the GPIO HW drivers may sleep when accessing the register. Move the lock before initializing the descriptors. Reported-by: Laxman Dewangan <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2016-05-30gpio: bail out silently on NULL descriptorsLinus Walleij1-3/+8
In fdeb8e1547cb9dd39d5d7223b33f3565cf86c28e ("gpio: reflect base and ngpio into gpio_device") assumed that GPIO descriptors are either valid or error pointers, but gpiod_get_[index_]optional() actually return NULL descriptors and then all subsequent calls should just bail out. Cc: [email protected] Cc: Sergei Shtylyov <[email protected]> Cc: Florian Fainelli <[email protected]> Cc: Andrew Lunn <[email protected]> Fixes: fdeb8e1547cb ("gpio: reflect base and ngpio into gpio_device") Reported-by: Uwe Kleine-König <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2016-05-30gpio: handle compatible ioctl() pointersLinus Walleij1-2/+13
If we're using the compatible ioctl() we need to handle the argument pointer in a special way or there will be trouble. Fixes: 3c702e9987e2 ("gpio: add a userspace chardev ABI for GPIOs") Reported-by: Dmitry Torokhov <[email protected]> Reviewed-by: Dmitry Torokhov <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2016-05-30MAINTAINERS: Add file patterns for pinctrl device tree bindingsGeert Uytterhoeven1-0/+1
Submitters of device tree binding documentation may forget to CC the subsystem maintainer if this is missing. Signed-off-by: Geert Uytterhoeven <[email protected]> Cc: Linus Walleij <[email protected]> Cc: [email protected] Signed-off-by: Linus Walleij <[email protected]>
2016-05-30pinctrl: nomadik: fix inversion of gpio directionLinus Walleij1-1/+1
The input/output directions were inversed on the GPIO direction read function. Loose a ! and it is correct. Signed-off-by: Linus Walleij <[email protected]>
2016-05-30gpio: flush direction status in gpiochip_lock_as_irq()Linus Walleij1-4/+17
As irqchip and gpiochip functions are orthogonal, the IRQ set-up or something else can have changed the direction of the GPIO line from what the GPIO descriptor knows when we get into gpiochip_lock_as_irq(). Make sure to re-read the direction setting if we have the .get_direction() callback enabled for the chip. Else we get problems like this: iio iio:device2: interrupts on the rising edge gpio gpiochip2: (8012e080.gpio): gpiochip_lock_as_irq: tried to flag a GPIO set as output for IRQ gpio gpiochip2: (8012e080.gpio): unable to lock HW IRQ 0 for IRQ genirq: Failed to request resources for l3g4200d-trigger (irq 111) on irqchip nmk1-32-63 iio iio:device2: failed to request trigger IRQ. st-gyro-i2c: probe of 2-0068 failed with error -22 Fixes: 72d320006177 ("gpio: set up initial state from .get_direction()") Signed-off-by: Linus Walleij <[email protected]>
2016-05-30gpio: lpc32xx: disable broken to_irq supportSylvain Lemieux1-47/+1
The "to_irq" functionality is broken inside this driver since commit 76ba59f8366f ("genirq: Add irq_domain-aware core IRQ handler"). The addition of the new lpc32xx irqchip driver in 4.7, fixed the lpc32xx platform interrupt issue. When switching to the new lpc32xx irqchip driver, a warning appear in the lpc32xx gpio driver: warning: "NR_IRQS" redefined. To remove this warning (temporary solution), this patch disables the broken "to_irq" mapping functionality support. Signed-off-by: Sylvain Lemieux <[email protected]> Acked-by: Vladimir Zapolskiy <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2016-05-30net: l2tp: Make l2tp_ip6 namespace awareShmulik Ladkani1-5/+7
l2tp_ip6 tunnel and session lookups were still using init_net, although the l2tp core infrastructure already supports lookups keyed by 'net'. As a result, l2tp_ip6_recv discarded packets for tunnels/sessions created in namespaces other than the init_net. Fix, by using dev_net(skb->dev) or sock_net(sk) where appropriate. Signed-off-by: Shmulik Ladkani <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-05-29Documentation: ip-sysctl.txt: clarify secure_redirectsEric Garver1-3/+5
Clarify how secure_redirects works. Mention that RFC1122 always applies. Signed-off-by: Eric Garver <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-05-29sfc: use flow dissector helpers for aRFSEdward Cree1-54/+21
Signed-off-by: Edward Cree <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-05-29ieee802154: fix logic error in ieee802154_llsec_parse_dev_addrBaozeng Ding1-2/+2
Fix a logic error to avoid potential null pointer dereference. Signed-off-by: Baozeng Ding <[email protected]> Reviewed-by: Stefan Schmidt<[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-05-29net: nps_enet: Disable interrupts before napi rescheduleElad Kanfi1-1/+3
Since NAPI works by shutting down event interrupts when theres work and turning them on when theres none, the net driver must make sure that interrupts are disabled when it reschedules polling. By calling napi_reschedule, the driver switches to polling mode, therefor there should be no interrupt interference. Any received packets will be handled in nps_enet_poll by polling the HW indication of received packet until all packets are handled. Signed-off-by: Elad Kanfi <[email protected]> Acked-by: Noam Camus <[email protected]> Tested-by: Alexey Brodkin <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-05-29net/lapb: tuse %*ph to dump buffersAndy Shevchenko3-15/+8
Use %*ph specifier to dump small buffers in hex format instead doing this byte-by-byte. Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-05-29ptp: oops in ptp_ioctl()Dan Carpenter1-0/+1
If we pass ERR_PTR(-EFAULT) to kfree() then it's going to oops. Fixes: 2ece068e1b1d ('ptp: use memdup_user().') Signed-off-by: Dan Carpenter <[email protected]> Acked-by: Richard Cochran <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-05-29fou: add Kconfig options for IPv6 supportArnd Bergmann3-2/+11
A previous patch added the fou6.ko module, but that failed to link in a couple of configurations: net/built-in.o: In function `ip6_tnl_encap_add_fou_ops': net/ipv6/fou6.c:88: undefined reference to `ip6_tnl_encap_add_ops' net/ipv6/fou6.c:94: undefined reference to `ip6_tnl_encap_add_ops' net/ipv6/fou6.c:97: undefined reference to `ip6_tnl_encap_del_ops' net/built-in.o: In function `ip6_tnl_encap_del_fou_ops': net/ipv6/fou6.c:106: undefined reference to `ip6_tnl_encap_del_ops' net/ipv6/fou6.c:107: undefined reference to `ip6_tnl_encap_del_ops' If CONFIG_IPV6=m, ip6_tnl_encap_add_ops/ip6_tnl_encap_del_ops are in a module, but fou6.c can still be built-in, and that obviously fails to link. Also, if CONFIG_IPV6=y, but CONFIG_IPV6_TUNNEL=m or CONFIG_IPV6_TUNNEL=n, the same problem happens for a different reason. This adds two new silent Kconfig symbols to work around both problems: - CONFIG_IPV6_FOU is now always set to 'm' if either CONFIG_NET_FOU=m or CONFIG_IPV6=m - CONFIG_IPV6_FOU_TUNNEL is set implicitly when IPV6_FOU is enabled and NET_FOU_IP_TUNNELS is also turned out, and it will ensure that CONFIG_IPV6_TUNNEL is also available. The options could be made user-visible as well, to give additional room for configuration, but it seems easier not to bother users with more choice here. Signed-off-by: Arnd Bergmann <[email protected]> Fixes: aa3463d65e7b ("fou: Add encap ops for IPv6 tunnels") Signed-off-by: David S. Miller <[email protected]>
2016-05-29ipv6: hide ip6_encap_hlen/ip6_tnl_encap definitionsArnd Bergmann1-1/+2
A recent cleanup moved MAX_IPTUN_ENCAP_OPS along with some other definitions, but it is now invisible when CONFIG_INET is not defined, but still referenced from ip6_tunnel.h: In file included from net/xfrm/xfrm_input.c:17:0: include/net/ip6_tunnel.h:67:17: error: 'MAX_IPTUN_ENCAP_OPS' undeclared here (not in a function) ip6tun_encaps[MAX_IPTUN_ENCAP_OPS]; ^~~~~~~~~~~~~~~~~~~ This hides the ip6_encap_hlen and ip6_tnl_encap functions inside of CONFIG_INET so we don't run into the the problem. Alternatively we could move the macro out of the #ifdef again to restore the previous behavior Signed-off-by: Arnd Bergmann <[email protected]> Fixes: 55c2bc143224 ("net: Cleanup encap items in ip_tunnels.h") Signed-off-by: David S. Miller <[email protected]>
2016-05-30powerpc/pseries/eeh: Refactor the configure_bridge RTAS tokensRussell Currey1-16/+12
The RTAS calls "ibm,configure-pe" and "ibm,configure-bridge" perform the same actions, however the former can skip configuration if unnecessary. The existing code treats them as different tokens even though only one will ever be called. Refactor this by making a single token that is assigned during init. Signed-off-by: Russell Currey <[email protected]> Acked-by: Gavin Shan <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2016-05-30powerpc/pseries/eeh: Handle RTAS delay requests in configure_bridgeRussell Currey1-15/+36
In the "ibm,configure-pe" and "ibm,configure-bridge" RTAS calls, the spec states that values of 9900-9905 can be returned, indicating that software should delay for 10^x (where x is the last digit, i.e. 990x) milliseconds and attempt the call again. Currently, the kernel doesn't know about this, and respecting it fixes some PCI failures when the hypervisor is busy. The delay is capped at 0.2 seconds. Cc: <[email protected]> # 3.10+ Signed-off-by: Russell Currey <[email protected]> Acked-by: Gavin Shan <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2016-05-29sparc64: Fix return from trap window fill crashes.David S. Miller5-52/+116
We must handle data access exception as well as memory address unaligned exceptions from return from trap window fill faults, not just normal TLB misses. Otherwise we can get an OOPS that looks like this: ld-linux.so.2(36808): Kernel bad sw trap 5 [#1] CPU: 1 PID: 36808 Comm: ld-linux.so.2 Not tainted 4.6.0 #34 task: fff8000303be5c60 ti: fff8000301344000 task.ti: fff8000301344000 TSTATE: 0000004410001601 TPC: 0000000000a1a784 TNPC: 0000000000a1a788 Y: 00000002 Not tainted TPC: <do_sparc64_fault+0x5c4/0x700> g0: fff8000024fc8248 g1: 0000000000db04dc g2: 0000000000000000 g3: 0000000000000001 g4: fff8000303be5c60 g5: fff800030e672000 g6: fff8000301344000 g7: 0000000000000001 o0: 0000000000b95ee8 o1: 000000000000012b o2: 0000000000000000 o3: 0000000200b9b358 o4: 0000000000000000 o5: fff8000301344040 sp: fff80003013475c1 ret_pc: 0000000000a1a77c RPC: <do_sparc64_fault+0x5bc/0x700> l0: 00000000000007ff l1: 0000000000000000 l2: 000000000000005f l3: 0000000000000000 l4: fff8000301347e98 l5: fff8000024ff3060 l6: 0000000000000000 l7: 0000000000000000 i0: fff8000301347f60 i1: 0000000000102400 i2: 0000000000000000 i3: 0000000000000000 i4: 0000000000000000 i5: 0000000000000000 i6: fff80003013476a1 i7: 0000000000404d4c I7: <user_rtt_fill_fixup+0x6c/0x7c> Call Trace: [0000000000404d4c] user_rtt_fill_fixup+0x6c/0x7c The window trap handlers are slightly clever, the trap table entries for them are composed of two pieces of code. First comes the code that actually performs the window fill or spill trap handling, and then there are three instructions at the end which are for exception processing. The userland register window fill handler is: add %sp, STACK_BIAS + 0x00, %g1; \ ldxa [%g1 + %g0] ASI, %l0; \ mov 0x08, %g2; \ mov 0x10, %g3; \ ldxa [%g1 + %g2] ASI, %l1; \ mov 0x18, %g5; \ ldxa [%g1 + %g3] ASI, %l2; \ ldxa [%g1 + %g5] ASI, %l3; \ add %g1, 0x20, %g1; \ ldxa [%g1 + %g0] ASI, %l4; \ ldxa [%g1 + %g2] ASI, %l5; \ ldxa [%g1 + %g3] ASI, %l6; \ ldxa [%g1 + %g5] ASI, %l7; \ add %g1, 0x20, %g1; \ ldxa [%g1 + %g0] ASI, %i0; \ ldxa [%g1 + %g2] ASI, %i1; \ ldxa [%g1 + %g3] ASI, %i2; \ ldxa [%g1 + %g5] ASI, %i3; \ add %g1, 0x20, %g1; \ ldxa [%g1 + %g0] ASI, %i4; \ ldxa [%g1 + %g2] ASI, %i5; \ ldxa [%g1 + %g3] ASI, %i6; \ ldxa [%g1 + %g5] ASI, %i7; \ restored; \ retry; nop; nop; nop; nop; \ b,a,pt %xcc, fill_fixup_dax; \ b,a,pt %xcc, fill_fixup_mna; \ b,a,pt %xcc, fill_fixup; And the way this works is that if any of those memory accesses generate an exception, the exception handler can revector to one of those final three branch instructions depending upon which kind of exception the memory access took. In this way, the fault handler doesn't have to know if it was a spill or a fill that it's handling the fault for. It just always branches to the last instruction in the parent trap's handler. For example, for a regular fault, the code goes: winfix_trampoline: rdpr %tpc, %g3 or %g3, 0x7c, %g3 wrpr %g3, %tnpc done All window trap handlers are 0x80 aligned, so if we "or" 0x7c into the trap time program counter, we'll get that final instruction in the trap handler. On return from trap, we have to pull the register window in but we do this by hand instead of just executing a "restore" instruction for several reasons. The largest being that from Niagara and onward we simply don't have enough levels in the trap stack to fully resolve all possible exception cases of a window fault when we are already at trap level 1 (which we enter to get ready to return from the original trap). This is executed inline via the FILL_*_RTRAP handlers. rtrap_64.S's code branches directly to these to do the window fill by hand if necessary. Now if you look at them, we'll see at the end: ba,a,pt %xcc, user_rtt_fill_fixup; ba,a,pt %xcc, user_rtt_fill_fixup; ba,a,pt %xcc, user_rtt_fill_fixup; And oops, all three cases are handled like a fault. This doesn't work because each of these trap types (data access exception, memory address unaligned, and faults) store their auxiliary info in different registers to pass on to the C handler which does the real work. So in the case where the stack was unaligned, the unaligned trap handler sets up the arg registers one way, and then we branched to the fault handler which expects them setup another way. So the FAULT_TYPE_* value ends up basically being garbage, and randomly would generate the backtrace seen above. Reported-by: Nick Alcock <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-05-29Merge tag 'scsi-fixes' of ↵Linus Torvalds5-10/+25
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "This is a set of four fixes noticed in the merge window. The aacraid one is an optimisation, the mp3sas one fixes a spurious printk, the sd_check_events one fixes a theoretical race and the failed zero length commands fixes a bug in our completion/retry routines that has been causing problems in the field" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: aacraid: do not activate events on non-SRC adapters mpt3sas: add missing curly braces sd: get disk reference in sd_check_events() scsi_lib: correctly retry failed zero length REQ_TYPE_FS commands
2016-05-29sparc: Harden signal return frame checks.David S. Miller5-45/+92
All signal frames must be at least 16-byte aligned, because that is the alignment we explicitly create when we build signal return stack frames. All stack pointers must be at least 8-byte aligned. Signed-off-by: David S. Miller <[email protected]>
2016-05-29Linux 4.7-rc1Linus Torvalds1-3/+3
2016-05-29hash_string: Fix zero-length case for !DCACHE_WORD_ACCESSGeorge Spelvin1-2/+2
The self-test was updated to cover zero-length strings; the function needs to be updated, too. Reported-by: Geert Uytterhoeven <[email protected]> Signed-off-by: George Spelvin <[email protected]> Fixes: fcfd2fbf22d2 ("fs/namei.c: Add hashlen_string() function") Signed-off-by: Linus Torvalds <[email protected]>
2016-05-28Rename other copy of hash_string to hashlen_stringGeorge Spelvin1-2/+2
The original name was simply hash_string(), but that conflicted with a function with that name in drivers/base/power/trace.c, and I decided that calling it "hashlen_" was better anyway. But you have to do it in two places. [ This caused build errors for architectures that don't define CONFIG_DCACHE_WORD_ACCESS - Linus ] Signed-off-by: George Spelvin <[email protected]> Reported-by: Guenter Roeck <[email protected]> Fixes: fcfd2fbf22d2 ("fs/namei.c: Add hashlen_string() function") Signed-off-by: Linus Torvalds <[email protected]>
2016-05-28hpfs: implement the show_options methodMikulas Patocka1-11/+32
The HPFS filesystem used generic_show_options to produce string that is displayed in /proc/mounts. However, there is a problem that the options may disappear after remount. If we mount the filesystem with option1 and then remount it with option2, /proc/mounts should show both option1 and option2, however it only shows option2 because the whole option string is replaced with replace_mount_options in hpfs_remount_fs. To fix this bug, implement the hpfs_show_options function that prints options that are currently selected. Signed-off-by: Mikulas Patocka <[email protected]> Cc: [email protected] Signed-off-by: Linus Torvalds <[email protected]>
2016-05-28affs: fix remount failure when there are no options changedMikulas Patocka1-2/+3
Commit c8f33d0bec99 ("affs: kstrdup() memory handling") checks if the kstrdup function returns NULL due to out-of-memory condition. However, if we are remounting a filesystem with no change to filesystem-specific options, the parameter data is NULL. In this case, kstrdup returns NULL (because it was passed NULL parameter), although no out of memory condition exists. The mount syscall then fails with ENOMEM. This patch fixes the bug. We fail with ENOMEM only if data is non-NULL. The patch also changes the call to replace_mount_options - if we didn't pass any filesystem-specific options, we don't call replace_mount_options (thus we don't erase existing reported options). Fixes: c8f33d0bec99 ("affs: kstrdup() memory handling") Signed-off-by: Mikulas Patocka <[email protected]> Cc: [email protected] # v4.1+ Signed-off-by: Linus Torvalds <[email protected]>
2016-05-28hpfs: fix remount failure when there are no options changedMikulas Patocka1-2/+3
Commit ce657611baf9 ("hpfs: kstrdup() out of memory handling") checks if the kstrdup function returns NULL due to out-of-memory condition. However, if we are remounting a filesystem with no change to filesystem-specific options, the parameter data is NULL. In this case, kstrdup returns NULL (because it was passed NULL parameter), although no out of memory condition exists. The mount syscall then fails with ENOMEM. This patch fixes the bug. We fail with ENOMEM only if data is non-NULL. The patch also changes the call to replace_mount_options - if we didn't pass any filesystem-specific options, we don't call replace_mount_options (thus we don't erase existing reported options). Fixes: ce657611baf9 ("hpfs: kstrdup() out of memory handling") Signed-off-by: Mikulas Patocka <[email protected]> Cc: [email protected] Signed-off-by: Linus Torvalds <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.