- 18 Nov, 2016 10 commits
-
-
Babu Moger authored
This new config parameter limits the space used for "Lock debugging: prove locking correctness" by about 4MB. The current sparc systems have the limitation of 32MB size for kernel size including .text, .data and .bss sections. With PROVE_LOCKING feature, the kernel size could grow beyond this limit and causing system boot-up issues. With this option, kernel limits the size of the entries of lock_chains, stack_trace etc., so that kernel fits in required size limit. This is not visible to user and only used for sparc. Signed-off-by: Babu Moger <babu.moger@oracle.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tushar Dave authored
sunbmac uses '__u32' for dma handle while invoking kernel DMA APIs, instead of using dma_addr_t. This hasn't caused any 'incompatible pointer type' warning on SPARC because until now dma_addr_t is of type u32. However, recent changes in SPARC ATU (iommu) enables 64bit DMA and therefore dma_addr_t becomes of type u64. This makes 'incompatible pointer type' warnings inevitable. e.g. drivers/net/ethernet/sun/sunbmac.c: In function ‘bigmac_ether_init’: drivers/net/ethernet/sun/sunbmac.c:1166: warning: passing argument 3 of ‘dma_alloc_coherent’ from incompatible pointer type ./include/linux/dma-mapping.h:445: note: expected ‘dma_addr_t *’ but argument is of type ‘__u32 *’ This patch resolves above compiler warning. Signed-off-by: Tushar Dave <tushar.n.dave@oracle.com> Reviewed-by: chris hyser <chris.hyser@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tushar Dave authored
sunqe uses '__u32' for dma handle while invoking kernel DMA APIs, instead of using dma_addr_t. This hasn't caused any 'incompatible pointer type' warning on SPARC because until now dma_addr_t is of type u32. However, recent changes in SPARC ATU (iommu) enables 64bit DMA and therefore dma_addr_t becomes of type u64. This makes 'incompatible pointer type' warnings inevitable. e.g. drivers/net/ethernet/sun/sunqe.c: In function ‘qec_ether_init’: drivers/net/ethernet/sun/sunqe.c:883: warning: passing argument 3 of ‘dma_alloc_coherent’ from incompatible pointer type ./include/linux/dma-mapping.h:445: note: expected ‘dma_addr_t *’ but argument is of type ‘__u32 *’ drivers/net/ethernet/sun/sunqe.c:885: warning: passing argument 3 of ‘dma_alloc_coherent’ from incompatible pointer type ./include/linux/dma-mapping.h:445: note: expected ‘dma_addr_t *’ but argument is of type ‘__u32 *’ This patch resolves above compiler warnings. Signed-off-by: Tushar Dave <tushar.n.dave@oracle.com> Reviewed-by: chris hyser <chris.hyser@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Tushar Dave says: ==================== sparc: Enable sun4v hypervisor PCI IOMMU v2 APIs and ATU ATU (Address Translation Unit) is a new IOMMU in SPARC supported with sun4v hypervisor PCI IOMMU v2 APIs. Current SPARC IOMMU supports only 32bit address ranges and one TSB per PCIe root complex that has a 2GB per root complex DVMA space limit. The limit has become a scalability bottleneck nowadays that a typical 10G/40G NIC can consume 500MB DVMA space per instance. When DVMA resource is exhausted, devices will not be usable since the driver can't allocate DVMA. For example, we recently experienced legacy IOMMU limitation while using i40e driver in system with large number of CPUs (e.g. 128). Four ports of i40e, each request 128 QP (Queue Pairs). Each queue has 512 (default) descriptors. So considering only RX queues (because RX premap DMA buffers), i40e takes 4*128*512 number of DMA entries in IOMMU table. Legacy IOMMU can have at max (2G/8K)- 1 entries available in table. So bringing up four instance of i40e alone saturate existing IOMMU resource. ATU removes bottleneck by allowing guest os to create IOTSB of size 32G (or more) with 64bit address ranges available in ATU HW. 32G is more than enough DVMA space to be shared by all PCIe devices under root complex contrast to 2G space provided by legacy IOMMU. ATU allows PCIe devices to use 64bit DMA addressing. Devices which choose to use 32bit DMA mask will continue to work with the existing legacy IOMMU. The patch set is tested on sun4v (T1000, T2000, T3, T4, T5, T7, S7) and sun4u SPARC. Thanks. -Tushar v2->v3: - Patch #5 addresses comment by Joe Perches. -- use %s, __func__ instead of embedding the function name. v1->v2: - Patch #2 addresses comments by Dave M. -- use page allocator to allocate IOTSB. -- use true/false with boolean variables. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tushar Dave authored
ATU 64bit addressing allows PCIe devices with 64bit DMA capabilities to use ATU for 64bit DMA. Signed-off-by: Tushar Dave <tushar.n.dave@oracle.com> Reviewed-by: chris hyser <chris.hyser@oracle.com> Acked-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tushar Dave authored
Add Hypervisor IOMMU v2 APIs pci_iotsb_map(), pci_iotsb_demap() and enable sun4v dma ops to use IOMMU v2 API for all PCIe devices with 64bit DMA mask. Signed-off-by: Tushar Dave <tushar.n.dave@oracle.com> Reviewed-by: chris hyser <chris.hyser@oracle.com> Acked-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tushar Dave authored
In order to use Hypervisor (HV) IOMMU v2 API for map/demap, each PCIe device has to be bound to IOTSB using HV API pci_iotsb_bind(). Signed-off-by: Tushar Dave <tushar.n.dave@oracle.com> Reviewed-by: chris hyser <chris.hyser@oracle.com> Acked-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tushar Dave authored
Like legacy IOMMU, use common iommu_map_table and iommu_pool for ATU. This change initializes iommu_map_table and iommu_pool for ATU. Signed-off-by: Tushar Dave <tushar.n.dave@oracle.com> Reviewed-by: chris hyser <chris.hyser@oracle.com> Reviewed-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tushar Dave authored
ATU (Address Translation Unit) is a new IOMMU in SPARC supported with Hypervisor IOMMU v2 APIs. Current SPARC IOMMU supports only 32bit address ranges and one TSB per PCIe root complex that has a 2GB per root complex DVMA space limit. The limit has become a scalability bottleneck nowadays that a typical 10G/40G NIC can consume 300MB-500MB DVMA space per instance. When DVMA resource is exhausted, devices will not be usable since the driver can't allocate DVMA. ATU removes bottleneck by allowing guest os to create IOTSB of size 32G (or more) with 64bit address ranges available in ATU HW. 32G is more than enough DVMA space to be shared by all PCIe devices under root complex contrast to 2G space provided by legacy IOMMU. ATU allows PCIe devices to use 64bit DMA addressing. Devices which choose to use 32bit DMA mask will continue to work with the existing legacy IOMMU. Signed-off-by: Tushar Dave <tushar.n.dave@oracle.com> Reviewed-by: chris hyser <chris.hyser@oracle.com> Acked-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Dave Kleikamp authored
This change allows ATU (new IOMMU) in SPARC systems to request large (32M) contiguous memory during boot for creating IOTSB backing store. Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com> Signed-off-by: Tushar Dave <tushar.n.dave@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 14 Nov, 2016 1 commit
-
-
Thomas Tai authored
A compile warning is introduced by a commit to fix the find_node(). This patch fix the compile warning by moving find_node() into __init section. Because find_node() is only used by memblock_nid_range() which is only used by a __init add_node_ranges(). find_node() and memblock_nid_range() should also be inside __init section. Signed-off-by: Thomas Tai <thomas.tai@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 11 Nov, 2016 2 commits
-
-
Andreas Larsson authored
Signed-off-by: Andreas Larsson <andreas@gaisler.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Thomas Tai authored
When booting up LDOM, find_node() warns that a physical address doesn't match a NUMA node. WARNING: CPU: 0 PID: 0 at arch/sparc/mm/init_64.c:835 find_node+0xf4/0x120 find_node: A physical address doesn't match a NUMA node rule. Some physical memory will be owned by node 0.Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 4.9.0-rc3 #4 Call Trace: [0000000000468ba0] __warn+0xc0/0xe0 [0000000000468c74] warn_slowpath_fmt+0x34/0x60 [00000000004592f4] find_node+0xf4/0x120 [0000000000dd0774] add_node_ranges+0x38/0xe4 [0000000000dd0b1c] numa_parse_mdesc+0x268/0x2e4 [0000000000dd0e9c] bootmem_init+0xb8/0x160 [0000000000dd174c] paging_init+0x808/0x8fc [0000000000dcb0d0] setup_arch+0x2c8/0x2f0 [0000000000dc68a0] start_kernel+0x48/0x424 [0000000000dcb374] start_early_boot+0x27c/0x28c [0000000000a32c08] tlb_fixup_done+0x4c/0x64 [0000000000027f08] 0x27f08 It is because linux use an internal structure node_masks[] to keep the best memory latency node only. However, LDOM mdesc can contain single latency-group with multiple memory latency nodes. If the address doesn't match the best latency node within node_masks[], it should check for an alternative via mdesc. The warning message should only be printed if the address doesn't match any node_masks[] nor within mdesc. To minimize the impact of searching mdesc every time, the last matched mask and index is stored in a variable. Signed-off-by: Thomas Tai <thomas.tai@oracle.com> Reviewed-by: Chris Hyser <chris.hyser@oracle.com> Reviewed-by: Liam Merwick <liam.merwick@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 09 Nov, 2016 3 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/soundLinus Torvalds authored
Pull sound fixes from Takashi Iwai: "This became a largish pull-request, as we've got a bunch of pending ASoC fixes at this time. One noticeable change is the removal of error directive in uapi/sound/asoc.h. We found that the API has been already used on Chromebooks, so we need to support it even now. A slight big LOC is found in Qualcomm lpass driver, but the rest are all small and easy fixes for ASoC drivers (sti, sun4i, Realtek codecs, Intel, tas571x, etc) in addition to the patches to harden the ALSA core proc file accesses" * tag 'sound-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (26 commits) ALSA: info: Return error for invalid read/write ALSA: info: Limit the proc text input size ASoC: samsung: spdif: Fix DMA filter initialization ASoC: sun4i-codec: Enable bus clock after getting GPIO ASoC: lpass-cpu: add module licence and description ASoC: lpass-platform: Fix broken pcm data usage ASoC: sun4i-codec: return error code instead of NULL when create_card fails ASoC: hdmi-codec: Fix hdmi_of_xlate_dai_name when #sound-dai-cells = <0> ASoC: samsung: get access to DMA engine early to defer probe properly ASoC: da7219: Connect output enable register to DAIOUT ASoC: Intel: Skylake: Fix to turn off hdmi power on probe failure ASoC: sti-sas: enable fast io for regmap ASoC: sti: fix channel status update after playback start ASoC: PXA: Brownstone needs I2C ASoC: Intel: Skylake: Always acquire runtime pm ref on unload ASoC: Intel: Atom: add terminate entry for dmi_system_id tables ASoC: rt298: fix jack type detect error ASoC: rt5663: fix a debug statement ASoC: cs4270: fix DAPM stream name mismatch ASoC: Intel: haswell depends on sst-firmware ...
-
git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linuxLinus Torvalds authored
Pull orangefs fix from Mike Marshall: "We recently refactored the Orangefs debugfs code. The refactor seemed to trigger dan.carpenter@oracle.com's static tester to find a possible double-free in the code. While designing the fix we saw a condition under which the buffer being freed could also be overflowed. We also realized how to rebuild the related debugfs file's "contents" (a string) without deleting and re-creating the file. This fix should eliminate the possible double-free, the potential overflow and improve code readability" * tag 'for-linus-4.9-rc4-ofs-1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux: orangefs: clean up debugfs
-
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linuxLinus Torvalds authored
Pull s390 fixes from Martin Schwidefsky: "Two bug fixes - a memory alignment fix in the s390 only hypfs code - a fix for the generic percpu code that caused ftrace to break on s390. This is not relevant for x86 but for all architectures that use the generic percpu code" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: percpu: use notrace variant of preempt_disable/preempt_enable s390/hypfs: Use get_free_page() instead of kmalloc to ensure page alignment
-
- 08 Nov, 2016 9 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommuLinus Torvalds authored
Pull IOMMU fixes from Joerg Roedel: - Four patches from Robin Murphy fix several issues with the recently merged generic DT-bindings support for arm-smmu drivers - A fix for a dead-lock issue in the VT-d driver, which shows up on iommu hotplug * tag 'iommu-fixes-v4.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: iommu/vt-d: Fix dead-locks in disable_dmar_iommu() path iommu/arm-smmu: Fix out-of-bounds dereference iommu/arm-smmu: Check that iommu_fwspecs are ours iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s iommu/arm-smmu: Work around ARM DMA configuration
-
Joerg Roedel authored
It turns out that the disable_dmar_iommu() code-path tried to get the device_domain_lock recursivly, which will dead-lock when this code runs on dmar removal. Fix both code-paths that could lead to the dead-lock. Fixes: 55d94043 ('iommu/vt-d: Get rid of domain->iommu_lock') Signed-off-by: Joerg Roedel <jroedel@suse.de>
-
Robin Murphy authored
When we iterate a master's config entries, what we generally care about is the entry's stream map index, rather than the entry index itself, so it's nice to have the iterator automatically assign the former from the latter. Unfortunately, booting with KASAN reveals the oversight that using a simple comma operator results in the entry index being dereferenced before being checked for validity, so we always access one element past the end of the fwspec array. Flip things around so that the check always happens before the index may be dereferenced. Fixes: adfec2e7 ("iommu/arm-smmu: Convert to iommu_fwspec") Reported-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
-
Robin Murphy authored
We seem to have forgotten to check that iommu_fwspecs actually belong to us before we go ahead and dereference their private data. Oops. Fixes: 021bb842 ("iommu/arm-smmu: Wire up generic configuration support") Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
-
Robin Murphy authored
We now delay installing our per-bus iommu_ops until we know an SMMU has successfully probed, as they don't serve much purpose beforehand, and doing so also avoids fights between multiple IOMMU drivers in a single kernel. However, the upshot of passing the return value of bus_set_iommu() back from our probe function is that if there happens to be more than one SMMUv3 device in a system, the second and subsequent probes will wind up returning -EBUSY to the driver core and getting torn down again. Avoid re-setting ops if ours are already installed, so that any genuine failures stand out. Fixes: 08d4ca2a ("iommu/arm-smmu: Support non-PCI devices with SMMUv3") CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> CC: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
-
Robin Murphy authored
The 32-bit ARM DMA configuration code predates the IOMMU core's default domain functionality, and instead relies on allocating its own domains and attaching any devices using the generic IOMMU binding to them. Unfortunately, it does this relatively early on in the creation of the device, before we've seen our add_device callback, which leads us to attempt to operate on a half-configured master. To avoid a crash, check for this situation on attach, but refuse to play, as there's nothing we can do. This at least allows VFIO to keep working for people who update their 32-bit DTs to the generic binding, albeit with a few (innocuous) warnings from the DMA layer on boot. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
-
Takashi Iwai authored
Currently the ALSA proc handler allows read or write even if the proc file were write-only or read-only. It's mostly harmless, does thing but allocating memory and ignores the input/output. But it doesn't tell user about the invalid use, and it's confusing and inconsistent in comparison with other proc files. This patch adds some sanity checks and let the proc handler returning an -EIO error when the invalid read/write is performed. Cc: <stable@vger.kernel.org> # v4.2+ Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The ALSA proc handler allows currently the write in the unlimited size until kmalloc() fails. But basically the write is supposed to be only for small inputs, mostly for one line inputs, and we don't have to handle too large sizes at all. Since the kmalloc error results in the kernel warning, it's better to limit the size beforehand. This patch adds the limit of 16kB, which must be large enough for the currently existing code. Cc: stable@vger.kernel.org # v4.2+ Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Heiko Carstens authored
Commit 345ddcc8 ("ftrace: Have set_ftrace_pid use the bitmap like events do") added a couple of this_cpu_read calls to the ftrace code. On x86 this is not a problem, since it has single instructions to read percpu data. Other architectures which use the generic variant now have additional preempt_disable and preempt_enable calls in the core ftrace code. This may lead to recursive calls and in result to a dead machine, e.g. if preemption and debugging options are enabled. To fix this use the notrace variant of preempt_disable and preempt_enable within the generic percpu code. Reported-and-bisected-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Tested-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Fixes: 345ddcc8 ("ftrace: Have set_ftrace_pid use the bitmap like events do") Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Acked-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
-
- 07 Nov, 2016 5 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linuxLinus Torvalds authored
Pull arm64 fix from Will Deacon: "It's been pretty quiet on the fixes side of things for us, but Artem reported a build failure introduced during the merge window that appears with older GCCs that do not support asm goto. The fix is bigger than I'd like, but it's a mechnical move of some constants to break an include dependency between atomic.h and jump_label.h when !HAVE_JUMP_LABEL. Summary: - Fix build failure on compilers without asm goto" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: Fix circular include of asm/lse.h through linux/jump_label.h
-
Linus Torvalds authored
Merge tag 'openrisc-for-linus-v4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull openrisc fix from Guenter Roeck: "Fix openrisc crash caused by ro_init changes" * tag 'openrisc-for-linus-v4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: openrisc: Define __ro_after_init to avoid crash
-
Linus Torvalds authored
Merge tag 'hwmon-for-linus-v4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fix from Guenter Roeck: "Fix resource leak on devm_kcalloc failure" * tag 'hwmon-for-linus-v4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (core) fix resource leak on devm_kcalloc failure
-
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hidLinus Torvalds authored
Pull HID fixes from Jiri Kosina: - modprobe-after-rmmod load failure bugfix for intel-ish, from Even Xu - IRQ probing bugfix for intel-ish, from Srinivas Pandruvada - attribute parsing fix in hid-sensor, from Ooi, Joyce - other small misc fixes / quirky device additions * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: HID: sensor: fix attributes in HID sensor interface HID: intel-ish-hid: request_irq failure HID: intel-ish-hid: Fix driver reinit failure HID: intel-ish-hid: Move DMA disable code to new function HID: intel-ish-hid: consolidate ish wake up operation HID: usbhid: add ATEN CS962 to list of quirky devices HID: intel-ish-hid: Fix !CONFIG_PM build warning HID: sensor-hub: Fix packing of result buffer for feature report
-
Mike Marshall authored
We recently refactored the Orangefs debugfs code. The refactor seemed to trigger dan.carpenter@oracle.com's static tester to find a possible double-free in the code. While designing the fix we saw a condition under which the buffer being freed could also be overflowed. We also realized how to rebuild the related debugfs file's "contents" (a string) without deleting and re-creating the file. This fix should eliminate the possible double-free, the potential overflow and improve code readability. Signed-off-by: Mike Marshall <hubcap@omnibond.com> Signed-off-by: Martin Brandenburg <martin@omnibond.com>
-
- 06 Nov, 2016 1 commit
-
-
Guenter Roeck authored
openrisc qemu tests fail with the following crash. Unable to handle kernel access at virtual address 0xc0300c34 Oops#: 0001 CPU #: 0 PC: c016c710 SR: 0000ae67 SP: c1017e04 GPR00: 00000000 GPR01: c1017e04 GPR02: c0300c34 GPR03: c0300c34 GPR04: 00000000 GPR05: c0300cb0 GPR06: c0300c34 GPR07: 000000ff GPR08: c107f074 GPR09: c0199ef4 GPR10: c1016000 GPR11: 00000000 GPR12: 00000000 GPR13: c107f044 GPR14: c0473774 GPR15: 07ce0000 GPR16: 00000000 GPR17: c107ed8a GPR18: 00009600 GPR19: c107f044 GPR20: c107ee74 GPR21: 00000003 GPR22: c0473770 GPR23: 00000033 GPR24: 000000bf GPR25: 00000019 GPR26: c046400c GPR27: 00000001 GPR28: c0464028 GPR29: c1018000 GPR30: 00000006 GPR31: ccf37483 RES: 00000000 oGPR11: ffffffff Process swapper (pid: 1, stackpage=c1001960) Stack: Stack dump [0xc1017cf8]: sp + 00: 0xc1017e04 sp + 04: 0xc0300c34 sp + 08: 0xc0300c34 sp + 12: 0x00000000 ... Bisect points to commit d2ec3f77 ("pty: make ptmx file ops read-only after init"). Fix by defining __ro_after_init for the openrisc architecture, similar to parisc. Fixes: d2ec3f77 ("pty: make ptmx file ops read-only after init") Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Stafford Horne <shorne@gmail.com>
-
- 05 Nov, 2016 9 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxLinus Torvalds authored
Pull i2c fix from Wolfram Sang: "A bugfix for the I2C core fixing a (rare) race condition" * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: core: fix NULL pointer dereference under race condition
-
Catalin Marinas authored
Commit efd9e03f ("arm64: Use static keys for CPU features") introduced support for static keys in asm/cpufeature.h, including linux/jump_label.h. When CC_HAVE_ASM_GOTO is not defined, this causes a circular dependency via linux/atomic.h, asm/lse.h and asm/cpufeature.h. This patch moves the capability macros out out of asm/cpufeature.h into a separate asm/cpucaps.h and modifies some of the #includes accordingly. Fixes: efd9e03f ("arm64: Use static keys for CPU features") Reported-by: Artem Savkov <asavkov@redhat.com> Tested-by: Artem Savkov <asavkov@redhat.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
-
Linus Torvalds authored
Merge branches 'sched-urgent-for-linus' and 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull stack vmap fixups from Thomas Gleixner: "Two small patches related to sched_show_task(): - make sure to hold a reference on the task stack while accessing it - remove the thread_saved_pc printout .. and add a sanity check into release_task_stack() to catch problems with task stack references" * 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/core: Remove pointless printout in sched_show_task() sched/core: Fix oops in sched_show_task() * 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: fork: Add task stack refcounting sanity check and prevent premature task stack freeing
-
git://git.kernel.org/pub/scm/linux/kernel/git/shli/mdLinus Torvalds authored
Pull MD fixes from Shaohua Li: "There are several bug fixes queued: - fix raid5-cache recovery bugs - fix discard IO error handling for raid1/10 - fix array sync writes bogus position to superblock - fix IO error handling for raid array with external metadata" * tag 'md/4.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/shli/md: md: be careful not lot leak internal curr_resync value into metadata. -- (all) raid1: handle read error also in readonly mode raid5-cache: correct condition for empty metadata write md: report 'write_pending' state when array in sync md/raid5: write an empty meta-block when creating log super-block md/raid5: initialize next_checkpoint field before use RAID10: ignore discard error RAID1: ignore discard error
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds authored
Pull SCSI fixes from James Bottomley: "Two more important data integrity fixes related to RAID device drivers which wrongly throw away the SYNCHRONIZE CACHE command in the non-RAID path and a memory leak in the scsi_debug driver" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: arcmsr: Send SYNCHRONIZE_CACHE command to firmware scsi: scsi_debug: Fix memory leak if LBP enabled and module is unloaded scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) devices
-
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/inputLinus Torvalds authored
Pull input subsystem updates from Dmitry Torokhov. * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: psmouse - cleanup Focaltech code Input: i8042 - add XMG C504 to keyboard reset table
-
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394Linus Torvalds authored
Pull FireWire (IEEE 1394) fixes from Stefan Richter: - add missing input validation to the firewire-net driver. Invalid IP-over-1394 encapsulation headers could trigger buffer overflows (CVE 2016-8633). - IP-over-1394 link fragmentation headers were read and written incorrectly, breaking fragmented RX/TX with other OS's stacks. * tag 'firewire-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: firewire: net: fix fragmented datagram_size off-by-one firewire: net: guard against rx buffer overflows
-
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-mediaLinus Torvalds authored
Pull media fixes from Mauro Carvalho Chehab: "A series of fixup patches meant to fix the usage of DMA on stack, plus one warning fixup" * tag 'media/v4.9-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (32 commits) [media] radio-bcm2048: don't ignore errors [media] pctv452e: fix semicolon.cocci warnings [media] flexcop-usb: don't use stack for DMA [media] stk-webcam: don't use stack for DMA [media] s2255drv: don't use stack for DMA [media] cpia2_usb: don't use stack for DMA [media] digitv: handle error code on RC query [media] dw2102: return error if su3000_power_ctrl() fails [media] nova-t-usb2: handle error code on RC query [media] technisat-usb2: use DMA buffers for I2C transfers [media] pctv452e: don't call BUG_ON() on non-fatal error [media] pctv452e: don't do DMA on stack [media] nova-t-usb2: don't do DMA on stack [media] gp8psk: don't go past the buffer size [media] gp8psk: don't do DMA on stack [media] dtv5100: don't do DMA on stack [media] dtt200u: handle USB control message errors [media] dtt200u: don't do DMA on stack [media] dtt200u-fe: handle errors on USB control messages [media] dtt200u-fe: don't do DMA on stack ...
-