On Wed, May 08, 2013 at 08:45:24PM +0200, Borislav Petkov wrote:
> On Wed, May 08, 2013 at 12:12:32PM -0400, Naoya Horiguchi wrote:
> > Thank you for the report.
> > I believe we can fix it with this one.
> > ---
> > From: Naoya Horiguchi <n-horigu...@ah.jp.nec.com>
> > Date: Wed, 8 May 2013 11:48:01 -0400
> > Subject: [PATCH] ipc/shm.c: don't use auto variable hs in newseg()
> > 
> > This patch fixes "warning: unused variable 'hs'" when !CONFIG_HUGETLB_PAGE
> > introduced by commit af73e4d9506d "hugetlbfs: fix mmap failure in unaligned
> > size request".
> > 
> > Reported-by: Borislav Petkov <b...@alien8.de>
> > Signed-off-by: Naoya Horiguchi <n-horigu...@ah.jp.nec.com>
> > ---
> >  ipc/shm.c | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/ipc/shm.c b/ipc/shm.c
> > index e316cb9..9ff741a 100644
> > --- a/ipc/shm.c
> > +++ b/ipc/shm.c
> > @@ -491,9 +491,8 @@ static int newseg(struct ipc_namespace *ns, struct 
> > ipc_params *params)
> >  
> >     sprintf (name, "SYSV%08x", key);
> >     if (shmflg & SHM_HUGETLB) {
> > -           struct hstate *hs = hstate_sizelog((shmflg >> SHM_HUGE_SHIFT)
> > -                                           & SHM_HUGE_MASK);
> > -           size_t hugesize = ALIGN(size, huge_page_size(hs));
> > +           size_t hugesize = ALIGN(size, huge_page_size(hstate_sizelog(
> > +                           (shmflg >> SHM_HUGE_SHIFT) & SHM_HUGE_MASK)));
> 
> Yeah, it fixes the warning alright but makes the code more unreadable.
> Which makes me wonder which is worse - to have an innocuous warning or
> have unreadable code.
> 
> You could also do the below. The line sticks out but it kills the
> warning. Readability is hmm, not optimal still though. :)
> --
> diff --git a/ipc/shm.c b/ipc/shm.c
> --- a/ipc/shm.c
> +++ b/ipc/shm.c
> @@ -491,9 +491,8 @@ static int newseg(struct ipc_namespace *ns, struct 
> ipc_params *params)
>  
>       sprintf (name, "SYSV%08x", key);
>       if (shmflg & SHM_HUGETLB) {
> -             struct hstate *hs = hstate_sizelog((shmflg >> SHM_HUGE_SHIFT)
> -                                             & SHM_HUGE_MASK);
> -             size_t hugesize = ALIGN(size, huge_page_size(hs));
> +             unsigned long hsz = huge_page_size(hstate_sizelog((shmflg >> 
> SHM_HUGE_SHIFT) & SHM_HUGE_MASK));
> +             size_t hugesize = ALIGN(size, hsz);
>  
>               /* hugetlb_file_setup applies strict accounting */
>               if (shmflg & SHM_NORESERVE)
> --
> 
> Yeah, you decide.

(CCed: Andrew and linux-mm)
OK, personally both are OK (comparably bad) for me, so I'll do the same
as af73e4d9506d3b does for SYSCALL_DEFINE6(mmap_pgoff), where we have
a line break just after '('.

Andrew, could you pick up the following fix?
-----
From: Naoya Horiguchi <n-horigu...@ah.jp.nec.com>
Date: Wed, 8 May 2013 11:48:01 -0400
Subject: [PATCH] ipc/shm.c: don't use auto variable hs in newseg()

This patch fixes "warning: unused variable 'hs'" when !CONFIG_HUGETLB_PAGE
introduced by commit af73e4d9506d "hugetlbfs: fix mmap failure in unaligned
size request".

Reported-by: Borislav Petkov <b...@alien8.de>
Signed-off-by: Naoya Horiguchi <n-horigu...@ah.jp.nec.com>
---
 ipc/shm.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/ipc/shm.c b/ipc/shm.c
index e316cb9..9ff741a 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -491,9 +491,8 @@ static int newseg(struct ipc_namespace *ns, struct 
ipc_params *params)
 
        sprintf (name, "SYSV%08x", key);
        if (shmflg & SHM_HUGETLB) {
-               struct hstate *hs = hstate_sizelog((shmflg >> SHM_HUGE_SHIFT)
-                                               & SHM_HUGE_MASK);
-               size_t hugesize = ALIGN(size, huge_page_size(hs));
+               size_t hugesize = ALIGN(size, huge_page_size(hstate_sizelog(
+                               (shmflg >> SHM_HUGE_SHIFT) & SHM_HUGE_MASK)));
 
                /* hugetlb_file_setup applies strict accounting */
                if (shmflg & SHM_NORESERVE)
-- 
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to