* Re: [PATCH v2 01/12] ARM: dts: da850: fix interrupt numbers for clocksource
From: David Lechner @ 2019-02-05 1:18 UTC (permalink / raw)
To: Bartosz Golaszewski, Sekhar Nori, Kevin Hilman, Daniel Lezcano,
Rob Herring, Mark Rutland, Thomas Gleixner
Cc: devicetree, stable, linux-kernel, linux-arm-kernel,
Bartosz Golaszewski
In-Reply-To: <20190204171757.32073-2-brgl@bgdev.pl>
On 2/4/19 11:17 AM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> The timer interrupts specified in commit 3652e2741f42 ("ARM: dts:
> da850: Add clocks") are wrong but since the current timer code
> hard-codes them, the bug was never spotted.
>
> This patch must go into stable since, once we introduce a proper
> clocksource driver, devices with buggy device tree will stop booting.
>
> Fixes: 3652e2741f42 ("ARM: dts: da850: Add clocks")
> Cc: stable@vger.kernel.org
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
Reviewed-by: David Lechner <david@lechnology.com>
^ permalink raw reply
* Re: [PATCH 3.16 045/305] x86/speculation: Apply IBPB more strictly to avoid cross-process data leak
From: Ben Hutchings @ 2019-02-05 1:13 UTC (permalink / raw)
To: Andi Kleen, Jiri Kosina
Cc: linux-kernel, stable, akpm, Denis Kirjanov, WoodhouseDavid,
Josh Poimboeuf, SchauflerCasey, Andrea Arcangeli, Thomas Gleixner,
Peter Zijlstra
In-Reply-To: <20190203213706.GA31598@tassilo.jf.intel.com>
[-- Attachment #1: Type: text/plain, Size: 842 bytes --]
On Sun, 2019-02-03 at 13:37 -0800, Andi Kleen wrote:
> On Sun, Feb 03, 2019 at 08:05:53PM +0100, Jiri Kosina wrote:
> > On Sun, 3 Feb 2019, Ben Hutchings wrote:
> >
> > > 3.16.63-rc1 review patch. If anyone has any objections, please let me know.
> > >
> > > ------------------
> > >
> > > From: Jiri Kosina <jkosina@suse.cz>
> > >
> > > commit dbfe2953f63c640463c630746cd5d9de8b2f63ae upstream.
> >
> > You really want the whole IBPB+STIBP revamp from upstream, otherwise
> > you're going to get noticeable performance penalties on some workloads
> > with some microcodes.
>
> Yes, we would need the opt-in/opt-out support too.
>
> Please don't merge it just as is.
Thanks, I've now dropped this.
Ben.
--
Ben Hutchings
It is impossible to make anything foolproof
because fools are so ingenious.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 3.16 000/305] 3.16.63-rc1 review
From: Ben Hutchings @ 2019-02-04 23:51 UTC (permalink / raw)
To: Guenter Roeck; +Cc: linux-kernel, stable, torvalds, Denis Kirjanov, akpm
In-Reply-To: <20190204213839.GA18895@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 787 bytes --]
On Mon, 2019-02-04 at 13:38 -0800, Guenter Roeck wrote:
> On Sun, Feb 03, 2019 at 02:45:07PM +0100, Ben Hutchings wrote:
> > This is the start of the stable review cycle for the 3.16.63 release.
> > There are 305 patches in this series, which will be posted as responses
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Fri Feb 08 18:00:00 UTC 2019.
> > Anything received after that time might be too late.
> >
>
> Build results:
> total: 137 pass: 136 fail: 1
> Failed builds:
> i386:tools/perf
> Qemu test results:
> total: 222 pass: 222 fail: 0
Great, thanks for checking.
Ben.
--
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2] tpm/st33zp24: Fix the name collisions in tpm_st33zp24_spi and tpm_i2c_infineon
From: Jarkko Sakkinen @ 2019-02-04 23:40 UTC (permalink / raw)
To: Roberto Sassu, jgg
Cc: linux-integrity, linux-kernel, linux-security-module, zohar,
stable
In-Reply-To: <20190204233117.GE14992@linux.intel.com>
On Tue, Feb 05, 2019 at 01:31:17AM +0200, Jarkko Sakkinen wrote:
> On Mon, Feb 04, 2019 at 02:49:54PM +0100, Roberto Sassu wrote:
> > On 2/4/2019 2:37 PM, Jarkko Sakkinen wrote:
> > > Rename TPM_BUFSIZE defined in drivers/char/tpm/st33zp24/st33zp24.h to
> > > ST33ZP24_BUFSIZE.
> > >
> > > Rename TPM_BUFSIZE defined in drivers/char/tpm/tpm_i2c_infineon.c to
> > > TPM_I2C_INFINEON_BUFSIZE.
> >
> > Please also add a prefix to TPM_RETRY in tpm_i2c_nuvoton.c.
>
> Thanks, can do.
TPM_RETRY defined in
32d33b29ba07 ("TPM: Retry SaveState command in suspend path")
has nothing to do with time. I'll also remove the comment about 5
seconds.
The definitions for TPM_RETRY seem fairly arbitrary. Jason, could
tpm_i2c_nuvoton also use the same constant as tpm_tis_spi and TPM 1.2
suspend, try max 50 times instead of five?
/Jarkko
^ permalink raw reply
* Re: [PATCH v2] RDMA/srp: Rework SCSI device reset handling
From: Jason Gunthorpe @ 2019-02-04 23:31 UTC (permalink / raw)
To: Bart Van Assche
Cc: Doug Ledford, linux-rdma, linux-scsi, Sergey Gorenko,
Max Gurtovoy, Laurence Oberman, stable
In-Reply-To: <20190130220555.8949-1-bvanassche@acm.org>
On Wed, Jan 30, 2019 at 02:05:55PM -0800, Bart Van Assche wrote:
> Since .scsi_done() must only be called after scsi_queue_rq() has
> finished, make sure that the SRP initiator driver does not call
> .scsi_done() while scsi_queue_rq() is in progress. Although
> invoking sg_reset -d while I/O is in progress works fine with kernel
> v4.20 and before, that is not the case with kernel v5.0-rc1. This
> patch avoids that the following crash is triggered with kernel
> v5.0-rc1:
>
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000138
> CPU: 0 PID: 360 Comm: kworker/0:1H Tainted: G B 5.0.0-rc1-dbg+ #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
> Workqueue: kblockd blk_mq_run_work_fn
> RIP: 0010:blk_mq_dispatch_rq_list+0x116/0xb10
> Call Trace:
> blk_mq_sched_dispatch_requests+0x2f7/0x300
> __blk_mq_run_hw_queue+0xd6/0x180
> blk_mq_run_work_fn+0x27/0x30
> process_one_work+0x4f1/0xa20
> worker_thread+0x67/0x5b0
> kthread+0x1cf/0x1f0
> ret_from_fork+0x24/0x30
>
> Cc: Sergey Gorenko <sergeygo@mellanox.com>
> Cc: Max Gurtovoy <maxg@mellanox.com>
> Cc: Laurence Oberman <loberman@redhat.com>
> Cc: <stable@vger.kernel.org>
> Fixes: 94a9174c630c ("IB/srp: reduce lock coverage of command completion") # v2.6.38
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> ---
>
> Changes compared to v1: left out the code that waits until in-progress requests
> have finished.
Applied to for-rc
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH v2] tpm/st33zp24: Fix the name collisions in tpm_st33zp24_spi and tpm_i2c_infineon
From: Jarkko Sakkinen @ 2019-02-04 23:31 UTC (permalink / raw)
To: Roberto Sassu
Cc: linux-integrity, linux-kernel, linux-security-module, zohar,
stable
In-Reply-To: <575f4693-129c-469c-e54e-dbb9ad2a66f2@huawei.com>
On Mon, Feb 04, 2019 at 02:49:54PM +0100, Roberto Sassu wrote:
> On 2/4/2019 2:37 PM, Jarkko Sakkinen wrote:
> > Rename TPM_BUFSIZE defined in drivers/char/tpm/st33zp24/st33zp24.h to
> > ST33ZP24_BUFSIZE.
> >
> > Rename TPM_BUFSIZE defined in drivers/char/tpm/tpm_i2c_infineon.c to
> > TPM_I2C_INFINEON_BUFSIZE.
>
> Please also add a prefix to TPM_RETRY in tpm_i2c_nuvoton.c.
Thanks, can do.
/Jarkko
^ permalink raw reply
* [to-be-updated] mm-proc-smaps_rollup-fix-pss_locked-calculation.patch removed from -mm tree
From: akpm @ 2019-02-04 23:30 UTC (permalink / raw)
To: mm-commits, vbabka, stable, dancol, avagin, adobriyan, sspatil
The patch titled
Subject: fs/proc/task_mmu.c: fix smaps_rollup pss_locked calculation
has been removed from the -mm tree. Its filename was
mm-proc-smaps_rollup-fix-pss_locked-calculation.patch
This patch was dropped because an updated version will be merged
------------------------------------------------------
From: Sandeep Patil <sspatil@android.com>
Subject: fs/proc/task_mmu.c: fix smaps_rollup pss_locked calculation
The 'pss_locked' field of smaps_rollup was being calculated incorrectly as
it accumulated the current pss everytime a locked VMA was found.
Fix that by making sure we record the current pss value before each VMA is
walked. So, we can only add the delta if the VMA was found to be
VM_LOCKED.
Link: http://lkml.kernel.org/r/20190121011049.160505-1-sspatil@android.com
Fixes: 493b0e9d945f ("mm: add /proc/pid/smaps_rollup")
Signed-off-by: Sandeep Patil <sspatil@android.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Andrey Vagin <avagin@openvz.org>
Cc: Daniel Colascione <dancol@google.com>
Cc: <stable@vger.kernel.org> [4.14.x 4.19.x]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/proc/task_mmu.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/fs/proc/task_mmu.c~mm-proc-smaps_rollup-fix-pss_locked-calculation
+++ a/fs/proc/task_mmu.c
@@ -709,6 +709,7 @@ static void smap_gather_stats(struct vm_
#endif
.mm = vma->vm_mm,
};
+ unsigned long pss;
smaps_walk.private = mss;
@@ -737,11 +738,12 @@ static void smap_gather_stats(struct vm_
}
}
#endif
-
+ /* record current pss so we can calculate the delta after page walk */
+ pss = mss->pss;
/* mmap_sem is held in m_start */
walk_page_vma(vma, &smaps_walk);
if (vma->vm_flags & VM_LOCKED)
- mss->pss_locked += mss->pss;
+ mss->pss_locked += mss->pss - pss;
}
#define SEQ_PUT_DEC(str, val) \
_
Patches currently in -mm which might be from sspatil@android.com are
^ permalink raw reply
* Re: [PATCH v2] tpm/tpm_crb: Avoid unaligned reads in crb_recv()
From: Jarkko Sakkinen @ 2019-02-04 23:24 UTC (permalink / raw)
To: Winkler, Tomas
Cc: linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, stable@vger.kernel.org,
James Morris, Jerry Snitselaar
In-Reply-To: <5B8DA87D05A7694D9FA63FD143655C1B9DA901F7@hasmsx108.ger.corp.intel.com>
On Mon, Feb 04, 2019 at 10:09:51PM +0000, Winkler, Tomas wrote:
> >
> > The current approach to read first 6 bytes from the response and then tail of
> > the response, can cause the 2nd memcpy_fromio() to do an unaligned read
> > (e.g. read 32-bit word from address aligned to a 16-bits), depending on how
> > memcpy_fromio() is implemented. If this happens, the read will fail and the
> > memory controller will fill the read with 1's.
> >
> > This was triggered by 170d13ca3a2f, which should be probably refined to check
> > and react to the address alignment. Before that commit, on x86
> > memcpy_fromio() turned out to be memcpy(). By a luck GCC has done the right
> > thing (from tpm_crb's perspective) for us so far, but we should not rely on that.
> > Thus, it makes sense to fix this also in tpm_crb, not least because the fix can be
> > then backported to stable kernels and make them more robust when compiled
> > in differing environments.
> >
> > Cc: stable@vger.kernel.org
> > Cc: James Morris <jmorris@namei.org>
> > Cc: Tomas Winkler <tomas.winkler@intel.com>
> > Cc: Jerry Snitselaar <jsnitsel@redhat.com>
> > Fixes: 30fc8d138e91 ("tpm: TPM 2.0 CRB Interface")
> > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
> After fixing the typos you can add my ack.
> Thanks
> Tomas
>
> > ---
> > v2:
> > * There was a trailing double colon in the end of the short summary.
> > * Check requested and expected length against TPM_HEADER_SIZE.
> > * Add some explanatory comments to crb_recv().
> > drivers/char/tpm/tpm_crb.c | 22 ++++++++++++++++------
> > 1 file changed, 16 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c index
> > 36952ef98f90..c084e61299aa 100644
> > --- a/drivers/char/tpm/tpm_crb.c
> > +++ b/drivers/char/tpm/tpm_crb.c
> > @@ -287,19 +287,29 @@ static int crb_recv(struct tpm_chip *chip, u8 *buf,
> > size_t count)
> > struct crb_priv *priv = dev_get_drvdata(&chip->dev);
> > unsigned int expected;
> >
> > - /* sanity check */
> > - if (count < 6)
> > + /* A sanity check that the upper layer wants to get at least the header
> > + * as that is the minimum size for any TPM response.
> > + */
> > + if (count < TPM_HEADER_SIZE)
> > return -EIO;
> >
> > + /* If this bit is set, according to the spec, the TPM is in unrecovable
> ^^^ typo ^^^^
> > + * condition.
> > + */
> > if (ioread32(&priv->regs_t->ctrl_sts) & CRB_CTRL_STS_ERROR)
> > return -EIO;
> >
> > - memcpy_fromio(buf, priv->rsp, 6);
> > - expected = be32_to_cpup((__be32 *) &buf[2]);
> > - if (expected > count || expected < 6)
> > + /* Read 8 bytes (not just 6 bytes, which would cover ^^^ tag and^^^ the response
> > length
> > + * field ^^^s^^^) in order to make sure that the reminding memory accesses
> ^^^ remaining^^^
> > will
> > + * be aligned.
> > + */
> > + memcpy_fromio(buf, priv->rsp, 8);
> > +
> > + expected = be32_to_cpup((__be32 *)&buf[2]);
> > + if (expected > count || expected < TPM_HEADER_SIZE)
> > return -EIO;
> >
> > - memcpy_fromio(&buf[6], &priv->rsp[6], expected - 6);
> > + memcpy_fromio(&buf[8], &priv->rsp[8], expected - 8);
> >
> > return expected;
> > }
> > --
> > 2.19.1
>
Thanks!
/Jarkko
^ permalink raw reply
* Re: [PATCH v2] tpm/tpm_crb: Avoid unaligned reads in crb_recv()
From: Jarkko Sakkinen @ 2019-02-04 23:19 UTC (permalink / raw)
To: David Laight
Cc: linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, stable@vger.kernel.org,
James Morris, Tomas Winkler, Jerry Snitselaar
In-Reply-To: <1047dac117cc43bbae1c0db922b13aa5@AcuMS.aculab.com>
On Mon, Feb 04, 2019 at 05:12:57PM +0000, David Laight wrote:
> > + * field) in order to make sure that the reminding memory accesses will
>
> remaining
Thanks for your feedback David. I'll implement your suggestions
(also in your other response).
/Jarkko
^ permalink raw reply
* Re: [PATCH REGRESSION] Revert "ath10k: add quiet mode support for QCA6174/QCA9377"
From: Brian Norris @ 2019-02-04 22:54 UTC (permalink / raw)
To: Kalle Valo
Cc: ath10k, linux-wireless, Linux Kernel, Yu Wang, Rakesh Pillai,
Govind Singh, stable
In-Reply-To: <20190204164254.86E0860734@smtp.codeaurora.org>
On Mon, Feb 4, 2019 at 8:43 AM Kalle Valo <kvalo@codeaurora.org> wrote:
> Brian Norris <briannorris@chromium.org> wrote:
>
> > This reverts commit cfb353c0dc058bc1619cc226d3cbbda1f360bdd3.
> >
> > WCN3990 firmware does not yet implement this feature, and so it crashes
> > like this:
> >
> > fatal error received: err_qdi.c:456:EX:wlan_process:1:WLAN RT:207a:PC=b001b4f0
> >
> > This feature can be re-implemented with a proper service bitmap or other
> > feature-discovery mechanism in the future. But it should not break
> > working boards.
> >
> > Fixes: cfb353c0dc05 ("ath10k: add quiet mode support for QCA6174/QCA9377")
> > Cc: Yu Wang <yyuwang@codeaurora.org>
> > Cc: Rakesh Pillai <pillair@codeaurora.org>
> > Cc: Govind Singh <govinds@codeaurora.org>
> > Cc: <stable@vger.kernel.org>
> > Signed-off-by: Brian Norris <briannorris@chromium.org>
>
> This regression should be fixed by (which is in v4.20):
>
> 53884577fbce ath10k: skip sending quiet mode cmd for WCN3990
>
> So this revert should not be needed anymore and I'll drop this.
Yes, that seems to work for me. I'll probably replace the revert with
the above in my downstream. Thanks!
Can't really be fixed now, but it would have been nice to have a Fixes
tag on that one.
Brian
^ permalink raw reply
* Re: [PATCH 4.4 00/65] 4.4.173-stable review
From: Guenter Roeck @ 2019-02-04 22:48 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuah, patches, ben.hutchings,
lkft-triage, stable
In-Reply-To: <20190204103610.583715954@linuxfoundation.org>
On Mon, Feb 04, 2019 at 11:35:53AM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.173 release.
> There are 65 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Feb 6 10:35:30 UTC 2019.
> Anything received after that time might be too late.
>
Build results:
total: 171 pass: 171 fail: 0
Qemu test results:
total: 291 pass: 291 fail: 0 (*)
Guenter
---
(*) I had to revert to gcc 5.3.0 for sh4 boot tests.
With gcc 8.2.0, most tests stall early in boot.
I didn't try to track down the root cause.
^ permalink raw reply
* RE: [PATCH v2] tpm/tpm_crb: Avoid unaligned reads in crb_recv()
From: Winkler, Tomas @ 2019-02-04 22:09 UTC (permalink / raw)
To: Jarkko Sakkinen, linux-integrity@vger.kernel.org
Cc: linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, stable@vger.kernel.org,
James Morris, Jerry Snitselaar
In-Reply-To: <20190204135943.15756-1-jarkko.sakkinen@linux.intel.com>
>
> The current approach to read first 6 bytes from the response and then tail of
> the response, can cause the 2nd memcpy_fromio() to do an unaligned read
> (e.g. read 32-bit word from address aligned to a 16-bits), depending on how
> memcpy_fromio() is implemented. If this happens, the read will fail and the
> memory controller will fill the read with 1's.
>
> This was triggered by 170d13ca3a2f, which should be probably refined to check
> and react to the address alignment. Before that commit, on x86
> memcpy_fromio() turned out to be memcpy(). By a luck GCC has done the right
> thing (from tpm_crb's perspective) for us so far, but we should not rely on that.
> Thus, it makes sense to fix this also in tpm_crb, not least because the fix can be
> then backported to stable kernels and make them more robust when compiled
> in differing environments.
>
> Cc: stable@vger.kernel.org
> Cc: James Morris <jmorris@namei.org>
> Cc: Tomas Winkler <tomas.winkler@intel.com>
> Cc: Jerry Snitselaar <jsnitsel@redhat.com>
> Fixes: 30fc8d138e91 ("tpm: TPM 2.0 CRB Interface")
> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
After fixing the typos you can add my ack.
Thanks
Tomas
> ---
> v2:
> * There was a trailing double colon in the end of the short summary.
> * Check requested and expected length against TPM_HEADER_SIZE.
> * Add some explanatory comments to crb_recv().
> drivers/char/tpm/tpm_crb.c | 22 ++++++++++++++++------
> 1 file changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c index
> 36952ef98f90..c084e61299aa 100644
> --- a/drivers/char/tpm/tpm_crb.c
> +++ b/drivers/char/tpm/tpm_crb.c
> @@ -287,19 +287,29 @@ static int crb_recv(struct tpm_chip *chip, u8 *buf,
> size_t count)
> struct crb_priv *priv = dev_get_drvdata(&chip->dev);
> unsigned int expected;
>
> - /* sanity check */
> - if (count < 6)
> + /* A sanity check that the upper layer wants to get at least the header
> + * as that is the minimum size for any TPM response.
> + */
> + if (count < TPM_HEADER_SIZE)
> return -EIO;
>
> + /* If this bit is set, according to the spec, the TPM is in unrecovable
^^^ typo ^^^^
> + * condition.
> + */
> if (ioread32(&priv->regs_t->ctrl_sts) & CRB_CTRL_STS_ERROR)
> return -EIO;
>
> - memcpy_fromio(buf, priv->rsp, 6);
> - expected = be32_to_cpup((__be32 *) &buf[2]);
> - if (expected > count || expected < 6)
> + /* Read 8 bytes (not just 6 bytes, which would cover ^^^ tag and^^^ the response
> length
> + * field ^^^s^^^) in order to make sure that the reminding memory accesses
^^^ remaining^^^
> will
> + * be aligned.
> + */
> + memcpy_fromio(buf, priv->rsp, 8);
> +
> + expected = be32_to_cpup((__be32 *)&buf[2]);
> + if (expected > count || expected < TPM_HEADER_SIZE)
> return -EIO;
>
> - memcpy_fromio(&buf[6], &priv->rsp[6], expected - 6);
> + memcpy_fromio(&buf[8], &priv->rsp[8], expected - 8);
>
> return expected;
> }
> --
> 2.19.1
^ permalink raw reply
* [PATCH 1/1] Fix: arm: kprobes: optimized kprobes illegal instruction
From: Mathieu Desnoyers @ 2019-02-04 21:52 UTC (permalink / raw)
To: Russell King
Cc: linux-kernel, Mathieu Desnoyers, Robert Berger, Masami Hiramatsu,
William Cohen, Laura Abbott, Kees Cook, # v4 . 14+
commit e46daee53bb5 "ARM: 8806/1: kprobes: Fix false positive with FORTIFY_SOURCE"
introduced a regression in optimized kprobes. It triggers "invalid
instruction" oopses when using kprobes instrumentation through lttng and
perf. This commit was introduced in kernel v4.20, and has been backported
to stable kernels 4.19 and 4.14.
This crash was also reported by Hongzhi Song on the redhat bugzilla
where the patch was originally introduced.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1639397
Link: https://bugs.lttng.org/issues/1174
Link: https://lore.kernel.org/lkml/342740659.2887.1549307721609.JavaMail.zimbra@efficios.com
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Reported-by: Robert Berger <Robert.Berger@ReliableEmbeddedSystems.com>
Tested-by: Robert Berger <Robert.Berger@ReliableEmbeddedSystems.com>
CC: Robert Berger <Robert.Berger@ReliableEmbeddedSystems.com>
CC: Masami Hiramatsu <mhiramat@kernel.org>
CC: William Cohen <wcohen@redhat.com>
CC: Laura Abbott <labbott@redhat.com>
CC: Kees Cook <keescook@chromium.org>
CC: Russell King <rmk+kernel@armlinux.org.uk>
CC: <stable@vger.kernel.org> # v4.14+
---
arch/arm/probes/kprobes/opt-arm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/probes/kprobes/opt-arm.c b/arch/arm/probes/kprobes/opt-arm.c
index 2c118a6ab358..0dc23fc227ed 100644
--- a/arch/arm/probes/kprobes/opt-arm.c
+++ b/arch/arm/probes/kprobes/opt-arm.c
@@ -247,7 +247,7 @@ int arch_prepare_optimized_kprobe(struct optimized_kprobe *op, struct kprobe *or
}
/* Copy arch-dep-instance from template. */
- memcpy(code, (unsigned char *)optprobe_template_entry,
+ memcpy(code, (unsigned long *)&optprobe_template_entry,
TMPL_END_IDX * sizeof(kprobe_opcode_t));
/* Adjust buffer according to instruction. */
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 4.20 00/80] 4.20.7-stable review
From: Guenter Roeck @ 2019-02-04 21:49 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuah, patches, ben.hutchings,
lkft-triage, stable
In-Reply-To: <20190204103620.287366543@linuxfoundation.org>
On Mon, Feb 04, 2019 at 11:36:20AM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.20.7 release.
> There are 80 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Feb 6 10:35:33 UTC 2019.
> Anything received after that time might be too late.
>
Build results:
total: 159 pass: 159 fail: 0
Qemu test results:
total: 343 pass: 343 fail: 0
Guenter
^ permalink raw reply
* Re: [PATCH 4.19 00/74] 4.19.20-stable review
From: Guenter Roeck @ 2019-02-04 21:49 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuah, patches, ben.hutchings,
lkft-triage, stable
In-Reply-To: <20190204103619.714714157@linuxfoundation.org>
On Mon, Feb 04, 2019 at 11:36:13AM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.20 release.
> There are 74 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Feb 6 10:35:34 UTC 2019.
> Anything received after that time might be too late.
>
Build results:
total: 156 pass: 156 fail: 0
Qemu test results:
total: 343 pass: 343 fail: 0
Guenter
^ permalink raw reply
* Re: [PATCH 4.14 00/46] 4.14.98-stable review
From: Guenter Roeck @ 2019-02-04 21:49 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuah, patches, ben.hutchings,
lkft-triage, stable
In-Reply-To: <20190204103608.651205056@linuxfoundation.org>
On Mon, Feb 04, 2019 at 11:36:31AM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.98 release.
> There are 46 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Feb 6 10:35:31 UTC 2019.
> Anything received after that time might be too late.
>
Build results:
total: 172 pass: 172 fail: 0
Qemu test results:
total: 328 pass: 328 fail: 0
Guenter
^ permalink raw reply
* Re: [PATCH 4.9 00/30] 4.9.155-stable review
From: Guenter Roeck @ 2019-02-04 21:48 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuah, patches, ben.hutchings,
lkft-triage, stable
In-Reply-To: <20190204103605.271746870@linuxfoundation.org>
On Mon, Feb 04, 2019 at 11:36:38AM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.155 release.
> There are 30 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Feb 6 10:35:37 UTC 2019.
> Anything received after that time might be too late.
>
Build results:
total: 172 pass: 172 fail: 0
Qemu test results:
total: 315 pass: 315 fail: 0
Guenter
^ permalink raw reply
* Re: [PATCH 3.18 00/31] 3.18.134-stable review
From: Guenter Roeck @ 2019-02-04 21:44 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuah, patches, ben.hutchings,
lkft-triage, stable
In-Reply-To: <20190204103557.903263774@linuxfoundation.org>
On Mon, Feb 04, 2019 at 11:36:15AM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.134 release.
> There are 31 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Feb 6 10:35:28 UTC 2019.
> Anything received after that time might be too late.
>
Build results:
total: 155 pass: 153 fail: 2
Failed builds:
arm64:defconfig
arm64:allmodconfig
Qemu test results:
total: 222 pass: 222 fail: 0
Error log:
Error log:
arch/arm64/kernel/head.o: In function `el2_setup':
(.head.text+0x130): relocation truncated to fit: R_AARCH64_ADR_PREL_LO21 against
symbol `__hyp_stub_vectors' defined in .hyp.text section in arch/arm64/kernel/built-in.o
Looks like this is due to commit 8640f2308921 ("arm64: hyp-stub: Forbid
kprobing of the hyp-stub").
Guenter
^ permalink raw reply
* [merged] mm-migrate-dont-rely-on-__pagemovable-of-newpage-after-unlocking-it.patch removed from -mm tree
From: akpm @ 2019-02-04 21:40 UTC (permalink / raw)
To: aarcange, aquini, david, jack, k.khlebnikov, kirill.shutemov,
linux, mgorman, mhocko, minchan, mm-commits, n-horiguchi, stable,
vbendel, willy
The patch titled
Subject: mm: migrate: don't rely on __PageMovable() of newpage after unlocking it
has been removed from the -mm tree. Its filename was
mm-migrate-dont-rely-on-__pagemovable-of-newpage-after-unlocking-it.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: David Hildenbrand <david@redhat.com>
Subject: mm: migrate: don't rely on __PageMovable() of newpage after unlocking it
We had a race in the old balloon compaction code before b1123ea6d3b3 ("mm:
balloon: use general non-lru movable page feature") refactored it that
became visible after backporting 195a8c43e93d ("virtio-balloon: deflate
via a page list") without the refactoring.
The bug existed from commit d6d86c0a7f8d ("mm/balloon_compaction: redesign
ballooned pages management") till b1123ea6d3b3 ("mm: balloon: use general
non-lru movable page feature"). d6d86c0a7f8d ("mm/balloon_compaction:
redesign ballooned pages management") was backported to 3.12, so the
broken kernels are stable kernels [3.12 - 4.7].
There was a subtle race between dropping the page lock of the newpage
in __unmap_and_move() and checking for
__is_movable_balloon_page(newpage).
Just after dropping this page lock, virtio-balloon could go ahead and
deflate the newpage, effectively dequeueing it and clearing PageBalloon,
in turn making __is_movable_balloon_page(newpage) fail.
This resulted in dropping the reference of the newpage via
putback_lru_page(newpage) instead of put_page(newpage), leading to
page->lru getting modified and a !LRU page ending up in the LRU lists.
With 195a8c43e93d ("virtio-balloon: deflate via a page list") backported,
one would suddenly get corrupted lists in release_pages_balloon():
- WARNING: CPU: 13 PID: 6586 at lib/list_debug.c:59 __list_del_entry+0xa1/0xd0
- list_del corruption. prev->next should be ffffe253961090a0, but was dead000000000100
Nowadays this race is no longer possible, but it is hidden behind very
ugly handling of __ClearPageMovable() and __PageMovable().
__ClearPageMovable() will not make __PageMovable() fail, only
PageMovable(). So the new check (__PageMovable(newpage)) will still hold
even after newpage was dequeued by virtio-balloon.
If anybody would ever change that special handling, the BUG would be
introduced again. So instead, make it explicit and use the information of
the original isolated page before migration.
This patch can be backported fairly easy to stable kernels (in contrast to
the refactoring).
Link: http://lkml.kernel.org/r/20190129233217.10747-1-david@redhat.com
Fixes: d6d86c0a7f8d ("mm/balloon_compaction: redesign ballooned pages management")
Signed-off-by: David Hildenbrand <david@redhat.com>
Reported-by: Vratislav Bendel <vbendel@redhat.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Rafael Aquini <aquini@redhat.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Vratislav Bendel <vbendel@redhat.com>
Cc: Rafael Aquini <aquini@redhat.com>
Cc: Konstantin Khlebnikov <k.khlebnikov@samsung.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: <stable@vger.kernel.org> [3.12 - 4.7]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/migrate.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/mm/migrate.c~mm-migrate-dont-rely-on-__pagemovable-of-newpage-after-unlocking-it
+++ a/mm/migrate.c
@@ -1130,10 +1130,13 @@ out:
* If migration is successful, decrease refcount of the newpage
* which will not free the page because new page owner increased
* refcounter. As well, if it is LRU page, add the page to LRU
- * list in here.
+ * list in here. Use the old state of the isolated source page to
+ * determine if we migrated a LRU page. newpage was already unlocked
+ * and possibly modified by its owner - don't rely on the page
+ * state.
*/
if (rc == MIGRATEPAGE_SUCCESS) {
- if (unlikely(__PageMovable(newpage)))
+ if (unlikely(!is_lru))
put_page(newpage);
else
putback_lru_page(newpage);
_
Patches currently in -mm which might be from david@redhat.com are
mm-balloon-update-comment-about-isolation-migration-compaction.patch
mm-convert-pg_balloon-to-pg_offline.patch
kexec-export-pg_offline-to-vmcoreinfo.patch
xen-balloon-mark-inflated-pages-pg_offline.patch
hv_balloon-mark-inflated-pages-pg_offline.patch
vmw_balloon-mark-inflated-pages-pg_offline.patch
vmw_balloon-mark-inflated-pages-pg_offline-v2.patch
pm-hibernate-use-pfn_to_online_page.patch
pm-hibernate-exclude-all-pageoffline-pages.patch
pm-hibernate-exclude-all-pageoffline-pages-v2.patch
agp-efficeon-no-need-to-set-pg_reserved-on-gatt-tables.patch
s390-vdso-dont-clear-pg_reserved.patch
powerpc-vdso-dont-clear-pg_reserved.patch
riscv-vdso-dont-clear-pg_reserved.patch
m68k-mm-use-__clearpagereserved.patch
arm64-kexec-no-need-to-clearpagereserved.patch
arm64-kdump-no-need-to-mark-crashkernel-pages-manually-pg_reserved.patch
ia64-perfmon-dont-mark-buffer-pages-as-pg_reserved.patch
mm-better-document-pg_reserved.patch
^ permalink raw reply
* [merged] mm-hwpoison-use-do_send_sig_info-instead-of-force_sig-re-pmem-error-handling-forces-sigkill-causes-kernel-panic.patch removed from -mm tree
From: akpm @ 2019-02-04 21:40 UTC (permalink / raw)
To: dan.j.williams, jane.chu, mm-commits, n-horiguchi, oleg, stable,
william.kucharski
The patch titled
Subject: mm: hwpoison: use do_send_sig_info() instead of force_sig()
has been removed from the -mm tree. Its filename was
mm-hwpoison-use-do_send_sig_info-instead-of-force_sig-re-pmem-error-handling-forces-sigkill-causes-kernel-panic.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Subject: mm: hwpoison: use do_send_sig_info() instead of force_sig()
Currently memory_failure() is racy against process's exiting, which
results in kernel crash by null pointer dereference.
The root cause is that memory_failure() uses force_sig() to forcibly kill
asynchronous (meaning not in the current context) processes. As discussed
in thread https://lkml.org/lkml/2010/6/8/236 years ago for OOM fixes, this
is not a right thing to do. OOM solves this issue by using
do_send_sig_info() as done in commit d2d393099de2 ("signal: oom_kill_task:
use SEND_SIG_FORCED instead of force_sig()"), so this patch is suggesting
to do the same for hwpoison. do_send_sig_info() properly accesses to
siglock with lock_task_sighand(), so is free from the reported race.
I confirmed that the reported bug reproduces with inserting some delay in
kill_procs(), and it never reproduces with this patch.
Note that memory_failure() can send another type of signal using
force_sig_mceerr(), and the reported race shouldn't happen on it because
force_sig_mceerr() is called only for synchronous processes (i.e.
BUS_MCEERR_AR happens only when some process accesses to the corrupted
memory.)
Link: http://lkml.kernel.org/r/20190116093046.GA29835@hori1.linux.bs1.fc.nec.co.jp
Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Reported-by: Jane Chu <jane.chu@oracle.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: William Kucharski <william.kucharski@oracle.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/memory-failure.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/mm/memory-failure.c~mm-hwpoison-use-do_send_sig_info-instead-of-force_sig-re-pmem-error-handling-forces-sigkill-causes-kernel-panic
+++ a/mm/memory-failure.c
@@ -372,7 +372,8 @@ static void kill_procs(struct list_head
if (fail || tk->addr_valid == 0) {
pr_err("Memory failure: %#lx: forcibly killing %s:%d because of failure to unmap corrupted page\n",
pfn, tk->tsk->comm, tk->tsk->pid);
- force_sig(SIGKILL, tk->tsk);
+ do_send_sig_info(SIGKILL, SEND_SIG_PRIV,
+ tk->tsk, PIDTYPE_PID);
}
/*
_
Patches currently in -mm which might be from n-horiguchi@ah.jp.nec.com are
^ permalink raw reply
* [merged] mm-oom-fix-use-after-free-in-oom_kill_process.patch removed from -mm tree
From: akpm @ 2019-02-04 21:40 UTC (permalink / raw)
To: guro, hannes, mhocko, mm-commits, penguin-kernel, rientjes,
shakeelb, stable
The patch titled
Subject: mm, oom: fix use-after-free in oom_kill_process
has been removed from the -mm tree. Its filename was
mm-oom-fix-use-after-free-in-oom_kill_process.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Shakeel Butt <shakeelb@google.com>
Subject: mm, oom: fix use-after-free in oom_kill_process
Syzbot instance running on upstream kernel found a use-after-free bug in
oom_kill_process. On further inspection it seems like the process
selected to be oom-killed has exited even before reaching
read_lock(&tasklist_lock) in oom_kill_process(). More specifically the
tsk->usage is 1 which is due to get_task_struct() in oom_evaluate_task()
and the put_task_struct within for_each_thread() frees the tsk and
for_each_thread() tries to access the tsk. The easiest fix is to do
get/put across the for_each_thread() on the selected task.
Now the next question is should we continue with the oom-kill as the
previously selected task has exited? However before adding more
complexity and heuristics, let's answer why we even look at the children
of oom-kill selected task? The select_bad_process() has already selected
the worst process in the system/memcg. Due to race, the selected process
might not be the worst at the kill time but does that matter? The
userspace can use the oom_score_adj interface to prefer children to be
killed before the parent. I looked at the history but it seems like this
is there before git history.
Link: http://lkml.kernel.org/r/20190121215850.221745-1-shakeelb@google.com
Reported-by: syzbot+7fbbfa368521945f0e3d@syzkaller.appspotmail.com
Fixes: 6b0c81b3be11 ("mm, oom: reduce dependency on tasklist_lock")
Signed-off-by: Shakeel Butt <shakeelb@google.com>
Reviewed-by: Roman Gushchin <guro@fb.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/oom_kill.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/mm/oom_kill.c~mm-oom-fix-use-after-free-in-oom_kill_process
+++ a/mm/oom_kill.c
@@ -975,6 +975,13 @@ static void oom_kill_process(struct oom_
* still freeing memory.
*/
read_lock(&tasklist_lock);
+
+ /*
+ * The task 'p' might have already exited before reaching here. The
+ * put_task_struct() will free task_struct 'p' while the loop still try
+ * to access the field of 'p', so, get an extra reference.
+ */
+ get_task_struct(p);
for_each_thread(p, t) {
list_for_each_entry(child, &t->children, sibling) {
unsigned int child_points;
@@ -994,6 +1001,7 @@ static void oom_kill_process(struct oom_
}
}
}
+ put_task_struct(p);
read_unlock(&tasklist_lock);
/*
_
Patches currently in -mm which might be from shakeelb@google.com are
memcg-localize-memcg_kmem_enabled-check.patch
memcg-schedule-high-reclaim-for-remote-memcgs-on-high_work.patch
memcg-schedule-high-reclaim-for-remote-memcgs-on-high_work-v3.patch
mm-oom-remove-prefer-children-over-parent-heuristic.patch
^ permalink raw reply
* [merged] mmmemory_hotplug-fix-scan_movable_pages-for-gigantic-hugepages.patch removed from -mm tree
From: akpm @ 2019-02-04 21:40 UTC (permalink / raw)
To: anthony.yznaga, david, mhocko, mm-commits, osalvador, stable
The patch titled
Subject: mm,memory_hotplug: fix scan_movable_pages() for gigantic hugepages
has been removed from the -mm tree. Its filename was
mmmemory_hotplug-fix-scan_movable_pages-for-gigantic-hugepages.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Oscar Salvador <osalvador@suse.de>
Subject: mm,memory_hotplug: fix scan_movable_pages() for gigantic hugepages
This is the same sort of error we saw in 17e2e7d7e1b83 ("mm, page_alloc:
fix has_unmovable_pages for HugePages").
Gigantic hugepages cross several memblocks, so it can be that the page we
get in scan_movable_pages() is a page-tail belonging to a 1G-hugepage. If
that happens, page_hstate()->size_to_hstate() will return NULL, and we
will blow up in hugepage_migration_supported().
The splat is as follows:
kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
kernel: #PF error: [normal kernel read fault]
kernel: PGD 0 P4D 0
kernel: Oops: 0000 [#1] SMP PTI
kernel: CPU: 1 PID: 1350 Comm: bash Tainted: G E 5.0.0-rc1-mm1-1-default+ #27
kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
kernel: RIP: 0010:__offline_pages+0x6ae/0x900
kernel: Code: 48 c7 c6 d0 3e a4 81 e8 44 c8 ad ff 49 8b 04 24 bf 00 10 00 00 a9 00 00 01 00 74 09 41 0f b6 4c 24 51 48 d3 e7 e8 42 2a c1 ff <8b> 40 08 83 f8 09 0f 84 b0 fc ff ff 83 f8 12 0f 84 a7 fc ff ff 83
kernel: RSP: 0018:ffffc900008e3d20 EFLAGS: 00010246
kernel: RAX: 0000000000000000 RBX: ffffea0000000000 RCX: 0000000000000009
kernel: RDX: ffffffff825c64f0 RSI: 0000000000001000 RDI: 0000000000001000
kernel: RBP: ffffc900008e3d68 R08: 0000000000200000 R09: 00000000000001e4
kernel: R10: 0000000000000058 R11: ffffffff8254a854 R12: ffffea0004200000
kernel: R13: 0000000000108000 R14: 0000000000110000 R15: 0000000000000000
kernel: FS: 00007ff172339b80(0000) GS:ffff88803eb00000(0000) knlGS:0000000000000000
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 0000000000000008 CR3: 0000000038d78006 CR4: 00000000003606a0
kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
kernel: Call Trace:
kernel: ? klist_next+0x79/0xe0
kernel: memory_subsys_offline+0x42/0x60
kernel: device_offline+0x80/0xa0
kernel: state_store+0xab/0xc0
kernel: kernfs_fop_write+0x102/0x180
kernel: __vfs_write+0x26/0x190
kernel: ? set_close_on_exec+0x49/0x70
kernel: vfs_write+0xad/0x1b0
kernel: ksys_write+0x42/0x90
kernel: do_syscall_64+0x5b/0x180
kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
kernel: RIP: 0033:0x7ff1719febe4
kernel: Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a fc 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
kernel: RSP: 002b:00007ffd50b7ddc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
kernel: RAX: ffffffffffffffda RBX: 0000000000000008 RCX: 00007ff1719febe4
kernel: RDX: 0000000000000008 RSI: 00005556e9216b20 RDI: 0000000000000001
kernel: RBP: 00005556e9216b20 R08: 000000000000000a R09: 0000000000000000
kernel: R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000008
kernel: R13: 0000000000000001 R14: 00007ff171cca720 R15: 0000000000000008
kernel: Modules linked in: af_packet(E) xt_tcpudp(E) ipt_REJECT(E) xt_conntrack(E) nf_conntrack(E) nf_defrag_ipv4(E) ip_set(E) nfnetlink(E) ebtable_nat(E) ebtable_broute(E) bridge(E) stp(E) llc(E) iptable_mangle(E) iptable_raw(E) iptable_security(E) ebtable_filter(E) ebtables(E) iptable_filter(E) ip_tables(E) x_tables(E) kvm_intel(E) kvm(E) irqbypass(E) crct10dif_pclmul(E) crc32_pclmul(E) ghash_clmulni_intel(E) bochs_drm(E) ttm(E) aesni_intel(E) drm_kms_helper(E) aes_x86_64(E) crypto_simd(E) cryptd(E) glue_helper(E) drm(E) virtio_net(E) syscopyarea(E) sysfillrect(E) net_failover(E) sysimgblt(E) pcspkr(E) failover(E) i2c_piix4(E) fb_sys_fops(E) parport_pc(E) parport(E) button(E) btrfs(E) libcrc32c(E) xor(E) zstd_decompress(E) zstd_compress(E) xxhash(E) raid6_pq(E) sd_mod(E) ata_generic(E) ata_piix(E) ahci(E) libahci(E) libata(E) crc32c_intel(E) serio_raw(E) virtio_pci(E) virtio_ring(E) virtio(E) sg(E) scsi_mod(E) autofs4(E)
kernel: CR2: 0000000000000008
kernel: ---[ end trace bdb71590872849fb ]---
kernel: RIP: 0010:__offline_pages+0x6ae/0x900
kernel: Code: 48 c7 c6 d0 3e a4 81 e8 44 c8 ad ff 49 8b 04 24 bf 00 10 00 00 a9 00 00 01 00 74 09 41 0f b6 4c 24 51 48 d3 e7 e8 42 2a c1 ff <8b> 40 08 83 f8 09 0f 84 b0 fc ff ff 83 f8 12 0f 84 a7 fc ff ff 83
kernel: RSP: 0018:ffffc900008e3d20 EFLAGS: 00010246
kernel: RAX: 0000000000000000 RBX: ffffea0000000000 RCX: 0000000000000009
kernel: RDX: ffffffff825c64f0 RSI: 0000000000001000 RDI: 0000000000001000
kernel: RBP: ffffc900008e3d68 R08: 0000000000200000 R09: 00000000000001e4
kernel: R10: 0000000000000058 R11: ffffffff8254a854 R12: ffffea0004200000
kernel: R13: 0000000000108000 R14: 0000000000110000 R15: 0000000000000000
kernel: FS: 00007ff172339b80(0000) GS:ffff88803eb00000(0000) knlGS:0000000000000000
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 0000000000000008 CR3: 0000000038d78006 CR4: 00000000003606a0
kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[akpm@linux-foundation.org: fix brace layout, per David. Reduce indentation]
Link: http://lkml.kernel.org/r/20190122154407.18417-1-osalvador@suse.de
Signed-off-by: Oscar Salvador <osalvador@suse.de>
Reviewed-by: Anthony Yznaga <anthony.yznaga@oracle.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/memory_hotplug.c | 36 ++++++++++++++++++++----------------
1 file changed, 20 insertions(+), 16 deletions(-)
--- a/mm/memory_hotplug.c~mmmemory_hotplug-fix-scan_movable_pages-for-gigantic-hugepages
+++ a/mm/memory_hotplug.c
@@ -1305,23 +1305,27 @@ int test_pages_in_a_zone(unsigned long s
static unsigned long scan_movable_pages(unsigned long start, unsigned long end)
{
unsigned long pfn;
- struct page *page;
+
for (pfn = start; pfn < end; pfn++) {
- if (pfn_valid(pfn)) {
- page = pfn_to_page(pfn);
- if (PageLRU(page))
- return pfn;
- if (__PageMovable(page))
- return pfn;
- if (PageHuge(page)) {
- if (hugepage_migration_supported(page_hstate(page)) &&
- page_huge_active(page))
- return pfn;
- else
- pfn = round_up(pfn + 1,
- 1 << compound_order(page)) - 1;
- }
- }
+ struct page *page, *head;
+ unsigned long skip;
+
+ if (!pfn_valid(pfn))
+ continue;
+ page = pfn_to_page(pfn);
+ if (PageLRU(page))
+ return pfn;
+ if (__PageMovable(page))
+ return pfn;
+
+ if (!PageHuge(page))
+ continue;
+ head = compound_head(page);
+ if (hugepage_migration_supported(page_hstate(head)) &&
+ page_huge_active(head))
+ return pfn;
+ skip = (1 << compound_order(head)) - (page - head);
+ pfn += skip - 1;
}
return 0;
}
_
Patches currently in -mm which might be from osalvador@suse.de are
^ permalink raw reply
* [merged] oom-oom_reaper-do-not-enqueue-same-task-twice.patch removed from -mm tree
From: akpm @ 2019-02-04 21:39 UTC (permalink / raw)
To: arekm, asarai, guro, hannes, jgkamat, mhocko, mm-commits,
penguin-kernel, stable, tj
The patch titled
Subject: oom, oom_reaper: do not enqueue same task twice
has been removed from the -mm tree. Its filename was
oom-oom_reaper-do-not-enqueue-same-task-twice.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Subject: oom, oom_reaper: do not enqueue same task twice
Arkadiusz reported that enabling memcg's group oom killing causes strange
memcg statistics where there is no task in a memcg despite the number of
tasks in that memcg is not 0. It turned out that there is a bug in
wake_oom_reaper() which allows enqueuing same task twice which makes
impossible to decrease the number of tasks in that memcg due to a refcount
leak.
This bug existed since the OOM reaper became invokable from
task_will_free_mem(current) path in out_of_memory() in Linux 4.7,
T1@P1 |T2@P1 |T3@P1 |OOM reaper
----------+----------+----------+------------
# Processing an OOM victim in a different memcg domain.
try_charge()
mem_cgroup_out_of_memory()
mutex_lock(&oom_lock)
try_charge()
mem_cgroup_out_of_memory()
mutex_lock(&oom_lock)
try_charge()
mem_cgroup_out_of_memory()
mutex_lock(&oom_lock)
out_of_memory()
oom_kill_process(P1)
do_send_sig_info(SIGKILL, @P1)
mark_oom_victim(T1@P1)
wake_oom_reaper(T1@P1) # T1@P1 is enqueued.
mutex_unlock(&oom_lock)
out_of_memory()
mark_oom_victim(T2@P1)
wake_oom_reaper(T2@P1) # T2@P1 is enqueued.
mutex_unlock(&oom_lock)
out_of_memory()
mark_oom_victim(T1@P1)
wake_oom_reaper(T1@P1) # T1@P1 is enqueued again due to oom_reaper_list == T2@P1 && T1@P1->oom_reaper_list == NULL.
mutex_unlock(&oom_lock)
# Completed processing an OOM victim in a different memcg domain.
spin_lock(&oom_reaper_lock)
# T1P1 is dequeued.
spin_unlock(&oom_reaper_lock)
but memcg's group oom killing made it easier to trigger this bug by
calling wake_oom_reaper() on the same task from one out_of_memory()
request.
Fix this bug using an approach used by commit 855b018325737f76 ("oom,
oom_reaper: disable oom_reaper for oom_kill_allocating_task"). As a side
effect of this patch, this patch also avoids enqueuing multiple threads
sharing memory via task_will_free_mem(current) path.
Link: http://lkml.kernel.org/r/e865a044-2c10-9858-f4ef-254bc71d6cc2@i-love.sakura.ne.jp
Link: http://lkml.kernel.org/r/5ee34fc6-1485-34f8-8790-903ddabaa809@i-love.sakura.ne.jp
Fixes: af8e15cc85a25315 ("oom, oom_reaper: do not enqueue task if it is on the oom_reaper_list head")
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Reported-by: Arkadiusz Miskiewicz <arekm@maven.pl>
Tested-by: Arkadiusz Miskiewicz <arekm@maven.pl>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Roman Gushchin <guro@fb.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Aleksa Sarai <asarai@suse.de>
Cc: Jay Kamat <jgkamat@fb.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/sched/coredump.h | 1 +
mm/oom_kill.c | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
--- a/include/linux/sched/coredump.h~oom-oom_reaper-do-not-enqueue-same-task-twice
+++ a/include/linux/sched/coredump.h
@@ -71,6 +71,7 @@ static inline int get_dumpable(struct mm
#define MMF_HUGE_ZERO_PAGE 23 /* mm has ever used the global huge zero page */
#define MMF_DISABLE_THP 24 /* disable THP for all VMAs */
#define MMF_OOM_VICTIM 25 /* mm is the oom victim */
+#define MMF_OOM_REAP_QUEUED 26 /* mm was queued for oom_reaper */
#define MMF_DISABLE_THP_MASK (1 << MMF_DISABLE_THP)
#define MMF_INIT_MASK (MMF_DUMPABLE_MASK | MMF_DUMP_FILTER_MASK |\
--- a/mm/oom_kill.c~oom-oom_reaper-do-not-enqueue-same-task-twice
+++ a/mm/oom_kill.c
@@ -647,8 +647,8 @@ static int oom_reaper(void *unused)
static void wake_oom_reaper(struct task_struct *tsk)
{
- /* tsk is already queued? */
- if (tsk == oom_reaper_list || tsk->oom_reaper_list)
+ /* mm is already queued? */
+ if (test_and_set_bit(MMF_OOM_REAP_QUEUED, &tsk->signal->oom_mm->flags))
return;
get_task_struct(tsk);
_
Patches currently in -mm which might be from penguin-kernel@I-love.SAKURA.ne.jp are
memcg-killed-threads-should-not-invoke-memcg-oom-killer.patch
mmoom-dont-kill-global-init-via-memoryoomgroup.patch
info-task-hung-in-generic_file_write_iter.patch
info-task-hung-in-generic_file_write-fix.patch
^ permalink raw reply
* [merged] mm-migrate-make-buffer_migrate_page_norefs-actually-succeed.patch removed from -mm tree
From: akpm @ 2019-02-04 21:39 UTC (permalink / raw)
To: aarcange, hannes, jack, mgorman, mhocko, mm-commits, pavel,
rientjes, sergey.senozhatsky.work, stable, vbabka, zi.yan
The patch titled
Subject: mm: migrate: make buffer_migrate_page_norefs() actually succeed
has been removed from the -mm tree. Its filename was
mm-migrate-make-buffer_migrate_page_norefs-actually-succeed.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Jan Kara <jack@suse.cz>
Subject: mm: migrate: make buffer_migrate_page_norefs() actually succeed
Currently, buffer_migrate_page_norefs() was constantly failing because
buffer_migrate_lock_buffers() grabbed reference on each buffer. In fact,
there's no reason for buffer_migrate_lock_buffers() to grab any buffer
references as the page is locked during all our operation and thus nobody
can reclaim buffers from the page. So remove grabbing of buffer
references which also makes buffer_migrate_page_norefs() succeed.
Link: http://lkml.kernel.org/r/20190116131217.7226-1-jack@suse.cz
Fixes: 89cb0888ca14 "mm: migrate: provide buffer_migrate_page_norefs()"
Signed-off-by: Jan Kara <jack@suse.cz>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Zi Yan <zi.yan@cs.rutgers.edu>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/migrate.c | 5 -----
1 file changed, 5 deletions(-)
--- a/mm/migrate.c~mm-migrate-make-buffer_migrate_page_norefs-actually-succeed
+++ a/mm/migrate.c
@@ -709,7 +709,6 @@ static bool buffer_migrate_lock_buffers(
/* Simple case, sync compaction */
if (mode != MIGRATE_ASYNC) {
do {
- get_bh(bh);
lock_buffer(bh);
bh = bh->b_this_page;
@@ -720,18 +719,15 @@ static bool buffer_migrate_lock_buffers(
/* async case, we cannot block on lock_buffer so use trylock_buffer */
do {
- get_bh(bh);
if (!trylock_buffer(bh)) {
/*
* We failed to lock the buffer and cannot stall in
* async migration. Release the taken locks
*/
struct buffer_head *failed_bh = bh;
- put_bh(failed_bh);
bh = head;
while (bh != failed_bh) {
unlock_buffer(bh);
- put_bh(bh);
bh = bh->b_this_page;
}
return false;
@@ -818,7 +814,6 @@ unlock_buffers:
bh = head;
do {
unlock_buffer(bh);
- put_bh(bh);
bh = bh->b_this_page;
} while (bh != head);
_
Patches currently in -mm which might be from jack@suse.cz are
^ permalink raw reply
* [merged] kernel-release-ptraced-tasks-before-zap_pid_ns_processes.patch removed from -mm tree
From: akpm @ 2019-02-04 21:39 UTC (permalink / raw)
To: avagin, ebiederm, mm-commits, oleg, stable
The patch titled
Subject: kernel/exit.c: release ptraced tasks before zap_pid_ns_processes
has been removed from the -mm tree. Its filename was
kernel-release-ptraced-tasks-before-zap_pid_ns_processes.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Andrei Vagin <avagin@gmail.com>
Subject: kernel/exit.c: release ptraced tasks before zap_pid_ns_processes
Currently, exit_ptrace() adds all ptraced tasks in a dead list, then
zap_pid_ns_processes() waits on all tasks in a current pidns, and only
then are tasks from the dead list released.
zap_pid_ns_processes() can get stuck on waiting tasks from the dead list. In
this case, we will have one unkillable process with one or more dead
children.
Thanks to Oleg for the advice to release tasks in find_child_reaper().
Link: http://lkml.kernel.org/r/20190110175200.12442-1-avagin@gmail.com
Fixes: 7c8bd2322c7f ("exit: ptrace: shift "reap dead" code from exit_ptrace() to forget_original_parent()")
Signed-off-by: Andrei Vagin <avagin@gmail.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/exit.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
--- a/kernel/exit.c~kernel-release-ptraced-tasks-before-zap_pid_ns_processes
+++ a/kernel/exit.c
@@ -558,12 +558,14 @@ static struct task_struct *find_alive_th
return NULL;
}
-static struct task_struct *find_child_reaper(struct task_struct *father)
+static struct task_struct *find_child_reaper(struct task_struct *father,
+ struct list_head *dead)
__releases(&tasklist_lock)
__acquires(&tasklist_lock)
{
struct pid_namespace *pid_ns = task_active_pid_ns(father);
struct task_struct *reaper = pid_ns->child_reaper;
+ struct task_struct *p, *n;
if (likely(reaper != father))
return reaper;
@@ -579,6 +581,12 @@ static struct task_struct *find_child_re
panic("Attempted to kill init! exitcode=0x%08x\n",
father->signal->group_exit_code ?: father->exit_code);
}
+
+ list_for_each_entry_safe(p, n, dead, ptrace_entry) {
+ list_del_init(&p->ptrace_entry);
+ release_task(p);
+ }
+
zap_pid_ns_processes(pid_ns);
write_lock_irq(&tasklist_lock);
@@ -668,7 +676,7 @@ static void forget_original_parent(struc
exit_ptrace(father, dead);
/* Can drop and reacquire tasklist_lock */
- reaper = find_child_reaper(father);
+ reaper = find_child_reaper(father, dead);
if (list_empty(&father->children))
return;
_
Patches currently in -mm which might be from avagin@gmail.com are
ptrace-take-into-account-saved_sigmask-in-ptrace_getsetsigmask.patch
include-replace-tsk-to-task-in-linux-sched-signalh.patch
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox