From: Gui J. <gui...@cn...> - 2010-10-29 02:39:49
|
This case is trying to set CPU-time clock(ID is returned by clock_getcpuclockid()) of a specific process by calling clock_settime(). But Linux kernel doesn't allow to reset a CPU-time clock of a specific process. Kernel returns -EPERM. So test fails. In "IEEE Std 1003.1, 2004 Edition", It's said as following: If _POSIX_CPUTIME is defined, implementations shall support clock ID values obtained by invoking clock_getcpuclockid(), which represent the CPU-time clock of a given process. Implementations shall also support the special clockid_t value CLOCK_PROCESS_CPUTIME_ID, which represents the CPU-time clock of the calling process when invoking one of the clock_*() or timer_*() functions. For these clock IDs, the values returned by clock_gettime() and specified by clock_settime() represent the amount of execution time of the process associated with the clock. Changing the value of a CPU-time clock via clock_settime() shall have no effect on the behavior of the sporadic server scheduling policy. So the behaviour when changing the value of a CPU-time clock via clock_settime() is operating system specific. We may change the test progress to stop using clock_settime(). Now, We just make use of clock_gettime() instead to achieve the same test purpose. Signed-off-by: Gui Jianfeng <gui...@cn...> --- .../interfaces/clock_getcpuclockid/2-1.c | 67 ++++++++++---------- 1 files changed, 33 insertions(+), 34 deletions(-) diff --git a/testcases/open_posix_testsuite/conformance/interfaces/clock_getcpuclockid/2-1.c b/testcases/open_posix_testsuite/conformance/interfaces/clock_getcpuclockid/2-1.c index edeb397..52240df 100644 --- a/testcases/open_posix_testsuite/conformance/interfaces/clock_getcpuclockid/2-1.c +++ b/testcases/open_posix_testsuite/conformance/interfaces/clock_getcpuclockid/2-1.c @@ -23,48 +23,47 @@ int main(int argc, char *argv[]) printf("_POSIX_CPUTIME unsupported\n"); return PTS_UNSUPPORTED; #else - unsigned long time_to_set; clockid_t clockid_1, clockid_2; struct timespec tp1, tp2; + int i; if (sysconf(_SC_CPUTIME) == -1) { printf("_POSIX_CPUTIME unsupported\n"); return PTS_UNSUPPORTED; } - if (clock_getcpuclockid(getpid(), &clockid_1) != 0) { - printf("clock_getcpuclockid(getpid(), ) failed\n"); - return PTS_FAIL; - } - - if (clock_getcpuclockid(0, &clockid_2) != 0) { - printf("clock_getcpuclockid(0, ) failed\n"); - return PTS_FAIL; - } + for (i = 0; i < 10; i++) { + if (clock_getcpuclockid(getpid(), &clockid_1) != 0) { + printf("clock_getcpuclockid(getpid(), ) failed\n"); + return PTS_FAIL; + } - /* Set clockid_1 as a random value from 1 sec to 10 sec */ - srand((unsigned long)time(NULL)); - time_to_set = rand() * 10.0 / RAND_MAX + 1; - tp1.tv_sec = time_to_set; - tp1.tv_nsec = 0; - if (clock_settime(clockid_1, &tp1) != 0) { - printf("clock_getcpuclockid() returned an invalid clockid_t: " - "%d\n", clockid_1); - return PTS_FAIL; - } - /* Get the time of clockid_2, should almost the same as clockid_1 */ - if (clock_gettime(clockid_2, &tp2) != 0) { - printf("clock_getcpuclockid() returned an invalid clockid_t: " - "%d\n", clockid_2); - return PTS_FAIL; - } - if (tp1.tv_sec == tp2.tv_sec) - { - printf("Test PASSED\n"); - return PTS_PASS; - } - printf("Test FAILED\n"); - return PTS_FAIL; - + if (clock_getcpuclockid(0, &clockid_2) != 0) { + printf("clock_getcpuclockid(0, ) failed\n"); + return PTS_FAIL; + } + + /* Get the time of clockid_1 */ + if (clock_gettime(clockid_1, &tp1) != 0) { + printf("clock_getcpuclockid() returned an invalid clockid_t: " + "%d\n", clockid_1); + return PTS_FAIL; + } + + /* Get the time of clockid_2, should almost the same as clockid_1 */ + if (clock_gettime(clockid_2, &tp2) != 0) { + printf("clock_getcpuclockid() returned an invalid clockid_t: " + "%d\n", clockid_2); + return PTS_FAIL; + } + + if (tp1.tv_sec != tp2.tv_sec) { + printf("Test FAILED\n"); + return PTS_FAIL; + } + } + + printf("Test PASSED\n"); + return PTS_PASS; #endif } -- 1.7.0.4 |
From: Gui J. <gui...@cn...> - 2010-11-08 04:09:08
|
Gui Jianfeng wrote: > This case is trying to set CPU-time clock(ID is returned by clock_getcpuclockid()) of > a specific process by calling clock_settime(). But Linux kernel doesn't allow to reset > a CPU-time clock of a specific process. Kernel returns -EPERM. So test fails. > > In "IEEE Std 1003.1, 2004 Edition", It's said as following: > If _POSIX_CPUTIME is defined, implementations shall support clock ID values obtained by > invoking clock_getcpuclockid(), which represent the CPU-time clock of a given process. > Implementations shall also support the special clockid_t value CLOCK_PROCESS_CPUTIME_ID, > which represents the CPU-time clock of the calling process when invoking one of the > clock_*() or timer_*() functions. For these clock IDs, the values returned by > clock_gettime() and specified by clock_settime() represent the amount of execution time > of the process associated with the clock. Changing the value of a CPU-time clock via > clock_settime() shall have no effect on the behavior of the sporadic server scheduling > policy. > > So the behaviour when changing the value of a CPU-time clock via clock_settime() is > operating system specific. > > We may change the test progress to stop using clock_settime(). Now, We just make use > of clock_gettime() instead to achieve the same test purpose. > > Signed-off-by: Gui Jianfeng <gui...@cn...> Hi Garrett, How do you think this fix? Gui > --- > .../interfaces/clock_getcpuclockid/2-1.c | 67 ++++++++++---------- > 1 files changed, 33 insertions(+), 34 deletions(-) > > diff --git a/testcases/open_posix_testsuite/conformance/interfaces/clock_getcpuclockid/2-1.c b/testcases/open_posix_testsuite/conformance/interfaces/clock_getcpuclockid/2-1.c > index edeb397..52240df 100644 > --- a/testcases/open_posix_testsuite/conformance/interfaces/clock_getcpuclockid/2-1.c > +++ b/testcases/open_posix_testsuite/conformance/interfaces/clock_getcpuclockid/2-1.c > @@ -23,48 +23,47 @@ int main(int argc, char *argv[]) > printf("_POSIX_CPUTIME unsupported\n"); > return PTS_UNSUPPORTED; > #else > - unsigned long time_to_set; > clockid_t clockid_1, clockid_2; > struct timespec tp1, tp2; > + int i; > > if (sysconf(_SC_CPUTIME) == -1) { > printf("_POSIX_CPUTIME unsupported\n"); > return PTS_UNSUPPORTED; > } > > - if (clock_getcpuclockid(getpid(), &clockid_1) != 0) { > - printf("clock_getcpuclockid(getpid(), ) failed\n"); > - return PTS_FAIL; > - } > - > - if (clock_getcpuclockid(0, &clockid_2) != 0) { > - printf("clock_getcpuclockid(0, ) failed\n"); > - return PTS_FAIL; > - } > + for (i = 0; i < 10; i++) { > + if (clock_getcpuclockid(getpid(), &clockid_1) != 0) { > + printf("clock_getcpuclockid(getpid(), ) failed\n"); > + return PTS_FAIL; > + } > > - /* Set clockid_1 as a random value from 1 sec to 10 sec */ > - srand((unsigned long)time(NULL)); > - time_to_set = rand() * 10.0 / RAND_MAX + 1; > - tp1.tv_sec = time_to_set; > - tp1.tv_nsec = 0; > - if (clock_settime(clockid_1, &tp1) != 0) { > - printf("clock_getcpuclockid() returned an invalid clockid_t: " > - "%d\n", clockid_1); > - return PTS_FAIL; > - } > - /* Get the time of clockid_2, should almost the same as clockid_1 */ > - if (clock_gettime(clockid_2, &tp2) != 0) { > - printf("clock_getcpuclockid() returned an invalid clockid_t: " > - "%d\n", clockid_2); > - return PTS_FAIL; > - } > - if (tp1.tv_sec == tp2.tv_sec) > - { > - printf("Test PASSED\n"); > - return PTS_PASS; > - } > - printf("Test FAILED\n"); > - return PTS_FAIL; > - > + if (clock_getcpuclockid(0, &clockid_2) != 0) { > + printf("clock_getcpuclockid(0, ) failed\n"); > + return PTS_FAIL; > + } > + > + /* Get the time of clockid_1 */ > + if (clock_gettime(clockid_1, &tp1) != 0) { > + printf("clock_getcpuclockid() returned an invalid clockid_t: " > + "%d\n", clockid_1); > + return PTS_FAIL; > + } > + > + /* Get the time of clockid_2, should almost the same as clockid_1 */ > + if (clock_gettime(clockid_2, &tp2) != 0) { > + printf("clock_getcpuclockid() returned an invalid clockid_t: " > + "%d\n", clockid_2); > + return PTS_FAIL; > + } > + > + if (tp1.tv_sec != tp2.tv_sec) { > + printf("Test FAILED\n"); > + return PTS_FAIL; > + } > + } > + > + printf("Test PASSED\n"); > + return PTS_PASS; > #endif > } |
From: Garrett C. <yan...@gm...> - 2010-11-08 06:02:30
|
On Sun, Nov 7, 2010 at 8:09 PM, Gui Jianfeng <gui...@cn...> wrote: > Gui Jianfeng wrote: >> This case is trying to set CPU-time clock(ID is returned by clock_getcpuclockid()) of >> a specific process by calling clock_settime(). But Linux kernel doesn't allow to reset >> a CPU-time clock of a specific process. Kernel returns -EPERM. So test fails. >> >> In "IEEE Std 1003.1, 2004 Edition", It's said as following: >> If _POSIX_CPUTIME is defined, implementations shall support clock ID values obtained by >> invoking clock_getcpuclockid(), which represent the CPU-time clock of a given process. >> Implementations shall also support the special clockid_t value CLOCK_PROCESS_CPUTIME_ID, >> which represents the CPU-time clock of the calling process when invoking one of the >> clock_*() or timer_*() functions. For these clock IDs, the values returned by >> clock_gettime() and specified by clock_settime() represent the amount of execution time >> of the process associated with the clock. Changing the value of a CPU-time clock via >> clock_settime() shall have no effect on the behavior of the sporadic server scheduling >> policy. >> >> So the behaviour when changing the value of a CPU-time clock via clock_settime() is >> operating system specific. >> >> We may change the test progress to stop using clock_settime(). Now, We just make use >> of clock_gettime() instead to achieve the same test purpose. >> >> Signed-off-by: Gui Jianfeng <gui...@cn...> > > Hi Garrett, > > How do you think this fix? The tort is the same in POSIX 2008.1. Taking out the chaff... a. If _POSIX_CPUTIME is defined, implementations shall support clock ID values obtained by invoking clock_getcpuclockid(), which represent the CPU-time clock of a given process. b. Implementations shall also support the special clockid_t value CLOCK_PROCESS_CPUTIME_ID, which represents the CPU-time clock of the calling process when invoking one of the clock_*() or timer_*() functions. c. For these clock IDs, the values returned by clock_gettime() and specified by clock_settime() represent the amount of execution time of the process associated with the clock. Nowhere does it say that you can't set that clock. Try running the test as root to see what you can do... if the test fails (even as root), then Linux needs to be fixed to conform to POSIX. Also, try running the other tests I just added to see whether or not the function call fails per POSIX's requirements. Thanks! -Garrett |
From: Gui J. <gui...@cn...> - 2010-11-08 06:20:52
|
Garrett Cooper wrote: > On Sun, Nov 7, 2010 at 8:09 PM, Gui Jianfeng <gui...@cn...> wrote: >> Gui Jianfeng wrote: >>> This case is trying to set CPU-time clock(ID is returned by clock_getcpuclockid()) of >>> a specific process by calling clock_settime(). But Linux kernel doesn't allow to reset >>> a CPU-time clock of a specific process. Kernel returns -EPERM. So test fails. >>> >>> In "IEEE Std 1003.1, 2004 Edition", It's said as following: >>> If _POSIX_CPUTIME is defined, implementations shall support clock ID values obtained by >>> invoking clock_getcpuclockid(), which represent the CPU-time clock of a given process. >>> Implementations shall also support the special clockid_t value CLOCK_PROCESS_CPUTIME_ID, >>> which represents the CPU-time clock of the calling process when invoking one of the >>> clock_*() or timer_*() functions. For these clock IDs, the values returned by >>> clock_gettime() and specified by clock_settime() represent the amount of execution time >>> of the process associated with the clock. Changing the value of a CPU-time clock via >>> clock_settime() shall have no effect on the behavior of the sporadic server scheduling >>> policy. >>> >>> So the behaviour when changing the value of a CPU-time clock via clock_settime() is >>> operating system specific. >>> >>> We may change the test progress to stop using clock_settime(). Now, We just make use >>> of clock_gettime() instead to achieve the same test purpose. >>> >>> Signed-off-by: Gui Jianfeng <gui...@cn...> >> Hi Garrett, >> >> How do you think this fix? > > The tort is the same in POSIX 2008.1. Taking out the chaff... > > a. If _POSIX_CPUTIME is defined, implementations shall support clock > ID values obtained by invoking clock_getcpuclockid(), which represent > the CPU-time clock of a given process. > b. Implementations shall also support the special clockid_t value > CLOCK_PROCESS_CPUTIME_ID, which represents the CPU-time clock of the > calling process when invoking one of the clock_*() or timer_*() > functions. > c. For these clock IDs, the values returned by clock_gettime() and > specified by clock_settime() represent the amount of execution time of > the process associated with the clock. > > Nowhere does it say that you can't set that clock. Try running the > test as root to see what you can do... if the test fails (even as > root), then Linux needs to be fixed to conform to POSIX. POSIX also says that: Changing the value of a CPU-time clock via clock_settime() shall have no effect on the behavior of the sporadic server scheduling policy. IMHO, this means clock_settime() implementation is OS specific, is it? So, even if Linux fails to set this clock, it's just fine. Am i missing something? Gui > > Also, try running the other tests I just added to see whether or not > the function call fails per POSIX's requirements. > > Thanks! > -Garrett > |
From: Gui J. <gui...@cn...> - 2010-11-15 03:21:07
|
Gui Jianfeng wrote: > Garrett Cooper wrote: >> On Sun, Nov 7, 2010 at 8:09 PM, Gui Jianfeng <gui...@cn...> wrote: >>> Gui Jianfeng wrote: >>>> This case is trying to set CPU-time clock(ID is returned by clock_getcpuclockid()) of >>>> a specific process by calling clock_settime(). But Linux kernel doesn't allow to reset >>>> a CPU-time clock of a specific process. Kernel returns -EPERM. So test fails. >>>> >>>> In "IEEE Std 1003.1, 2004 Edition", It's said as following: >>>> If _POSIX_CPUTIME is defined, implementations shall support clock ID values obtained by >>>> invoking clock_getcpuclockid(), which represent the CPU-time clock of a given process. >>>> Implementations shall also support the special clockid_t value CLOCK_PROCESS_CPUTIME_ID, >>>> which represents the CPU-time clock of the calling process when invoking one of the >>>> clock_*() or timer_*() functions. For these clock IDs, the values returned by >>>> clock_gettime() and specified by clock_settime() represent the amount of execution time >>>> of the process associated with the clock. Changing the value of a CPU-time clock via >>>> clock_settime() shall have no effect on the behavior of the sporadic server scheduling >>>> policy. >>>> >>>> So the behaviour when changing the value of a CPU-time clock via clock_settime() is >>>> operating system specific. >>>> >>>> We may change the test progress to stop using clock_settime(). Now, We just make use >>>> of clock_gettime() instead to achieve the same test purpose. >>>> >>>> Signed-off-by: Gui Jianfeng <gui...@cn...> >>> Hi Garrett, >>> >>> How do you think this fix? >> The tort is the same in POSIX 2008.1. Taking out the chaff... >> >> a. If _POSIX_CPUTIME is defined, implementations shall support clock >> ID values obtained by invoking clock_getcpuclockid(), which represent >> the CPU-time clock of a given process. >> b. Implementations shall also support the special clockid_t value >> CLOCK_PROCESS_CPUTIME_ID, which represents the CPU-time clock of the >> calling process when invoking one of the clock_*() or timer_*() >> functions. >> c. For these clock IDs, the values returned by clock_gettime() and >> specified by clock_settime() represent the amount of execution time of >> the process associated with the clock. >> >> Nowhere does it say that you can't set that clock. Try running the >> test as root to see what you can do... if the test fails (even as >> root), then Linux needs to be fixed to conform to POSIX. > > POSIX also says that: > Changing the value of a CPU-time clock via clock_settime() shall have no effect > on the behavior of the sporadic server scheduling policy. > > IMHO, this means clock_settime() implementation is OS specific, is it? > So, even if Linux fails to set this clock, it's just fine. Am i missing something? Hi Garrett, If you don't object, would you apply this patch? Gui > > Gui > >> Also, try running the other tests I just added to see whether or not >> the function call fails per POSIX's requirements. >> >> Thanks! >> -Garrett >> > > ------------------------------------------------------------------------------ > The Next 800 Companies to Lead America's Growth: New Video Whitepaper > David G. Thomson, author of the best-selling book "Blueprint to a > Billion" shares his insights and actions to help propel your > business during the next growth cycle. Listen Now! > http://p.sf.net/sfu/SAP-dev2dev > _______________________________________________ > Ltp-list mailing list > Ltp...@li... > https://lists.sourceforge.net/lists/listinfo/ltp-list > |
From: Cyril H. <ch...@su...> - 2010-11-18 20:17:20
|
Hi! > The tort is the same in POSIX 2008.1. Taking out the chaff... > > a. If _POSIX_CPUTIME is defined, implementations shall support clock > ID values obtained by invoking clock_getcpuclockid(), which represent > the CPU-time clock of a given process. > b. Implementations shall also support the special clockid_t value > CLOCK_PROCESS_CPUTIME_ID, which represents the CPU-time clock of the > calling process when invoking one of the clock_*() or timer_*() > functions. > c. For these clock IDs, the values returned by clock_gettime() and > specified by clock_settime() represent the amount of execution time of > the process associated with the clock. > > Nowhere does it say that you can't set that clock. Try running the > test as root to see what you can do... if the test fails (even as > root), then Linux needs to be fixed to conform to POSIX. > > Also, try running the other tests I just added to see whether or not > the function call fails per POSIX's requirements. > >From clock_settime POSIX documentation: ... The effect of setting a clock via clock_settime() on armed per-process timers associated with that clock is implementation-dependent. The appropriate privilege to set a particular clock is implementation-dependent. ... >From man clock_settime: ... According to POSIX.1-2001, a process with "appropriate privileges" may set the CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID clocks using clock_settime(). On Linux, these clocks are not settable (i.e., no process has "appropriate privileges"). ... This is pretty creative understanding of the standart, but I couldn't say it's wrong anyway. -- Cyril Hrubis ch...@su... |
From: Garrett C. <yan...@gm...> - 2010-11-20 22:44:31
|
On Thu, Nov 18, 2010 at 12:29 PM, Cyril Hrubis <ch...@su...> wrote: > Hi! >> The tort is the same in POSIX 2008.1. Taking out the chaff... >> >> a. If _POSIX_CPUTIME is defined, implementations shall support clock >> ID values obtained by invoking clock_getcpuclockid(), which represent >> the CPU-time clock of a given process. >> b. Implementations shall also support the special clockid_t value >> CLOCK_PROCESS_CPUTIME_ID, which represents the CPU-time clock of the >> calling process when invoking one of the clock_*() or timer_*() >> functions. >> c. For these clock IDs, the values returned by clock_gettime() and >> specified by clock_settime() represent the amount of execution time of >> the process associated with the clock. >> >> Nowhere does it say that you can't set that clock. Try running the >> test as root to see what you can do... if the test fails (even as >> root), then Linux needs to be fixed to conform to POSIX. >> >> Also, try running the other tests I just added to see whether or not >> the function call fails per POSIX's requirements. >> > > From clock_settime POSIX documentation: > > ... > > The effect of setting a clock via clock_settime() on armed per-process timers > associated with that clock is implementation-dependent. > > The appropriate privilege to set a particular clock is implementation-dependent. > > ... > > > From man clock_settime: > > ... > > According to POSIX.1-2001, a process with "appropriate privileges" may set the > CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID clocks using > clock_settime(). On Linux, these clocks are not settable (i.e., no process has > "appropriate privileges"). > > ... > > > > This is pretty creative understanding of the standart, but I couldn't > say it's wrong anyway. I agree that privilege is multitiered and the implications of running as a particular user, whether or not SELinux is enabled, MAC allows it, etc are all bits to take into consideration. Just running the program as root seems like a simple test to run to see whether or not the testcase passes. -Garrett |
From: Garrett C. <yan...@gm...> - 2010-11-21 03:35:55
|
On Sat, Nov 20, 2010 at 2:38 PM, Garrett Cooper <yan...@gm...> wrote: > On Thu, Nov 18, 2010 at 12:29 PM, Cyril Hrubis <ch...@su...> wrote: >> Hi! >>> The tort is the same in POSIX 2008.1. Taking out the chaff... >>> >>> a. If _POSIX_CPUTIME is defined, implementations shall support clock >>> ID values obtained by invoking clock_getcpuclockid(), which represent >>> the CPU-time clock of a given process. >>> b. Implementations shall also support the special clockid_t value >>> CLOCK_PROCESS_CPUTIME_ID, which represents the CPU-time clock of the >>> calling process when invoking one of the clock_*() or timer_*() >>> functions. >>> c. For these clock IDs, the values returned by clock_gettime() and >>> specified by clock_settime() represent the amount of execution time of >>> the process associated with the clock. >>> >>> Nowhere does it say that you can't set that clock. Try running the >>> test as root to see what you can do... if the test fails (even as >>> root), then Linux needs to be fixed to conform to POSIX. >>> >>> Also, try running the other tests I just added to see whether or not >>> the function call fails per POSIX's requirements. >>> >> >> From clock_settime POSIX documentation: >> >> ... >> >> The effect of setting a clock via clock_settime() on armed per-process timers >> associated with that clock is implementation-dependent. >> >> The appropriate privilege to set a particular clock is implementation-dependent. >> >> ... >> >> >> From man clock_settime: >> >> ... >> >> According to POSIX.1-2001, a process with "appropriate privileges" may set the >> CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID clocks using >> clock_settime(). On Linux, these clocks are not settable (i.e., no process has >> "appropriate privileges"). >> >> ... >> >> >> >> This is pretty creative understanding of the standart, but I couldn't >> say it's wrong anyway. > > I agree that privilege is multitiered and the implications of running > as a particular user, whether or not SELinux is enabled, MAC allows > it, etc are all bits to take into consideration. > > Just running the program as root seems like a simple test to run to > see whether or not the testcase passes. FYI, I removed the clock_settime call and simplified the testcase because it wasn't really buying much in the overall scheme of things to make sure that the time matched on the two clock values. If anything that should be tested with the clock_settime conformance testcase. Thanks, -Garrett |
From: Gui J. <gui...@cn...> - 2010-11-30 10:07:51
|
Garrett Cooper wrote: > On Sat, Nov 20, 2010 at 2:38 PM, Garrett Cooper <yan...@gm...> wrote: >> On Thu, Nov 18, 2010 at 12:29 PM, Cyril Hrubis <ch...@su...> wrote: >>> Hi! >>>> The tort is the same in POSIX 2008.1. Taking out the chaff... >>>> >>>> a. If _POSIX_CPUTIME is defined, implementations shall support clock >>>> ID values obtained by invoking clock_getcpuclockid(), which represent >>>> the CPU-time clock of a given process. >>>> b. Implementations shall also support the special clockid_t value >>>> CLOCK_PROCESS_CPUTIME_ID, which represents the CPU-time clock of the >>>> calling process when invoking one of the clock_*() or timer_*() >>>> functions. >>>> c. For these clock IDs, the values returned by clock_gettime() and >>>> specified by clock_settime() represent the amount of execution time of >>>> the process associated with the clock. >>>> >>>> Nowhere does it say that you can't set that clock. Try running the >>>> test as root to see what you can do... if the test fails (even as >>>> root), then Linux needs to be fixed to conform to POSIX. >>>> >>>> Also, try running the other tests I just added to see whether or not >>>> the function call fails per POSIX's requirements. >>>> >>> From clock_settime POSIX documentation: >>> >>> ... >>> >>> The effect of setting a clock via clock_settime() on armed per-process timers >>> associated with that clock is implementation-dependent. >>> >>> The appropriate privilege to set a particular clock is implementation-dependent. >>> >>> ... >>> >>> >>> From man clock_settime: >>> >>> ... >>> >>> According to POSIX.1-2001, a process with "appropriate privileges" may set the >>> CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID clocks using >>> clock_settime(). On Linux, these clocks are not settable (i.e., no process has >>> "appropriate privileges"). >>> >>> ... >>> >>> >>> >>> This is pretty creative understanding of the standart, but I couldn't >>> say it's wrong anyway. >> I agree that privilege is multitiered and the implications of running >> as a particular user, whether or not SELinux is enabled, MAC allows >> it, etc are all bits to take into consideration. >> >> Just running the program as root seems like a simple test to run to >> see whether or not the testcase passes. > > FYI, I removed the clock_settime call and simplified the testcase > because it wasn't really buying much in the overall scheme of things > to make sure that the time matched on the two clock values. If > anything that should be tested with the clock_settime conformance > testcase. Hi Cooper, I have a look of the code you modified. Consider the following piece: /* Get the time of clockid_1. */ if (clockid_1 != clockid_2) { printf("clock_getcpuclockid(0, ..) != " "clock_getcpuclockid(%d, ..): (%d != %d)\n", clockid_1, clockid_2); return PTS_FAIL; } IMO, you can't do such comparision, it's problematic. In this case, clockid_1 and clockid_2 own different values, but they point to the same clock. So you can't modify like this. Do you have any concerns about my patch? If not, can you please apply it. Thanks, Gui > Thanks, > -Garrett > -- Regards Gui Jianfeng |
From: Cyril H. <ch...@su...> - 2010-12-02 12:00:35
|
Hi! > >>>> The tort is the same in POSIX 2008.1. Taking out the chaff... > >>>> > >>>> a. If _POSIX_CPUTIME is defined, implementations shall support clock > >>>> ID values obtained by invoking clock_getcpuclockid(), which represent > >>>> the CPU-time clock of a given process. > >>>> b. Implementations shall also support the special clockid_t value > >>>> CLOCK_PROCESS_CPUTIME_ID, which represents the CPU-time clock of the > >>>> calling process when invoking one of the clock_*() or timer_*() > >>>> functions. > >>>> c. For these clock IDs, the values returned by clock_gettime() and > >>>> specified by clock_settime() represent the amount of execution time of > >>>> the process associated with the clock. > >>>> > >>>> Nowhere does it say that you can't set that clock. Try running the > >>>> test as root to see what you can do... if the test fails (even as > >>>> root), then Linux needs to be fixed to conform to POSIX. > >>>> > >>>> Also, try running the other tests I just added to see whether or not > >>>> the function call fails per POSIX's requirements. > >>>> > >>> From clock_settime POSIX documentation: > >>> > >>> ... > >>> > >>> The effect of setting a clock via clock_settime() on armed per-process timers > >>> associated with that clock is implementation-dependent. > >>> > >>> The appropriate privilege to set a particular clock is implementation-dependent. > >>> > >>> ... > >>> > >>> > >>> From man clock_settime: > >>> > >>> ... > >>> > >>> According to POSIX.1-2001, a process with "appropriate privileges" may set the > >>> CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID clocks using > >>> clock_settime(). On Linux, these clocks are not settable (i.e., no process has > >>> "appropriate privileges"). > >>> > >>> ... > >>> > >>> > >>> > >>> This is pretty creative understanding of the standart, but I couldn't > >>> say it's wrong anyway. > >> I agree that privilege is multitiered and the implications of running > >> as a particular user, whether or not SELinux is enabled, MAC allows > >> it, etc are all bits to take into consideration. > >> > >> Just running the program as root seems like a simple test to run to > >> see whether or not the testcase passes. > > > > FYI, I removed the clock_settime call and simplified the testcase > > because it wasn't really buying much in the overall scheme of things > > to make sure that the time matched on the two clock values. If > > anything that should be tested with the clock_settime conformance > > testcase. > > Hi Cooper, > > I have a look of the code you modified. Consider the following piece: > > /* Get the time of clockid_1. */ > if (clockid_1 != clockid_2) { > printf("clock_getcpuclockid(0, ..) != " > "clock_getcpuclockid(%d, ..): (%d != %d)\n", clockid_1, > clockid_2); > return PTS_FAIL; > } > > IMO, you can't do such comparision, it's problematic. In this case, clockid_1 > and clockid_2 own different values, but they point to the same clock. So you > can't modify like this. Yes this assumption seems to be incorrect as I couldn't find in a place in POSIX documentation which explicitly states that two obtained clock_id that points to the same clock must be the same. On linux calling clock_getcpuclockid() with 0 and value from getpid() returns two different id which both points to the same clock. -- Cyril Hrubis ch...@su... |
From: Gui J. <gui...@cn...> - 2010-12-09 08:46:13
|
Cyril Hrubis wrote: > Hi! >>>>>> The tort is the same in POSIX 2008.1. Taking out the chaff... >>>>>> >>>>>> a. If _POSIX_CPUTIME is defined, implementations shall support clock >>>>>> ID values obtained by invoking clock_getcpuclockid(), which represent >>>>>> the CPU-time clock of a given process. >>>>>> b. Implementations shall also support the special clockid_t value >>>>>> CLOCK_PROCESS_CPUTIME_ID, which represents the CPU-time clock of the >>>>>> calling process when invoking one of the clock_*() or timer_*() >>>>>> functions. >>>>>> c. For these clock IDs, the values returned by clock_gettime() and >>>>>> specified by clock_settime() represent the amount of execution time of >>>>>> the process associated with the clock. >>>>>> >>>>>> Nowhere does it say that you can't set that clock. Try running the >>>>>> test as root to see what you can do... if the test fails (even as >>>>>> root), then Linux needs to be fixed to conform to POSIX. >>>>>> >>>>>> Also, try running the other tests I just added to see whether or not >>>>>> the function call fails per POSIX's requirements. >>>>>> >>>>> From clock_settime POSIX documentation: >>>>> >>>>> ... >>>>> >>>>> The effect of setting a clock via clock_settime() on armed per-process timers >>>>> associated with that clock is implementation-dependent. >>>>> >>>>> The appropriate privilege to set a particular clock is implementation-dependent. >>>>> >>>>> ... >>>>> >>>>> >>>>> From man clock_settime: >>>>> >>>>> ... >>>>> >>>>> According to POSIX.1-2001, a process with "appropriate privileges" may set the >>>>> CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID clocks using >>>>> clock_settime(). On Linux, these clocks are not settable (i.e., no process has >>>>> "appropriate privileges"). >>>>> >>>>> ... >>>>> >>>>> >>>>> >>>>> This is pretty creative understanding of the standart, but I couldn't >>>>> say it's wrong anyway. >>>> I agree that privilege is multitiered and the implications of running >>>> as a particular user, whether or not SELinux is enabled, MAC allows >>>> it, etc are all bits to take into consideration. >>>> >>>> Just running the program as root seems like a simple test to run to >>>> see whether or not the testcase passes. >>> FYI, I removed the clock_settime call and simplified the testcase >>> because it wasn't really buying much in the overall scheme of things >>> to make sure that the time matched on the two clock values. If >>> anything that should be tested with the clock_settime conformance >>> testcase. >> Hi Cooper, >> >> I have a look of the code you modified. Consider the following piece: >> >> /* Get the time of clockid_1. */ >> if (clockid_1 != clockid_2) { >> printf("clock_getcpuclockid(0, ..) != " >> "clock_getcpuclockid(%d, ..): (%d != %d)\n", clockid_1, >> clockid_2); >> return PTS_FAIL; >> } >> >> IMO, you can't do such comparision, it's problematic. In this case, clockid_1 >> and clockid_2 own different values, but they point to the same clock. So you >> can't modify like this. > > Yes this assumption seems to be incorrect as I couldn't find in a place > in POSIX documentation which explicitly states that two obtained > clock_id that points to the same clock must be the same. On linux > calling clock_getcpuclockid() with 0 and value from getpid() returns two > different id which both points to the same clock. Hi Garrett, Currently, this case always fails. Would you revert previous commit and apply the patch I posted several days ago? Gui |
From: Cyril H. <ch...@su...> - 2010-12-30 16:35:08
|
Hi! > Yes this assumption seems to be incorrect as I couldn't find in a place > in POSIX documentation which explicitly states that two obtained > clock_id that points to the same clock must be the same. On linux > calling clock_getcpuclockid() with 0 and value from getpid() returns two > different id which both points to the same clock. Garrett ping. -- Cyril Hrubis ch...@su... |
From: Garrett C. <yan...@gm...> - 2010-12-30 17:21:55
|
Not sure when I'll be able to get to this this week. Sent from my iPhone On Dec 30, 2010, at 8:50 AM, Cyril Hrubis <ch...@su...> wrote: > Hi! >> Yes this assumption seems to be incorrect as I couldn't find in a place >> in POSIX documentation which explicitly states that two obtained >> clock_id that points to the same clock must be the same. On linux >> calling clock_getcpuclockid() with 0 and value from getpid() returns two >> different id which both points to the same clock. > > Garrett ping. > > -- > Cyril Hrubis > ch...@su... |
From: Gui J. <gui...@cn...> - 2011-01-25 02:41:17
|
Garrett Cooper wrote: > Not sure when I'll be able to get to this this week. Garrett, Would you commit the patch? Thanks, Gui > > Sent from my iPhone > > On Dec 30, 2010, at 8:50 AM, Cyril Hrubis <ch...@su...> wrote: > >> Hi! >>> Yes this assumption seems to be incorrect as I couldn't find in a place >>> in POSIX documentation which explicitly states that two obtained >>> clock_id that points to the same clock must be the same. On linux >>> calling clock_getcpuclockid() with 0 and value from getpid() returns two >>> different id which both points to the same clock. >> Garrett ping. >> >> -- >> Cyril Hrubis >> ch...@su... > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Ltp-list mailing list > Ltp...@li... > https://lists.sourceforge.net/lists/listinfo/ltp-list > -- Regards Gui Jianfeng |
From: Gui J. <gui...@cn...> - 2011-02-24 06:21:35
|
Hi Garrett, This case always fails when I do the test. Would you take a look this patch, If you don't object, can you commit this patch? Or give some comments about it. Thanks, Gui Gui Jianfeng wrote: > This case is trying to set CPU-time clock(ID is returned by clock_getcpuclockid()) of > a specific process by calling clock_settime(). But Linux kernel doesn't allow to reset > a CPU-time clock of a specific process. Kernel returns -EPERM. So test fails. > > In "IEEE Std 1003.1, 2004 Edition", It's said as following: > If _POSIX_CPUTIME is defined, implementations shall support clock ID values obtained by > invoking clock_getcpuclockid(), which represent the CPU-time clock of a given process. > Implementations shall also support the special clockid_t value CLOCK_PROCESS_CPUTIME_ID, > which represents the CPU-time clock of the calling process when invoking one of the > clock_*() or timer_*() functions. For these clock IDs, the values returned by > clock_gettime() and specified by clock_settime() represent the amount of execution time > of the process associated with the clock. Changing the value of a CPU-time clock via > clock_settime() shall have no effect on the behavior of the sporadic server scheduling > policy. > > So the behaviour when changing the value of a CPU-time clock via clock_settime() is > operating system specific. > > We may change the test progress to stop using clock_settime(). Now, We just make use > of clock_gettime() instead to achieve the same test purpose. > > Signed-off-by: Gui Jianfeng <gui...@cn...> > --- > .../interfaces/clock_getcpuclockid/2-1.c | 67 ++++++++++---------- > 1 files changed, 33 insertions(+), 34 deletions(-) > > diff --git a/testcases/open_posix_testsuite/conformance/interfaces/clock_getcpuclockid/2-1.c b/testcases/open_posix_testsuite/conformance/interfaces/clock_getcpuclockid/2-1.c > index edeb397..52240df 100644 > --- a/testcases/open_posix_testsuite/conformance/interfaces/clock_getcpuclockid/2-1.c > +++ b/testcases/open_posix_testsuite/conformance/interfaces/clock_getcpuclockid/2-1.c > @@ -23,48 +23,47 @@ int main(int argc, char *argv[]) > printf("_POSIX_CPUTIME unsupported\n"); > return PTS_UNSUPPORTED; > #else > - unsigned long time_to_set; > clockid_t clockid_1, clockid_2; > struct timespec tp1, tp2; > + int i; > > if (sysconf(_SC_CPUTIME) == -1) { > printf("_POSIX_CPUTIME unsupported\n"); > return PTS_UNSUPPORTED; > } > > - if (clock_getcpuclockid(getpid(), &clockid_1) != 0) { > - printf("clock_getcpuclockid(getpid(), ) failed\n"); > - return PTS_FAIL; > - } > - > - if (clock_getcpuclockid(0, &clockid_2) != 0) { > - printf("clock_getcpuclockid(0, ) failed\n"); > - return PTS_FAIL; > - } > + for (i = 0; i < 10; i++) { > + if (clock_getcpuclockid(getpid(), &clockid_1) != 0) { > + printf("clock_getcpuclockid(getpid(), ) failed\n"); > + return PTS_FAIL; > + } > > - /* Set clockid_1 as a random value from 1 sec to 10 sec */ > - srand((unsigned long)time(NULL)); > - time_to_set = rand() * 10.0 / RAND_MAX + 1; > - tp1.tv_sec = time_to_set; > - tp1.tv_nsec = 0; > - if (clock_settime(clockid_1, &tp1) != 0) { > - printf("clock_getcpuclockid() returned an invalid clockid_t: " > - "%d\n", clockid_1); > - return PTS_FAIL; > - } > - /* Get the time of clockid_2, should almost the same as clockid_1 */ > - if (clock_gettime(clockid_2, &tp2) != 0) { > - printf("clock_getcpuclockid() returned an invalid clockid_t: " > - "%d\n", clockid_2); > - return PTS_FAIL; > - } > - if (tp1.tv_sec == tp2.tv_sec) > - { > - printf("Test PASSED\n"); > - return PTS_PASS; > - } > - printf("Test FAILED\n"); > - return PTS_FAIL; > - > + if (clock_getcpuclockid(0, &clockid_2) != 0) { > + printf("clock_getcpuclockid(0, ) failed\n"); > + return PTS_FAIL; > + } > + > + /* Get the time of clockid_1 */ > + if (clock_gettime(clockid_1, &tp1) != 0) { > + printf("clock_getcpuclockid() returned an invalid clockid_t: " > + "%d\n", clockid_1); > + return PTS_FAIL; > + } > + > + /* Get the time of clockid_2, should almost the same as clockid_1 */ > + if (clock_gettime(clockid_2, &tp2) != 0) { > + printf("clock_getcpuclockid() returned an invalid clockid_t: " > + "%d\n", clockid_2); > + return PTS_FAIL; > + } > + > + if (tp1.tv_sec != tp2.tv_sec) { > + printf("Test FAILED\n"); > + return PTS_FAIL; > + } > + } > + > + printf("Test PASSED\n"); > + return PTS_PASS; > #endif > } |
From: Cyril H. <ch...@su...> - 2011-02-25 14:30:01
|
Hi! I've just commited a slightly different fix which: * reports sucess if clock ids are the same * check differencies of timers, if they arent Garrett, could you check this version works on BSD as well? -- Cyril Hrubis ch...@su... |
From: Gui J. <gui...@cn...> - 2011-02-28 04:47:49
|
Cyril Hrubis wrote: > Hi! > I've just commited a slightly different fix which: Thanks a lot. Gui > > * reports sucess if clock ids are the same > > * check differencies of timers, if they arent > > Garrett, could you check this version works on BSD as well? > |