All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@linaro.org>
To: Li Wang <liwang@redhat.com>
Cc: Theodore Grey <theodore.grey@linaro.org>, ltp@lists.linux.it
Subject: Re: [LTP] shmctl03.c is broken for 32bit compat mode
Date: Mon, 11 Aug 2025 11:03:54 +0300	[thread overview]
Message-ID: <aJmj6kmNvgzbd1Zi@stanley.mountain> (raw)
In-Reply-To: <CAEemH2cBH+usbwMsHnDW=QM-qDKOCg2wp063O=1gtrRdqNFpug@mail.gmail.com>

On Sun, Aug 10, 2025 at 11:46:32AM +0800, Li Wang wrote:
> Hi Dan,
> 
> On Fri, Aug 8, 2025 at 9:53 PM Dan Carpenter <dan.carpenter@linaro.org>
> wrote:
> 
> > In 32bit compat mode the shmctl03.c test will always fail:
> >
> > shmctl03.c:33: TFAIL: /proc/sys/kernel/shmmax != 2147483647 got 4294967295
> > shmctl03.c:34: TPASS: /proc/sys/kernel/shmmni = 4096
> > shmctl03.c:35: TFAIL: /proc/sys/kernel/shmall != 4278190079 got 4294967295
> >
> > The test basically does this:
> > // === === ===
> > #define _GNU_SOURCE
> > #include <sys/shm.h>
> > #include <stdio.h>
> >
> > int main(void)
> > {
> >         struct shminfo info;
> >
> >         shmctl(0, IPC_INFO, (struct shmid_ds *)&info);
> >
> >         printf("shmmax = %lu\n", info.shmmax);
> >         printf("shmmni = %lu\n", info.shmmni);
> >         printf("shmall = %lu\n", info.shmall);
> >
> >         return 0;
> > }
> > // === === ===
> >
> > It compares that output with what we read from the file.  You can run
> > "gcc -m32 test.c && ./a.out" to see the issue.
> >
> > In the first line shmmax is not the value that we read from the file
> > because it was capped at INT_MAX by the kernel in commit af7c693f1460
> > ("Cap shmmax at INT_MAX in compat shminfo").
> > https://elixir.bootlin.com/linux/v6.16/source/ipc/shm.c#L1347
> >
> > With the last line we're trying to store a u64 value into a u32.  We're
> > going to lose something so it's not going to be accurate.  The difference
> > is how scanf() truncates it.  If you have 32bit longs then it will give
> > you the first u32 but if you assign a u64 to a u32 like the rest of the
> > code does then you'll get the last 32 bits.
> >
> > What's the right way to go about fixing this?
> >
> 
> Maybe we can simply split the comparison part into two:
> 
>   #ifdef TST_ABI64: go with the original way.
> 
>   #ifdef TST_ABI32:

Will this affect real 32bit systems?  The problem is only when we're
emulating a 32bit system on a 64bit system using the COMPAT code.

>       'shmmax' expects INT_MAX from shmctl(0, IPC_INFO, ...), even if '
> /proc/sys/kernel/shmmax' is higher.
>       'shmall' compares the lower 32 bits of the value (expect_shmall =
> shmall & 0xFFFFFFFF;)
> 

To be honest, the correct thing with regards to shmall is to cap it at
INT_MAX in the kernel as well.  I didn't want to suggest this because it
was Friday afternoon.  Reporting whatever is in the low 32bits is sort
of random.  But that would make it even more tricky to handle in LTP.

regards,
dan carpenter


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2025-08-11  8:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-08 13:53 [LTP] shmctl03.c is broken for 32bit compat mode Dan Carpenter
2025-08-10  3:46 ` Li Wang via ltp
2025-08-11  8:03   ` Dan Carpenter [this message]
2025-08-11  9:35     ` Cyril Hrubis
2025-08-12  8:40     ` Li Wang via ltp

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=aJmj6kmNvgzbd1Zi@stanley.mountain \
    --to=dan.carpenter@linaro.org \
    --cc=liwang@redhat.com \
    --cc=ltp@lists.linux.it \
    --cc=theodore.grey@linaro.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.