summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2016-09-10Merge branch 'libnvdimm-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm Pull libnvdimm fixes from Dan Williams: "nvdimm fixes for v4.8, two of them are tagged for -stable: - Fix devm_memremap_pages() to use track_pfn_insert(). Otherwise, DAX pmd mappings end up with an uncached pgprot, and unusable performance for the device-dax interface. The device-dax interface appeared in 4.7 so this is tagged for -stable. - Fix a couple VM_BUG_ON() checks in the show_smaps() path to understand DAX pmd entries. This fix is tagged for -stable. - Fix a mis-merge of the nfit machine-check handler to flip the polarity of an if() to match the final version of the patch that Vishal sent for 4.8-rc1. Without this the nfit machine check handler never detects / inserts new 'badblocks' entries which applications use to identify lost portions of files. - For test purposes, fix the nvdimm_clear_poison() path to operate on legacy / simulated nvdimm memory ranges. Without this fix a test can set badblocks, but never clear them on these ranges. - Fix the range checking done by dax_dev_pmd_fault(). This is not tagged for -stable since this problem is mitigated by specifying aligned resources at device-dax setup time. These patches have appeared in a next release over the past week. The recent rebase you can see in the timestamps was to drop an invalid fix as identified by the updated device-dax unit tests [1]. The -mm touches have an ack from Andrew" [1]: "[ndctl PATCH 0/3] device-dax test for recent kernel bugs" https://lists.01.org/pipermail/linux-nvdimm/2016-September/006855.html * 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: libnvdimm: allow legacy (e820) pmem region to clear bad blocks nfit, mce: Fix SPA matching logic in MCE handler mm: fix cache mode of dax pmd mappings mm: fix show_smap() for zone_device-pmd ranges dax: fix mapping size check
2016-09-10Merge branch 'i2c/for-current' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "Mostly driver bugfixes, but also a few cleanups which are nice to have out of the way" * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: rk3x: Restore clock settings at resume time i2c: Spelling s/acknowedge/acknowledge/ i2c: designware: save the preset value of DW_IC_SDA_HOLD Documentation: i2c: slave-interface: add note for driver development i2c: mux: demux-pinctrl: run properly with multiple instances i2c: bcm-kona: fix inconsistent indenting i2c: rcar: use proper device with dma_mapping_error i2c: sh_mobile: use proper device with dma_mapping_error i2c: mux: demux-pinctrl: invalidate properly when switching fails
2016-09-10Merge tag 'for_linus_stable' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 Pull fscrypto fixes fromTed Ts'o: "Fix some brown-paper-bag bugs for fscrypto, including one one which allows a malicious user to set an encryption policy on an empty directory which they do not own" * tag 'for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: fscrypto: require write access to mount to set encryption policy fscrypto: only allow setting encryption policy on directories fscrypto: add authorization check for setting encryption policy
2016-09-10perf/x86/intel/uncore: Add Skylake server uncore supportKan Liang
This patch implements the uncore monitoring driver for Skylake server. The uncore subsystem in Skylake server is similar to previous server. There are some differences in config register encoding and pci device IDs. Besides, Skylake introduces many new boxes to reflect the MESH architecture changes. The control registers for IIO and UPI have been extended to 64 bit. This patch also introduces event_mask_ext to handle the high 32 bit mask. The CHA box number could vary for different machines. This patch gets the CHA box number by counting the CHA register space during initialization at runtime. Signed-off-by: Kan Liang <kan.liang@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Link: http://lkml.kernel.org/r/1471378190-17276-3-git-send-email-kan.liang@intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-09-10perf/x86/rapl: Enable Apollo Lake RAPL supportHarry Pan
This patch enables RAPL counters (energy consumption counters) support for Intel Apollo Lake (Goldmont) processors (Model 92): RAPL of Goldmont, unlikes ESU increment of Silvermont/Airmont, it likes the Haswell microarchitecture in 1/2^ESU joules and supports power domains in PP0/PP1/PKG/RAM. ESU and power domains refer to Intel Software Developers' Manual, Vol. 3C, Order No. 325384, Table 35-12. Usage example: $ perf list $ perf stat -a -e power/energy-cores/,power/energy-pkg/ sleep 10 Signed-off-by: Harry Pan <harry.pan@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Cc: bp@alien8.de Cc: gs0622@gmail.com Cc: hpa@zytor.com Cc: srinivas.pandruvada@linux.intel.com Link: http://lkml.kernel.org/r/1473325738-730-1-git-send-email-harry.pan@intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-09-10Merge branch 'perf/urgent' into perf/core, to pick up fixesIngo Molnar
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-09-10sched/deadline: Document behavior of sched_yield()Tommaso Cucinotta
This is a documentation only patch, explaining the behavior of sched_yield() when a SCHED_DEADLINE task calls it (give up remaining runtime and be throttled until next period begins). Signed-off-by: Tommaso Cucinotta <tommaso.cucinotta@sssup.it> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Juri Lelli <juri.lelli@arm.com> Reviewed-by: Luca Abeni <luca.abeni@unitn.it> Reviewed-by: Daniel Bristot de Oliveira <bristot@redhat.com> Cc: Juri Lelli <juri.lelli@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-dl@retis.sssup.it Link: http://lkml.kernel.org/r/1473443117-11794-2-git-send-email-tommaso.cucinotta@sssup.it Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-09-10Revert "sched/fair: Make update_min_vruntime() more readable"Peter Zijlstra
There's a bug in this commit: 97a7142f157a ("sched/fair: Make update_min_vruntime() more readable") ... when !rb_leftmost && curr we fail to advance min_vruntime. So revert it. Reported-by: Byungchul Park <byungchul.park@lge.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-09-10perf/x86/intel: Fix PEBSv3 record drainPeter Zijlstra
Alexander hit the WARN_ON_ONCE(!event) on his Skylake while running the perf fuzzer. This means the PEBSv3 record included a status bit for an inactive event, something that _should_ not happen. Move the code that filters the status bits against our known PEBS events up a spot to guarantee we only deal with events we know about. Further add "continue" statements to the WARN_ON_ONCE()s such that we'll not die nor generate silly events in case we ever do hit them again. Reported-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Tested-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Kan Liang <kan.liang@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vince@deater.net> Cc: stable@vger.kernel.org Fixes: a3d86542de88 ("perf/x86/intel/pebs: Add PEBSv3 decoding") Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-09-10perf/x86/intel/bts: Kill a silly warningAlexander Shishkin
At the moment, intel_bts will WARN() out if there is more than one event writing to the same ring buffer, via SET_OUTPUT, and will only send data from one event to a buffer. There is no reason to have this warning in, so kill it. Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: vince@deater.net Link: http://lkml.kernel.org/r/20160906132353.19887-6-alexander.shishkin@linux.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-09-10perf/x86/intel/bts: Fix BTS PMI detectionAlexander Shishkin
Since BTS doesn't have a dedicated PMI status bit, the driver needs to take extra care to check for the condition that triggers it to avoid spurious NMI warnings. Regardless of the local BTS context state, the only way of knowing that the NMI is ours is to compare the write pointer against the interrupt threshold. Reported-by: Vince Weaver <vincent.weaver@maine.edu> Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: vince@deater.net Link: http://lkml.kernel.org/r/20160906132353.19887-5-alexander.shishkin@linux.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-09-10perf/x86/intel/bts: Fix confused ordering of PMU callbacksAlexander Shishkin
The intel_bts driver is using a CPU-local 'started' variable to order callbacks and PMIs and make sure that AUX transactions don't get messed up. However, the ordering rules in regard to this variable is a complete mess, which recently resulted in perf_fuzzer-triggered warnings and panics. The general ordering rule that is patch is enforcing is that this cpu-local variable be set only when the cpu-local AUX transaction is active; consequently, this variable is to be checked before the AUX related bits can be touched. Reported-by: Vince Weaver <vincent.weaver@maine.edu> Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: vince@deater.net Link: http://lkml.kernel.org/r/20160906132353.19887-4-alexander.shishkin@linux.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-09-10perf/core: Fix aux_mmap_count vs aux_refcount orderAlexander Shishkin
The order of accesses to ring buffer's aux_mmap_count and aux_refcount has to be preserved across the users, namely perf_mmap_close() and perf_aux_output_begin(), otherwise the inversion can result in the latter holding the last reference to the aux buffer and subsequently free'ing it in atomic context, triggering a warning. > ------------[ cut here ]------------ > WARNING: CPU: 0 PID: 257 at kernel/events/ring_buffer.c:541 __rb_free_aux+0x11a/0x130 > CPU: 0 PID: 257 Comm: stopbug Not tainted 4.8.0-rc1+ #2596 > Call Trace: > [<ffffffff810f3e0b>] __warn+0xcb/0xf0 > [<ffffffff810f3f3d>] warn_slowpath_null+0x1d/0x20 > [<ffffffff8121182a>] __rb_free_aux+0x11a/0x130 > [<ffffffff812127a8>] rb_free_aux+0x18/0x20 > [<ffffffff81212913>] perf_aux_output_begin+0x163/0x1e0 > [<ffffffff8100c33a>] bts_event_start+0x3a/0xd0 > [<ffffffff8100c42d>] bts_event_add+0x5d/0x80 > [<ffffffff81203646>] event_sched_in.isra.104+0xf6/0x2f0 > [<ffffffff8120652e>] group_sched_in+0x6e/0x190 > [<ffffffff8120694e>] ctx_sched_in+0x2fe/0x5f0 > [<ffffffff81206ca0>] perf_event_sched_in+0x60/0x80 > [<ffffffff81206d1b>] ctx_resched+0x5b/0x90 > [<ffffffff81207281>] __perf_event_enable+0x1e1/0x240 > [<ffffffff81200639>] event_function+0xa9/0x180 > [<ffffffff81202000>] ? perf_cgroup_attach+0x70/0x70 > [<ffffffff8120203f>] remote_function+0x3f/0x50 > [<ffffffff811971f3>] flush_smp_call_function_queue+0x83/0x150 > [<ffffffff81197bd3>] generic_smp_call_function_single_interrupt+0x13/0x60 > [<ffffffff810a6477>] smp_call_function_single_interrupt+0x27/0x40 > [<ffffffff81a26ea9>] call_function_single_interrupt+0x89/0x90 > [<ffffffff81120056>] finish_task_switch+0xa6/0x210 > [<ffffffff81120017>] ? finish_task_switch+0x67/0x210 > [<ffffffff81a1e83d>] __schedule+0x3dd/0xb50 > [<ffffffff81a1efe5>] schedule+0x35/0x80 > [<ffffffff81128031>] sys_sched_yield+0x61/0x70 > [<ffffffff81a25be5>] entry_SYSCALL_64_fastpath+0x18/0xa8 > ---[ end trace 6235f556f5ea83a9 ]--- This patch puts the checks in perf_aux_output_begin() in the same order as that of perf_mmap_close(). Reported-by: Vince Weaver <vincent.weaver@maine.edu> Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: vince@deater.net Link: http://lkml.kernel.org/r/20160906132353.19887-3-alexander.shishkin@linux.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-09-10perf/core: Fix a race between mmap_close() and set_output() of AUX eventsAlexander Shishkin
In the mmap_close() path we need to stop all the AUX events that are writing data to the AUX area that we are unmapping, before we can safely free the pages. To determine if an event needs to be stopped, we're comparing its ->rb against the one that's getting unmapped. However, a SET_OUTPUT ioctl may turn up inside an AUX transaction and swizzle event::rb to some other ring buffer, but the transaction will keep writing data to the old ring buffer until the event gets scheduled out. At this point, mmap_close() will skip over such an event and will proceed to free the AUX area, while it's still being used by this event, which will set off a warning in the mmap_close() path and cause a memory corruption. To avoid this, always stop an AUX event before its ->rb is updated; this will release the (potentially) last reference on the AUX area of the buffer. If the event gets restarted, its new ring buffer will be used. If another SET_OUTPUT comes and switches it back to the old ring buffer that's getting unmapped, it's also fine: this ring buffer's aux_mmap_count will be zero and AUX transactions won't start any more. Reported-by: Vince Weaver <vincent.weaver@maine.edu> Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: vince@deater.net Link: http://lkml.kernel.org/r/20160906132353.19887-2-alexander.shishkin@linux.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-09-10fscrypto: require write access to mount to set encryption policyEric Biggers
Since setting an encryption policy requires writing metadata to the filesystem, it should be guarded by mnt_want_write/mnt_drop_write. Otherwise, a user could cause a write to a frozen or readonly filesystem. This was handled correctly by f2fs but not by ext4. Make fscrypt_process_policy() handle it rather than relying on the filesystem to get it right. Signed-off-by: Eric Biggers <ebiggers@google.com> Cc: stable@vger.kernel.org # 4.1+; check fs/{ext4,f2fs} Signed-off-by: Theodore Ts'o <tytso@mit.edu> Acked-by: Jaegeuk Kim <jaegeuk@kernel.org>
2016-09-09Move check for prefix path to within cifs_get_root()Sachin Prabhu
Signed-off-by: Sachin Prabhu <sprabhu@redhat.com> Tested-by: Aurelien Aptel <aaptel@suse.com> Signed-off-by: Steve French <smfrench@gmail.com>
2016-09-09Compare prepaths when comparing superblocksSachin Prabhu
The patch fs/cifs: make share unaccessible at root level mountable makes use of prepaths when any component of the underlying path is inaccessible. When mounting 2 separate shares having different prepaths but are other wise similar in other respects, we end up sharing superblocks when we shouldn't be doing so. Signed-off-by: Sachin Prabhu <sprabhu@redhat.com> Tested-by: Aurelien Aptel <aaptel@suse.com> Signed-off-by: Steve French <smfrench@gmail.com>
2016-09-09Fix memory leaks in cifs_do_mount()Sachin Prabhu
Fix memory leaks introduced by the patch fs/cifs: make share unaccessible at root level mountable Also move allocation of cifs_sb->prepath to cifs_setup_cifs_sb(). Signed-off-by: Sachin Prabhu <sprabhu@redhat.com> Tested-by: Aurelien Aptel <aaptel@suse.com> Signed-off-by: Steve French <smfrench@gmail.com>
2016-09-09fscrypto: only allow setting encryption policy on directoriesEric Biggers
The FS_IOC_SET_ENCRYPTION_POLICY ioctl allowed setting an encryption policy on nondirectory files. This was unintentional, and in the case of nonempty regular files did not behave as expected because existing data was not actually encrypted by the ioctl. In the case of ext4, the user could also trigger filesystem errors in ->empty_dir(), e.g. due to mismatched "directory" checksums when the kernel incorrectly tried to interpret a regular file as a directory. This bug affected ext4 with kernels v4.8-rc1 or later and f2fs with kernels v4.6 and later. It appears that older kernels only permitted directories and that the check was accidentally lost during the refactoring to share the file encryption code between ext4 and f2fs. This patch restores the !S_ISDIR() check that was present in older kernels. Signed-off-by: Eric Biggers <ebiggers@google.com> Cc: stable@vger.kernel.org Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2016-09-09fscrypto: add authorization check for setting encryption policyEric Biggers
On an ext4 or f2fs filesystem with file encryption supported, a user could set an encryption policy on any empty directory(*) to which they had readonly access. This is obviously problematic, since such a directory might be owned by another user and the new encryption policy would prevent that other user from creating files in their own directory (for example). Fix this by requiring inode_owner_or_capable() permission to set an encryption policy. This means that either the caller must own the file, or the caller must have the capability CAP_FOWNER. (*) Or also on any regular file, for f2fs v4.6 and later and ext4 v4.8-rc1 and later; a separate bug fix is coming for that. Signed-off-by: Eric Biggers <ebiggers@google.com> Cc: stable@vger.kernel.org # 4.1+; check fs/{ext4,f2fs} Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2016-09-09mtd: nand: davinci: Reinitialize the HW ECC engine in 4bit hwctlKarl Beldan
This fixes subpage writes when using 4-bit HW ECC. There has been numerous reports about ECC errors with devices using this driver for a while. Also the 4-bit ECC has been reported as broken with subpages in [1] and with 16 bits NANDs in the driver and in mach* board files both in mainline and in the vendor BSPs. What I saw with 4-bit ECC on a 16bits NAND (on an LCDK) which got me to try reinitializing the ECC engine: - R/W on whole pages properly generates/checks RS code - try writing the 1st subpage only of a blank page, the subpage is well written and the RS code properly generated, re-reading the same page the HW detects some ECC error, reading the same page again no ECC error is detected Note that the ECC engine is already reinitialized in the 1-bit case. Tested on my LCDK with UBI+UBIFS using subpages. This could potentially get rid of the issue workarounded in [1]. [1] 28c015a9daab ("mtd: davinci-nand: disable subpage write for keystone-nand") Fixes: 6a4123e581b3 ("mtd: nand: davinci_nand, 4-bit ECC for smallpage") Cc: <stable@vger.kernel.org> Signed-off-by: Karl Beldan <kbeldan@baylibre.com> Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2016-09-09drivers: net: phy: mdio-xgene: Add hardware dependencyJean Delvare
The mdio-xgene driver is only useful on X-Gene SoC. Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Iyappan Subramanian <isubramanian@apm.com> Cc: David S. Miller <davem@davemloft.net> Acked-by: Iyappan Subramanian <isubramanian@apm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-09-09Merge tag 'wireless-drivers-for-davem-2016-09-08' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers Kalle Valo says: ==================== wireless-drivers fixes for 4.8 iwlwifi * fix P2P dump trigger * prevent a potential null dereference in iwlmvm * prevent an uninitialized value from being returned in iwlmvm * advertise support for channel width change in AP mode ath10k * fix racy rx status retrieval from htt context * QCA9887 support is not experimental anymore, remove the warning message ath9k * fix regression with led GPIOs * fix AR5416 GPIO access warning brcmfmac * avoid potential stack overflow in brcmf_cfg80211_start_ap() ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2016-09-09dwc_eth_qos: do not register semi-initialized deviceLars Persson
We move register_netdev() to the end of dwceqos_probe() to close any races where the netdev callbacks are called before the initialization has finished. Reported-by: Pavel Andrianov <andrianov@ispras.ru> Signed-off-by: Lars Persson <larper@axis.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-09-09sctp: identify chunks that need to be fragmented at IP levelMarcelo Ricardo Leitner
Previously, without GSO, it was easy to identify it: if the chunk didn't fit and there was no data chunk in the packet yet, we could fragment at IP level. So if there was an auth chunk and we were bundling a big data chunk, it would fragment regardless of the size of the auth chunk. This also works for the context of PMTU reductions. But with GSO, we cannot distinguish such PMTU events anymore, as the packet is allowed to exceed PMTU. So we need another check: to ensure that the chunk that we are adding, actually fits the current PMTU. If it doesn't, trigger a flush and let it be fragmented at IP level in the next round. Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-09-10ACPI / PCI: fix GIC irq model default PCI IRQ polarityLorenzo Pieralisi
On ACPI ARM based systems the GIC interrupt controller and corresponding interrupt model permit only the high polarity for level interrupts. ACPI firmware describes PCI legacy IRQs through entries in the _PRT objects. Entries in the _PRT can be of two types: - Static: not configurable, trigger/polarity default to level-low, _PRT entry defines the global GSI interrupt number - Configurable: _PRT interrupt entry contains a reference to the corresponding PCI interrupt link device (that in turn provides the interrupt descriptor through its _CRS/_PRS methods) Configurable IRQ entries are not currently allowed by the ACPI specification on ARM since they can only be used for interrupt pins that are routable, as per ACPI specifications (version 6.1, 6.2.13): "[...] There are two ways that _PRT can be used. Typically, the interrupt input that a given PCI interrupt is on is configurable. For example, a given PCI interrupt might be configured for either IRQ 10 or 11 on an 8259 interrupt controller. In this model, each interrupt is represented in the ACPI namespace as a PCI Interrupt Link Device. [...]" ARM platforms GIC configurations do not allow dynamic IRQ routing, since routing is statically laid out at synthesis time; therefore PCI interrupt links cannot be used for PCI legacy IRQ descriptions in the _PRT on ARM systems. On the other hand, current core ACPI code handling PCI legacy IRQs consider IRQ trigger/polarity for static _PRT entries as level-low. On ARM systems with a GIC interrupt controller and corresponding ACPI interrupt model this does not work in that GIC interrupt controller is only capable of handling level interrupts whose polarity is high (for PCI legacy IRQs - that are level-low by specification - this means that the legacy IRQs are inverted before reaching the interrupt controller pin), resulting in IRQ allocation failures such as: genirq: Setting trigger mode 8 for irq 18 failed (gic_set_type+0x0/0x48) Change the default polarity for PCI legacy IRQs to high on systems booting wth ACPI on platforms with a GIC interrupt controller model, fixing the discrepancy between specification and HW behaviour. Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Tested-by: Duc Dang <dhdang@apm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-10ACPICA: Update version to 20160831Bob Moore
ACPICA commit 3c8c04c2e8a371018b3a29f5cfe27a241caea48d Version 20160831 Link: https://github.com/acpica/acpica/commit/3c8c04c2 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-10ACPICA: Tables: Tune table mutex to be a leaf lockLv Zheng
ACPICA commit f564d57c6501b97a2871f0b4c048e79910f71783 This patch tunes MTX_TABLES into a leaf lock by always ensuring it is released before holding other locks. This patch also collects all table loading related functions into acpi_tb_load_table() (invoked by load_table opcode) and acpi_tb_install_and_load_table() (invoked by Load opcode and acpi_load_table()) so that we can have lock tuning code collected at the boundary of these 2 functions. Lv Zheng. Link: https://github.com/acpica/acpica/commit/f564d57c Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Dutch Guy <lucht_piloot@gmx.net> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-10ACPICA: Dispatcher: Fix a mutex issue for method auto serializationLv Zheng
ACPICA commit fd305eda14f1a1e684edef4fac53f194bf00ed3f This patch fixes an issue with acpi_ds_auto_serialized_method(). The parser will invoke acpi_ex_release_all_mutexes(), which in return cause mutexes held in ACPI_ERROR_METHOD() failed. Lv Zheng. Link: https://bugs.acpica.org/show_bug.cgi?id=1324 Link: https://github.com/acpica/acpica/commit/fd305eda Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Greg White <gwhite@kupulau.com> Tested-by: Dutch Guy <lucht_piloot@gmx.net> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-10ACPICA: Namespace: Fix dynamic table loading issuesLv Zheng
ACPICA commit 767ee53354e0c4b7e8e7c57c6dd7bf569f0d52bb There are issues related to the namespace/interpreter locks, which causes several ACPI functionalities not specification compliant. The lock issues were detectec when we were trying to fix the functionalities (please see Link # [1] for the details). What's the lock issues? Let's first look into the namespace/interpreter lock usages inside of the object evaluation and the table loading which are the key AML interpretion code paths: Table loading: acpi_ns_load_table L(Namespace) acpi_ns_parse_table acpi_ns_one_complete_parse(LOAD_PASS1/LOAD_PASS2) acpi_ds_load1_begion_op acpi_ds_load1_end_op acpi_ds_load2_begion_op acpi_ds_load2_end_op U(Namespace) Object evaluation: acpi_ns_evaluate L(Interpreter) acpi_ps_execute_method acpi_ds_exec_begin_op acpi_ds_exec_end_op U(Interpreter) acpi_ns_load_table L(Namespace) U(Namespace) acpi_ev_initialize_region L(Namespace) U(Namespace) address_space.Setup address_space.Handler acpi_os_wait_semaphore acpi_os_acquire_mutex acpi_os_sleep L(Interpreter) U(Interpreter) L(Interpreter) acpi_ex_resolve_node_to_value U(Interpreter) acpi_ns_check_return_value Where: 1. L(Interpreter) means acquire(MTX_INTERPRETER); 2. U(Interpreter) means release(MTX_INTERPRETER); 3. L(Namespace) means acquire(MTX_NAMESPACE); 4. U(Namespace) means release(MTX_NAMESPACE); We can see that acpi_ns_exec_module_code() (which invokes acpi_ns_evaluate) is implemented in a deferred way just in order to avoid to reacquire the namespace lock. This is in fact the root cause of many other ACPICA issues: 1. We now know for sure that the module code should be executed right in place by the Windows AML interpreter. So in the current design, if the region initializations/accesses or the table loadings (where the namespace surely should be locked again) happening during the table loading period, dead lock could happen because ACPICA never unlocks the namespace during the AML interpretion. 2. ACPICA interpreter just ensures that all static namespace nodes (named objects created during the acpi_load_tables()) are created (acpi_ns_lookup()) with the correct lock held, but doesn't ensure that the named objects created by the control method are created with the same correct lock held. It requires the control methods to be executed in a serial way after "loading a table", that's why ACPICA requires method auto serialization. This patch fixes these software design issues by extending interpreter enter/exit APIs to hold both interpreter/namespace locks to ensure the lock order correctness, so that we can get these code paths: Table loading: acpi_ns_load_table E(Interpreter) acpi_ns_parse_table acpi_ns_one_complete_parse acpi_ns_execute_table X(Interpreter) acpi_ns_load_table acpi_ev_initialize_region address_space.Setup address_space.Handler acpi_os_wait_semaphore acpi_os_acquire_mutex acpi_os_sleep E(Interpreter) X(Interpreter) Object evaluation: acpi_ns_evaluate E(Interpreter) acpi_ps_execute_method X(Interpreter) acpi_ns_load_table acpi_ev_initialize_region address_space.Setup address_space.Handler acpi_os_wait_semaphore acpi_os_acquire_mutex acpi_os_sleep E(Interpreter) X(Interpreter) Where: 1. E(Interpreter) means acquire(MTX_INTERPRETER, MTX_NAMESPACE); 2. X(Interpreter) means release(MTX_NAMESPACE, MTX_INTERPRETER); After this change, we can see: 1. All namespace nodes creations are locked by the namespace lock. 2. All namespace nodes referencing are locked with the same lock. 3. But we also can notice a defact that, all namespace nodes deletions could be affected by this change. As a consequence, acpi_ns_delete_namespace_subtree() may delete a static namespace node that is still referenced by the interpreter (for example, the parser scopes). Currently, we needn't worry about the last defact because in ACPICA, table unloading is not fully functioning, its design strictly relies on the fact that when the namespace deletion happens, either the AML table or the OSPMs should have been notified and thus either the AML table or the OSPMs shouldn't reference deletion-related namespace nodes during the namespace deletion. And this change still works with the above restrictions applied. While making this a-step-forward helps us to correct the wrong grammar to pull many things back to the correct rail. And pulling things back to the correct rail in return makes it possible for us to support fully functioning table unloading after doing many cleanups. While this patch is generated, all namespace locks are examined to ensure that they can meet either of the following pattens: 1. L(Namespace) U(Namespace) 2. E(Interpreter) X(Interpreter) 3. E(Interpreter) X(Interpreter) L(Namespace) U(Namespace) E(Interpreter) X(Interpreter) We ensure this by adding X(Interpreter)/E(Interpreter) or removing U(Namespace)/L(Namespace) for those currently are executed in the following order: E(Interpreter) L(Namespace) U(Namespace) X(Interpreter) And adding E(Interpreter)/X(Interpreter) for those currently are executed in the following order: X(Interpreter) E(Interpreter) Originally, the interpreter lock is held for the execution AML opcodes, the namespace lock is held for the named object creation AML opcodes. Since they are actually same in MS interpreter (can all be executed during the table loading), we can combine the 2 locks and tune the locking code better in this way. Lv Zheng. Link: https://bugzilla.kernel.org/show_bug.cgi?id=153541 # [1] Link: https://bugzilla.kernel.org/show_bug.cgi?id=121701 # [1] Link: https://bugs.acpica.org/show_bug.cgi?id=1323 Link: https://github.com/acpica/acpica/commit/767ee533 Reported-and-tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reported-and-tested-by: Greg White <gwhite@kupulau.com> Reported-and-tested-by: Dutch Guy <lucht_piloot@gmx.net> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-10ACPICA: Namespace: Add acpi_ns_get_node_unlocked()Lv Zheng
ACPICA commit 3ef1a1bf5612fe1a629424c09eaaeb6f299d313c Add acpi_ns_get_node_unlocked() to be used when ACPI_MTX_NAMESPACE is locked. Lv Zheng. Link: https://github.com/acpica/acpica/commit/3ef1a1bf Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Greg White <gwhite@kupulau.com> Tested-by: Dutch Guy <lucht_piloot@gmx.net> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-10ACPICA: Interpreter: Fix MLC issues by switching to new term_list grammar ↵Lv Zheng
for table loading ACPICA commit 0e24fb67cde08d7df7671d7d7b183490dc79707e The MLC (Module Level Code) is an ACPICA terminology describing the AML code out of any control method, its support is an indication of the interpreter behavior during the table loading. The original implementation of MLC in ACPICA had several issues: 1. Out of any control method, besides of the object creating opcodes, only the code blocks wrapped by "If/Else/While" opcodes were supported. 2. The supported MLC code blocks were executed after loading the table rather than being executed right in place. ============================================================ The demo of this order issue is as follows: Name (OBJ1, 1) If (CND1 == 1) { Name (OBJ2, 2) } Name (OBJ3, 3) The original MLC support created OBJ2 after OBJ3's creation. ============================================================ Other than these limitations, MLC support in ACPICA looks correct. And supporting this should be easy/natural for ACPICA, but enabling of this was blocked by some ACPICA internal and OSPM specific initialization order issues we've fixed recently. The wrong support started from the following false bug fixing commit: Commit: 7f0c826a437157d2b19662977e9cf3b472cf24a6 Subject: ACPICA: Add support for module-level executable AML code Commit: 9a884ab64a4d092b4c3bf24fd9a30f7fbd4591e7 Subject: ACPICA: Add additional module-level code support ... We can confirm Windows interpreter behavior via reverse engineering means. It can be proven that not only If/Else/While wrapped code blocks, all opcodes can be executed at the module level, including operation region accesses. And it can be proven that the MLC should be executed right in place, not in such a deferred way executed after loading the table. And the above facts indeed reflect the spec words around ACPI definition block tables (DSDT/SSDT/...), the entire table and the Scope object is defined by the AML specification in BNF style as: AMLCode := def_block_header term_list def_scope := scope_op pkg_length name_string term_list The bodies of the scope opening terms (AMLCode/Scope) are all term_list, thus the table loading should be no difference than the control method evaluations as the body of the Method is also defined by the AML specification as term_list: def_method := method_op pkg_length name_string method_flags term_list The only difference is: after evaluating control method, created named objects may be freed due to no reference, while named objects created by the table loading should only be freed after unloading the table. So this patch follows the spec and the de-facto standard behavior, enables the new grammar (term_list) for the table loading. By doing so, beyond the fixes to the above issues, we can see additional differences comparing to the old grammar based table loading: 1. Originally, beyond the scope opening terms (AMLCode/Scope), If/Else/While wrapped code blocks under the scope creating terms (Device/power_resource/Processor/thermal_zone) are also supported as deferred MLC, which violates the spec defined grammar where object_list is enforced. With MLC support improved as non-deferred, the interpreter parses such scope creating terms as term_list rather object_list like the scope opening terms. After probing the Windows behavior and proving that it also parses these terms as term_list, we submitted an ECR (Engineering Change Request) to the ASWG (ACPI Specification Working Group) to clarify this. The ECR is titled as "ASL Grammar Clarification for Executable AML Opcodes" and has been accepted by the ASWG. The new grammar will appear in ACPI specification 6.2. 2. Originally, Buffer/Package/operation_region/create_XXXField/bank_field arguments are evaluated in a deferred way after loading the table. With MLC support improved, they are also parsed right in place during the table loading. This is also Windows compliant and the only difference is the removal of the debugging messages implemented before acpi_ds_execute_arguments(), see Link # [1] for the details. A previous commit should have ensured that acpi_check_address_range() won't regress. Note that enabling this feature may cause regressions due to long term Linux ACPI support on top of the wrong grammar. So this patch also prepares a global option to be used to roll back to the old grammar during the period between a regression is reported and the regression is root-cause-fixed. Lv Zheng. Link: https://bugzilla.kernel.org/show_bug.cgi?id=112911 # [1] Link: https://bugzilla.kernel.org/show_bug.cgi?id=117671 # [1] Link: https://bugzilla.kernel.org/show_bug.cgi?id=153541 # [1] Link: https://github.com/acpica/acpica/issues/122 Link: https://bugs.acpica.org/show_bug.cgi?id=963 Link: https://github.com/acpica/acpica/commit/0e24fb67 Reported-and-tested-by: Chris Bainbridge <chris.bainbridge@gmail.com> Reported-by: Ehsan <dashesy@gmail.com> Reported-and-tested-by: Dutch Guy <lucht_piloot@gmx.net> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-10ACPICA: Update return value for intenal _OSI methodBob Moore
ACPICA commit 82101009c7c04845edb3495e66a274a613758bca Instead of 0xFFFFFFFF, _OSI is now defined to return "Ones". This is for compatibility with Windows. The ACPI spec will be updated to reflect this. Link: https://github.com/acpica/acpica/commit/82101009 Reported-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-10ACPICA: Tables: Override all 64-bit GAS fields when ↵Lv Zheng
acpi_gbl_use32_bit_fadt_addresses is TRUE ACPICA commit aaace77db4c3b267a65b75c33f84ace6f65bbcf7 Originally, when acpi_gbl_use32_bit_fadt_addresses is TRUE, GAS override can only happen when the Address field mismatches. According to the investigation result, Windows may favor 32-bit FADT addresses in some cases. So we need this quirk working after enabling full GAS support. This requires us to override GAS access_size/bit_width/bit_offset fields as long as acpi_gbl_use32_bit_fadt_addresses is TRUE. This patch enhances this quirk mechanism to make it working with full GAS support. Lv Zheng. Link: https://bugzilla.kernel.org/show_bug.cgi?id=151501 Link: https://github.com/acpica/acpica/commit/aaace77d Reported-and-tested-by: Andrey Skvortsov <andrej.skvortzov@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-10ACPICA: Tables: Add new table events indicating table ↵Lv Zheng
installation/uninstallation ACPICA commit ed6a5fbc694f3a27d93014391aa9a6f6fe490461 This patch adds 2 new table events to indicate table installation/uninstallation. Currently, as ACPICA never uninstalls tables, this patch thus only adds table handler invocation for the table installation event. Lv Zheng. The 2 events are to be used to fix a sysfs table handling issue related to LoadTable opcode (see Link # [1] below). The actual sysfs fixing code is not included, the sysfs fixes will be sent as separate patches. Link: https://bugzilla.kernel.org/show_bug.cgi?id=150841 # [1] Link: https://github.com/acpica/acpica/commit/ed6a5fbc Reported-by: Jason Voelz <jason.voelz@intel.com> Reported-by: Francisco Leoner <francisco.j.lenoer.soto@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-10ACPICA: Tables: Remove wrong table event macrosLv Zheng
ACPICA commit fcc129d04f865161f308d3b8743496cc3f4d233e There are wrong table event macros, this patch cleans them up. Link: https://bugs.acpica.org/show_bug.cgi?id=1321 Link: https://github.com/acpica/acpica/commit/fcc129d0 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-10ACPICA: Tables: Remove acpi_tb_install_fixed_table()Lv Zheng
ACPICA commit 42c7b848d2faa02c7691ef2c53ea741c23cd4665 acpi_tb_install_fixed_table() is now redundant as we've removed the fixed table indexing mechanism: Commit: 8ec3f459073e67e5c6d78507dec693064b3040a2 Subject: ACPICA: Tables: Fix global table list issues by removing fixed table indexes This patch cleans up the code accordingly. No functional change. Lv Zheng. Link: https://bugs.acpica.org/show_bug.cgi?id=1320 Link: https://github.com/acpica/acpica/commit/42c7b848 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-10ACPICA: Add a couple of casts to uthex.cBob Moore
ACPICA commit 2ba5d3fdaa24d66d67694cbae6ec66971a7a67c1 Required in some environments. Link: https://github.com/acpica/acpica/commit/2ba5d3fd Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-10ACPICA: Cleanup for all string-to-integer conversionsBob Moore
ACPICA commit e2e72a351201fd58e4694418859ae2c247dafca0 Consolidate multiple versions of strtoul64 to one common version. limit possible bases to either 10 or 16. Handles both implicit and explicit conversions. Added a 2-character ascii-to-hex function for GPEs and buffers. Adds a new file, utstrtoul64.c Link: https://github.com/acpica/acpica/commit/e2e72a35 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-10ACPICA: Debugger: Add subcommand for predefined name executionBob Moore
ACPICA commit be5808f0e642ff9963d86f362521b4af2340e2f5 "Execute Predefined" will execute all predefined (public) names within the namespace. Link: https://github.com/acpica/acpica/commit/be5808f0 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-09libnvdimm: allow legacy (e820) pmem region to clear bad blocksDave Jiang
Bad blocks can be injected via /sys/block/pmemN/badblocks. In a situation where legacy pmem is being used or a pmem region created by using memmap kernel parameter, the injected bad blocks are not cleared due to nvdimm_clear_poison() failing from lack of ndctl function pointer. In this case we need to just return as handled and allow the bad blocks to be cleared rather than fail. Reviewed-by: Vishal Verma <vishal.l.verma@intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2016-09-09nfit, mce: Fix SPA matching logic in MCE handlerVishal Verma
The check for a 'pmem' type SPA in the MCE handler was inverted due to a merge/rebase error. Fixes: 6839a6d nfit: do an ARS scrub on hitting a latent media error Cc: linux-acpi@vger.kernel.org Cc: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2016-09-09mm: fix cache mode of dax pmd mappingsDan Williams
track_pfn_insert() in vmf_insert_pfn_pmd() is marking dax mappings as uncacheable rendering them impractical for application usage. DAX-pte mappings are cached and the goal of establishing DAX-pmd mappings is to attain more performance, not dramatically less (3 orders of magnitude). track_pfn_insert() relies on a previous call to reserve_memtype() to establish the expected page_cache_mode for the range. While memremap() arranges for reserve_memtype() to be called, devm_memremap_pages() does not. So, teach track_pfn_insert() and untrack_pfn() how to handle tracking without a vma, and arrange for devm_memremap_pages() to establish the write-back-cache reservation in the memtype tree. Cc: <stable@vger.kernel.org> Cc: Matthew Wilcox <mawilcox@microsoft.com> Cc: Ross Zwisler <ross.zwisler@linux.intel.com> Cc: Nilesh Choudhury <nilesh.choudhury@oracle.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reported-by: Toshi Kani <toshi.kani@hpe.com> Reported-by: Kai Zhang <kai.ka.zhang@oracle.com> Acked-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2016-09-09mm: fix show_smap() for zone_device-pmd rangesDan Williams
Attempting to dump /proc/<pid>/smaps for a process with pmd dax mappings currently results in the following VM_BUG_ONs: kernel BUG at mm/huge_memory.c:1105! task: ffff88045f16b140 task.stack: ffff88045be14000 RIP: 0010:[<ffffffff81268f9b>] [<ffffffff81268f9b>] follow_trans_huge_pmd+0x2cb/0x340 [..] Call Trace: [<ffffffff81306030>] smaps_pte_range+0xa0/0x4b0 [<ffffffff814c2755>] ? vsnprintf+0x255/0x4c0 [<ffffffff8123c46e>] __walk_page_range+0x1fe/0x4d0 [<ffffffff8123c8a2>] walk_page_vma+0x62/0x80 [<ffffffff81307656>] show_smap+0xa6/0x2b0 kernel BUG at fs/proc/task_mmu.c:585! RIP: 0010:[<ffffffff81306469>] [<ffffffff81306469>] smaps_pte_range+0x499/0x4b0 Call Trace: [<ffffffff814c2795>] ? vsnprintf+0x255/0x4c0 [<ffffffff8123c46e>] __walk_page_range+0x1fe/0x4d0 [<ffffffff8123c8a2>] walk_page_vma+0x62/0x80 [<ffffffff81307696>] show_smap+0xa6/0x2b0 These locations are sanity checking page flags that must be set for an anonymous transparent huge page, but are not set for the zone_device pages associated with dax mappings. Cc: Ross Zwisler <ross.zwisler@linux.intel.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Acked-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2016-09-10ACPI / EC: Fix issues related to boot_ecLv Zheng
There are issues related to the boot_ec: 1. If acpi_ec_remove() is invoked, boot_ec will also be freed, this is not expected as the boot_ec could be enumerated via ECDT. 2. Address space handler installation/unstallation lead to unexpected _REG evaluations. This patch adds acpi_is_boot_ec() check to be used to fix the above issues. However, since acpi_ec_remove() actually won't be invoked, this patch doesn't handle the reference counting of "struct acpi_ec", it only ensures the correctness of the boot_ec destruction during the boot. Link: https://bugzilla.kernel.org/show_bug.cgi?id=153511 Reported-and-tested-by: Jonh Henderson <jw.hendy@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-10ACPI / EC: Fix a gap that ECDT EC cannot handle EC eventsLv Zheng
It is possible to register _Qxx from namespace and use the ECDT EC to perform event handling. The reported bug reveals that Windows is using ECDT in this way in case the namespace EC is not present. This patch facilitates Linux to support ECDT in this way. Link: https://bugzilla.kernel.org/show_bug.cgi?id=115021 Reported-and-tested-by: Luya Tshimbalanga <luya@fedoraproject.org> Tested-by: Jonh Henderson <jw.hendy@gmail.com> Reviewed-by: Peter Wu <peter@lekensteyn.nl> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-10ACPI / EC: Fix a memory leakage issue in acpi_ec_add()Lv Zheng
When the handler installation failed, there was no code to free the allocated EC device. This patch fixes this memory leakage issue. Link: https://bugzilla.kernel.org/show_bug.cgi?id=115021 Reported-and-tested-by: Luya Tshimbalanga <luya@fedoraproject.org> Tested-by: Jonh Henderson <jw.hendy@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-10ACPI / EC: Cleanup first_ec/boot_ec codeLv Zheng
In order to support full ECDT (driving the ECDT EC after probing the namespace EC), we need to change our EC device alloc/free algorithm, ensure not to free old boot EC before qualifying new boot EC. This patch achieves this by cleaning up first_ec/boot_ec logic: 1. first_ec: used to perform transactions, so it is assigned in new acpi_ec_setup() function. 2. boot_ec: used to track early EC device, so it is assigned in new acpi_config_boot_ec() function which explictly tells the driver to save the EC device as early EC device. Link: https://bugzilla.kernel.org/show_bug.cgi?id=115021 Reported-and-tested-by: Luya Tshimbalanga <luya@fedoraproject.org> Tested-by: Jonh Henderson <jw.hendy@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-09Merge branch 'mlxsw-fixes'David S. Miller
Jiri Pirko says: ==================== mlxsw: couple of fixes Couple of fixes from Ido and myself. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2016-09-09mlxsw: spectrum: Set port type before setting its addressIdo Schimmel
During port init, we currently set the port's type to Ethernet after setting its MAC address. However, the hardware documentation states this should be the other way around. Align the driver with the hardware documentation and set the port's MAC address after setting its type. Fixes: 56ade8fe3fe1 ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit (git 2.34.1) at 2025-09-15 09:42:09 +0000