Cgroup2 currently doesn't have a per-cgroup swappiness setting. We
might want to add one later - that's a different discussion - but until
we do, the cgroups should always follow the system setting. Otherwise
it will be unchangeably set to whatever the ancestor inherited from the
system setting at the time of cgroup creation.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Vladimir Davydov <vdavydov@virtuozzo.com>
Cc: <stable@vger.kernel.org> [4.5]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
split_huge_pages doesn't support get method at all, so the read
permission sounds confusing, change the permission to write only.
And, add "\n" to the output of set method to make it more readable.
Signed-off-by: Yang Shi <yang.shi@linaro.org>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Hugh Dickins <hughd@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
My last pull request for asm-generic had just one patch that added two
new system calls to asm/unistd.h, but unfortunately it turned out
to be wrong, pointing arch/tile compat mode at the native handlers
rather than the compat ones.
This was spotted by Yury Norov, who is working on ILP32 mode
for arch/arm64, which would have the same problem when merged.
This fixes the table to use the correct compat syscalls, like
the other 64-bit architectures do.
I'll try to find the time to come up with a solution that
prevents this problem from happening again, by allowing all
future system calls to just get added in a single file
for use by all architectures.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIVAwUAVyuiZWCrR//JCVInAQLgcxAAnDsLXnepV7gYfkF3MjoN3GVR2BzehI+a
f7YWTAoA/7MA9DJsSeSlqz0F0/M0TnVM7Yg3VkG4RvxhgSpHCnpol9/CEXuG4TLe
1Yn3CqNyMfNv9G3WfwWwSu4NeRWUeZAYbNkmWovhx3uWzmk1I+BnShd+IWmzDo0v
+KC9tkiq7NYlManpdUR+e80Eoougqkrryk6VAdNcgmVvVSCEhSA3VVxiTx26kcdd
mI7oz0gcJxlCwMZvNfRFFtrEAN9XGwV8bwkO5gYD/1nQSbzXcGLkmFpJmw8eCIX7
oM5gRs46tcKAEUA9fGVG58drrn0itwKqQO1LlUAhp+fsXU96c9rcgvZfY4Twehhk
lGVIGPfRUJFOtXtVICofR0DPBkNvZB+EVTPV12gZlPOQKzSPHefEzQMkmUemZO13
Pv1lB8EeKeKlXsC9cSfKyNgBUNAkV35gV1s6wg/MrZo4Asx5/TlqO85n2wU0fspg
d8yb866F+guz3OvU+RPyJpZL4sZ6tlg0/4TpBpDJetUwxYZNo4c1KpdwMFr64AFI
Xh3wckbIBfLSUmB4ex6GCchqDlhla4QMA8Vl/ij/bfLMR6SwQEvfrtGegCluJsVX
LRWV2arusSJTgcdCxa+chVnXjd6xwet8wPgahpOpTKtkJ9B7fnTFheMY+RRIV5Bb
V7h/3AEbkvs=
=yaH0
-----END PGP SIGNATURE-----
Merge tag 'asm-generic-4.6' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic
Pull asm-generic syscall fix from Arnd Bergmann:
"My last pull request for asm-generic had just one patch that added two
new system calls to asm/unistd.h, but unfortunately it turned out to
be wrong, pointing arch/tile compat mode at the native handlers rather
than the compat ones.
This was spotted by Yury Norov, who is working on ILP32 mode for
arch/arm64, which would have the same problem when merged. This fixes
the table to use the correct compat syscalls, like the other 64-bit
architectures do.
I'll try to find the time to come up with a solution that prevents
this problem from happening again, by allowing all future system calls
to just get added in a single file for use by all architectures"
* tag 'asm-generic-4.6' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic:
asm-generic: use compat version for preadv2 and pwritev2
This last minute set is concerned with a regression in the mpu6050 driver.
The regression causes a null pointer dereference on any ACPI device
that has one of these present such as the ASUS T100TA Baytrail/T.
The issue was known but thought (i.e. missunderstood by me)
to only be a possible with no reports, so was routed via the normal merge
window. Turns out this was wrong (thanks to Alan for reporting the crash).
The pull is just for the null dereference fix and a followup fix
that also stops the reported name of the device being NULL.
* mpu6050
- Fix a 'possible' NULL dereference introduced as part of splitting the
driver to allow both i2c and spi to be supported. The issue affects ACPI
systems with this device.
- Fix a follow up issue where the name and chip id both get set to null if
the device driver instance is instantiated from ACPI tables.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJXK50kAAoJEFSFNJnE9BaIP1MP/j3t1WfFkpbuoPlrsUOiYxd1
2VM9iNGZoLQa06p4WWkBv611NCht4yoOnvK9i8v3QM775xekmZQsnQBiCfm2eWHI
cL19hCfQnCNcoJxQIUnGrO0xE7AYRxtgvYqmLljOLjKI/q23DxoPshadveLbEHhS
zxo9hmDI7V8hxapyo15G3JZMSBWTz+d4yJn83d95GSEfdrRExJ66Ta7+eM62WR/M
4wiPEWtr5nL39orM0wY7lcGyV7KbG+csHSvXLjPq4tRV+D7kk9O916LWsWKNfcU3
3QiM0RYBdZIHZlpsTZH32+Zygt7efg6/BzRp/sXs/+CLaZw3mroeeQ8hjUaEnzac
xiVtfc2SOUaSfWw6NO6DeyIBiHoe3EtcXBE5i0y6IjabhP3uUhQGZhWQGb8sinQl
w6vvtHwS9/5hz6WN2qdkOUWVyThEaR1j7xd6dNA062pAjErZvwJ/zK9Z+CLojZ/P
GAy9XS34qJ7ttx6NCvUqfWBXhU/K38UXEc6mPJCdSxMx2Q3J2UMojgTLCHC8/Eun
H+m6cBXL58obGHZS7XcLT2W7u5mAAvNFg1T2bnpCcf3vLWGbpjXI55laATWw72ob
m/LeYEfLO37Bbxe4XPU992zb2U6CrL8sJ/33pYJVQCnobenRDR9NmTn5IeHLKl5K
lf1rwmtzTr1KNz4NBsP3
=FQCc
-----END PGP SIGNATURE-----
Merge tag 'iio-fixes-for-4.6d' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
Fourth set of IIO fixes for the 4.6 cycle.
This last minute set is concerned with a regression in the mpu6050 driver.
The regression causes a null pointer dereference on any ACPI device
that has one of these present such as the ASUS T100TA Baytrail/T.
The issue was known but thought (i.e. missunderstood by me)
to only be a possible with no reports, so was routed via the normal merge
window. Turns out this was wrong (thanks to Alan for reporting the crash).
The pull is just for the null dereference fix and a followup fix
that also stops the reported name of the device being NULL.
* mpu6050
- Fix a 'possible' NULL dereference introduced as part of splitting the
driver to allow both i2c and spi to be supported. The issue affects ACPI
systems with this device.
- Fix a follow up issue where the name and chip id both get set to null if
the device driver instance is instantiated from ACPI tables.
are for the OMAP platforms, quoting Tony Lindgren:
Fixes for omaps for v4.6-rc cycle. All dts fixes, mostly
affecting voltages and pinctrl for various device drivers:
- Regulator minimum voltage fixes for omap5
- ISP syscon register offset fix for omap3
- Fix regulator initial modes for n900
- Fix omap5 pinctrl wkup instance size
The rest are all for different platforms:
- Allwinner:
Remove incorrect constraints from a dcdc1 regulator
- Alltera SoCFPGA:
Fix compilation in thumb2 mode
- Samsung exynos:
Fix a potential oops in the pm-domain error handling
- Davinci:
Avoid a link error if NVMEM is disabled
- Renesas:
Do not mark an external uart clock as disabled, to allow
probing the uarts
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIVAwUAVyud6WCrR//JCVInAQKhXBAAir8+FCYQGLzwFQrCHTRa6zJq0sGUOLss
DBawxezSxtcz9LYn2s9EI5W7yqs/vtjILNTtV3bNNHZTrn/cE8Jpvo+kjNK096PP
3m0LS20pbGV/629JXiuf55pWugoXUvQNP4kTcuW8dQzQWWuzv2QfJwtW776Q8rOQ
ZRvh6uUsCgsc6JCCnZESVAnWQ7VA5YpTpZRhokhogdU0r6VTuHfOf8NPD10kiel+
jpayjC852MPJtS+1JI/d9vIydsSPHbfS8lkVp0rX7oep/Xjp6C3HGSNH+KkLTjXf
9q6uVm21Kko24wd3RAFYNFshNmD80j+BQJN+59gx7jUnQsVA+WZkNlKSPD1svf+R
9Ym+fGVn+UgsU/rSW+hhTYft7ao6Tud+W80QARFgWX6B3E3xF/ExJ9TE07hg0sK7
b+JZAFoSnEut6yTq5g99/YdvDLfqANPo3f3968bl18rKh15Iso/u177KR3cbMPBw
rKFXg9fkmjd3g5mUUekYvaEKbb+bEeLaAT+2Cri3diSW7odTzsLQSXELS0UTOWfx
TLTJSkmgxvABhdZZPQscHBvxwXPGQO8S479GGXG2xcI+tiT7ZDJPZeVm0P99B8WB
Y2VjTjuc49ZALrzT93nY9nInyjhzI5NsnccG5Khw+qoxlZ3+H+N2tVkhwt6+FNcg
vl8vcFbj9hM=
=ymz3
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Arnd Bergmann:
"Here are a couple last-minute fixes for ARM SoCs. Most of them are
for the OMAP platforms, the rest are all for different platforms.
OMAP:
All dts fixes, mostly affecting voltages and pinctrl for various
device drivers:
- Regulator minimum voltage fixes for omap5
- ISP syscon register offset fix for omap3
- Fix regulator initial modes for n900
- Fix omap5 pinctrl wkup instance size
Allwinner:
Remove incorrect constraints from a dcdc1 regulator
Alltera SoCFPGA:
Fix compilation in thumb2 mode
Samsung exynos:
Fix a potential oops in the pm-domain error handling
Davinci:
Avoid a link error if NVMEM is disabled
Renesas:
Do not mark an external uart clock as disabled, to allow probing
the uarts"
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: davinci: only use NVMEM when available
ARM: SoCFPGA: Fix secondary CPU startup in thumb2 kernel
ARM: dts: omap5: fix range of permitted wakeup pinmux registers
ARM: dts: omap3-n900: Specify peripherals LDO regulators initial mode
ARM: dts: omap3: Fix ISP syscon register offset
ARM: dts: omap5-cm-t54: fix ldo1_reg and ldo4_reg ranges
ARM: dts: omap5-board-common: fix ldo1_reg and ldo4_reg ranges
arm64: dts: r8a7795: Don't disable referenced optional scif clock
ARM: EXYNOS: Properly skip unitialized parent clock in power domain on
ARM: dts: sun8i-q8-common: Do not set constraints on dc1sw regulator
Update my email and web addresses in the kernel maintainers file.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit 947e9762a8 ("writeback: update wb_over_bg_thresh() to use
wb_domain aware operations") unintentionally changed this function's
meaning from "are there more dirty pages than the background writeback
threshold" to "are there more dirty pages than the writeback threshold".
The background writeback threshold is typically half of the writeback
threshold, so this had the effect of raising the number of dirty pages
required to cause a writeback worker to perform background writeout.
This can cause a very severe performance regression when a BDI uses
BDI_CAP_STRICTLIMIT because balance_dirty_pages() and the writeback worker
can now disagree on whether writeback should be initiated.
For example, in a system having 1GB of RAM, a single spinning disk, and a
"pass-through" FUSE filesystem mounted over the disk, application code
mmapped a 128MB file on the disk and was randomly dirtying pages in that
mapping.
Because FUSE uses strictlimit and has a default max_ratio of only 1%, in
balance_dirty_pages, thresh is ~200, bg_thresh is ~100, and the
dirty_freerun_ceiling is the average of those, ~150. So, it pauses the
dirtying processes when we have 151 dirty pages and wakes up a background
writeback worker. But the worker tests the wrong threshold (200 instead of
100), so it does not initiate writeback and just returns.
Thus, balance_dirty_pages keeps looping, sleeping and then waking up the
worker who will do nothing. It remains stuck in this state until the few
dirty pages that we have finally expire and we write them back for that
reason. Then the whole process repeats, resulting in near-zero throughput
through the FUSE BDI.
The fix is to call the parameterized variant of wb_calc_thresh, so that the
worker will do writeback if the bg_thresh is exceeded which was the
behavior before the referenced commit.
Fixes: 947e9762a8 ("writeback: update wb_over_bg_thresh() to use wb_domain aware operations")
Signed-off-by: Howard Cochran <hcochran@kernelspring.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Cc: <stable@vger.kernel.org> # v4.2+
Tested-by Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Recursive undefined instrcution falut is seen with R-class taking an
exception. The reson for that is __show_regs() tries to get domain
information, but domains is not available on !MMU cores, like R/M
class.
Fix it by puting {set,get}_domain functions under CONFIG_CPU_CP15_MMU
guard and providing stubs for the case where domains is not supported.
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Commit 19accfd3 (ARM: move vector stubs) moved the vector stubs in an
additional page above the base vector one. This change wasn't taken into
account by the nommu memreserve.
This patch ensures that the kernel won't overwrite any vector stub on
nommu.
[changed the MPU side too]
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Commit 1c2f87c (ARM: 8025/1: Get rid of meminfo) broke the support for
MPU on ARMv7-R. This patch adapts the code inside CONFIG_ARM_MPU to use
memblocks appropriately.
MPU initialisation only uses the first memory region, and removes all
subsequent ones. Because looping over all regions that need removal is
inefficient, and memblock_remove already handles memory ranges, we can
flatten the 'for_each_memblock' part.
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
iSER currently has a couple places that set max_sectors in either the host
template or SCSI host, and all of them get it wrong.
This patch instead uses a single assignment that (hopefully) gets it right:
the max_sectors value must be derived from the number of segments in the
FR or FMR structure, but actually be one lower than the page size multiplied
by the number of sectors, as it has to handle the case of non-aligned I/O.
Without this I get trivial to reproduce hangs when running xfstests
(on XFS) over iSER to Linux targets.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Max Gurtovoy <maxg@mellanox.com>
Acked-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Pull userns fix from Eric Biederman:
"This contains just a single fix for a nasty oops"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace:
propogate_mnt: Handle the first propogated copy being a slave
A couple of fixes for virtio and for the new QEMU fw cfg driver.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJXJfuWAAoJECgfDbjSjVRpRdwH/RQjAQnqTuLAI/mn/kbinK24
EoDubbWKq+KVDDwoc3tkWRNBoyXDUIYLHrrJNhLtrXNULTGtIejqJdBnD1THuiZ2
GGWzDiB86qtU1uXSEaXSBFpLi0YYP26bcQ8hjnDhSUWqESE2AC63NO0E0plyu2NI
oPIiWLN3gJovr12vVURbYcrXxZ1zykd/8E80jj/Gus81XrbKXsn8Wmq1cSrtD/DC
S07pWbF43YRl3pWyezQW8D4RowF1f9x8CSzrcvqt3qw5d0+jqtcKz0iR0vsi3wIy
poAadEn+91Xi2kVZUm9bCB30+7A+iqGnFIG7x29xrdZl+2rbvquwRiNlvX4RM4g=
=GoGi
-----END PGP SIGNATURE-----
Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
Pull virtio/qemu fixes from Michael Tsirkin:
"A couple of fixes for virtio and for the new QEMU fw cfg driver"
* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
virtio: Silence uninitialized variable warning
firmware: qemu_fw_cfg.c: potential unintialized variable
On DCE6.1 PPLL2 is exclusively available to UNIPHYA, so it should not
be taken into consideration when looking for an already enabled PLL
to be shared with other outputs.
This fixes the broken VGA port (TRAVIS DP->VGA bridge) on my Richland
based laptop, where the internal display is connected to UNIPHYA through
a TRAVIS DP->LVDS bridge.
Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=78987
v2: agd: add check in radeon_get_shared_nondp_ppll as well, drop
extra parameter.
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
There is an issue observed when we hotplug a second DP
4K monitor to the system. Sometimes, the link training
fails for the second monitor after HPD interrupt
generation.
The issue happens when some queued or deferred transactions
are already present on the AUX channel when we initiate
a new transcation to (say) get DPCD or during link training.
We set AUX_IGNORE_HPD_DISCON bit in the AUX_CONTROL
register so that we can ignore any such deferred
transactions when a new AUX transaction is initiated.
Signed-off-by: Arindam Nath <arindam.nath@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
When the first propgated copy was a slave the following oops would result:
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
> IP: [<ffffffff811fba4e>] propagate_one+0xbe/0x1c0
> PGD bacd4067 PUD bac66067 PMD 0
> Oops: 0000 [#1] SMP
> Modules linked in:
> CPU: 1 PID: 824 Comm: mount Not tainted 4.6.0-rc5userns+ #1523
> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
> task: ffff8800bb0a8000 ti: ffff8800bac3c000 task.ti: ffff8800bac3c000
> RIP: 0010:[<ffffffff811fba4e>] [<ffffffff811fba4e>] propagate_one+0xbe/0x1c0
> RSP: 0018:ffff8800bac3fd38 EFLAGS: 00010283
> RAX: 0000000000000000 RBX: ffff8800bb77ec00 RCX: 0000000000000010
> RDX: 0000000000000000 RSI: ffff8800bb58c000 RDI: ffff8800bb58c480
> RBP: ffff8800bac3fd48 R08: 0000000000000001 R09: 0000000000000000
> R10: 0000000000001ca1 R11: 0000000000001c9d R12: 0000000000000000
> R13: ffff8800ba713800 R14: ffff8800bac3fda0 R15: ffff8800bb77ec00
> FS: 00007f3c0cd9b7e0(0000) GS:ffff8800bfb00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000010 CR3: 00000000bb79d000 CR4: 00000000000006e0
> Stack:
> ffff8800bb77ec00 0000000000000000 ffff8800bac3fd88 ffffffff811fbf85
> ffff8800bac3fd98 ffff8800bb77f080 ffff8800ba713800 ffff8800bb262b40
> 0000000000000000 0000000000000000 ffff8800bac3fdd8 ffffffff811f1da0
> Call Trace:
> [<ffffffff811fbf85>] propagate_mnt+0x105/0x140
> [<ffffffff811f1da0>] attach_recursive_mnt+0x120/0x1e0
> [<ffffffff811f1ec3>] graft_tree+0x63/0x70
> [<ffffffff811f1f6b>] do_add_mount+0x9b/0x100
> [<ffffffff811f2c1a>] do_mount+0x2aa/0xdf0
> [<ffffffff8117efbe>] ? strndup_user+0x4e/0x70
> [<ffffffff811f3a45>] SyS_mount+0x75/0xc0
> [<ffffffff8100242b>] do_syscall_64+0x4b/0xa0
> [<ffffffff81988f3c>] entry_SYSCALL64_slow_path+0x25/0x25
> Code: 00 00 75 ec 48 89 0d 02 22 22 01 8b 89 10 01 00 00 48 89 05 fd 21 22 01 39 8e 10 01 00 00 0f 84 e0 00 00 00 48 8b 80 d8 00 00 00 <48> 8b 50 10 48 89 05 df 21 22 01 48 89 15 d0 21 22 01 8b 53 30
> RIP [<ffffffff811fba4e>] propagate_one+0xbe/0x1c0
> RSP <ffff8800bac3fd38>
> CR2: 0000000000000010
> ---[ end trace 2725ecd95164f217 ]---
This oops happens with the namespace_sem held and can be triggered by
non-root users. An all around not pleasant experience.
To avoid this scenario when finding the appropriate source mount to
copy stop the walk up the mnt_master chain when the first source mount
is encountered.
Further rewrite the walk up the last_source mnt_master chain so that
it is clear what is going on.
The reason why the first source mount is special is that it it's
mnt_parent is not a mount in the dest_mnt propagation tree, and as
such termination conditions based up on the dest_mnt mount propgation
tree do not make sense.
To avoid other kinds of confusion last_dest is not changed when
computing last_source. last_dest is only used once in propagate_one
and that is above the point of the code being modified, so changing
the global variable is meaningless and confusing.
Cc: stable@vger.kernel.org
fixes: f2ebb3a921 ("smarter propagate_mnt()")
Reported-by: Tycho Andersen <tycho.andersen@canonical.com>
Reviewed-by: Seth Forshee <seth.forshee@canonical.com>
Tested-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
If a quota bit is set in NFACCT_FLAGS but the NFACCT_QUOTA parameter is
missing then a NULL pointer dereference is triggered. CAP_NET_ADMIN is
required to trigger the bug.
Signed-off-by: Phil Turnbull <phil.turnbull@oracle.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
The code for checking whether a BAR address range is valid will break
out of the loop when a start address of 0x0 is encountered.
This behaviour is wrong since by breaking out of the loop we may miss
the BAR that describes the EFI frame buffer in a later iteration.
Because of this bug I can't use video=efifb: boot parameter to get
efifb on my new ThinkPad E550 for my old linux system hard disk with
3.10 kernel. In 3.10, efifb is the only choice due to DRM/I915 not
supporting the GPU.
This patch also add a trivial optimization to break out after we find
the frame buffer address range without testing later BARs.
Signed-off-by: Wang YanQing <udknight@gmail.com>
[ Rewrote changelog. ]
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Reviewed-by: Peter Jones <pjones@redhat.com>
Cc: <stable@vger.kernel.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1462454061-21561-2-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Initial HIGHMEM support on ARC was introduced for PAE40 where the low
memory (0x8000_0000 based) and high memory (0x1_0000_0000) were
physically contiguous. So CONFIG_FLATMEM sufficed (despite a peipheral
hole in the middle, which wasted a bit of struct page memory, but things
worked).
However w/o PAE, highmem was not possible and we could only reach
~1.75GB of DDR. Now there is a use case to access ~4GB of DDR w/o PAE40
The idea is to have low memory at canonical 0x8000_0000 and highmem
at 0 so enire 4GB address space is available for physical addressing
This needs additional platform/interconnect mapping to convert
the non contiguous physical addresses into linear bus adresses.
From Linux point of view, non contiguous divide means FLATMEM no
longer works and DISCONTIGMEM is needed to track the pfns in the 2
regions.
This scheme would also work for PAE40, only better in that we don't
waste struct page memory for the peripheral hole.
The DT description will be something like
memory {
...
reg = <0x80000000 0x200000000 /* 512MB: lowmem */
0x00000000 0x10000000>; /* 256MB: highmem */
}
Signed-off-by: Noam Camus <noamc@ezchip.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
So a benign looking cleanup which macro'ized PAGE_SHIFT shifts turned
out to be bad (since it was done non-sensically across the board).
It caused boot failures with PAE40 as forced cast to (unsigned long)
from newly introduced virt_to_pfn() was causing truncatiion of the
(long long) pte/paddr values.
It is OK to use this in accessors dealing with kernel virtual address,
pointers etc, but not for PTE values themelves.
Fixes: cJ2ff5cf2735c ("ARC: mm: Use virt_to_pfn() for addr >> PAGE_SHIFT pattern)
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
While reviewing a different change to asm-generic/io.h Arnd spotted that
ARC ioread32 and ioread32be both of which come from asm-generic versions
are not symmetrical in terms of calling the io barriers.
generic ioread32 -> ARC readl() [ has barriers]
generic ioread32be -> __be32_to_cpu(__raw_readl()) [ lacks barriers]
While generic ioread32be is being remediated to call readl(), that involves
a swab32(), causing double swaps on ioread32be() on Big Endian systems.
So provide our versions of big endian IO accessors to ensure io barrier
calls while also keeping them optimal
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Cc: stable@vger.kernel.org [4.2+]
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Just checking ifdef CONFIG_USB is not enough, if the USB is compiled
as module. The same applies to PCI.
Tested with the following .config alternatives:
CONFIG_USB=m
CONFIG_MEDIA_CONTROLLER=y
CONFIG_MEDIA_SUPPORT=m
CONFIG_VIDEO_AU0828=m
CONFIG_USB=m
CONFIG_MEDIA_CONTROLLER=y
CONFIG_MEDIA_SUPPORT=y
CONFIG_VIDEO_AU0828=m
CONFIG_USB=y
CONFIG_MEDIA_CONTROLLER=y
CONFIG_MEDIA_SUPPORT=y
CONFIG_VIDEO_AU0828=m
CONFIG_USB=y
CONFIG_MEDIA_CONTROLLER=y
CONFIG_MEDIA_SUPPORT=y
CONFIG_VIDEO_AU0828=y
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The new sanity check introduced by:
2665784850 ("perf/core: Verify we have a single perf_hw_context PMU")
... triggered on the AMD IOMMU driver.
IOMMUs are not per logical CPU, they cannot have per-task counters. Fix it.
Reported-by: Borislav Petkov <bp@alien8.de>
Tested-by: Borislav Petkov <bp@suse.de>
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: jroedel@suse.de
Cc: suravee.suthikulpanit@amd.com
Link: http://lkml.kernel.org/r/20160423224255.GB3430@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
A while back the following commit:
d394f2d9d8 ("x86/platform/UV: Remove EFI memmap quirk for UV2+")
changed uv_system_init() to only call map_low_mmrs() on older UV1 hardware,
which requires EFI_OLD_MEMMAP to be set in order to boot.
The recent changes to the EFI memory mapping code in:
d2f7cbe7b2 ("x86/efi: Runtime services virtual mapping")
exposed some issues with the fact that we were relying on the EFI memory
mapping mechanisms to map in our MMRs for us, after commit d394f2d9d8.
Rather than revert the entire commit and go back to forcing
EFI_OLD_MEMMAP on all UVs, we're going to add the call to map_low_mmrs()
back into uv_system_init(), and then fix up our EFI runtime calls to use
the appropriate page table.
For now, UV2+ will still need efi=old_map to boot, but there will be
other changes soon that should eliminate the need for this.
Signed-off-by: Alex Thorlton <athorlton@sgi.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Adam Buchbinder <adam.buchbinder@gmail.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Russ Anderson <rja@sgi.com>
Cc: Dimitri Sivanich <sivanich@sgi.com>
Link: http://lkml.kernel.org/r/1462401592-120735-1-git-send-email-athorlton@sgi.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The pkcs1pad template needs CRYPTO_MANAGER so it needs
to be explicitly selected by CRYPTO_RSA.
Reported-by: Jamie Heilman <jamie@audible.transient.net>
Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The crypto hash walk code is broken when supplied with an offset
greater than or equal to PAGE_SIZE. This patch fixes it by adjusting
walk->pg and walk->offset when this happens.
Cc: <stable@vger.kernel.org>
Reported-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
i915 fixes for 4.6. A bit more than I'd like at this stage, but
OTOH they're all stable material.
* tag 'drm-intel-fixes-2016-05-02' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Make RPS EI/thresholds multiple of 25 on SNB-BDW
drm/i915: Fake HDMI live status
drm/i915: Fix eDP low vswing for Broadwell
drm/i915/ddi: Fix eDP VDD handling during booting and suspend/resume
drm/i915: Fix system resume if PCI device remained enabled
drm/i915: Avoid stalling on pending flips for legacy cursor updates
two fixes for hw lockups and one for a double free
* 'drm-fixes-4.6' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: make sure vertical front porch is at least 1
drm/radeon: make sure vertical front porch is at least 1
drm/amdgpu: set metadata pointer to NULL after freeing.
If of_node is set before calling platform_device_add, the driver core
will try to use of: modalias matching, which fails because the device
tree nodes don't have a compatible property set. This patch fixes
imx-ipuv3-crtc module autoloading by setting the of_node property only
after the platform modalias is set.
Fixes: 304e6be652 ("gpu: ipu-v3: Assign of_node of child platform devices to corresponding ports")
Reported-by: Dennis Gilmore <dennis@ausil.us>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Tested-By: Dennis Gilmore <dennis@ausil.us>
Cc: stable@vger.kernel.org # 4.4+
Signed-off-by: Dave Airlie <airlied@redhat.com>
Regulators are optional for devices using OPPs and the OPP core
shouldn't be printing any errors for such missing regulators.
It was fine before the commit 0c717d0f9c, but that failed to update
this part of the code to remove an 'always true' check and an extra
unwanted print message.
Fix that now.
Fixes: 0c717d0f9c (PM / OPP: Initialize regulator pointer to an error value)
Reported-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Compat architectures that does not use generic unistd (mips, s390),
declare compat version in their syscall tables for preadv2 and
pwritev2. Generic unistd syscall table should do it as well.
[arnd: this initially slipped through the review and an
incorrect patch got merged. arch/tile/ is the only architecture
that could be affected for their 32-bit compat mode, every
other architecture we support today is fine.]
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Michael Chan says:
====================
bnxt_en: 2 bug fixes.
Fix crash on ppc64 due to missing memory barrier and restore multicast
after reset.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The multicast/all-multicast internal flags are not properly restored
after device reset. This could lead to unreliable multicast operations
after an ethtool configuration change for example.
Call bnxt_mc_list_updated() and setup the vnic->mask in bnxt_init_chip()
to fix the issue.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The code determines if the next ring entry is valid before proceeding
further to read the rest of the entry. The CPU can re-order and read
the rest of the entry first, possibly reading a stale entry, if DMA
of a new entry happens right after reading it. This issue can be
readily seen on a ppc64 system, causing it to crash.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
ACPICA commit 7a3bd2d962f221809f25ddb826c9e551b916eb25
Set the mutex owner thread ID.
Original patch from: Prarit Bhargava <prarit@redhat.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=115121
Link: https://github.com/acpica/acpica/commit/7a3bd2d9
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Tested-by: Andy Lutomirski <luto@kernel.org> # On a Dell XPS 13 9350
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Steffen Klassert says:
====================
pull request (net): ipsec 2016-05-04
1) The flowcache can hit an OOM condition if too
many entries are in the gc_list. Fix this by
counting the entries in the gc_list and refuse
new allocations if the value is too high.
2) The inner headers are invalid after a xfrm transformation,
so reset the skb encapsulation field to ensure nobody tries
access the inner headers. Otherwise tunnel devices stacked
on top of xfrm may build the outer headers based on wrong
informations.
3) Add pmtu handling to vti, we need it to report
pmtu informations for local generated packets.
Please pull or let me know if there are problems.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The stack object “map” has a total size of 32 bytes. Its last 4
bytes are padding generated by compiler. These padding bytes are
not initialized and sent out via “nla_put”.
Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
The stack object “info” has a total size of 12 bytes. Its last byte
is padding which is not initialized and leaked via “put_cmsg”.
Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull IMA fix from James Morris.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
ima: fix the string representation of the LSM/IMA hook enumeration ordering
In the receive path a queue's work bit was cleared unconditionally even
if fec_enet_rx_queue only read out a part of the available packets from
the hardware. This resulted in not reading any packets in the next napi
turn and so packets were delayed or lost.
The obvious fix is to only clear a queue's bit when the queue was
emptied.
Fixes: 4d494cdc92 ("net: fec: change data structure to support multiqueue")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Tested-by: Fugang Duan <fugang.duan@nxp.com>
Acked-by: Fugang Duan <fugang.duan@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
First of all, trying to open them r/w is idiocy; it's guaranteed to fail.
Moreover, assigning ->f_pos and assuming that everything will work is
blatantly broken - try that with e.g. tmpfs as underlying layer and watch
the fireworks. There may be a non-trivial amount of state associated with
current IO position, well beyond the numeric offset. Using the single
struct file associated with underlying inode is really not a good idea;
we ought to open one for each ecryptfs directory struct file.
Additionally, file_operations both for directories and non-directories are
full of pointless methods; non-directories should *not* have ->iterate(),
directories should not have ->flush(), ->fasync() and ->splice_read().
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
When probe bails out with an error, we try to unregister the
netdev before we have even registered it. Fix the goto statements
for that.
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
- Fix two regressions causing crashes in 32-bit PV guests.
- Fix a regression in the evtchn driver.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJXKhf2AAoJEFxbo/MsZsTRYeEH/jkKi9CsCpcHBdJudqJ/RCmr
ZLWu9JT5+iYUOD2o+NVumiMbNE7Ary/5rDVYzskzgtD2OL1MQJWQia3FC9Mhvj7y
6lFEl5m6SPNMi1VOW+BPU8k6tduSgnPISYyJbsQ5/YoAiHNX+ieaWX5UhFFlfDkj
8kpjVNclc3efgh6RqV1GzrmqhkYwVFATwG3SQFujzGSIC7KZNJHy5RQEH3UBvTU2
ymcL+eO35VSZrH9BXVvOberI3ME3UOkFxFIlAVqlBEgO8MoOlV0tFs/ciqjsHZvH
ieKAb5jxLlHTwIu6ZxL2vCMp/ili9jeDNsiADkk9utJUUuI5WlHDjrLbqnUf2aY=
=ckNq
-----END PGP SIGNATURE-----
Merge tag 'for-linus-4.6-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Pull xen regression fixes from David Vrabel:
- Fix two regressions causing crashes in 32-bit PV guests
- Fix a regression in the evtchn driver
* tag 'for-linus-4.6-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
xen/evtchn: fix ring resize when binding new events
xen/balloon: Fix crash when ballooning on x86 32 bit PAE
xen: Fix page <-> pfn conversion on 32 bit systems
The TSO code creates A-MSDUs from a single large send. Each
A-MSDU is an skb and skb->len doesn't include the number of
bytes which need to be added for the headers being added
(subframe header, TCP header, IP header, SNAP, padding).
To be able to set the right value in the Tx command, we
put the number of bytes added by those headers in
driver_data in iwl_mvm_tx_tso and use this value in
iwl_mvm_set_tx_cmd.
The problem by setting this value in driver_data is that
it overrides the ieee80211_tx_info. The bug manifested
itself when we send P2P related frames in CCK since the
rate in ieee80211_tx_info is zero-ed. This of course is
a violation of the P2P specification.
To fix this, copy the original ieee80211_tx_info to the
stack and pass it to the functions which need it.
Assign the number of bytes added by the headers to the
driver_data inside the skb itself.
Fixes: a6d5e32f24 ("iwlwifi: mvm: send large SKBs to the transport")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The copying of ring data was wrong for two cases: For a full ring
nothing got copied at all (as in that case the canonicalized producer
and consumer indexes are identical). And in case one or both of the
canonicalized (after the resize) indexes would point into the second
half of the buffer, the copied data ended up in the wrong (free) part
of the new buffer. In both cases uninitialized data would get passed
back to the caller.
Fix this by simply copying the old ring contents twice: Once to the
low half of the new buffer, and a second time to the high half.
This addresses the inability to boot a HVM guest with 64 or more
vCPUs. This regression was caused by 8620015499 (xen/evtchn:
dynamically grow pending event channel ring).
Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: <stable@vger.kernel.org> # 4.4+
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
After commit 8fa520af50 "intel_pstate: Remove freq calculation from
intel_pstate_calc_busy()" intel_pstate_get() calls get_avg_frequency()
to compute the average frequency, which is problematic for two reasons.
First, intel_pstate_get() may be invoked before the driver reads the
CPU feedback registers for the first time and if that happens,
get_avg_frequency() will attempt to divide by zero.
Second, the get_avg_frequency() call in intel_pstate_get() is racy
with respect to intel_pstate_sample() and it may end up returning
completely meaningless values for this reason.
Moreover, after commit 7349ec0470 "intel_pstate: Move
intel_pstate_calc_busy() into get_target_pstate_use_performance()"
sample.core_pct_busy is never computed on Atom, but it is used in
intel_pstate_adjust_busy_pstate() in that case too.
To address those problems notice that if sample.core_pct_busy
was used in the average frequency computation carried out by
get_avg_frequency(), both the divide by zero problem and the
race with respect to intel_pstate_sample() would be avoided.
Accordingly, move the invocation of intel_pstate_calc_busy() from
get_target_pstate_use_performance() to intel_pstate_update_util(),
which also will take care of the uninitialized sample.core_pct_busy
on Atom, and modify get_avg_frequency() to use sample.core_pct_busy
as per the above.
Reported-by: kernel test robot <ying.huang@linux.intel.com>
Link: http://marc.info/?l=linux-kernel&m=146226437623173&w=4
Fixes: 8fa520af50 "intel_pstate: Remove freq calculation from intel_pstate_calc_busy()"
Fixes: 7349ec0470 "intel_pstate: Move intel_pstate_calc_busy() into get_target_pstate_use_performance()"
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch fixes the string representation of the LSM/IMA hook enumeration
ordering used for displaying the IMA policy.
Fixes: d9ddf077bb ("ima: support for kexec image and initramfs")
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Tested-by: Eric Richter <erichte@linux.vnet.ibm.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
When using ACPI, id is NULL and the current code automatically
defaults name to NULL and chip id to 0. We should instead use
the data provided in the ACPI device table.
Fixes: c816d9e7a5 ("iio: imu: mpu6050: fix possible NULL dereferences")
Signed-off-by: Daniel Baluta <daniel.baluta@intel.com>
Reviewed-By: Matt Ranostay <matt.ranostay@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
