From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Guenter Roeck <linux@roeck-us.net>
Cc: stable@vger.kernel.org, Sasha Levin <sashal@kernel.org>
Subject: Re: Patches for v4.14.y
Date: Mon, 30 Mar 2020 10:55:40 +0200 [thread overview]
Message-ID: <20200330085540.GD239298@kroah.com> (raw)
In-Reply-To: <20200329213322.GA23871@roeck-us.net>
On Sun, Mar 29, 2020 at 02:33:22PM -0700, Guenter Roeck wrote:
> Hi,
>
> Please consider applying the following patches to v4.14.y.
>
> The following patches were found to be missing in v4.14.y by the ChromeOS
> missing patch robot. The patches meet the following criteria.
> - The patch includes a Fixes: tag
> - The patch referenced in the Fixes: tag has been applied to v4.14.y
> - The patch has not been applied to v4.14.y
>
> All patches have been applied to v4.14.y and chromeos-4.14. Resulting images
> have been build- and runtime-tested on real hardware with chromeos-4.14
> and with virtual hardware on kerneltests.org.
>
> Upstream commit 76fc52bd07d3 ("arm64: ptrace: map SPSR_ELx<->PSR for compat tasks")
> Fixes: 7206dc93a58fb764 ("arm64: Expose Arm v8.4 features")
> in v4.14.y: 053cdffad3dd
Now queued up.
> Upstream commit 25dc2c80cfa3 ("arm64: compat: map SPSR_ELx<->PSR for signals")
> Fixes: 7206dc93a58fb764 ("arm64: Expose Arm v8.4 features")
> in v4.14.y: 053cdffad3dd
Now queued up.
> Upstream commit 93a64ee71d10 ("MAINTAINERS: Remove deleted file from futex file pattern")
> Fixes: 04e7712f4460 ("y2038: futex: Move compat implementation into futex.c")
> in v4.14.y: 0c08f1da992d
> Notes:
> Also applies to v4.19.y.
> This is an example for a patch which isn't really necessary
> (it doesn't fix a bug, only an entry in the the MAINTAINERS file),
> but automation won't be able to know that. Please let me know
> what to do with similar patches in the future.
Just drop it, there will always be these types of "fixes" that don't
make sense for stable trees.
> Upstream commit 074376ac0e1d ("ftrace/x86: Anotate text_mutex split between ftrace_arch_code_modify_post_process() and ftrace_arch_code_modify_prepare()")
> Fixes: 39611265edc1a ("ftrace/x86: Add a comment to why we take text_mutex in ftrace_arch_code_modify_prepare()")
> Fixes: d5b844a2cf507 ("ftrace/x86: Remove possible deadlock between register_kprobe() and ftrace_run_update_code()")
> in v4.14.y: 0c0b54770189 (upstream d5b844a2cf507)
> Notes:
> Also applies to v4.19.y.
This only affects running sparse on the code, which for 4.14 I doubt
anyone is doing anymore. But I'll take it as it might make things
easier for some people auditing 4.19 at the moment.
thanks,
greg k-h
prev parent reply other threads:[~2020-03-30 8:55 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-29 21:33 Patches for v4.14.y Guenter Roeck
2020-03-30 8:55 ` Greg Kroah-Hartman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200330085540.GD239298@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=linux@roeck-us.net \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.