ACK/cmnt: [PULL][unstable][Artful][SRU Zesty] arm64: fix crash reading from /proc/kcore

[Seth Forshee]

On Thu, Jul 13, 2017 at 09:32:11AM -0600, dann frazier wrote:
> On Thu, Jul 13, 2017 at 2:56 AM, Stefan Bader
> <stefan.bader at canonical.com> wrote:
> > On 12.07.2017 21:42, dann frazier wrote:
> >> On Wed, Jul 12, 2017 at 2:18 AM, Stefan Bader
> >> <stefan.bader at canonical.com> wrote:
> >>> On 06.07.2017 23:55, dann frazier wrote:
> >>>> See:
> >>>> BugLink: https://bugs.launchpad.net/bugs/1702749
> >>>>
> >>>> The following changes since commit f4f26263ff6a66c2012e9417a56e1b01a95c45d0:
> >>>>
> >>>>   UBUNTU: Ubuntu-4.10.0-28.32 (2017-06-29 11:24:09 +0200)
> >>>>
> >>>> are available in the git repository at:
> >>>>
> >>>>   git://git.launchpad.net/~dannf/ubuntu/+source/linux/+git/linux lp1702749
> >>>>
> >>>> for you to fetch changes up to a1d4967053e162bf4933b5a62b7be3490c3ba882:
> >>>>
> >>>>   arm64: mm: select CONFIG_ARCH_PROC_KCORE_TEXT (2017-07-06 13:53:23 -0600)
> >>>>
> >>>> ----------------------------------------------------------------
> >>>> Ard Biesheuvel (2):
> >>>>       fs/proc: kcore: use kcore_list type to check for vmalloc/module address
> >>>>       arm64: mm: select CONFIG_ARCH_PROC_KCORE_TEXT
> >>>>
> >>>>  arch/arm64/Kconfig | 3 +++
> >>>>  fs/proc/kcore.c    | 2 +-
> >>>>  2 files changed, 4 insertions(+), 1 deletion(-)
> >>>>
> >>> Acked-by: Stefan Bader <stefan.bader at canonical.com>
> >>>
> >>> Looks reasonable, did not find any fixups related to the kcore patch. Might need
> >>> an updateconfigs check when applying to Zesty.
> >>
> >> Thanks Stefan. fyi, I ran an updateconfigs in zesty & didn't see any changes.
> >>
> >>> <whine>Could be a little more
> >>> descriptive in the pull-request</whine>
> >>
> >> Yeah, I do go back & forth on what to put in the pull-request since I
> >> try to capture everything in the bug. Perhaps I can just cut & paste
> >> the bug description/SRU template in future PRs?
> >
> > Partially it is a lot just depending on time, coffee levels and general
> > displeasement with the world. Generally I believe sru justifications in bug
> > reports should be a little less technical and more rational (make a sru team
> > member feel ok with the change, and those not necessarily are kernel devs) and
> > the info sent along with the patches more of the sort where does it come from,
> > were those simple cherry-picks or how hard had things to be tweaked.
> 
> Ah, yeah - I've started omitting those notes, relying on the
> "cherry-picked from" (vs "backported from") notation in the commits
> themselves when they are clean cherry picks. But yeah - doesn't hurt
> to add more color, esp. as an extra check in case the annotation is
> incorrect.
> 
> > And in this
> > case (but personal limits vary greatly between people) I would have preferred a
> > the patches themselves on the mailing list instead of a pull request (I would
> > say my limit is about 5, but again might vary depending on how badly one feels
> > annoyed by the world in general).
> 
> Makes sense. In the past, I'd been told by another k-t member that
> PR's are preferred, even for 1 patch, but always happy to adjust for
> those who are actively reviewing my patches :)

The problem is it comes down to personal preference. A nice compromise
is to include the pull request in the cover letter for the patch series.
Though a pull request for a single patch seems extreme to me.