public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com>
To: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com>,
	LTP <ltp-list@lists.sourceforge.net>
Subject: Re: [LTP] Segmentation fault when running sched_setaffinity01 in RHEL5.10GA
Date: Fri, 25 Jul 2014 10:39:47 +0400	[thread overview]
Message-ID: <53D1FBB3.1030601@oracle.com> (raw)
In-Reply-To: <53D1ED3D.2070907@cn.fujitsu.com>



On 07/25/2014 09:38 AM, Xiaoguang Wang wrote:
> Hi,
>
> When we run sched_setaffinity01 in RHEL5.10GA, it occurs a segmentation fault.
> Below is the possible reason.

Hi!

I though I'd checked this test case on OL5 before submission. Let me 
check it again.

>
> Hi Jan, would you please help to confirm this problem. I'm afraid RHEL5.10GA is an old
> distribution, which many people may not use it now, thanks!
>
>
> Glibc provides a encapsulation for the raw kernel sched_setaffinity(2) system call,
> the corresponding code is below(The version of glibc I used is glibc-2.5-20061008T1257-RHEL5.11Beta):
> I delete some code just for simple.
>
> #######################################################################################
>
> /* Size definition for CPU sets.  */
> # define __CPU_SETSIZE  1024
> # define __NCPUBITS     (8 * sizeof (__cpu_mask))
>
> /* Type for array elements in 'cpu_set'.  */
> typedef unsigned long int __cpu_mask;
>
> /* Basic access functions.  */
> # define __CPUELT(cpu)  ((cpu) / __NCPUBITS)
>
> /* Data structure to describe CPU mask.  */
> typedef struct
> {
>    __cpu_mask __bits[__CPU_SETSIZE / __NCPUBITS];
> } cpu_set_t;
>
>
> int __sched_setaffinity_new (pid_t pid, size_t cpusetsize, const cpu_set_t *cpuset)
> {
>    if (__builtin_expect (__kernel_cpumask_size == 0, 0))
>      {
>        int res;
>
>        while (res = INTERNAL_SYSCALL (sched_getaffinity, err, 3, getpid (),
>                                       psize, p),
>               INTERNAL_SYSCALL_ERROR_P (res, err)
>               && INTERNAL_SYSCALL_ERRNO (res, err) == EINVAL)
>       	....
>
>        __kernel_cpumask_size = res;
>      }
>
>    /* We now know the size of the kernel cpumask_t.  Make sure the user
>       does not request to set a bit beyond that.  */
>    for (size_t cnt = __kernel_cpumask_size; cnt < cpusetsize; ++cnt)
>      if (((char *) cpuset)[cnt] != '\0')
>        {
>          /* Found a nonzero byte.  This means the user request cannot be
>             fulfilled.  */
>          __set_errno (EINVAL);
>          return -1;
>        }
>
>    return INLINE_SYSCALL (sched_setaffinity, 3, pid, cpusetsize, cpuset);
> }
> #######################################################################################
>
> Glibc in RHEL5.10GA does not provide CPU_ALLOC_SIZE marco, so in ltp testcases/kernel/syscalls/sched_setaffinity/sched_setaffinity.h,
> we define one.
> #######################################################################################
> #ifndef CPU_ALLOC_SIZE
> #define CPU_ALLOC_SIZE(size) sizeof(cpu_set_t)
> #endif
> #######################################################################################
>
> Then CPU_ALLOC_SIZE would always return 128 in RHEL5.10GA, that is when we test EFAULT for sched_setaffinity(2),
> the passed cpusetsize is 128. But look at __sched_setaffinity_new() above, it first call
> raw sched_getaffinity(2) to get  the size of the kernel cpumask_t, In RHEL5.10GA,
> this value depends on CONFIG_NR_CPUS, if CONFIG_NR_CPUS is 255, the raw sched_getaffinity(2) will return 32.
> In this case, __kernel_cpumask_size would be 32, cpusetsize is 128. Give that we're testing
> EFAULT, cpuset is a invalid pointer, if cnt > 32, it will generate segmentation fault in glibc code,
> so this case exits abnormally
>
> As why this test case can run normally in RHEL6.5GA or RHEL7.0GA, it's because
> sched_getaffinity(2) in old kernel(RHEL5.10GA) return sizeof(cpumask_t), which totally depends on CONFIG_NR_CPUS.
> In newer kernel, sched_getaffinity(2) returns the smaller one between min_t(size_t, len, cpumask_size()),
> here len is the value passed to sched_getaffinity as cpusetsize, cpumask_size() is the max allowed length.
> so we can ensure __kernel_cpumask_size will never smaller cpusetsize, so the segmentation fault won't occur.
>
> So I also think CPU_ALLOC and CPU_ALLOC_SIZE is wrong in testcases/kernel/syscalls/sched_setaffinity/sched_setaffinity.h. We should
> refer to the implementation in glibc. or we define CPU_ALLOC_SIZE using raw sched_getaffinity as a workaround in older kernel . See below code:
> #########################################################################################
>
>          int ret;
>          cpu_set_t cst;
>
>          memset(&cst, 0, sizeof(cst));
>
>          ret = syscall(__NR_sched_getaffinity, getpid(),
>                        sizeof(cpu_set_t), &cst);
>          if (ret < 0) {
>                  fprintf(stderr, "sched_getaffinity failed: %s\n",
>                          strerror(errno));
>                  return 1;
>          } else {
>                  printf("length of bit mask the kernel uses to represent the CPU"
>                         ": %d\n", ret);
>          }
> #########################################################################################
>
> Regards,
> Xiaoguang Wang
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list
>

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

  reply	other threads:[~2014-07-25  6:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-25  5:38 [LTP] Segmentation fault when running sched_setaffinity01 in RHEL5.10GA Xiaoguang Wang
2014-07-25  6:39 ` Stanislav Kholmanskikh [this message]
2014-07-25  7:32   ` Xiaoguang Wang
2014-07-25  7:50     ` Stanislav Kholmanskikh
2014-07-25  7:05 ` Jan Stancek
2014-07-25  7:28   ` Xiaoguang Wang

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=53D1FBB3.1030601@oracle.com \
    --to=stanislav.kholmanskikh@oracle.com \
    --cc=ltp-list@lists.sourceforge.net \
    --cc=wangxg.fnst@cn.fujitsu.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox