2016-03-23 12:49:37

by Vaishali Thakkar

[permalink] [raw]
Subject: [PATCH v2 0/6] mm/hugetlb: Fix commandline parsing behavior for invalid hugepagesize

Current code fails to ignore the 'hugepages=' parameters when unsupported
hugepagesize is specified. With this patchset, introduce new architecture
independent routine hugetlb_bad_size to handle such command line options.
And then call it in architecture specific code.

Changes since v1:
- Separated different architecture specific changes in different
patches
- CC'ed all arch maintainers

Vaishali Thakkar (6):
mm/hugetlb: Introduce hugetlb_bad_size
arm64: mm: Use hugetlb_bad_size
metag: mm: Use hugetlb_bad_size
powerpc: mm: Use hugetlb_bad_size
tile: mm: Use hugetlb_bad_size
x86: mm: Use hugetlb_bad_size

arch/arm64/mm/hugetlbpage.c | 1 +
arch/metag/mm/hugetlbpage.c | 1 +
arch/powerpc/mm/hugetlbpage.c | 6 ++++--
arch/tile/mm/hugetlbpage.c | 7 ++++++-
arch/x86/mm/hugetlbpage.c | 1 +
include/linux/hugetlb.h | 1 +
mm/hugetlb.c | 14 +++++++++++++-
7 files changed, 27 insertions(+), 4 deletions(-)

--
2.1.4


2016-03-23 13:30:19

by Michal Hocko

[permalink] [raw]
Subject: Re: [PATCH v2 0/6] mm/hugetlb: Fix commandline parsing behavior for invalid hugepagesize

On Wed 23-03-16 17:37:18, Vaishali Thakkar wrote:
> Current code fails to ignore the 'hugepages=' parameters when unsupported
> hugepagesize is specified. With this patchset, introduce new architecture
> independent routine hugetlb_bad_size to handle such command line options.
> And then call it in architecture specific code.
>
> Changes since v1:
> - Separated different architecture specific changes in different
> patches
> - CC'ed all arch maintainers

The hugetlb parameters parsing is a bit mess but this at least makes it
behave more consistently. Feel free to add to all patches
Acked-by: Michal Hocko <[email protected]>

On a side note. I have received patches with broken threading - the
follow up patches are not in the single thread under this cover email.
I thought this was the default behavior of git send-email but maybe your
(older) version doesn't do that. --thread option would enforce that
(with --no-chain-reply-to) or you can set it up in the git config. IMHO
it is always better to have the patchset in the single email thread.

--
Michal Hocko
SUSE Labs

2016-03-23 16:03:42

by Vaishali Thakkar

[permalink] [raw]
Subject: Re: [PATCH v2 0/6] mm/hugetlb: Fix commandline parsing behavior for invalid hugepagesize



On Wednesday 23 March 2016 07:00 PM, Michal Hocko wrote:
> On Wed 23-03-16 17:37:18, Vaishali Thakkar wrote:
>> Current code fails to ignore the 'hugepages=' parameters when unsupported
>> hugepagesize is specified. With this patchset, introduce new architecture
>> independent routine hugetlb_bad_size to handle such command line options.
>> And then call it in architecture specific code.
>>
>> Changes since v1:
>> - Separated different architecture specific changes in different
>> patches
>> - CC'ed all arch maintainers
> The hugetlb parameters parsing is a bit mess but this at least makes it
> behave more consistently. Feel free to add to all patches
> Acked-by: Michal Hocko <[email protected]>
>
> On a side note. I have received patches with broken threading - the
> follow up patches are not in the single thread under this cover email.
> I thought this was the default behavior of git send-email but maybe your
> (older) version doesn't do that. --thread option would enforce that
> (with --no-chain-reply-to) or you can set it up in the git config. IMHO
> it is always better to have the patchset in the single email thread.
>
Yes, now I have set up my git config for that. Hopefully, things will
work properly - patchset in a single thread from the next time.

Thanks.

--
Vaishali