On Fri, Nov 13, 2020 at 9:27 AM syzbot
wrote:
>
> syzbot suspects this issue was fixed by commit:
>
> commit a49145acfb975d921464b84fe00279f99827d816
> Author: George Kennedy
> Date: Tue Jul 7 19:26:03 2020 +
>
> fbmem: add margin check to fb_check_caps()
>
> bisection log: https://syz
On 12/11/2020 10:48:10+, Lee Jones wrote:
> On Thu, 12 Nov 2020, Alexandre Belloni wrote:
>
> > Hi,
> >
> > On 12/11/2020 09:39:18+, Lee Jones wrote:
> > > Both the caller and the supplier's source file should have access to
> > > the include file containing the prototypes.
> > >
> > > F
From: Lars-Peter Clausen
Use a heap allocated memory for the SPI transfer buffer. Using stack memory
can corrupt stack memory when using DMA on some systems.
This change moves the buffer from the stack of the trigger handler call to
the heap of the buffer of the state struct. The size increases
This patch series add bus format negotiation support for Cadence MHDP8546 bridge
driver.
The patch series has four patches in the below sequence:
1. drm: bridge: cdns-mhdp8546: Add output bus format negotiation
Add minimal output bus format negotiation support.
2. drm: bridge: cdns-mhdp8546: Modif
Modify atomic_get_input_bus_format function to return input formats
based on the output format instead of using hardcoded value.
Signed-off-by: Yuti Amonkar
---
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 110 --
1 file changed, 100 insertions(+), 10 deletions(-)
diff --git
On Thu, Nov 12, 2020 at 12:56:27PM -0500, Jim Quinlan wrote:
> The SMC/HVC SCMI transport is modified to allow the completion of an SCMI
> message to be indicated by an interrupt rather than the return of the smc
> call. This accommodates the existing behavior of the BrcmSTB SCMI
> "platform" whos
This patch adds minimal output bus format negotiation support.
Currently we are adding support for only MEDIA_BUS_FMT_FIXED.
Signed-off-by: Yuti Amonkar
---
.../drm/bridge/cadence/cdns-mhdp8546-core.c| 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/brid
Get the pixel format and bpc based on the output bus format
negotiated instead of hardcoding the values.
Signed-off-by: Yuti Amonkar
---
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 82 +++
1 file changed, 64 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/
As we are using bus negotiations for selecting bus format
remove the setting of bus format using the connector info
structure.
Signed-off-by: Yuti Amonkar
---
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/caden
From: Kaixu Xia
The value of variable timeout is overwritten by the following statement in
rtl8xxxu_gen1_init_aggregation(), so here the value assignment is useless.
Remove it.
Reported-by: Tosk Robot
Signed-off-by: Kaixu Xia
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 2 +-
1
The attr->set() receive a value of u64, but simple_strtoll() is used
for doing the conversion. It will lead to the error cast if user inputs
a negative value.
Use kstrtoull() instead of simple_strtoll() to convert a string got
from the user to an unsigned value. The former will return '-EINVAL' if
Hi Dmitry,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on c34f157421f6905e6b4a79a312e9175dce2bc607]
url:
https://github.com/0day-ci/linux/commits/Dmitry-Safonov/Add-generic-user_landing-tracking/20201109-090354
base:c34f157421f6905e6b4a79a312e9175dce2b
On Fri, 13 Nov 2020, Alexandre Belloni wrote:
> On 12/11/2020 10:48:10+, Lee Jones wrote:
> > On Thu, 12 Nov 2020, Alexandre Belloni wrote:
> >
> > > Hi,
> > >
> > > On 12/11/2020 09:39:18+, Lee Jones wrote:
> > > > Both the caller and the supplier's source file should have access to
> >
On 2020/11/13 17:22, Ning, Hongyu wrote:
> On 2020/11/7 4:55, Joel Fernandes wrote:
>> All,
>>
>> I am getting ready to send the next v9 series based on tip/master
>> branch. Could you please give the below tree a try and report any results in
>> your testing?
>> git tree:
>> https://git.kernel.o
On Sat, 07 Nov 2020, Johan Jonker wrote:
> With the conversion of syscon.yaml minItems for compatibles
> was set to 2. Current Rockchip dtsi files only use "syscon" for
> QoS registers. Add Rockchip QoS compatibles to reduce notifications
> produced with:
>
> make ARCH=arm dtbs_check
> DT_SCHEMA_
On 29/10/2020 22:51, Laurent Pinchart wrote:
> Hi Andy,
>
> On Fri, Oct 30, 2020 at 12:22:15AM +0200, Andy Shevchenko wrote:
>> On Thu, Oct 29, 2020 at 11:29:30PM +0200, Laurent Pinchart wrote:
>>> On Thu, Oct 29, 2020 at 10:26:56PM +0200, Andy Shevchenko wrote:
On Thu, Oct 29, 2020 at 10:21 P
This needs to call of_node_put(np) before returning if of_iomap() fails.
Fixes: e0218dca5787 ("soc: aspeed: Add soc info driver")
Signed-off-by: Dan Carpenter
---
drivers/soc/aspeed/aspeed-socinfo.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/aspeed/aspeed-
On Tue, 10 Nov 2020, Amelie Delaunay wrote:
> ret may be 0 so, dev_err_probe should be called only when ret is an error
> code.
>
> Fixes: 41c9c06c491a ("mfd: stmfx: Simplify with dev_err_probe()")
> Signed-off-by: Amelie Delaunay
> ---
> drivers/mfd/stmfx.c | 5 ++---
> 1 file changed, 2 inser
On Tue, 10 Nov 2020, michael.s...@seznam.cz wrote:
> From: Michael Srba
>
> Fix regulators on rt5033 by converting some values to bitmasks which were
> errorneously not defined as such in the header file.
>
> Cc: Beomho Seo
> Fixes: 0b271258544b ("mfd: rt5033: Add Richtek RT5033 driver core."
On Tue, 10 Nov 2020, Geert Uytterhoeven wrote:
> Currently the Kontron sl28cpld Board Management Controller is found only
> on Kontron boards equipped with a Freescale Layerscape SoC. Hence add a
> dependency on ARCH_LAYERSCAPE, to prevent asking the user about a driver
> for this controller when
Clean up the first driver if the second driver can't be registered.
Fixes: 4ee9fe3e292b ("clk: qcom: lpass-sc7180: Disentangle the two clock
devices")
Signed-off-by: Dan Carpenter
---
drivers/clk/qcom/lpasscorecc-sc7180.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git
On Tue, 10 Nov 2020, Guenter Roeck wrote:
> On Tue, Nov 10, 2020 at 03:23:21PM +, Michael Brunner wrote:
> > Change the detection order to priorize DMI table entries over available
> > ACPI entries.
> >
> > This makes it more easy for product developers to patch product specific
> > handling
On Tue, 10 Nov 2020, Michael Brunner wrote:
> Change the detection order to priorize DMI table entries over available
> ACPI entries.
>
> This makes it more easy for product developers to patch product specific
> handling into the driver.
> Furthermore it allows to simplify the implementation a b
On 2020/11/12 22:03, Suzuki K Poulose wrote:
> On 11/12/20 1:09 PM, Qi Liu wrote:
>>
>>
>> On 2020/11/12 1:03, Mathieu Poirier wrote:
>>> On Wed, Nov 11, 2020 at 04:58:23PM +0800, Qi Liu wrote:
Hi Mathieu,
On 2020/9/10 0:26, Mathieu Poirier wrote:
> On Wed, Sep 09, 2020 at 12:
Michael, Stephen: Could you take this clk patch?
On Friday 06 November 2020 11:51:18 Marek Behún wrote:
> Also, this is how A3720 WTMI code and ATF determines XTAL clock rate.
> No reason for kernel to do it differently.
>
> Reviewed-by: Marek Behún
>
> On Fri, 6 Nov 2020 11:00:39 +0100
> Pali
On Tue, 10 Nov 2020, Enric Balletbo i Serra wrote:
> This adds syscon_regmap_lookup_by_phandle_optional() function to get an
> optional regmap.
>
> It behaves the same as syscon_regmap_lookup_by_phandle() except where
> there is no regmap phandle. In this case, instead of returning -ENODEV,
> the
On Wed, 11 Nov 2020, Tony Lindgren wrote:
> With commit 3a6f0fb7b8eb ("regmap: irq: Add support to clear ack
> registers"), the cpcap interrupts are no longer getting acked properly
> leading to a very unresponsive device with CPUs fully loaded spinning
> in the threaded IRQ handlers.
>
> To me i
On 11/13/20 10:18 AM, Qi Liu wrote:
On 2020/11/12 22:03, Suzuki K Poulose wrote:
On 11/12/20 1:09 PM, Qi Liu wrote:
On 2020/11/12 1:03, Mathieu Poirier wrote:
On Wed, Nov 11, 2020 at 04:58:23PM +0800, Qi Liu wrote:
Hi Mathieu,
On 2020/9/10 0:26, Mathieu Poirier wrote:
On Wed, Sep 09, 20
On Thu 12-11-20 09:42:44, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> There are 3 places in namei.c where the equivalent of ext2_put_page() is
> open coded on a page which was returned from the ext2_get_page() call
> [through the use of ext2_find_entry() and ext2_dotdot()].
>
> Move ext2_pu
On Monday 19 October 2020 14:25:37 Andrew Lunn wrote:
> On Mon, Oct 19, 2020 at 10:04:08AM +0200, Pali Rohár wrote:
> > Hello! Gregory, I would like to remind you following patch.
>
> Hi Pali
>
> Since the merge window is open at the moment, no new patches will be
> accepted until it closes.
>
>
On Fri 2020-11-13 08:59:37, Zhang, Qiang wrote:
>
>
>
> 发件人: Andrew Morton
> 发送时间: 2020年11月13日 8:01
> 收件人: Zhang, Qiang
> 抄送: pmla...@suse.com; t...@kernel.org; linux...@kvack.org;
> linux-kernel@vger.kernel.org
> 主题: Re: [PATCH] kthread_worker: Add flus
On Fri, Nov 13, 2020 at 12:01:21AM +0200, Jarkko Sakkinen wrote:
> From: Sean Christopherson
>
> Background
> ==
>
> 1. SGX enclave pages are populated with data by copying from normal memory
>via ioctl() (SGX_IOC_ENCLAVE_ADD_PAGES), which will be added later in
>this series.
> 2
Ping?
On Monday 19 October 2020 10:19:33 Pali Rohár wrote:
> Gregory, it is OK now?
>
> On Monday 05 October 2020 15:35:13 Pali Rohár wrote:
> > Up-to-date version of V7 schematic is on new URL linked from official
> > tech-spec webpage http://espressobin.net/tech-spec/
> >
> > Signed-off-by: Pa
Hello,
On Fri, Nov 13, 2020 at 09:16:22AM +0100, Peter Zijlstra wrote:
> Works for me. TJ, do I take this or do you want it in the cgroup tree?
>
> In that case:
>
> Acked-by: Peter Zijlstra (Intel)
Please take it through the sched tree, and FWIW
Acked-by: Tejun Heo
Thank you.
--
tejun
On Thu, Nov 12, 2020 at 07:31:12PM +, Valentin Schneider wrote:
> I think what is happening here is:
>
> affine_move_task()
> // task_running() case
> stop_one_cpu()
> wait_for_completion(&pending->done);
>
> and this is !PREEMPT, so the stopper can very well hit:
>
>
Hi Chen,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 585e5b17b92dead8a3aca4e3c9876fbca5f7e0ba
commit: ee8642162a9edd40daafd3fb894e3fd3f909e361 drm/nouveau: fix build error
without CONFIG_IOMMU_API
date: 10 mon
Hi Ard,
Please see the bisection report below about a boot failure on
RPi-2b.
Reports aren't automatically sent to the public while we're
trialing new bisection features on kernelci.org but this one
looks valid.
There's nothing in the serial console log, probably because it's
crashing too early
On Fri, Nov 13, 2020 at 01:17PM +0800, David Gow wrote:
> On Thu, Nov 12, 2020 at 8:37 PM Marco Elver wrote:
[...]
> > > (It also might be a little tricky with the current implementation to
> > > produce the test plan, as the parameters come from a generator, and I
> > > don't think there's a way
+++ Andrii Nakryiko [11/11/20 12:11 -0800]:
On Wed, Nov 11, 2020 at 2:13 AM Jessica Yu wrote:
+++ Andrii Nakryiko [09/11/20 17:19 -0800]:
[snipped]
>diff --git a/kernel/module.c b/kernel/module.c
>index a4fa44a652a7..f2996b02ab2e 100644
>--- a/kernel/module.c
>+++ b/kernel/module.c
>@@ -380,6
Hi Georgi, Chanwoo,
On 13.11.2020 10:07, Chanwoo Choi wrote:
> On 11/13/20 5:48 PM, Georgi Djakov wrote:
>> On 11/12/20 16:09, Sylwester Nawrocki wrote:
[...]
>>
>> Good work Sylwester! Thank you and all the reviewers! What would be the merge
>> path for this patchset? Looks like there is no build
On Fri 13-11-20 10:47:36, Stephen Rothwell wrote:
> Hi all,
>
> After merging the ext3 tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from fs/ext2/file.c:28:
> fs/ext2/ext2.h: In function 'ext2_get_page':
> fs/ext2/ext2.h:764:28: error: implicit
On Fri, 13 Nov 2020 at 11:31, Guillaume Tucker
wrote:
>
> Hi Ard,
>
> Please see the bisection report below about a boot failure on
> RPi-2b.
>
> Reports aren't automatically sent to the public while we're
> trialing new bisection features on kernelci.org but this one
> looks valid.
>
> There's no
: arm-randconfig-r005-20201113 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https
Commit 11c9c7edae06 ("mm/page_poison.c: replace bool variable with static key")
changed page_poisoning_enabled() to a static key check. However, the function
is not inlined, so each check still involves a function call with overhead not
eliminated when page poisoning is disabled.
Analogically to h
Changes since v2 [2]
- rebase to next-20201113
- apply review feedback from David
- acks from David and Rafael (thanks!)
The first version was called "optimize handling of memory debugging parameters"
[1], changes are:
- apply review feedback
- drop former Patch 3
- add new patches 3
Page poisoning used to be incompatible with hibernation, as the state of
poisoned pages was lost after resume, thus enabling CONFIG_HIBERNATION forces
CONFIG_PAGE_POISONING_NO_SANITY. For the same reason, the poisoning with zeroes
variant CONFIG_PAGE_POISONING_ZERO used to disable hibernation. The
CONFIG_PAGE_POISONING_NO_SANITY skips the check on page alloc whether the
poison pattern was corrupted, suggesting a use-after-free. The motivation to
introduce it in commit 8823b1dbc05f ("mm/page_poison.c: enable PAGE_POISONING
as a separate option") was to simply sanitize freed pages, optimally t
Enabling page_poison=1 together with init_on_alloc=1 or init_on_free=1 produces
a warning in dmesg that page_poison takes precedence. However, as these
warnings are printed in early_param handlers for init_on_alloc/free, they are
not printed if page_poison is enabled later on the command line (hand
CONFIG_PAGE_POISONING_ZERO uses the zero pattern instead of 0xAA. It was
introduced by commit 1414c7f4f7d7 ("mm/page_poisoning.c: allow for zero
poisoning"), noting that using zeroes retains the benefit of sanitizing content
of freed pages, with the benefit of not having to zero them again on alloc
On 21/09/2020 14:58, John Garry wrote:
On 21/09/2020 14:43, Will Deacon wrote:
On Fri, Aug 21, 2020 at 09:54:20PM +0800, John Garry wrote:
As mentioned in [0], the CPU may consume many cycles processing
arm_smmu_cmdq_issue_cmdlist(). One issue we find is the cmpxchg()
loop to
get space on the
Am 13.11.2020 um 10:07 schrieb Lev Stipakov:
> Commit d3fd65484c781 ("net: core: add dev_sw_netstats_tx_add") has added
> function "dev_sw_netstats_tx_add()" to update net device per-cpu TX
> stats.
>
> Use this function instead of own code.
>
> While on it, remove xfrmi_get_stats64() and replace
Am 13.11.2020 um 09:58 schrieb Lev Stipakov:
> Commits
>
> d3fd65484c781 ("net: core: add dev_sw_netstats_tx_add")
> 451b05f413d3f ("net: netdevice.h: sw_netstats_rx_add helper)
>
> have added API to update net device per-cpu TX/RX stats.
>
> Use core API instead of ieee80211_tx/rx_stats().
Am 13.11.2020 um 10:02 schrieb Lev Stipakov:
> Commit d3fd65484c781 ("net: core: add dev_sw_netstats_tx_add") has added
> function "dev_sw_netstats_tx_add()" to update net device per-cpu TX
> stats.
>
> Use this function instead of own code.
>
> While on it, remove internal_get_stats() and replac
Hi Joe,
On Tue, Nov 03, 2020 at 08:49:36AM -0800, Joe Perches wrote:
> On Tue, 2020-11-03 at 16:56 +0200, Sakari Ailus wrote:
> > On Tue, Nov 03, 2020 at 04:47:47PM +0200, Andy Shevchenko wrote:
> > > On Tue, Nov 03, 2020 at 03:34:00PM +0200, Sakari Ailus wrote:
> > > > Add a printk modifier %p4cc
On Fri, 2020-11-13 at 10:58 +0200, Lev Stipakov wrote:
> Commits
>
> d3fd65484c781 ("net: core: add dev_sw_netstats_tx_add")
> 451b05f413d3f ("net: netdevice.h: sw_netstats_rx_add helper)
>
> have added API to update net device per-cpu TX/RX stats.
>
> Use core API instead of ieee80211_tx/rx
Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM
pixel formats denoted by fourccs. The fourcc encoding is the same for both
so the same implementation can be used.
Suggested-by: Mauro Carvalho Chehab
Signed-off-by: Sakari Ailus
---
since v4:
- Use correct destination for
Hi Sylwester,
On 13.11.2020 11:32, Sylwester Nawrocki wrote:
> On 13.11.2020 10:07, Chanwoo Choi wrote:
>> On 11/13/20 5:48 PM, Georgi Djakov wrote:
>>> On 11/12/20 16:09, Sylwester Nawrocki wrote:
> [...]
>>> Good work Sylwester! Thank you and all the reviewers! What would be the
>>> merge
>>> p
In the later patch, we will use {get,put}_page_bootmem() to initialize
the page for vmemmap or free vmemmap page to buddy. So move them out of
CONFIG_MEMORY_HOTPLUG_SPARSE. This is just code movement without any
functional change.
Signed-off-by: Muchun Song
Acked-by: Mike Kravetz
---
arch/x86/m
On Fri, Nov 13, 2020 at 01:29:35PM +0900, Namhyung Kim wrote:
SNIP
> >
> > struct {
> > struct perf_event_headerheader;
> > @@ -7997,13 +8003,23 @@ static void perf_event_mmap_output(struct
> > perf_event *event,
> > mmap_event->event_id.pid = perf_event_pid(event,
If the size of HugeTLB page is 2MB, we need 512 struct page structures
(8 pages) to be associated with it. As far as I know, we only use the
first 4 struct page structures. Use of first 4 struct page structures
comes from HUGETLB_CGROUP_MIN_ORDER.
For tail pages, the value of compound_head is the
In the later patch, we can use the free_vmemmap_page() to free the
unused vmemmap pages and initialize a page for vmemmap page using
via prepare_vmemmap_page().
Signed-off-by: Muchun Song
---
include/linux/bootmem_info.h | 24
1 file changed, 24 insertions(+)
diff --git
The page->private shares storage with page->ptl. In the later patch,
we will use the page->ptl. So here we combine bootmem info and type
into page->freelist so that we can do not use page->private.
Signed-off-by: Muchun Song
---
arch/x86/mm/init_64.c| 2 +-
include/linux/bootmem_info.h
-20201113
i386 randconfig-a005-20201113
i386 randconfig-a002-20201113
i386 randconfig-a001-20201113
i386 randconfig-a003-20201113
i386 randconfig-a004-20201113
x86_64 randconfig-a015-20201113
x86_64
When we free a hugetlb page to the buddy, we should allocate the vmemmap
pages associated with it. We can do that in the __free_hugepage().
Signed-off-by: Muchun Song
---
mm/hugetlb.c | 2 ++
mm/hugetlb_vmemmap.c | 100 +++
mm/hugetlb_vme
We should flush work when dissolving a hugetlb page to make sure that
the hugetlb page is freed to the buddy.
Signed-off-by: Muchun Song
---
mm/hugetlb.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index b853aacd5c16..9aad0b6
The gigantic page is allocated by bootmem, if we want to free the
unused vmemmap pages. We also should allocate the page table. So
we also allocate page tables from bootmem.
Signed-off-by: Muchun Song
---
include/linux/hugetlb.h | 3 +++
mm/hugetlb.c| 5 +
mm/hugetlb_vmemmap.c
Merge pte to huge pmd if it has ever been split. Now only support
gigantic page which's vmemmap pages size is an integer multiple of
PMD_SIZE. This is the simplest case to handle.
Signed-off-by: Muchun Song
---
arch/x86/include/asm/hugetlb.h | 8 +++
mm/hugetlb_vmemmap.c | 118 ++
Add a kernel parameter hugetlb_free_vmemmap to disable the feature of
freeing unused vmemmap pages associated with each hugetlb page on boot.
Signed-off-by: Muchun Song
---
Documentation/admin-guide/kernel-parameters.txt | 9 +
Documentation/admin-guide/mm/hugetlbpage.rst| 3 +++
m
Add nvmem-cell related stuff for the soc unique ID.
Signed-off-by: Alice Guo
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 6 ++
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 6 ++
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 6 ++
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 6 ++
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: ff828729be446b86957f7c294068758231cd2183
Gitweb:
https://git.kernel.org/tip/ff828729be446b86957f7c294068758231cd2183
Author:Thomas Gleixner
AuthorDate:Thu, 12 Nov 2020 20:14:16 +01:00
Commit
There are only `RESERVE_VMEMMAP_SIZE / sizeof(struct page)` struct pages
can be used when CONFIG_HUGETLB_PAGE_FREE_VMEMMAP, so add a BUILD_BUG_ON
to catch this invalid usage of tail struct page.
Signed-off-by: Muchun Song
---
mm/hugetlb_vmemmap.c | 3 +++
1 file changed, 3 insertions(+)
diff --
On Thu, Nov 12, 2020 at 12:00PM -0800, Paul E. McKenney wrote:
> On Thu, Nov 12, 2020 at 07:12:54PM +0100, Marco Elver wrote:
> > On Thu, Nov 12, 2020 at 09:54AM -0800, Paul E. McKenney wrote:
> > > On Thu, Nov 12, 2020 at 05:14:39PM +0100, Marco Elver wrote:
> > > > On Thu, Nov 12, 2020 at 01:49PM
Hi Ard,
On Fri, 13 Nov 2020, Ard Biesheuvel wrote:
On Thu, 12 Nov 2020 at 22:23, Adrian Ratiu
wrote:
From: Nathan Chancellor
Drop warning because kernel now requires GCC >= v4.9 after
commit 6ec4476ac825 ("Raise gcc version requirement to 4.9").
Reported-by: Nick Desaulniers
Signed-
On 2020-11-13 16:17, Pavel Procopiuc wrote:
Op 12.11.2020 om 11:48 schreef David Hildenbrand:
Trying to understand the code, it looks like there are always two
rounds of reqests. The first one always fails ("requesting one big
chunk of DMA memory"), the second one (providing multiple chunks of
On Fri, Nov 13, 2020 at 01:40:00PM +0900, Namhyung Kim wrote:
> On Mon, Nov 09, 2020 at 10:54:15PM +0100, Jiri Olsa wrote:
> > Adding --buildid-mmap option to enable build id in mmap2 events.
> > It will only work if there's kernel support for that and it disables
> > build id cache (implies --no-b
On 11/3/20 12:04 PM, David Edmondson wrote:
> The instruction emulator ignores clflush instructions, yet fails to
> support clflushopt. Treat both similarly.
>
> Fixes: 13e457e0eebf ("KVM: x86: Emulator does not decode clflush well")
> Signed-off-by: David Edmondson
FWIW,
Reviewed-by: Joao Mart
Protection map difference between RIXI and non RIXI cpus is _PAGE_NO_EXEC
and _PAGE_NO_READ usage. Both already take care of cpu_has_rixi while
setting up the page bits. So we just need one setup of protection map
and can drop the now unused (and broken for RIXI) PAGE_* defines.
Signed-off-by: Tho
MIPS protection bits are setup during runtime so using defines like
PAGE_READONLY ignores these runtime changes. To fix this we simply
use the page protection of the setup vma.
Signed-off-by: Thomas Bogendoerfer
---
arch/mips/kernel/vdso.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-
On Fri, Nov 13, 2020 at 01:32:22PM +0900, Namhyung Kim wrote:
> On Mon, Nov 09, 2020 at 10:54:06PM +0100, Jiri Olsa wrote:
> > Adding build id to synthesized mmap2 events for
> > everything - kernel/modules/tasks.
> >
> > Signed-off-by: Jiri Olsa
> > ---
> > tools/perf/util/synthetic-events.c |
MIPS protection bits are setup during runtime so using defines like
PAGE_SHARED ignores this runtime changes. Using vm_get_page_prot
to get correct page protection fixes this.
Signed-off-by: Thomas Bogendoerfer
---
arch/mips/kvm/mmu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
dif
If sb_occ_port_pool_get() failed in devlink_nl_sb_port_pool_fill(),
msg should be canceled by genlmsg_cancel().
Fixes: df38dafd2559 ("devlink: implement shared buffer occupancy monitoring
interface")
Reported-by: Hulk Robot
Signed-off-by: Wang Hai
---
v1->v2: use goto instead of direct return
We only can free the unused vmemmap to the buddy system when the
size of struct page is a power of two.
Signed-off-by: Muchun Song
---
mm/hugetlb_vmemmap.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
index f67aec6e3bb1..a0a5df
A warning was hit when running xfstests/generic/068 in a Hyper-V guest:
[...] [ cut here ]
[...] DEBUG_LOCKS_WARN_ON(lockdep_hardirqs_enabled())
[...] WARNING: CPU: 2 PID: 1350 at kernel/locking/lockdep.c:5280
check_flags.part.0+0x165/0x170
[...] ...
[...] Workqueue: event
For hugetlb page, there are more metadata to save in the struct
page. But the head struct page cannot meet our needs, so we have
to abuse other tail struct page to store the metadata. In order
to avoid conflicts caused by subsequent use of more tail struct
pages, we can gather these discrete indexe
Hi Catalin,
On 11/12/20 9:43 AM, Catalin Marinas wrote:
> On Tue, Nov 10, 2020 at 11:10:27PM +0100, Andrey Konovalov wrote:
>> From: Vincenzo Frascino
>>
>> Hardware tag-based KASAN relies on Memory Tagging Extension (MTE)
>> feature and requires it to be enabled. MTE supports
>>
>> This patch ad
Introduce helper macro to make lines shorter.
Signed-off-by: Thomas Bogendoerfer
---
arch/mips/mm/cache.c | 38 +-
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/arch/mips/mm/cache.c b/arch/mips/mm/cache.c
index 3e81ba96..f66a8bfc030e 1006
Add compatible string to .dtsi file for binding of imx8_soc_init_driver
and device.
Signed-off-by: Alice Guo
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx
Directly reading ocotp register depends on that bootloader enables ocotp
clk, which is not always effective, so change to use nvmem API. Using
nvmem API requires to support driver defer probe and thus change
soc-imx8m.c to use platform driver.
The other reason is that directly reading ocotp regist
Add DT Binding doc for the Unique ID of i.MX 8M series.
Signed-off-by: Alice Guo
---
.../devicetree/bindings/arm/fsl.yaml | 25 +++
1 file changed, 25 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml
b/Documentation/devicetree/bindings/arm/fsl.
Because we reuse the first tail page, if we set PageHWPosion on a
tail page. It indicates that we may set PageHWPoison on a series
of pages. So we can use the head[4].mapping to record the real
error page index and set the raw error page PageHWPoison later.
Signed-off-by: Muchun Song
---
mm/huge
When we allocate hugetlb page from buddy, we may need split huge pmd
to pte. When we free the hugetlb page, we can merge pte to pmd. So
we need to distinguish whether the previous pmd has been split. The
page table is not allocated from slab. So we can reuse the PG_slab
to indicate that the pmd has
In the later patch, we will use the vmemmap page table lock to
guard the splitting of the vmemmap PMD. So initialize the vmemmap
page table lock.
Signed-off-by: Muchun Song
---
mm/hugetlb_vmemmap.c | 69
1 file changed, 69 insertions(+)
diff
On Fri, 13 Nov 2020, Ard Biesheuvel wrote:
On Thu, 12 Nov 2020 at 22:23, Adrian Ratiu
wrote:
Using a pragma like GCC optimize is a bad idea because it tags
all functions with an __attribute__((optimize)) which replaces
optimization options rather than appending so could result in
dropping
The __free_huge_page_pmd_vmemmap and __remap_huge_page_pmd_vmemmap are
almost the same code. So introduce remap_free_huge_page_pmd_vmemmap
helper to simplify the code.
Signed-off-by: Muchun Song
---
mm/hugetlb_vmemmap.c | 108 +--
1 file changed, 4
In the subsequent patch, we will allocate the vmemmap pages when free
huge pages. But update_and_free_page() is be called from a non-task
context(and hold hugetlb_lock), we can defer the actual freeing in
a workqueue to prevent use GFP_ATOMIC to allocate the vmemmap pages.
Signed-off-by: Muchun So
On 27/10/2020 15:30, Christopher Obbard wrote:
The UML random driver creates a dummy device under the guest,
/dev/hw_random. When this file is read from the guest, the driver
reads from the host machine's /dev/random, in-turn reading from
the host kernel's entropy pool. This entropy pool could
When we allocate a hugetlb page from the buddy, we should free the
unused vmemmap pages associated with it. We can do that in the
prep_new_huge_page().
Signed-off-by: Muchun Song
---
arch/x86/include/asm/hugetlb.h | 9 ++
arch/x86/include/asm/pgtable_64_types.h | 8 ++
mm/hugetlb.c
On x86_64, vmemmap is always PMD mapped if the machine has hugepages
support and if we have 2MB contiguos pages and PMD aligned. If we want
to free the unused vmemmap pages, we have to split the huge pmd firstly.
So we should pre-allocate pgtable to split PMD to PTE.
Signed-off-by: Muchun Song
--
The purpose of introducing HUGETLB_PAGE_FREE_VMEMMAP is to configure
whether to enable the feature of freeing unused vmemmap associated
with HugeTLB pages. Now only support x86.
Signed-off-by: Muchun Song
---
arch/x86/mm/init_64.c | 2 +-
fs/Kconfig| 14 ++
2 files chang
Hello Michał,
On 11/13/20 1:20 AM, Michał Mirosław wrote:
> It turns out that commit aea6cb99703e ("regulator: resolve supply
> after creating regulator") exposed a number of issues in regulator
> initialization and introduced a memory leak of its own. One uncovered
> problem was already fixed by
101 - 200 of 1310 matches
Mail list logo
