I don't know if fix is functional correct, but at least it compiles now.
It failed before with a config for an AMD CPU.
Bug was introduced with commit d01b1f96a82e5dd7841a1d39db3abfdaf95f70ab
"perf/x86/intel: Make cpuc allocations consistent" which was merged
with 004cc08675b761fd82288bab1b5ba5e1ca746eca.
Signed-off-by: Alexander Holler <holler(a)ahsoftware.de>
Cc: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: <stable(a)vger.kernel.org>
---
arch/x86/events/perf_event.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h
index b04ae6c..a759557 100644
--- a/arch/x86/events/perf_event.h
+++ b/arch/x86/events/perf_event.h
@@ -1033,12 +1033,12 @@ static inline int intel_pmu_init(void)
return 0;
}
-static inline int intel_cpuc_prepare(struct cpu_hw_event *cpuc, int cpu)
+static inline int intel_cpuc_prepare(struct cpu_hw_events *cpuc, int cpu)
{
return 0;
}
-static inline void intel_cpuc_finish(struct cpu_hw_event *cpuc)
+static inline void intel_cpuc_finish(struct cpu_hw_events *cpuc)
{
}
--
2.9.5
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id…
The additional hardware support would be helpful in the 4.4 long term tree.
e1000e: Initial support for KabeLake
i219 (4) and i219 (5) are the next LOM generations that will be
available on the next Intel platform (KabeLake).
This patch provides the initial support for the devices.
Signed-off-by: Raanan Avargil <raanan.avargil(a)intel.com>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
--
Pat Riehecky
Fermi National Accelerator Laboratory
www.fnal.govwww.scientificlinux.org
Hi,
On Tue, Mar 05, 2019 at 10:23:15PM +0100, Peter Zijlstra (Intel) wrote:
> The cpuc data structure allocation is different between fake and real
> cpuc's; use the same code to init/free both.
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
With allmodconfig-CONFIG_CPU_SUP_INTEL, this patch results in:
In file included from arch/x86/events/amd/core.c:8:0:
arch/x86/events/amd/../perf_event.h:1036:45: warning: ‘struct cpu_hw_event’ declared inside parameter list will not be visible outside of this definition or declaration
static inline int intel_cpuc_prepare(struct cpu_hw_event *cpuc, int cpu)
^~~~~~~~~~~~
arch/x86/events/amd/../perf_event.h:1041:45: warning: ‘struct cpu_hw_event’ declared inside parameter list will not be visible outside of this definition or declaration
static inline void intel_cpuc_finish(struct cpu_hw_event *cpuc)
^~~~~~~~~~~~
With -Werror, this is fatal, and I think it may be buggy (should it be
cpu_hw_events) ?
The patch has been applied to stable releases. Any idea, anyone, why
this is the case ? It doesn't look like a bug fix to me, and reverting
it from v4.14.106 didn't seem to have a negative impact.
Guenter
Ext4 needs to serialize unaligned direct AIO because the zeroing of
partial blocks of two competing unaligned AIOs can result in data
corruption.
However it decides not to serialize if the potentially unaligned aio is
past i_size with the rationale that no pending writes are possible past
i_size. Unfortunately if the i_size is not block aligned and the second
unaligned write lands past i_size, but still into the same block, it has
the potential of corrupting the previous unaligned write to the same
block.
This is (very simplified) reproducer from Frank
// 41472 = (10 * 4096) + 512
// 37376 = 41472 - 4096
ftruncate(fd, 41472);
io_prep_pwrite(iocbs[0], fd, buf[0], 4096, 37376);
io_prep_pwrite(iocbs[1], fd, buf[1], 4096, 41472);
io_submit(io_ctx, 1, &iocbs[1]);
io_submit(io_ctx, 1, &iocbs[2]);
io_getevents(io_ctx, 2, 2, events, NULL);
Without this patch the 512B range from 40960 up to the start of the
second unaligned write (41472) is going to be zeroed overwriting the data
written by the first write. This is a data corruption.
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
00009200 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
*
0000a000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0000a200 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31
With this patch the data corruption is avoided because we will recognize
the unaligned_aio and wait for the unwritten extent conversion.
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
00009200 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
*
0000a200 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31
*
0000b200
Reported-by: Frank Sorenson <fsorenso(a)redhat.com>
Signed-off-by: Lukas Czerner <lczerner(a)redhat.com>
Fixes: e9e3bcecf44c ("ext4: serialize unaligned asynchronous DIO")
Cc: <stable(a)vger.kernel.org>
---
fs/ext4/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext4/file.c b/fs/ext4/file.c
index 69d65d49837b..98ec11f69cd4 100644
--- a/fs/ext4/file.c
+++ b/fs/ext4/file.c
@@ -125,7 +125,7 @@ ext4_unaligned_aio(struct inode *inode, struct iov_iter *from, loff_t pos)
struct super_block *sb = inode->i_sb;
int blockmask = sb->s_blocksize - 1;
- if (pos >= i_size_read(inode))
+ if (pos >= ALIGN(i_size_read(inode), sb->s_blocksize))
return 0;
if ((pos | iov_iter_alignment(from)) & blockmask)
--
2.20.1
On Thu, Mar 14, 2019 at 07:59:00PM +0000, Alan J. Wylie wrote:
> Greg KH <gregkh(a)linuxfoundation.org> writes:
>
> > I'm announcing the release of the 5.0.2 kernel.
>
> There is a regression for AMD-only builds.
Adding the stable list, which people should do...
>
> See also Alec Ari's report:
> https://lkml.org/lkml/2019/3/13/1113
>
> > If CONFIG_CPU_SUP_INTEL is disabled with either the 5.0.2 or 4.20.16
> > kernel, it errors out right away:
>
> $ grep "CONFIG_CPU_SUP_" .config
> # CONFIG_CPU_SUP_INTEL is not set
> CONFIG_CPU_SUP_AMD=y
> # CONFIG_CPU_SUP_HYGON is not set
> # CONFIG_CPU_SUP_CENTAUR is not set
>
> CC arch/x86/events/core.o
> In file included from arch/x86/events/core.c:44:
> arch/x86/events/perf_event.h:1035:45: warning: ‘struct cpu_hw_event’ declared inside parameter list will not be visible outside of this definition or declaration
> static inline int intel_cpuc_prepare(struct cpu_hw_event *cpuc, int cpu)
> ^~~~~~~~~~~~
> arch/x86/events/perf_event.h:1040:45: warning: ‘struct cpu_hw_event’ declared inside parameter list will not be visible outside of this definition or declaration
> static inline void intel_cpuc_finish(struct cpu_hw_event *cpuc)
> ^~~~~~~~~~~~
> arch/x86/events/core.c: In function ‘free_fake_cpuc’:
> arch/x86/events/core.c:1998:20: error: passing argument 1 of ‘intel_cpuc_finish’ from incompatible pointer type [-Werror=incompatible-pointer-types]
> intel_cpuc_finish(cpuc);
> ^~~~
> In file included from arch/x86/events/core.c:44:
> arch/x86/events/perf_event.h:1040:59: note: expected ‘struct cpu_hw_event *’ but argument is of type ‘struct cpu_hw_events *’
> static inline void intel_cpuc_finish(struct cpu_hw_event *cpuc)
> ~~~~~~~~~~~~~~~~~~~~~^~~~
> arch/x86/events/core.c: In function ‘allocate_fake_cpuc’:
> arch/x86/events/core.c:2012:25: error: passing argument 1 of ‘intel_cpuc_prepare’ from incompatible pointer type [-Werror=incompatible-pointer-types]
> if (intel_cpuc_prepare(cpuc, cpu))
> ^~~~
> In file included from arch/x86/events/core.c:44:
> arch/x86/events/perf_event.h:1035:59: note: expected ‘struct cpu_hw_event *’ but argument is of type ‘struct cpu_hw_events *’
> static inline int intel_cpuc_prepare(struct cpu_hw_event *cpuc, int cpu)
> ~~~~~~~~~~~~~~~~~~~~~^~~~
> cc1: some warnings being treated as errors
Is this a regression? If so, what commit caused this? Is this also an
issue in Linus's tree right now?
thanks,
greg k-h
Hello!
While trying to add Perf tests to LKFT [1], we encountered some
problems building it for two specific combinations:
* 4.4 and x86-64
* 4.14 and x86-32
On 4.4, this is what the build failure looks like:
| bench/mem-memcpy-x86-64-asm.S:4:10: fatal error:
../../../arch/x86/lib/memcpy_64.S: No such file or directory
| #include "../../../arch/x86/lib/memcpy_64.S"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This was fixed in mainline by commit 7d7d1bf1d1da ("perf bench: Copy
kernel files needed to build mem{cpy,set} x86_64 benchmarks"). Instead
of just cherry-picking, it requires a proper backport as it needs to
copy the existing files in 4.4, not the ones contained in that commit
(which are from v4.7-rc5+).
On 4.14, this is what the build failure looks like:
| In file included from util/libunwind/x86_32.c:33:0:
| util/libunwind/../../arch/x86/util/unwind-libunwind.c: In function
'libunwind__x86_reg_id':
| util/libunwind/../../arch/x86/util/unwind-libunwind.c:110:11: error:
'EINVAL' undeclared (first use in this function); did you mean
'UNW_EINVAL'?
| return -EINVAL;
| ^~~~~~
| UNW_EINVAL
This was fixed by 44df1afdb174 ("perf tools: Fix compile error with
libunwind x86"); it applies cleanly on top of v4.14.106.
Thanks and greetings!
Daniel Díaz
daniel.diaz(a)linaro.org
[1] https://lkft.linaro.org/about/
Hello,
Syzkaller has triggered a kernel BUG when fuzzing a 4.4 kernel with the following stacktrace.
Call Trace:
[<ffffffff818568d5>] construct_alloc_key security/keys/request_key.c:388 [inline]
[<ffffffff818568d5>] construct_key_and_link security/keys/request_key.c:479 [inline]
[<ffffffff818568d5>] request_key_and_link+0x49b/0x8c5 security/keys/request_key.c:594
[<ffffffff8184fb08>] SYSC_request_key security/keys/keyctl.c:213 [inline]
[<ffffffff8184fb08>] SyS_request_key+0x1ac/0x2a2 security/keys/keyctl.c:158
[<ffffffff832bec3a>] entry_SYSCALL_64_fastpath+0x31/0xb3
Could the following patches be applied to v4.4.y?
* 4aa68e07d845 ("KEYS: restrict /proc/keys by credentials at open time")
* ede0fa98a900 ("KEYS: always initialize keyring_index_key::desc_len")
Note: queue-4.4 currently has a backport for "keys-always-initialize-keyring_index_key-desc_len.patch".
This request is to apply the 2 patches above instead of just one, to 4.4.y,
as the first patch is a bugfix as well. They apply cleanly if applied one after another.
Tests:
* Chrome OS tryjob
* Syzkaller reproducer
* Test to check if 4aa68e07d845 works as intended
Thanks,
- Zubin
From: Eric Biggers <ebiggers(a)google.com>
commit 4aa68e07d845562561f5e73c04aa521376e95252 upstream
When checking for permission to view keys whilst reading from
/proc/keys, we should use the credentials with which the /proc/keys file
was opened. This is because, in a classic type of exploit, it can be
possible to bypass checks for the *current* credentials by passing the
file descriptor to a suid program.
Following commit 34dbbcdbf633 ("Make file credentials available to the
seqfile interfaces") we can finally fix it. So let's do it.
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Zubin Mithra <zsm(a)chromium.org>
---
* A test confirmed that when reading from a file descriptor
corresponding to /proc/keys the permissions for the reader were being
used instead of the permissions of the user who opened the file.
This patch is required for 4.4.y as well; however, the original patch
will apply cleanly there. I'll send a separate request for the same.
security/keys/proc.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/security/keys/proc.c b/security/keys/proc.c
index ec493ddadd111..f2c7e090a66d7 100644
--- a/security/keys/proc.c
+++ b/security/keys/proc.c
@@ -187,7 +187,7 @@ static int proc_keys_show(struct seq_file *m, void *v)
struct keyring_search_context ctx = {
.index_key = key->index_key,
- .cred = current_cred(),
+ .cred = m->file->f_cred,
.match_data.cmp = lookup_user_key_possessed,
.match_data.raw_data = key,
.match_data.lookup_type = KEYRING_SEARCH_LOOKUP_DIRECT,
@@ -207,11 +207,7 @@ static int proc_keys_show(struct seq_file *m, void *v)
}
}
- /* check whether the current task is allowed to view the key (assuming
- * non-possession)
- * - the caller holds a spinlock, and thus the RCU read lock, making our
- * access to __current_cred() safe
- */
+ /* check whether the current task is allowed to view the key */
rc = key_task_permission(key_ref, ctx.cred, KEY_NEED_VIEW);
if (rc < 0)
return 0;
--
2.21.0.360.g471c308f928-goog
commit upstream 8b23570ab001c1982c8a068cde468ff067255314
This commit ("ACPICA: Reference Counts: increase max to 0x4000 for large servers") fixes an issue that has been seen on large memory systems. The first release with the fix was 4.19.
It's a low risk fix, and the value has been bumped in the past already. It should be fine on anything below 4.19, but I've only included 4.9 and 4.14 here, since the issue was actually observed on those versions.
Thanks,
Frank
I'm announcing the release of the 5.0.2 kernel.
All users of the 5.0 kernel series must upgrade.
The updated 5.0.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.0.y
and can be browsed at the normal kernel.org git web browser:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Makefile | 2
arch/arm/boot/dts/exynos3250.dtsi | 3
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 13 -
arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 2
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 2
arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts | 1
arch/x86/events/core.c | 13 -
arch/x86/events/intel/core.c | 154 ++++++++++++++----
arch/x86/events/perf_event.h | 17 +-
arch/x86/include/asm/cpufeatures.h | 1
arch/x86/include/asm/msr-index.h | 6
arch/x86/pci/fixup.c | 16 +
drivers/firmware/iscsi_ibft.c | 1
drivers/input/mouse/elan_i2c_core.c | 1
drivers/input/tablet/wacom_serial4.c | 2
drivers/media/rc/rc-main.c | 13 +
drivers/media/usb/uvc/uvc_driver.c | 14 +
drivers/net/wireless/ath/ath9k/init.c | 6
drivers/pci/pcie/pme.c | 27 ---
drivers/scsi/aacraid/commsup.c | 5
drivers/staging/erofs/namei.c | 183 +++++++++++-----------
drivers/staging/erofs/unzip_vle.c | 38 ++--
drivers/staging/erofs/unzip_vle.h | 3
drivers/staging/erofs/unzip_vle_lz4.c | 19 --
fs/gfs2/glock.c | 2
include/drm/drm_cache.h | 18 ++
net/core/skmsg.c | 1
scripts/gdb/linux/constants.py.in | 12 -
scripts/gdb/linux/proc.py | 12 -
29 files changed, 365 insertions(+), 222 deletions(-)
Alexander Shishkin (1):
x86/PCI: Fixup RTIT_BAR of Intel Denverton Trace Hub
Alistair Strachan (2):
media: uvcvideo: Fix 'type' check leading to overflow
arm64: dts: hikey: Revert "Enable HS200 mode on eMMC"
Andreas Gruenbacher (1):
gfs2: Fix missed wakeups in find_insert_glock
Ard Biesheuvel (1):
drm: disable uncached DMA optimization for ARM and arm64
Daniel F. Dickinson (1):
ath9k: Avoid OF no-EEPROM quirks without qca,no-eeprom
Gao Xiang (2):
staging: erofs: keep corrupted fs from crashing kernel in erofs_namei()
staging: erofs: compressed_pages should not be accessed again after freed
Greg Kroah-Hartman (1):
Linux 5.0.2
Gustavo A. R. Silva (2):
iscsi_ibft: Fix missing break in switch statement
scsi: aacraid: Fix missing break in switch statement
Jackie Liu (1):
scripts/gdb: replace flags (MS_xyz -> SB_xyz)
Jakub Sitnicki (1):
bpf: Stop the psock parser before canceling its work
Jan Kiszka (2):
arm64: dts: zcu100-revC: Give wifi some time after power-on
arm64: dts: hikey: Give wifi some time after power-on
Jason Gerecke (1):
Input: wacom_serial4 - add support for Wacom ArtPad II tablet
Marek Szyprowski (3):
ARM: dts: exynos: Fix pinctrl definition for eMMC RTSN line on Odroid X2/U3
ARM: dts: exynos: Add minimal clkout parameters to Exynos3250 PMU
ARM: dts: exynos: Fix max voltage for buck8 regulator on Odroid XU3/XU4
Mika Westerberg (1):
Revert "PCI/PME: Implement runtime PM callbacks"
Peter Zijlstra (Intel) (4):
perf/x86/intel: Make cpuc allocations consistent
perf/x86/intel: Generalize dynamic constraint creation
x86: Add TSX Force Abort CPUID/MSR
perf/x86/intel: Implement support for TSX Force Abort
Sean Young (1):
media: Revert "media: rc: some events are dropped by userspace"
Vincent Batts (1):
Input: elan_i2c - add id for touchpad found in Lenovo s21e-20
Hi, Daniel & Greg
This patch (979d63d50c0c bpf: prevent out of bounds speculation on
pointer arithmetic) was assigned a CVE (CVE-2019-7308) with a high score:
CVSS v3.0 Severity and Metrics:
Base Score: 9.8 CRITICAL
And this patch is not in stable-4.4, would you please backport this
patch to 4.4?
Thanks,
Jason
The commit f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded
memory to zones until online") introduced move_pfn_range_to_zone() which
calls memmap_init_zone() during onlining a memory block.
memmap_init_zone() will reset pagetype flags and makes migrate type to
be MOVABLE.
However, in __offline_pages(), it also call undo_isolate_page_range()
after offline_isolated_pages() to do the same thing. Due to
the commit 2ce13640b3f4 ("mm: __first_valid_page skip over offline
pages") changed __first_valid_page() to skip offline pages,
undo_isolate_page_range() here just waste CPU cycles looping around the
offlining PFN range while doing nothing, because __first_valid_page()
will return NULL as offline_isolated_pages() has already marked all
memory sections within the pfn range as offline via
offline_mem_sections().
Also, after calling the "useless" undo_isolate_page_range() here, it
reaches the point of no returning by notifying MEM_OFFLINE. Those pages
will be marked as MIGRATE_MOVABLE again once onlining. The only thing
left to do is to decrease the number of isolated pageblocks zone
counter which would make some paths of the page allocation slower that
the above commit introduced.
Even if alloc_contig_range() can be used to isolate 16GB-hugetlb pages
on ppc64, an "int" should still be enough to represent the number of
pageblocks there. Fix an incorrect comment along the way.
Fixes: 2ce13640b3f4 ("mm: __first_valid_page skip over offline pages")
Cc: <stable(a)vger.kernel.org> # v4.13+
Acked-by: Michal Hocko <mhocko(a)suse.com>
Reviewed-by: Oscar Salvador <osalvador(a)suse.de>
Signed-off-by: Qian Cai <cai(a)lca.pw>
---
v4: Further consolidate comments.
Turn on kernel-doc and add a stable tag per Michal.
v3: Reconstruct the kernel-doc comments.
Use a more meaningful variable name per Oscar.
Update the commit log a bit.
v2: Return the nubmer of isolated pageblocks in start_isolate_page_range() per
Oscar; take the zone lock when undoing zone->nr_isolate_pageblock per
Michal.
include/linux/page-isolation.h | 10 -------
mm/memory_hotplug.c | 17 +++++++++---
mm/page_alloc.c | 2 +-
mm/page_isolation.c | 48 +++++++++++++++++++++-------------
mm/sparse.c | 2 +-
5 files changed, 45 insertions(+), 34 deletions(-)
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index 4eb26d278046..280ae96dc4c3 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -41,16 +41,6 @@ int move_freepages_block(struct zone *zone, struct page *page,
/*
* Changes migrate type in [start_pfn, end_pfn) to be MIGRATE_ISOLATE.
- * If specified range includes migrate types other than MOVABLE or CMA,
- * this will fail with -EBUSY.
- *
- * For isolating all pages in the range finally, the caller have to
- * free all pages in the range. test_page_isolated() can be used for
- * test it.
- *
- * The following flags are allowed (they can be combined in a bit mask)
- * SKIP_HWPOISON - ignore hwpoison pages
- * REPORT_FAILURE - report details about the failure to isolate the range
*/
int
start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index d63c5a2959cf..cd1a8c4c6183 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1580,7 +1580,7 @@ static int __ref __offline_pages(unsigned long start_pfn,
{
unsigned long pfn, nr_pages;
long offlined_pages;
- int ret, node;
+ int ret, node, nr_isolate_pageblock;
unsigned long flags;
unsigned long valid_start, valid_end;
struct zone *zone;
@@ -1606,10 +1606,11 @@ static int __ref __offline_pages(unsigned long start_pfn,
ret = start_isolate_page_range(start_pfn, end_pfn,
MIGRATE_MOVABLE,
SKIP_HWPOISON | REPORT_FAILURE);
- if (ret) {
+ if (ret < 0) {
reason = "failure to isolate range";
goto failed_removal;
}
+ nr_isolate_pageblock = ret;
arg.start_pfn = start_pfn;
arg.nr_pages = nr_pages;
@@ -1661,8 +1662,16 @@ static int __ref __offline_pages(unsigned long start_pfn,
/* Ok, all of our target is isolated.
We cannot do rollback at this point. */
offline_isolated_pages(start_pfn, end_pfn);
- /* reset pagetype flags and makes migrate type to be MOVABLE */
- undo_isolate_page_range(start_pfn, end_pfn, MIGRATE_MOVABLE);
+
+ /*
+ * Onlining will reset pagetype flags and makes migrate type
+ * MOVABLE, so just need to decrease the number of isolated
+ * pageblocks zone counter here.
+ */
+ spin_lock_irqsave(&zone->lock, flags);
+ zone->nr_isolate_pageblock -= nr_isolate_pageblock;
+ spin_unlock_irqrestore(&zone->lock, flags);
+
/* removal success */
adjust_managed_page_count(pfn_to_page(start_pfn), -offlined_pages);
zone->present_pages -= offlined_pages;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 03fcf73d47da..d96ca5bc555b 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -8233,7 +8233,7 @@ int alloc_contig_range(unsigned long start, unsigned long end,
ret = start_isolate_page_range(pfn_max_align_down(start),
pfn_max_align_up(end), migratetype, 0);
- if (ret)
+ if (ret < 0)
return ret;
/*
diff --git a/mm/page_isolation.c b/mm/page_isolation.c
index e8baab91b1d1..019280712e1b 100644
--- a/mm/page_isolation.c
+++ b/mm/page_isolation.c
@@ -161,27 +161,36 @@ __first_valid_page(unsigned long pfn, unsigned long nr_pages)
return NULL;
}
-/*
- * start_isolate_page_range() -- make page-allocation-type of range of pages
- * to be MIGRATE_ISOLATE.
- * @start_pfn: The lower PFN of the range to be isolated.
- * @end_pfn: The upper PFN of the range to be isolated.
- * @migratetype: migrate type to set in error recovery.
+/**
+ * start_isolate_page_range() - make page-allocation-type of range of pages to
+ * be MIGRATE_ISOLATE.
+ * @start_pfn: The lower PFN of the range to be isolated.
+ * @end_pfn: The upper PFN of the range to be isolated.
+ * start_pfn/end_pfn must be aligned to pageblock_order.
+ * @migratetype: Migrate type to set in error recovery.
+ * @flags: The following flags are allowed (they can be combined in
+ * a bit mask)
+ * SKIP_HWPOISON - ignore hwpoison pages
+ * REPORT_FAILURE - report details about the failure to
+ * isolate the range
*
* Making page-allocation-type to be MIGRATE_ISOLATE means free pages in
* the range will never be allocated. Any free pages and pages freed in the
- * future will not be allocated again.
- *
- * start_pfn/end_pfn must be aligned to pageblock_order.
- * Return 0 on success and -EBUSY if any part of range cannot be isolated.
+ * future will not be allocated again. If specified range includes migrate types
+ * other than MOVABLE or CMA, this will fail with -EBUSY. For isolating all
+ * pages in the range finally, the caller have to free all pages in the range.
+ * test_page_isolated() can be used for test it.
*
* There is no high level synchronization mechanism that prevents two threads
- * from trying to isolate overlapping ranges. If this happens, one thread
+ * from trying to isolate overlapping ranges. If this happens, one thread
* will notice pageblocks in the overlapping range already set to isolate.
* This happens in set_migratetype_isolate, and set_migratetype_isolate
- * returns an error. We then clean up by restoring the migration type on
- * pageblocks we may have modified and return -EBUSY to caller. This
+ * returns an error. We then clean up by restoring the migration type on
+ * pageblocks we may have modified and return -EBUSY to caller. This
* prevents two threads from simultaneously working on overlapping ranges.
+ *
+ * Return: the number of isolated pageblocks on success and -EBUSY if any part
+ * of range cannot be isolated.
*/
int start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
unsigned migratetype, int flags)
@@ -189,6 +198,7 @@ int start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
unsigned long pfn;
unsigned long undo_pfn;
struct page *page;
+ int nr_isolate_pageblock = 0;
BUG_ON(!IS_ALIGNED(start_pfn, pageblock_nr_pages));
BUG_ON(!IS_ALIGNED(end_pfn, pageblock_nr_pages));
@@ -197,13 +207,15 @@ int start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
pfn < end_pfn;
pfn += pageblock_nr_pages) {
page = __first_valid_page(pfn, pageblock_nr_pages);
- if (page &&
- set_migratetype_isolate(page, migratetype, flags)) {
- undo_pfn = pfn;
- goto undo;
+ if (page) {
+ if (set_migratetype_isolate(page, migratetype, flags)) {
+ undo_pfn = pfn;
+ goto undo;
+ }
+ nr_isolate_pageblock++;
}
}
- return 0;
+ return nr_isolate_pageblock;
undo:
for (pfn = start_pfn;
pfn < undo_pfn;
diff --git a/mm/sparse.c b/mm/sparse.c
index 69904aa6165b..56e057c432f9 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -567,7 +567,7 @@ void online_mem_sections(unsigned long start_pfn, unsigned long end_pfn)
}
#ifdef CONFIG_MEMORY_HOTREMOVE
-/* Mark all memory sections within the pfn range as online */
+/* Mark all memory sections within the pfn range as offline */
void offline_mem_sections(unsigned long start_pfn, unsigned long end_pfn)
{
unsigned long pfn;
--
2.17.2 (Apple Git-113)
Hi,
> Hi,
>
> the cpu frequency scaling never worked right (only on the 4.4 kernel from
> marvell). If you use the 1000 MHz firmware you are running with just 800
> MHz (this is the case on my board with a current firmware).
>
> Just have a look what the kernel thinks it is running at (frequency).
Ok, probably my bad here. By 'worked fine' i mean that this didn't lead to any
freezes or panics. I know the actual frequency wasn't set properly
Regards
/Ilias
>
> Regards,
> Christian
>
> Ilias Apalodimas <ilias.apalodimas(a)linaro.org> schrieb am Do., 14. März
> 2019, 14:44:
>
> > Hello Christian,
> > > Hi,
> > >
> > > I assume you use the 1000 MHz firmware. This does also not work on my
> > Rev 7
> > > board. But I'm pretty sure this is not a problem of the patches, because
> > if
> > > I take a newer kernel (4.19.20/27) without the patches it also does not
> > > work. A kernel 4.19.17 does work for me. My opinion on that is that this
> > is
> > > another problem which does just occure now because now the cpu frequency
> > > scaling is working with the right frequencies.
> > I am not sure which firmware i am running, i did all my tests on 5.0.0 and
> > changing between governors worked fine without the patches
> >
> > Regards
> > /Ilias
> > >
> > > Ilias Apalodimas <ilias.apalodimas(a)linaro.org> schrieb am Do., 14. März
> > > 2019, 13:15:
> > >
> > > > Hi Gregory,
> > > > > The clock parenting was not setup properly when DVFS was enabled. It
> > was
> > > > > expected that the same clock source was used with and without DVFS
> > which
> > > > > was not the case.
> > > > >
> > > > > This patch fixes this issue, allowing to make the cpufreq support
> > work
> > > > > when the CPU clocks source are not the default ones.
> > > > >
> > > > > Fixes: 92ce45fb875d ("cpufreq: Add DVFS support for Armada 37xx")
> > > > > Cc: <stable(a)vger.kernel.org>
> > > > > Reported-by: Christian Neubert <christian.neubert.86(a)gmail.com>
> > > > > Reported-by: Ilias Apalodimas <ilias.apalodimas(a)linaro.org>
> > > > > Signed-off-by: Gregory CLEMENT <gregory.clement(a)bootlin.com>
> > > > > ---
> > > > > drivers/clk/mvebu/armada-37xx-periph.c | 11 +++++++++++
> > > > > 1 file changed, 11 insertions(+)
> > > > >
> > > > > diff --git a/drivers/clk/mvebu/armada-37xx-periph.c
> > > > b/drivers/clk/mvebu/armada-37xx-periph.c
> > > > > index 1f1cff428d78..26ed3c18a239 100644
> > > > > --- a/drivers/clk/mvebu/armada-37xx-periph.c
> > > > > +++ b/drivers/clk/mvebu/armada-37xx-periph.c
> > > > > @@ -671,6 +671,17 @@ static int armada_3700_add_composite_clk(const
> > > > struct clk_periph_data *data,
> > > > > map = syscon_regmap_lookup_by_compatible(
> > > > > "marvell,armada-3700-nb-pm");
> > > > > pmcpu_clk->nb_pm_base = map;
> > > > > +
> > > > > + /*
> > > > > + * Use the same parent when DVFS is enabled that the
> > > > > + * default parent received at boot time. When this
> > > > > + * function is called, DVFS is not enabled yet, so we
> > > > > + * get the default parent and we can set the parent
> > > > > + * for DVFS.
> > > > > + */
> > > > > + if (clk_pm_cpu_set_parent(muxrate_hw,
> > > > > +
> > > > clk_pm_cpu_get_parent(muxrate_hw)))
> > > > > + dev_warn(dev, "Failed to setup default parent
> > > > clock for DVFS\n");
> > > > > }
> > > > >
> > > > > *hw = clk_hw_register_composite(dev, data->name,
> > > > data->parent_names,
> > > > > --
> > > > > 2.20.1
> > > > >
> > > > Applied this and selected only
> > > >
> > > > CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
> > > > CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
> > > > CONFIG_CPU_FREQ_GOV_POWERSAVE=y
> > > >
> > > > After changing the governor from 'powersave' to 'performance' the board
> > > > completely froze (i even lost access to the serial port)
> > > >
> > > > Cheers
> > > > /Ilias
> > > >
> >
The clock parenting was not setup properly when DVFS was enabled. It was
expected that the same clock source was used with and without DVFS which
was not the case.
This patch fixes this issue, allowing to make the cpufreq support work
when the CPU clocks source are not the default ones.
Fixes: 92ce45fb875d ("cpufreq: Add DVFS support for Armada 37xx")
Cc: <stable(a)vger.kernel.org>
Reported-by: Christian Neubert <christian.neubert.86(a)gmail.com>
Reported-by: Ilias Apalodimas <ilias.apalodimas(a)linaro.org>
Signed-off-by: Gregory CLEMENT <gregory.clement(a)bootlin.com>
---
drivers/clk/mvebu/armada-37xx-periph.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/clk/mvebu/armada-37xx-periph.c b/drivers/clk/mvebu/armada-37xx-periph.c
index 1f1cff428d78..26ed3c18a239 100644
--- a/drivers/clk/mvebu/armada-37xx-periph.c
+++ b/drivers/clk/mvebu/armada-37xx-periph.c
@@ -671,6 +671,17 @@ static int armada_3700_add_composite_clk(const struct clk_periph_data *data,
map = syscon_regmap_lookup_by_compatible(
"marvell,armada-3700-nb-pm");
pmcpu_clk->nb_pm_base = map;
+
+ /*
+ * Use the same parent when DVFS is enabled that the
+ * default parent received at boot time. When this
+ * function is called, DVFS is not enabled yet, so we
+ * get the default parent and we can set the parent
+ * for DVFS.
+ */
+ if (clk_pm_cpu_set_parent(muxrate_hw,
+ clk_pm_cpu_get_parent(muxrate_hw)))
+ dev_warn(dev, "Failed to setup default parent clock for DVFS\n");
}
*hw = clk_hw_register_composite(dev, data->name, data->parent_names,
--
2.20.1
From: Christian Neubert <christian.neubert.86(a)gmail.com>
The clock parenting was not setup properly when DVFS was enabled. It was
expected that the same clock source was used with and without DVFS which
was not the case.
This patch fixes this issue, allowing to make the cpufreq support work
when the CPU clock source are not the default ones.
Fixes: 92ce45fb875d ("cpufreq: Add DVFS support for Armada 37xx")
Cc: <stable(a)vger.kernel.org>
[gregory: extract from a larger patch, modify comments and commit log]
Signed-off-by: Christian Neubert <christian.neubert.86(a)gmail.com>
Signed-off-by: Gregory CLEMENT <gregory.clement(a)bootlin.com>
---
drivers/cpufreq/armada-37xx-cpufreq.c | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/armada-37xx-cpufreq.c b/drivers/cpufreq/armada-37xx-cpufreq.c
index 75491fc841a6..ad4463e4266e 100644
--- a/drivers/cpufreq/armada-37xx-cpufreq.c
+++ b/drivers/cpufreq/armada-37xx-cpufreq.c
@@ -162,11 +162,25 @@ static void __init armada37xx_cpufreq_dvfs_setup(struct regmap *base,
}
/*
- * Set cpu clock source, for all the level we keep the same
- * clock source that the one already configured. For this one
- * we need to use the clock framework
+ * Set CPU clock source, for all the level we keep the same
+ * clock source that the one already configured with DVS
+ * disabled. For this one we need to use the clock framework
*/
parent = clk_get_parent(clk);
+
+ /*
+ * Unset parent clock to force the clock framework setting again
+ * the clock parent
+ */
+ clk_set_parent(clk, NULL);
+
+ /*
+ * For the Armada 37xx CPU clocks, setting the parent will
+ * actually configure the parent when DVFS is enabled. At
+ * hardware level it will be a different register from the one
+ * read when doing clk_get_parent that will be set with
+ * clk_set_parent.
+ */
clk_set_parent(clk, parent);
}
--
2.20.1