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

[dann frazier]

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 :)

 -dann