On a 4-socket Brickland system, hot-removing one ioapic is fine.
Hot-removing the 2nd one causes panic in mp_unregister_ioapic()
while calling release_resource().
It is because the iomem_res pointer has already been released
when removing the first ioapic.
To explain the use of &res[num] here: res is assigned to ioapic_resources,
and later in ioapic_insert_resources() we do:
struct resource *r = ioapic_resources;
for_each_ioapic(i) {
insert_resource(&iomem_resource, r);
r++;
}
Here 'r' is treated as an arry of 'struct resource', and the r++ ensures
that each element of the array is inserted separately. Thus we should call
release_resouce() on each element at &res[num].
Fix it by assigning the correct pointers to ioapics[i].iomem_res in
ioapic_setup_resources().
Signed-off-by: Rui Wang <rui.y.wang@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: tony.luck@intel.com
Cc: linux-pci@vger.kernel.org
Cc: rjw@rjwysocki.net
Cc: linux-acpi@vger.kernel.org
Cc: bhelgaas@google.com
Link: http://lkml.kernel.org/r/1465369193-4816-3-git-send-email-rui.y.wang@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Forcing in_interrupt() to return true if we're not in a bona fide
interrupt confuses the softirq code. This fixes warnings like:
NOHZ: local_softirq_pending 282
... which can happen when running things like selftests/x86.
This will change perf's static percpu buffer usage in IST context.
I think this is okay, and it's changing the behavior to match
historical (pre-4.0) behavior.
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Fixes: 9592747538 ("x86, traps: Track entry into and exit from IST context")
Link: http://lkml.kernel.org/r/cdc215f94d118d691d73df35275022331156fb45.1464130360.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The device emulation may send segCnt of 1 for LRO packets.
Signed-off-by: Shrikrishna Khare <skhare@vmware.com>
Signed-off-by: Jin Heo <heoj@vmware.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Socket option PACKET_FANOUT_DATA takes a struct sock_fprog as argument
if PACKET_FANOUT has mode PACKET_FANOUT_CBPF. This structure contains
a pointer into user memory. If userland is 32-bit and kernel is 64-bit
the two disagree about the layout of struct sock_fprog.
Add compat setsockopt support to convert a 32-bit compat_sock_fprog to
a 64-bit sock_fprog. This is analogous to compat_sock_fprog support for
SO_REUSEPORT added in commit 1957598840 ("soreuseport: add compat
case for setsockopt SO_ATTACH_REUSEPORT_CBPF").
Reported-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
The dwmac4_set_umac_addr() takes a struct mac_device_info as
the first parameter, but is being passed a ioaddr instead from
dwmac4_set_filter(). Fix the warning/bug by changing the first
parameter.
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c:159:46: warning: incorrect type in argument 1 (different address spaces)
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c:159:46: expected struct mac_device_info *hw
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c:159:46: got void [noderef] <asn:2>*ioaddr
Note, only compile tested this as do not have any
hardware with it in.
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Saeed Mahameed says:
====================
Mellanox 100G mlx5 fixes for 4.7-rc
The following series provides some small fixes for mlx5 driver.
Two small fixes for the mlx5e netdev, the 1st is for the blue flame
quota accounting and the 2nd is a small refactoring in shutdown flow.
Five trivial fixes for mlx5 E-Switch.
- Allmulti mc_promisc flag was not set in a specific flow.
- Modify VF node guid when admin mac is changed.
- Race in vport enable flow.
- Misc code fixes (kvfree when needed and error pointers checking).
Three in mlx5 steering area. Correct capabilities checking and root flow table update.
Three misc fixes in mlx5 commands enum and layouts.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Blue flame is a latency enhancement feature that allows the driver to
write the packet data directly to the NIC's registers thus making the
read of the packet data from host memory redundant.
We maintain a quota for the blue flame which is reloaded whenever we
identify that the hardware is processing send requests and processes
them fast enough so by the time we post the next send request it was
able to process all the pending ones. This indicates that the hardware
is capable of processing more blue flame requests efficiently. The blue
flame quota is decremented whenever we send using blue flame.
The current code erroneously clears the budget if we did not use blue
flame for the current post send operation and we fix it here.
Fixes: 88a85f99e5 ('net/mlx5e: TX latency optimization to save DMA reads')
Signed-off-by: Eli Cohen <eli@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The current implementation copies the flow of ndo_stop instead of
calling it explicitly, Fixed it.
Fixes: 5fc7197d3a ("net/mlx5: Add pci shutdown callback")
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Set the mc_promisc flag also in the case of adding new mc address to
existing allmulti vport.
Fixes: a35f71f27a ('net/mlx5: E-Switch, Implement promiscuous rx modes vf request handling')
Signed-off-by: Mohamad Haj Yahia <mohamad@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In RoCE, the RDMA-CM needs the node guid to establish connection
between nodes.
Today, the node guid exposed to mlx5 Ethernet VFs is zero, therefore
RDMA-CM on the VF is broken.
Whenever the administrator sets a MAC for a VF, derive the node guid
from it and set it as well in the following way:
MAC: e4:1d:2d:b3:f4:01 -> node_guid: e4:1d:2d:ff:fe:b3:f4:01
Fixes: 77256579c6 ('net/mlx5: E-Switch, Introduce Vport...')
Signed-off-by: Noa Osherovich <noaos@mellanox.com>
Signed-off-by: Majd Dibbiny <majd@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Reorder vport enable flow to mark the vport as enabled before calling
the vport change handler which was modified to handle the case for
when vport is not enabled.
This fixes the case for when the PF netdev is open before sriov is
enabled, once sriov is enabled at esw_enable_vport,
esw_vport_change_handle_locked didn't read the PF context since it
thought the PF vport was not enabled.
When we enable the vport, arming for events is not required anymore,
since it's done on the vport change handle
Fixes: 586cfa7f1d ('net/mlx5: E-Switch, Use vport event handler for vport cleanup')
Signed-off-by: Mohamad Haj Yahia <mohamad@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The mlx5 flow-steering API (mlx5_create_flow_table/group/rule) never
returns null pointer on error. Even if it was doing that, checking
for IS_ERR_OR_NULL(p) and then returning PTR_ERR(p) would have cause
bugs, since PTR_ERR(NULL) --> success, crash.
To make things more robust and protect against related future bugs,
convert all IS_ERR_OR_NULL checks on returned values to IS_ERR.
Fixes: 5742df0f7d ('net/mlx5: E-Switch, Introduce VST vport ingress/egress ACLs')
Fixes: 86d722ad2c ('net/mlx5: Use flow steering infrastructure for mlx5_en')
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Reported-by: Ilya Lesokhin <ilyal@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We must use kvfree() for something that could have been allocated with vzalloc(),
do that.
Fixes: 5742df0f7d ('net/mlx5: E-Switch, Introduce VST vport ingress/egress ACLs')
Fixes: 86d722ad2c ('net/mlx5: Use flow steering infrastructure for mlx5_en')
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Reported-by: Ilya Lesokhin <ilyal@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add missing capabilities check for E-Switch FDB and ACLs flow
tables before creating their namespace in flow steering.
Fixes: efdc810ba3 ('net/mlx5: Flow steering, Add vport ACL support')
Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Flow steering infrastructure is currently used only on link layer
ethernet, therefore the driver should initialize the flow steering
when the device link layer is ethernet.
In addition, add missing capability check before initializing the
namespace of NIC RX flow tables.
Fixes: 2530236303 ('net/mlx5_core: Flow steering tree initialization')
Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When we destroy the last flow table we need to update
the root_ft to NULL.
It fixes an issue for when the last flow table is destroyed
and recreated again, root_ft pointer will not be updated,
as a result traffic will be dropped.
Fixes: 2cc43b494a ('net/mlx5_core: Managing root flow table')
Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Having MLX5_CMD_OP_MAX on another file causes us to repeatedly miss
accounting new commands added to the driver and hence there're no entries
for them in debugfs. To solve that, we integrate it into the commands enum
as the last entry.
Fixes: 34a40e6893 ('net/mlx5_core: Introduce modify flow table command')
Signed-off-by: Shahar Klein <shahark@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Mask the reserved bits when reading the number of newly
created XRCD.
Fixes: e126ba97db ('mlx5: Add driver for Mellanox Connect-IB adapters')
Signed-off-by: Majd Dibbiny <majd@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add 16 reserved bytes at the end of mlx5_modify_qp_mbox_in to
match the hardware spec definition.
Fixes: e126ba97db ('mlx5: Add driver for Mellanox Connect-IB adapters')
Signed-off-by: Majd Dibbiny <majd@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 74701d5947 "powerpc/mm: Rename function to indicate we are
allocating fragments" renamed page_table_free() to pte_fragment_free().
One occurrence was mistyped as pte_fragment_fre().
This only breaks the nohash 64K page build, which is not the default or
enabled in any defconfig.
Fixes: 74701d5947 ("powerpc/mm: Rename function to indicate we are allocating fragments")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Mostly memory leak and firmware leak fixes for amdgpu. A bit bigger than
usual since this is several weeks worth of fixes.
* 'drm-fixes-4.7' of git://people.freedesktop.org/~agd5f/linux: (28 commits)
drm/amd/powerplay: delete useless code as pptable changed in vbios.
drm/amd/powerplay: fix bug visit array out of bounds
drm/amdgpu: fix smu ucode memleak (v2)
drm/amdgpu: add release firmware for cgs
drm/amdgpu: fix tonga smu_fini mem leak
drm/amdgpu: fix fiji smu fini mem leak
drm/amdgpu: fix cik sdma ucode memleak
drm/amdgpu: fix sdma24 ucode mem leak
drm/amdgpu: fix sdma3 ucode mem leak
drm/amdgpu: fix uvd fini mem leak
drm/amdgpu: fix gfx 7 ucode mem leak
drm/amdgpu: fix gfx8 ucode mem leak
drm/amdgpu: fix missing free wb for cond_exec
drm/amdgpu: fix memleak in pptable_init
drm/amdgpu: fix mem leak in atombios
drm/amdgpu: fix mem leak in pplib/hwmgr
drm/amdgpu: fix mem leak in smumgr
drm/amdgpu: add pipeline sync while vmid switch in same ctx
drm/amdgpu: vBIOS post only call when mem_size zero
drm/amdgpu: modify sdma start sequence
...
* pm-cpufreq-fixes:
cpufreq: intel_pstate: Fix ->set_policy() interface for no_turbo
cpufreq: intel_pstate: Fix code ordering in intel_pstate_set_policy()
* pm-cpuidle:
cpuidle: Do not access cpuidle_devices when !CONFIG_CPU_IDLE
- Multiple minor fixes to the rdma core
- Multiple minor fixes to hfi1
- Multiple minor fixes to mlx5
- A very few other minor fixes (SRP, IPoIB, usNIC, mlx4)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJXVt8TAAoJELgmozMOVy/dqkUQAIBZXo6VqyykcO1hAvT8kvNG
bi5wuTDe7SVU7dHE4DBjCHbxEYRwWXEqlWpywSHd84pv7awvUTXHiHppdYxkor5V
1Yo+gz/WHFaE8dHNRuiWpzqNxd7+D16mx3Xaq2xVGdKSG0kQln3Wo0s8g3yAKyNS
KTDSIN5ik4WwK043REWPjyPLtmy3sssmC6OnqF9arFqq1W1xy4I6CudRHrCmGD9b
f7Q9lrFk30nAtOyoyFJNMXpHtrgiIbbvpa6yF5FxY/Aoa7bOAJfI2oTZZOL0wHqH
GhHw/uLxDotBckDUCOT90JT4Bkq7Qd9nzqNgpvfsCSVr3z64PNYYM5+pJc5kYZOB
0VwxCXrKIuo+YWF6/L3SWef6rfHltFlhjaAobbuNsze/cm9kR9pFqm7y/6cMrDWS
fNSi50ljhOcrw9aAvC8zUbHCkP4Mw3A4L9btZlOJsfZ/heHDVJ6b90fcV/976xQQ
B5ml/RcIs3afH03Mn4OD52YEFV0h7JgXq9YPYugjSbL73sKwHFDHSJ6NaK1DFu1V
j8NYiIP+vTmcgoUfe6g0Qd9Vnz1+zw0wqLvKV9GPD+tflPDy13+2VMhvvn3VPlSc
ndK+JnQYuzJdWitrY3a1RUB2BziDnzQ/Hu6QZ09zGvuEIABf3xfrvJX5dgRYYBR7
t2CeyZu0Q9wp54+LzLIE
=LjUT
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma
Pull rdma fixes from Doug Ledford:
"This is the first -rc pull for the RDMA subsystem. The patch count is
high, but they are all smallish patches fixing simple things for the
most part, and the overall line count of changes here is smaller than
the patch count would lead a person to believe.
Code is up and running in my labs, including direct testing of cxgb4,
mlx4, mlx5, ocrdma, and qib.
Summary:
- Multiple minor fixes to the rdma core
- Multiple minor fixes to hfi1
- Multiple minor fixes to mlx5
- A very few other minor fixes (SRP, IPoIB, usNIC, mlx4)"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma: (35 commits)
IB/IPoIB: Don't update neigh validity for unresolved entries
IB/mlx5: Fix alternate path code
IB/mlx5: Fix pkey_index length in the QP path record
IB/mlx5: Fix entries check in mlx5_ib_resize_cq
IB/mlx5: Fix entries checks in mlx5_ib_create_cq
IB/mlx5: Check BlueFlame HCA support
IB/mlx5: Fix returned values of query QP
IB/mlx5: Limit query HCA clock
IB/mlx5: Fix FW version diaplay in sysfs
IB/mlx5: Return PORT_ERR in Active to Initializing tranisition
IB/mlx5: Set flow steering capability bit
IB/core: Make all casts in ib_device_cap_flags enum consistent
IB/core: Fix bit curruption in ib_device_cap_flags structure
IB/core: Initialize sysfs attributes before sysfs create group
IB/IPoIB: Disable bottom half when dealing with device address
IB/core: Fix removal of default GID cache entry
IB/IPoIB: Fix race between ipoib_remove_one to sysfs functions
IB/core: Fix query port failure in RoCE
IB/core: fix error unwind in sysfs hw counters code
IB/core: Fix array length allocation
...
- Revert of ll-sc backoff retry workaround in atomics/spinlocks as hardware
is now proven to work just fine
- Typo fixes (Thanks Andrea Gelmini)
- Removal of obsolete DT property (Alexey)
- Other minor fixes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJXWOz1AAoJEGnX8d3iisJe6H4QAKaXFUGr3WxTMbMGF8w9LYCx
cYDMCKoJgSxpE2S4uT36O39swFDhA9CTH+T4pziZgTFtCduf9jqtTd6JwLmVsvZK
vveDZnZMP+AtWqiwpNuBTrj4+P0FcvwSq+lrRYSWWQ3HjgTQk2q5kU5355yLpD38
Q0BHuMwhVGohWDzi167kOnZcHtd+hxDhj21Uqh/+/4tzCHkiqkO9HjR9i+EYUjPK
YAEBeqK2ayT3GdjQhOlRSIopNJ5rMQhvBboKRzUpXV0SjAxbTQBP+94sgxY0OdJ+
C3qFFjeGHeJmVIM1BaojPcobJJoyjdTcIq3KBjO+Pz7GipwBgFQnlQDBcA7tsdS8
x6devNjaDOLKS5ii3LPrkVplQxEinPJL/snMkpcfNQw8xbsUD2zxCPNruf4F6USD
pFRs/Or9IbfpZu1BXVSNMmgVQ3sdpEcI6ZJnzHaZWI0LWSEhYMak4vn+sDgyzZs2
bWXFjAtMpU3aXa/61GlXa3azs/wYbkPWyZD6biWswUwE7NiQDAe+bGHinyBT8BfK
kyvAr5jcdCGY3zWDyVIs6C/4wS+c7ATBnqHLRWYnOJ3ZyAbeuP6Jqtg4Ofe5WZE+
6OHFTI82hntp7geXaO61CS5SFyHXzLX0JcFBCGv/FSSkngwBOllBw91IRjpuVb3G
t+wToBJ3DN6oosQlLFpo
=VQXp
-----END PGP SIGNATURE-----
Merge tag 'arc-4.7-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc
Pull ARC fixes from Vineet Gupta:
- Revert of ll-sc backoff retry workaround in atomics/spinlocks as
hardware is now proven to work just fine
- Typo fixes (Thanks Andrea Gelmini)
- Removal of obsolete DT property (Alexey)
- Other minor fixes
* tag 'arc-4.7-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
Revert "ARCv2: spinlock/rwlock/atomics: Delayed retry of failed SCOND with exponential backoff"
Revert "ARCv2: spinlock/rwlock: Reset retry delay when starting a new spin-wait cycle"
Revert "ARCv2: spinlock/rwlock/atomics: reduce 1 instruction in exponential backoff"
ARC: don't enable DISCONTIGMEM unconditionally
ARC: [intc-compact] simplify code for 2 priority levels
arc: Get rid of root core-frequency property
Fix typos
I noticed that the logic in the fadvise64_64 syscall is incorrect for
partial pages. While first page of the region is correctly skipped if
it is partial, the last page of the region is mistakenly discarded.
This leads to problems for applications that read data in
non-page-aligned chunks discarding already processed data between the
reads.
A somewhat misguided application that does something like write(XX bytes
(non-page-alligned)); drop the data it just wrote; repeat gets a
significant penalty in performance as a result.
Link: http://lkml.kernel.org/r/1464917140-1506698-1-git-send-email-green@linuxhacker.ru
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch is based on https://patchwork.ozlabs.org/patch/574623/.
Tejun submitted commit 23d11a58a9 ("workqueue: skip flush dependency
checks for legacy workqueues") for the legacy create*_workqueue()
interface.
But some workq created by alloc_workqueue still reports warning on
memory reclaim, e.g nvme_workq with flag WQ_MEM_RECLAIM set:
workqueue: WQ_MEM_RECLAIM nvme:nvme_reset_work is flushing !WQ_MEM_RECLAIM events:lru_add_drain_per_cpu
------------[ cut here ]------------
WARNING: CPU: 0 PID: 6 at SoC/linux/kernel/workqueue.c:2448 check_flush_dependency+0xb4/0x10c
...
check_flush_dependency+0xb4/0x10c
flush_work+0x54/0x140
lru_add_drain_all+0x138/0x188
migrate_prep+0xc/0x18
alloc_contig_range+0xf4/0x350
cma_alloc+0xec/0x1e4
dma_alloc_from_contiguous+0x38/0x40
__dma_alloc+0x74/0x25c
nvme_alloc_queue+0xcc/0x36c
nvme_reset_work+0x5c4/0xda8
process_one_work+0x128/0x2ec
worker_thread+0x58/0x434
kthread+0xd4/0xe8
ret_from_fork+0x10/0x50
That's because lru_add_drain_all() will schedule the drain work on
system_wq, whose flag is set to 0, !WQ_MEM_RECLAIM.
Introduce a dedicated WQ_MEM_RECLAIM workqueue to do
lru_add_drain_all(), aiding in getting memory freed.
Link: http://lkml.kernel.org/r/1464917521-9775-1-git-send-email-shhuiw@foxmail.com
Signed-off-by: Wang Sheng-Hui <shhuiw@foxmail.com>
Acked-by: Tejun Heo <tj@kernel.org>
Cc: Keith Busch <keith.busch@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Ingo Molnar <mingo@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Christian Borntraeger reported a kernel panic after corrupt page counts,
and it turned out to be a regression introduced with commit aa88b68c3b
("thp: keep huge zero page pinned until tlb flush"), at least on s390.
put_huge_zero_page() was moved over from zap_huge_pmd() to
release_pages(), and it was replaced by tlb_remove_page(). However,
release_pages() might not always be triggered by (the arch-specific)
tlb_remove_page().
On s390 we call free_page_and_swap_cache() from tlb_remove_page(), and
not tlb_flush_mmu() -> free_pages_and_swap_cache() like the generic
version, because we don't use the MMU-gather logic. Although both
functions have very similar names, they are doing very unsimilar things,
in particular free_page_xxx is just doing a put_page(), while
free_pages_xxx calls release_pages().
This of course results in very harmful put_page()s on the huge zero
page, on architectures where tlb_remove_page() is implemented in this
way. It seems to affect only s390 and sh, but sh doesn't have THP
support, so the problem (currently) probably only exists on s390.
The following quick hack fixed the issue:
Link: http://lkml.kernel.org/r/20160602172141.75c006a9@thinkpad
Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Hugh Dickins <hughd@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: <stable@vger.kernel.org> [4.6.x]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Revert commit 1383399d7b ("mm: memcontrol: fix possible css ref leak
on oom"). Johannes points out "There is a task_in_memcg_oom() check
before calling mem_cgroup_oom()".
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Vladimir Davydov <vdavydov@virtuozzo.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Change the following memory hot-add error messages to info messages.
There is no need for these to be errors.
kasan: WARNING: KASAN doesn't support memory hot-add
kasan: Memory hot-add will be disabled
Link: http://lkml.kernel.org/r/1464794430-5486-1-git-send-email-shuahkh@osg.samsung.com
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When creating a private mapping of a hugetlbfs file, it is possible to
unmap pages via ftruncate or fallocate hole punch. If subsequent faults
repopulate these mappings, the reserve counts will go negative. This is
because the code currently assumes all faults to private mappings will
consume reserves. The problem can be recreated as follows:
- mmap(MAP_PRIVATE) a file in hugetlbfs filesystem
- write fault in pages in the mapping
- fallocate(FALLOC_FL_PUNCH_HOLE) some pages in the mapping
- write fault in pages in the hole
This will result in negative huge page reserve counts and negative
subpool usage counts for the hugetlbfs. Note that this can also be
recreated with ftruncate, but fallocate is more straight forward.
This patch modifies the routines vma_needs_reserves and vma_has_reserves
to examine the reserve map associated with private mappings similar to
that for shared mappings. However, the reserve map semantics for
private and shared mappings are very different. This results in subtly
different code that is explained in the comments.
Link: http://lkml.kernel.org/r/1464720957-15698-1-git-send-email-mike.kravetz@oracle.com
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Kirill Shutemov <kirill.shutemov@linux.intel.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
of_match_table was not filled which prevents device to be
instantiated from device tree node.
Signed-off-by: Lukasz Gemborowski <lukasz.gemborowski@nokia.com>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Correct references to i2c-mux.txt which was previously mux.txt.
Also correct the spelling of relevant.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The NVMe driver only requests the PCIe device's memory regions but releases
all possible regions (including eventual I/O regions). This leads to a stale
warning entry in dmesg about freeing non existent resources.
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
Remove the warning about a too long SMBUS message because
the ipmi_ssif driver triggers this warning too frequently so it
spams the message log.
Signed-off-by: Jan Glauber <jglauber@cavium.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
During receive the controller requires the AAK flag for all
bytes but the final one. This was wrong in case of I2C_M_RECV_LEN,
where the decision if the final byte is to be transmitted
happened before adding the additional received length byte.
Set the AAK flag if additional bytes are to be received.
Signed-off-by: Jan Glauber <jglauber@cavium.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Many Intel systems the BIOS declares a SystemIO OpRegion below the SMBus
PCI device as can be seen in ACPI DSDT table from Lenovo Yoga 900:
Device (SBUS)
{
OperationRegion (SMBI, SystemIO, (SBAR << 0x05), 0x10)
Field (SMBI, ByteAcc, NoLock, Preserve)
{
HSTS, 8,
Offset (0x02),
HCON, 8,
HCOM, 8,
TXSA, 8,
DAT0, 8,
DAT1, 8,
HBDR, 8,
PECR, 8,
RXSA, 8,
SDAT, 16
}
There are also bunch of AML methods that that the BIOS can use to access
these fields. Most of the systems in question AML methods accessing the
SMBI OpRegion are never used.
Now, because of this SMBI OpRegion many systems fail to load the SMBus
driver with an error looking like one below:
ACPI Warning: SystemIO range 0x0000000000003040-0x000000000000305F
conflicts with OpRegion 0x0000000000003040-0x000000000000304F
(\_SB.PCI0.SBUS.SMBI) (20160108/utaddress-255)
ACPI: If an ACPI driver is available for this device, you should use
it instead of the native driver
The reason is that this SMBI OpRegion conflicts with the PCI BAR used by
the SMBus driver.
It turns out that we can install a custom SystemIO address space handler
for the SMBus device to intercept all accesses through that OpRegion. This
allows us to share the PCI BAR with the AML code if it for some reason is
using it. We do not expect that this OpRegion handler will ever be called
but if it is we print a warning and prevent all access from the SMBus
driver itself.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=110041
Reported-by: Andy Lutomirski <luto@kernel.org>
Reported-by: Pali Rohár <pali.rohar@gmail.com>
Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@vger.kernel.org
The function early_init_dt_alloc_reserved_memory_arch is defined
in drivers/of/of_reserved_mem.c but is not declared in any of the
header files. Add the declaration of this to avoid the warning:
drivers/of/of_reserved_mem.c:31:19: warning: symbol 'early_init_dt_alloc_reserved_memory_arch' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
[robh: drop extern from declaration]
Signed-off-by: Rob Herring <robh@kernel.org>
The function is unflattening device sub-tree blob if @dad passed to
the function is valid. Currently, this functionality is used by PPC
PowerNV PCI hotplug driver only. There are possibly multiple nodes
in the first level of depth, fdt_next_node() bails immediately when
@depth becomes negative before the second device node can be probed
successfully. It leads to the device nodes except the first one won't
be unflattened successfully.
This fixes the issue by setting the initial depth (@inital_depth) to
1 when this function is called to unflatten device sub-tree blob. No
logic changes when this function is used to unflatten non-sub-tree
blob.
Cc: Rhyland Klein <rklein@nvidia.com>
Fixes: 78c44d910 ("drivers/of: Fix depth when unflattening devicetree")
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Tested-by: Rhyland Klein <rklein@nvidia.com>
Tested-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Rob Herring <robh@kernel.org>
* a fix for a long-standing iwpriv 32/64 compat issue
* two fairly recently introduced (4.6) warning asking for
symmetric operations are erroneous and I remove them
-----BEGIN PGP SIGNATURE-----
iQIcBAABCgAGBQJXWWVNAAoJEGt7eEactAAd2HMP/RGyAWN/uXJVNySsqvBSqiew
t5ZTopRfL2YEcO1EUF749bncfJo6P9KUtuM72gYYRYART5viucdYFk53Ky8EtKh8
QQ7WTGyiuQP7XvderfXmrjV/J35KFiPTnf83KUfOnBTVOCtw6doIBIMutUmR7FPV
cyH4e56j9agzbBJ7mjeLYGBMmyhq2uZ85vXqk/mnpn5fH9+lGojcoIVZfhXWmMoI
d5O/giARzjDM7LTMIwgepY5w/j8RX1rMJCXfxiZsGMuiSTYH8FETbe3Go9CL/qHS
8cZCCQRMCpjMK+SOmNr7xYx70YjIJQabwo9luYmcdCkhw6VHRxHl47lk/2XLp4F9
G+ReA1A7izV2XSyJIWTl+Or1qzgzsf6SfZHKszSdY47NXzK5aCprRfUvXyxLv6GZ
IGcHzNWOFF/1fKhh3w2NylhTd/omkvtZzt5Xuom94OPXdyxzy/PmViZ+xuhutrGt
dYxhmzPZcw+/OeTGgbt2YfYFUdMZqbHkaHPE0wia03r1yXzQD/x05/QET2vwIA0L
C+ATyaykSCCOm/ovwm5rada151Iai1engCWIVw/pZ3HUj6C8xqwyDS3+xsTRmKzI
oBp1O3K3yR0c0T9KJNmORnnrYQAbSBIQNhdioXVCBpByTOjYfATKVQtaSIV/uu4/
2r1KQmrT4z5OrL6lm2wv
=0I3T
-----END PGP SIGNATURE-----
Merge tag 'mac80211-for-davem-2016-06-09' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
Johannes Berg says:
====================
Two more fixes for now:
* a fix for a long-standing iwpriv 32/64 compat issue
* two fairly recently introduced (4.6) warning asking for
symmetric operations are erroneous and I remove them
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Jiri Pirko says:
====================
mlxsw: couple of fixes
Couple of fixes from Ido.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
When rtnl_fill_ifinfo() is called for a certain netdevice it queries its
various parameters such as switch id and physical port name. The
function might get called in an atomic context, which means the
underlying driver must not sleep during the query operation.
Don't query the device and sleep during ndo_get_phys_port_name(), but
instead store the needed parameters in port creation time.
Fixes: 2bf9a58675 ("mlxsw: spectrum: Add support for physical port names")
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>
When a port is created following a split / unsplit we need to map it to
the correct module and lane, enable it and then continue to initialize
its various parameters such as MTU and VLAN filters.
Under certain conditions, such as trying to split ports at the bottom
row of the front panel by four, we get firmware errors.
After evaluating this with the firmware team it was decided to alter the
split / unsplit flow, so that first all the affected ports are mapped,
then enabled and finally each is initialized separately.
Fix the split / unsplit flow by first mapping and enabling all the
affected ports. Newer firmware versions will support both flows.
Fixes: 18f1e70c41 ("mlxsw: spectrum: Introduce port splitting")
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>
The vbios table changed so this code is useless now.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
