- Jun 19, 2016
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-coreLinus Torvalds authored
Pull driver core fixes from Greg KH: "Here are a small number of debugfs, ISA, and one driver core fix for 4.7-rc4. All of these resolve reported issues. The ISA ones have spent the least amount of time in linux-next, sorry about that, I didn't realize they were regressions that needed to get in now (thanks to Thorsten for the prodding!) but they do all pass the 0-day bot tests. The others have been in linux-next for a while now. Full details about them are in the shortlog below" * tag 'driver-core-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: isa: Dummy isa_register_driver should return error code isa: Call isa_bus_init before dependent ISA bus drivers register watchdog: ebc-c384_wdt: Allow build for X86_64 iio: stx104: Allow build for X86_64 gpio: Allow PC/104 devices on X86_64 isa: Allow ISA-style drivers on modern systems base: make module_create_drivers_dir race-free debugfs: open_proxy_open(): avoid double fops release debugfs: full_proxy_open(): free proxy on ->open() failure kernel/kcov: unproxify debugfs file's fops
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-miscLinus Torvalds authored
Pull char/misc driver fixes from Greg KH: "Here are a small number of char and misc driver fixes for 4.7-rc4. They resolve some minor issues that have been reported, and have all been in linux-next" * tag 'char-misc-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: coresight: Handle build path error coresight: Fix erroneous memset in tmc_read_unprepare_etr coresight: Fix tmc_read_unprepare_etr coresight: Fix NULL pointer dereference in _coresight_build_path extcon: palmas: Fix boot up state of VBUS when using GPIO detection mcb: Acquire reference to carrier module in core mcb: Acquire reference to device in probe mei: don't use wake_up_interruptible for wr_ctrl
-
- Jun 18, 2016
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfsLinus Torvalds authored
Pull btrfs fixes from Chris Mason: "The most user visible change here is a fix for our recent superblock validation checks that were causing problems on non-4k pagesized systems" * 'for-linus-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs: Btrfs: btrfs_check_super_valid: Allow 4096 as stripesize btrfs: remove build fixup for qgroup_account_snapshot btrfs: use new error message helper in qgroup_account_snapshot btrfs: avoid blocking open_ctree from cleaner_kthread Btrfs: don't BUG_ON() in btrfs_orphan_add btrfs: account for non-CoW'd blocks in btrfs_abort_transaction Btrfs: check if extent buffer is aligned to sectorsize btrfs: Use correct format specifier
-
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pmLinus Torvalds authored
Pull ACPI fix from Rafael Wysocki: "Revert a recent ACPICA commit that introduced a suspend-to-RAM regression on one system due to incorrect information in its ACPI tables that had not been taken into consideration at all before (and everything worked), but the commit in question started to use it" * tag 'acpi-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: Revert "ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support for acpi_hw_write()"
-
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pmLinus Torvalds authored
Pull power management fixes from Rafael Wysocki: "Fixes for two recent regressions that may lead to degraded performance (operating performance points framework, intel_pstate). Specifics: - Fix a recent regression in the intel_pstate driver that may lead to degraded performance on some systems due to missing turbo state entry in the table returned by the ACPI _PSS object (Srinivas Pandruvada). - Fix a recent regression in the OPP (operating performance points) framework that may lead to degraded performance on some systems where the OPP table is created too early (Viresh Kumar)" * tag 'pm-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: PM / OPP: Add 'UNKNOWN' status for shared_opp in struct opp_table cpufreq: intel_pstate: Adjust _PSS[0] freqeuency if needed
-
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hidLinus Torvalds authored
Pull HID subsystem fixes from Jiri Kosina: - kernel panic fix in hid-elo from Oliver Neukum - Surface Pro 3 device quirk from Benjamin Tissoires * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: HID: multitouch: Add MT_QUIRK_NOT_SEEN_MEANS_UP to Surface Pro 3 HID: elo: kill not flush the work
-
William Breathitt Gray authored
The inline isa_register_driver stub simply allows compilation on systems with CONFIG_ISA disabled; the dummy isa_register_driver does not register an isa_driver at all. The inline isa_register_driver should return -ENODEV to indicate lack of support when attempting to register an isa_driver on such a system with CONFIG_ISA disabled. Cc: Matthew Wilcox <matthew@wil.cx> Reported-by:
Sasha Levin <sasha.levin@oracle.com> Tested-by: Ye Xiaolong Signed-off-by:
William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
William Breathitt Gray authored
The isa_bus_init function must be called before drivers which utilize the ISA bus driver are registered. A race condition for initilization exists if device_initcall is used (the isa_bus_init callback is placed in the same initcall level as dependent drivers which use module_init). This patch ensures that isa_bus_init is called first by utilizing postcore_initcall in favor of device_initcall. Fixes: a5117ba7 ("[PATCH] Driver model: add ISA bus") Cc: Rene Herman <rene.herman@keyaccess.nl> Signed-off-by:
William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
William Breathitt Gray authored
With the introduction of the ISA_BUS_API Kconfig option, ISA-style drivers may be built for X86_64 architectures. This patch changes the ISA Kconfig option dependency of the WinSystems EBC-C384 watchdog timer driver to ISA_BUS_API, thus allowing it to build for X86_64 as it is expected to. Cc: Wim Van Sebroeck <wim@iguana.be> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
William Breathitt Gray authored
With the introduction of the ISA_BUS_API Kconfig option, ISA-style drivers may be built for X86_64 architectures. This patch changes the ISA Kconfig option dependency of the Apex Embedded Systems STX104 DAC driver to ISA_BUS_API, thus allowing it to build for X86_64 as it is expected to. Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
William Breathitt Gray <vilhelm.gray@gmail.com> Acked-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
William Breathitt Gray authored
With the introduction of the ISA_BUS_API Kconfig option, ISA-style drivers may be built for X86_64 architectures. This patch changes the ISA Kconfig option dependency of the PC/104 drivers to ISA_BUS_API, thus allowing them to build for X86_64 as they are expected to. Cc: Alexandre Courbot <gnurou@gmail.com> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
William Breathitt Gray <vilhelm.gray@gmail.com> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
William Breathitt Gray authored
Several modern devices, such as PC/104 cards, are expected to run on modern systems via an ISA bus interface. Since ISA is a legacy interface for most modern architectures, ISA support should remain disabled in general. Support for ISA-style drivers should be enabled on a per driver basis. To allow ISA-style drivers on modern systems, this patch introduces the ISA_BUS_API and ISA_BUS Kconfig options. The ISA bus driver will now build conditionally on the ISA_BUS_API Kconfig option, which defaults to the legacy ISA Kconfig option. The ISA_BUS Kconfig option allows the ISA_BUS_API Kconfig option to be selected on architectures which do not enable ISA (e.g. X86_64). The ISA_BUS Kconfig option is currently only implemented for X86 architectures. Other architectures may have their own ISA_BUS Kconfig options added as required. Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
William Breathitt Gray <vilhelm.gray@gmail.com> Acked-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Rafael J. Wysocki authored
* acpica-fixes: Revert "ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support for acpi_hw_write()"
-
Rafael J. Wysocki authored
* pm-opp: PM / OPP: Add 'UNKNOWN' status for shared_opp in struct opp_table * pm-cpufreq-fixes: cpufreq: intel_pstate: Adjust _PSS[0] freqeuency if needed
-
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linuxLinus Torvalds authored
Pull arm64 fixes from Will Deacon: "The main things are getting kgdb up and running with upstream GDB after a protocol change was reverted and fixing our spin_unlock_wait and spin_is_locked implementations after doing some similar work with PeterZ on the qspinlock code last week. Whilst we haven't seen any failures in practice, it's still worth getting this fixed. Summary: - Plug the ongoing spin_unlock_wait/spin_is_locked mess - KGDB protocol fix to sync w/ GDB - Fix MIDR-based PMU probing for old 32-bit SMP systems (OMAP4/Realview) - Minor tweaks to the fault handling path" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: kgdb: Match pstate size with gdbserver protocol arm64: spinlock: Ensure forward-progress in spin_unlock_wait arm64: spinlock: fix spin_unlock_wait for LSE atomics arm64: spinlock: order spin_{is_locked,unlock_wait} against local locks arm: pmu: Fix non-devicetree probing arm64: mm: mark fault_info table const arm64: fix dump_instr when PAN and UAO are in use
-
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommuLinus Torvalds authored
Pull IOMMU fixes from Joerg Roedel: "Three patches queued up: - Fix for ARM-SMMU to add a missing iommu-ops callback which is required by common iommu code - Fix for the rockchip iommu where the wrong MMUs got the commands - A regression fix for the Intel VT-d driver. The regression only showed up on X58 chipsets with more than one iommu. These chipsets seem to require that QI is enabled on all IOMMUs before it can be used" * tag 'iommu-fixes-v4.7-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: iommu/vt-d: Enable QI on all IOMMUs before setting root entry iommu/rockchip: Fix zap cache during device attach iommu/arm-smmu: Wire up map_sg for arm-smmu-v3
-
git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-ledsLinus Torvalds authored
Pull LED fixes from Jacek Anaszewski: - Fix brightness setting upon hardware blinking enabled - Handle suspend/resume in heartbeat trigger * tag 'for-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds: leds: handle suspend/resume in heartbeat trigger leds: core: Fix brightness setting upon hardware blinking enabled
-
Chris Mason authored
Merge branch 'for-chris' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux into for-linus-4.7
-
Chandan Rajendra authored
Older btrfs-progs/mkfs.btrfs sets 4096 as the stripesize. Hence restricting stripesize to be equal to sectorsize would cause super block validation to return an error on architectures where PAGE_SIZE is not equal to 4096. Hence as a workaround, this commit allows stripesize to be set to 4096 bytes. Signed-off-by:
Chandan Rajendra <chandan@linux.vnet.ibm.com> Signed-off-by:
David Sterba <dsterba@suse.com>
-
David Sterba authored
Introduced in 2c1984f2 ("btrfs: build fixup for qgroup_account_snapshot") as temporary bisectability build fixup. Signed-off-by:
David Sterba <dsterba@suse.com>
-
David Sterba authored
We've renamed btrfs_std_error, this one is left from last merge. Signed-off-by:
David Sterba <dsterba@suse.com>
-
Zygo Blaxell authored
This fixes a problem introduced in commit 2f3165ec "btrfs: don't force mounts to wait for cleaner_kthread to delete one or more subvolumes". open_ctree eventually calls btrfs_replay_log which in turn calls btrfs_commit_super which tries to lock the cleaner_mutex, causing a recursive mutex deadlock during mount. Instead of playing whack-a-mole trying to keep up with all the functions that may want to lock cleaner_mutex, put all the cleaner_mutex lockers back where they were, and attack the problem more directly: keep cleaner_kthread asleep until the filesystem is mounted. When filesystems are mounted read-only and later remounted read-write, open_ctree did not set fs_info->open and neither does anything else. Set this flag in btrfs_remount so that neither btrfs_delete_unused_bgs nor cleaner_kthread get confused by the common case of "/" filesystem read-only mount followed by read-write remount. Signed-off-by:
Zygo Blaxell <ce3g8jdj@umail.furryterror.org> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
David Sterba <dsterba@suse.com>
-
Josef Bacik authored
This is just a screwup for developers, so change it to an ASSERT() so developers notice when things go wrong and deal with the error appropriately if ASSERT() isn't enabled. Thanks, Signed-off-by:
Josef Bacik <jbacik@fb.com> Reviewed-by:
Mark Fasheh <mfasheh@suse.de> Signed-off-by:
David Sterba <dsterba@suse.com>
-
Jeff Mahoney authored
The test for !trans->blocks_used in btrfs_abort_transaction is insufficient to determine whether it's safe to drop the transaction handle on the floor. btrfs_cow_block, informed by should_cow_block, can return blocks that have already been CoW'd in the current transaction. trans->blocks_used is only incremented for new block allocations. If an operation overlaps the blocks in the current transaction entirely and must abort the transaction, we'll happily let it clean up the trans handle even though it may have modified the blocks and will commit an incomplete operation. In the long-term, I'd like to do closer tracking of when the fs is actually modified so we can still recover as gracefully as possible, but that approach will need some discussion. In the short term, since this is the only code using trans->blocks_used, let's just switch it to a bool indicating whether any blocks were used and set it when should_cow_block returns false. Cc: stable@vger.kernel.org # 3.4+ Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Reviewed-by:
Filipe Manana <fdmanana@suse.com> Signed-off-by:
David Sterba <dsterba@suse.com>
-
Liu Bo authored
Thanks to fuzz testing, we can pass an invalid bytenr to extent buffer via alloc_extent_buffer(). An unaligned eb can have more pages than it should have, which ends up extent buffer's leak or some corrupted content in extent buffer. This adds a warning to let us quickly know what was happening. Now that alloc_extent_buffer() no more returns NULL, this changes its caller and callers of its caller to match with the new error handling. Signed-off-by:
Liu Bo <bo.li.liu@oracle.com> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
David Sterba <dsterba@suse.com>
-
Heinrich Schuchardt authored
Component mirror_num of struct btrfsic_block is defined as unsigned int. Use %u as format specifier. Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
David Sterba <dsterba@suse.com>
-
- Jun 17, 2016
-
-
Joerg Roedel authored
This seems to be required on some X58 chipsets on systems with more than one IOMMU. QI does not work until it is enabled on all IOMMUs in the system. Reported-by:
Dheeraj CVR <cvr.dheeraj@gmail.com> Tested-by:
Dheeraj CVR <cvr.dheeraj@gmail.com> Fixes: 5f0a7f76 ('iommu/vt-d: Make root entry visible for hardware right after allocation') Cc: stable@vger.kernel.org Signed-off-by:
Joerg Roedel <jroedel@suse.de>
-
Linus Torvalds authored
Merge tag 'pwm/for-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm Pull pwm fixes from Thierry Reding: "These changes fix a bit of fallout from the introduction of the atomic API" * tag 'pwm/for-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: pwm: atmel-hlcdc: Fix default PWM polarity pwm: sysfs: Get return value from pwm_apply_state() pwm: Improve args checking in pwm_apply_state()
-
git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds authored
Pull KVM fixes from Paolo Bonzini: - miscellaneous fixes for MIPS and s390 - one new kvm_stat for s390 - correctly disable VT-d posted interrupts with the rest of posted interrupts - "make randconfig" fix for x86 AMD - off-by-one in irq route check (the "good" kind that errors out a bit too early!) * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: kvm: vmx: check apicv is active before using VT-d posted interrupt kvm: Fix irq route entries exceeding KVM_MAX_IRQ_ROUTES kvm: svm: Do not support AVIC if not CONFIG_X86_LOCAL_APIC kvm: svm: Fix implicit declaration for __default_cpu_present_to_apicid() MIPS: KVM: Fix CACHE triggered exception emulation MIPS: KVM: Don't unwind PC when emulating CACHE MIPS: KVM: Include bit 31 in segment matches MIPS: KVM: Fix modular KVM under QEMU KVM: s390: Add stats for PEI events KVM: s390: ignore IBC if zero
-
git://linux-nfs.org/~bfields/linuxLinus Torvalds authored
Pull nfsd bugfixes from Bruce Fields: "Oleg Drokin found and fixed races in the nfsd4 state code that go back to the big nfs4_lock_state removal around 3.17 (but that were also probably hard to reproduce before client changes in 3.20 allowed the client to perform parallel opens). Also fix a 4.1 backchannel crash due to rpc multipath changes in 4.6. Trond acked the client-side rpc fixes going through my tree" * tag 'nfsd-4.7-1' of git://linux-nfs.org/~bfields/linux: nfsd: Make init_open_stateid() a bit more whole nfsd: Extend the mutex holding region around in nfsd4_process_open2() nfsd: Always lock state exclusively. rpc: share one xps between all backchannels nfsd4/rpc: move backchannel create logic into rpc code SUNRPC: fix xprt leak on xps allocation failure nfsd: Fix NFSD_MDS_PR_KEY on 32-bit by adding ULL postfix
-
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfsLinus Torvalds authored
Pull overlayfs fixes from Miklos Szeredi: "This contains two regression fixes: one for the xattr API update and one for using the mounter's creds in file creation in overlayfs. There's also a fix for a bug in handling hard linked AF_UNIX sockets that's been there from day one. This fix is overlayfs only despite the fact that it touches code outside the overlay filesystem: d_real() is an identity function for all except overlay dentries" * 'overlayfs-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs: ovl: fix uid/gid when creating over whiteout ovl: xattr filter fix af_unix: fix hard linked sockets on overlay vfs: add d_real_inode() helper
-
Dan Carpenter authored
If __key_link_begin() failed then "edit" would be uninitialized. I've added a check to fix that. This allows a random user to crash the kernel, though it's quite difficult to achieve. There are three ways it can be done as the user would have to cause an error to occur in __key_link(): (1) Cause the kernel to run out of memory. In practice, this is difficult to achieve without ENOMEM cropping up elsewhere and aborting the attempt. (2) Revoke the destination keyring between the keyring ID being looked up and it being tested for revocation. In practice, this is difficult to time correctly because the KEYCTL_REJECT function can only be used from the request-key upcall process. Further, users can only make use of what's in /sbin/request-key.conf, though this does including a rejection debugging test - which means that the destination keyring has to be the caller's session keyring in practice. (3) Have just enough key quota available to create a key, a new session keyring for the upcall and a link in the session keyring, but not then sufficient quota to create a link in the nominated destination keyring so that it fails with EDQUOT. The bug can be triggered using option (3) above using something like the following: echo 80 >/proc/sys/kernel/keys/root_maxbytes keyctl request2 user debug:fred negate @t The above sets the quota to something much lower (80) to make the bug easier to trigger, but this is dependent on the system. Note also that the name of the keyring created contains a random number that may be between 1 and 10 characters in size, so may throw the test off by changing the amount of quota used. Assuming the failure occurs, something like the following will be seen: kfree_debugcheck: out of range ptr 6b6b6b6b6b6b6b68h ------------[ cut here ]------------ kernel BUG at ../mm/slab.c:2821! ... RIP: 0010:[<ffffffff811600f9>] kfree_debugcheck+0x20/0x25 RSP: 0018:ffff8804014a7de8 EFLAGS: 00010092 RAX: 0000000000000034 RBX: 6b6b6b6b6b6b6b68 RCX: 0000000000000000 RDX: 0000000000040001 RSI: 00000000000000f6 RDI: 0000000000000300 RBP: ffff8804014a7df0 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8804014a7e68 R11: 0000000000000054 R12: 0000000000000202 R13: ffffffff81318a66 R14: 0000000000000000 R15: 0000000000000001 ... Call Trace: kfree+0xde/0x1bc assoc_array_cancel_edit+0x1f/0x36 __key_link_end+0x55/0x63 key_reject_and_link+0x124/0x155 keyctl_reject_key+0xb6/0xe0 keyctl_negate_key+0x10/0x12 SyS_keyctl+0x9f/0xe7 do_syscall_64+0x63/0x13a entry_SYSCALL64_slow_path+0x25/0x25 Fixes: f70e2e06 ('KEYS: Do preallocation for __key_link()') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
David Howells <dhowells@redhat.com> cc: stable@vger.kernel.org Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Daniel Thompson authored
Current versions of gdb do not interoperate cleanly with kgdb on arm64 systems because gdb and kgdb do not use the same register description. This patch modifies kgdb to work with recent releases of gdb (>= 7.8.1). Compatibility with gdb (after the patch is applied) is as follows: gdb-7.6 and earlier Ok gdb-7.7 series Works if user provides custom target description gdb-7.8(.0) Works if user provides custom target description gdb-7.8.1 and later Ok When commit 44679a4f ("arm64: KGDB: Add step debugging support") was introduced it was paired with a gdb patch that made an incompatible change to the gdbserver protocol. This patch was eventually merged into the gdb sources: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=a4d9ba85ec5597a6a556afe26b712e878374b9dd The change to the protocol was mostly made to simplify big-endian support inside the kernel gdb stub. Unfortunately the gdb project released gdb-7.7.x and gdb-7.8.0 before the protocol incompatibility was identified and reversed: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=bdc144174bcb11e808b4e73089b850cf9620a7ee This leaves us in a position where kgdb still uses the no-longer-used protocol; gdb-7.8.1, which restored the original behaviour, was released on 2014-10-29. I don't believe it is possible to detect/correct the protocol incompatiblity which means the kernel must take a view about which version of the gdb remote protocol is "correct". This patch takes the view that the original/current version of the protocol is correct and that version found in gdb-7.7.x and gdb-7.8.0 is anomalous. Signed-off-by:
Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by:
Will Deacon <will.deacon@arm.com>
-
- Jun 16, 2016
-
-
Viresh Kumar authored
dev_pm_opp_get_sharing_cpus() returns 0 even in the case when the OPP core doesn't know whether or not the table is shared. It works on the majority of platforms, where the OPP table is never created before invoking the function and then -ENODEV is returned by it. But in the case of one platform (Jetson TK1) at least, the situation is a bit different. The OPP table has been created (somehow) before dev_pm_opp_get_sharing_cpus() is called and it returns 0. Its caller treats that as 'the CPUs don't share OPPs' and that leads to degraded performance. Fix this by converting 'shared_opp' in struct opp_table to an enum and making dev_pm_opp_get_sharing_cpus() return -EINVAL in case when the value of that field is "access unknown", so that the caller can handle it accordingly (cpufreq-dt considers that as 'all CPUs share the table', for example). Fixes: 6f707daa "PM / OPP: Add dev_pm_opp_get_sharing_cpus()" Reported-and-tested-by:
Alexandre Courbot <acourbot@nvidia.com> Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> [ rjw : Subject & changelog ] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Yang Zhang authored
VT-d posted interrupt is relying on the CPU side's posted interrupt. Need to check whether VCPU's APICv is active before enabing VT-d posted interrupt. Fixes: d62caabb Cc: stable@vger.kernel.org Signed-off-by:
Yang Zhang <yang.zhang.wz@gmail.com> Signed-off-by:
Shengge Ding <shengge.dsg@alibaba-inc.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Xiubo Li authored
These days, we experienced one guest crash with 8 cores and 3 disks, with qemu error logs as bellow: qemu-system-x86_64: /build/qemu-2.0.0/kvm-all.c:984: kvm_irqchip_commit_routes: Assertion `ret == 0' failed. And then we found one patch(bdf026317d) in qemu tree, which said could fix this bug. Execute the following script will reproduce the BUG quickly: irq_affinity.sh ======================================================================== vda_irq_num=25 vdb_irq_num=27 while [ 1 ] do for irq in {1,2,4,8,10,20,40,80} do echo $irq > /proc/irq/$vda_irq_num/smp_affinity echo $irq > /proc/irq/$vdb_irq_num/smp_affinity dd if=/dev/vda of=/dev/zero bs=4K count=100 iflag=direct dd if=/dev/vdb of=/dev/zero bs=4K count=100 iflag=direct done done ======================================================================== The following qemu log is added in the qemu code and is displayed when this bug reproduced: kvm_irqchip_commit_routes: max gsi: 1008, nr_allocated_irq_routes: 1024, irq_routes->nr: 1024, gsi_count: 1024. That's to say when irq_routes->nr == 1024, there are 1024 routing entries, but in the kernel code when routes->nr >= 1024, will just return -EINVAL; The nr is the number of the routing entries which is in of [1 ~ KVM_MAX_IRQ_ROUTES], not the index in [0 ~ KVM_MAX_IRQ_ROUTES - 1]. This patch fix the BUG above. Cc: stable@vger.kernel.org Signed-off-by:
Xiubo Li <lixiubo@cmss.chinamobile.com> Signed-off-by:
Wei Tang <tangwei@cmss.chinamobile.com> Signed-off-by:
Zhang Zhuoyu <zhangzhuoyu@cmss.chinamobile.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Suzuki K Poulose authored
Enabling a component via sysfs (echo 1 > enable_source), would trigger building a path from the enabled sources to the sink. If there is an error in the process (e.g, sink not enabled or the device (CPU corresponding to ETM) is not online), we never report failure, except for leaving a message in the dmesg. Do proper error checking for the build path and return the error. Before: $ echo 0 > /sys/devices/system/cpu/cpu2/online $ echo 1 > /sys/devices/cs_etm/cpu2/enable_source $ echo $? 0 After: $ echo 0 > /sys/devices/system/cpu/cpu2/online $ echo 1 > /sys/devices/cs_etm/cpu2/enable_source -bash: echo: write error: No such device or address Signed-off-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Acked-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Suzuki K Poulose authored
At the end of a trace collection, we try to clear the entire buffer and enable the ETR back if it was already enabled. But, we would have adjusted the drvdata->buf to point to the beginning of the trace data in the trace buffer @drvdata->vaddr. So, the following code which clears the buffer is dangerous and can cause crashes, like below : memset(drvdata->buf, 0, drvdata->size); Unable to handle kernel paging request at virtual address ffffff800a145000 pgd = ffffffc974726000 *pgd=00000009f3e91003, *pud=00000009f3e91003, *pmd=0000000000000000 PREEMPT SMP Modules linked in: CPU: 4 PID: 1692 Comm: dd Not tainted 4.7.0-rc2+ #1721 Hardware name: ARM Juno development board (r0) (DT) task: ffffffc9734a0080 ti: ffffffc974460000 task.ti: ffffffc974460000 PC is at __memset+0x1ac/0x200 LR is at tmc_read_unprepare_etr+0x144/0x1bc pc : [<ffffff80083a05ac>] lr : [<ffffff800859c984>] pstate: 200001c5 ... [<ffffff80083a05ac>] __memset+0x1ac/0x200 [<ffffff800859b2e4>] tmc_release+0x90/0x94 [<ffffff8008202f58>] __fput+0xa8/0x1ec [<ffffff80082030f4>] ____fput+0xc/0x14 [<ffffff80080c3ef8>] task_work_run+0xb0/0xe4 [<ffffff8008088bf4>] do_notify_resume+0x64/0x6c [<ffffff8008084d5c>] work_pending+0x10/0x14 Code: 91010108 54ffff4a 8b040108 cb050042 (d50b7428) Since we clear the buffer anyway in the following call to tmc_etr_enable_hw(), remove the erroneous memset(). Fixes: commit de546197 ("coresight: tmc: allocating memory when needed") Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Suzuki K Poulose authored
At the end of the trace capture, we free the allocated memory, resetting the drvdata->buf to NULL, to indicate that trace data was collected and the next trace session should allocate the memory in tmc_enable_etr_sink_sysfs. The tmc_enable_etr_sink_sysfs, we only allocate memory if drvdata->vaddr is not NULL (which is not performed at the end of previous session). This can cause, drvdata->vaddr getting assigned NULL and later we do memset() which causes a crash as below : Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = ffffffc9747f0000 [00000000] *pgd=00000009f402e003, *pud=00000009f402e003, *pmd=0000000000000000 Internal error: Oops: 96000046 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 1592 Comm: bash Not tainted 4.7.0-rc1+ #1712 Hardware name: ARM Juno development board (r0) (DT) task: ffffffc078fe0080 ti: ffffffc974178000 task.ti: ffffffc974178000 PC is at __memset+0x1ac/0x200 LR is at tmc_enable_etr_sink+0xf8/0x304 pc : [<ffffff80083a002c>] lr : [<ffffff800859be44>] pstate: 400001c5 sp : ffffffc97417bc00 x29: ffffffc97417bc00 x28: ffffffc974178000 Call trace: Exception stack(0xffffffc97417ba40 to 0xffffffc97417bb60) ba40: 0000000000000001 ffffffc974a5d098 ffffffc97417bc00 ffffff80083a002c ba60: ffffffc974a5d118 0000000000000000 0000000000000000 0000000000000000 ba80: 0000000000000001 0000000000000000 ffffff800859bdec 0000000000000040 baa0: ffffff8008b45b58 00000000000001c0 ffffffc97417baf0 ffffff80080eddb4 bac0: 0000000000000003 ffffffc078fe0080 ffffffc078fe0960 ffffffc078fe0940 bae0: 0000000000000000 0000000000000000 00000000007fffc0 0000000000000004 bb00: 0000000000000000 0000000000000040 000000000000003f 0000000000000000 bb20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001 bb40: ffffffc078fe0960 0000000000000018 ffffffffffffffff 0008669628000000 [<ffffff80083a002c>] __memset+0x1ac/0x200 [<ffffff8008599814>] coresight_enable_path+0xa8/0x1dc [<ffffff8008599b10>] coresight_enable+0x88/0x1b8 [<ffffff8008599d88>] enable_source_store+0x3c/0x6c [<ffffff800845eaf4>] dev_attr_store+0x18/0x28 [<ffffff80082829e8>] sysfs_kf_write+0x54/0x64 [<ffffff8008281c30>] kernfs_fop_write+0x148/0x1d8 [<ffffff8008200128>] __vfs_write+0x28/0x110 [<ffffff8008200e88>] vfs_write+0xa0/0x198 [<ffffff80082021b0>] SyS_write+0x44/0xa0 [<ffffff8008084e70>] el0_svc_naked+0x24/0x28 Code: 91010108 54ffff4a 8b040108 cb050042 (d50b7428) This patch fixes the issue by clearing the drvdata->vaddr while we free the allocated buffer at the end of a session, so that we allocate the memory again. Cc: mathieu.poirier@linaro.org Signed-off-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Suzuki K Poulose authored
_coresight_build_path assumes that all the connections of a csdev has the child_dev initialised. This may not be true if the particular component is not supported by the kernel config(e.g TPIU) but is present in the DT. In which case, building a path can cause a crash like this : Unable to handle kernel NULL pointer dereference at virtual address 00000010 pgd = ffffffc9750dd000 [00000010] *pgd=00000009f5e90003, *pud=00000009f5e90003, *pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Modules linked in: CPU: 4 PID: 1348 Comm: bash Not tainted 4.6.0-next-20160517 #1646 Hardware name: ARM Juno development board (r0) (DT) task: ffffffc97517a280 ti: ffffffc9762c4000 task.ti: ffffffc9762c4000 PC is at _coresight_build_path+0x18/0xe4 LR is at _coresight_build_path+0xc0/0xe4 pc : [<ffffff80083d5130>] lr : [<ffffff80083d51d8>] pstate: 20000145 sp : ffffffc9762c7ba0 [<ffffff80083d5130>] _coresight_build_path+0x18/0xe4 [<ffffff80083d51d8>] _coresight_build_path+0xc0/0xe4 [<ffffff80083d51d8>] _coresight_build_path+0xc0/0xe4 [<ffffff80083d51d8>] _coresight_build_path+0xc0/0xe4 [<ffffff80083d51d8>] _coresight_build_path+0xc0/0xe4 [<ffffff80083d51d8>] _coresight_build_path+0xc0/0xe4 [<ffffff80083d5cdc>] coresight_build_path+0x40/0x68 [<ffffff80083d5e14>] coresight_enable+0x74/0x1bc [<ffffff80083d60a0>] enable_source_store+0x3c/0x6c [<ffffff800830b17c>] dev_attr_store+0x18/0x28 [<ffffff80081ca9c4>] sysfs_kf_write+0x40/0x50 [<ffffff80081c9e38>] kernfs_fop_write+0x140/0x1cc [<ffffff8008163ec8>] __vfs_write+0x28/0x110 [<ffffff8008164bf0>] vfs_write+0xa0/0x174 [<ffffff8008165d18>] SyS_write+0x44/0xa0 [<ffffff8008084e70>] el0_svc_naked+0x24/0x28 Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-