Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
2001 |
Jan
(1) |
Feb
|
Mar
(7) |
Apr
(3) |
May
(3) |
Jun
(7) |
Jul
(10) |
Aug
(1) |
Sep
(50) |
Oct
(74) |
Nov
(28) |
Dec
(32) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(63) |
Feb
(27) |
Mar
(88) |
Apr
(21) |
May
(59) |
Jun
(41) |
Jul
(61) |
Aug
(89) |
Sep
(179) |
Oct
(152) |
Nov
(190) |
Dec
(92) |
2003 |
Jan
(140) |
Feb
(160) |
Mar
(193) |
Apr
(107) |
May
(84) |
Jun
(60) |
Jul
(97) |
Aug
(97) |
Sep
(42) |
Oct
(105) |
Nov
(99) |
Dec
(52) |
2004 |
Jan
(99) |
Feb
(97) |
Mar
(62) |
Apr
(73) |
May
(94) |
Jun
(37) |
Jul
(32) |
Aug
(89) |
Sep
(87) |
Oct
(72) |
Nov
(114) |
Dec
(35) |
2005 |
Jan
(25) |
Feb
(42) |
Mar
(120) |
Apr
(151) |
May
(71) |
Jun
(36) |
Jul
(35) |
Aug
(92) |
Sep
(19) |
Oct
(57) |
Nov
(77) |
Dec
(61) |
2006 |
Jan
(107) |
Feb
(114) |
Mar
(66) |
Apr
(101) |
May
(74) |
Jun
(64) |
Jul
(42) |
Aug
(51) |
Sep
(106) |
Oct
(118) |
Nov
(138) |
Dec
(162) |
2007 |
Jan
(148) |
Feb
(222) |
Mar
(73) |
Apr
(160) |
May
(166) |
Jun
(125) |
Jul
(184) |
Aug
(58) |
Sep
(41) |
Oct
(102) |
Nov
(111) |
Dec
(52) |
2008 |
Jan
(104) |
Feb
(67) |
Mar
(48) |
Apr
(125) |
May
(114) |
Jun
(98) |
Jul
(206) |
Aug
(89) |
Sep
(88) |
Oct
(163) |
Nov
(115) |
Dec
(113) |
2009 |
Jan
(131) |
Feb
(85) |
Mar
(157) |
Apr
(198) |
May
(202) |
Jun
(154) |
Jul
(156) |
Aug
(75) |
Sep
(80) |
Oct
(148) |
Nov
(88) |
Dec
(83) |
2010 |
Jan
(78) |
Feb
(59) |
Mar
(89) |
Apr
(54) |
May
(92) |
Jun
(66) |
Jul
(38) |
Aug
(73) |
Sep
(84) |
Oct
(91) |
Nov
(52) |
Dec
(62) |
2011 |
Jan
(86) |
Feb
(68) |
Mar
(129) |
Apr
(121) |
May
(154) |
Jun
(81) |
Jul
(55) |
Aug
(55) |
Sep
(58) |
Oct
(115) |
Nov
(88) |
Dec
(95) |
2012 |
Jan
(105) |
Feb
(62) |
Mar
(52) |
Apr
(54) |
May
(103) |
Jun
(89) |
Jul
(152) |
Aug
(73) |
Sep
(58) |
Oct
(60) |
Nov
(52) |
Dec
(90) |
2013 |
Jan
(102) |
Feb
(63) |
Mar
(68) |
Apr
(128) |
May
(82) |
Jun
(94) |
Jul
(87) |
Aug
(29) |
Sep
(24) |
Oct
(25) |
Nov
(40) |
Dec
(51) |
2014 |
Jan
(41) |
Feb
(60) |
Mar
(33) |
Apr
(22) |
May
(38) |
Jun
(23) |
Jul
(86) |
Aug
(113) |
Sep
(23) |
Oct
(22) |
Nov
(18) |
Dec
(13) |
2015 |
Jan
(40) |
Feb
(12) |
Mar
(28) |
Apr
(32) |
May
(53) |
Jun
(65) |
Jul
(27) |
Aug
(6) |
Sep
(13) |
Oct
(25) |
Nov
(48) |
Dec
(19) |
2016 |
Jan
(5) |
Feb
(10) |
Mar
(23) |
Apr
(31) |
May
(19) |
Jun
(28) |
Jul
(19) |
Aug
(2) |
Sep
(9) |
Oct
(18) |
Nov
(10) |
Dec
(4) |
2017 |
Jan
(23) |
Feb
(42) |
Mar
(13) |
Apr
(5) |
May
(7) |
Jun
(26) |
Jul
(13) |
Aug
(8) |
Sep
(1) |
Oct
(3) |
Nov
(27) |
Dec
(4) |
2018 |
Jan
(9) |
Feb
(22) |
Mar
(27) |
Apr
(8) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: William Cohen <wcohen@nc...> - 2018-04-20 23:26:06
|
On 04/20/2018 06:02 PM, First Strike wrote: > To add, I am building the kernel with following configs: > CONFIG_OPROFILE=y > CONFIG_HAVE_OPROFILE=y > CONFIG_TRACING=y > CONFIG_TRACING_SUPPORT=y > > > On Fri, Apr 20, 2018 at 2:48 PM, First Strike <first010strike@... <mailto:first010strike@...>> wrote: > > Folks, > > I am running Windriver linux (4.8.22-WR9) on ARM Cortex A9 CPU with > # operf -v > operf: oprofile 1.1.0 > > I ran 'operf --system-wide' as well as for a specific process for approx 5mins followed by opreport. It complains with error "No Sample found". > > Can someone let me know what I could be missing out? > Hi, operf uses the perf interface rather than the older oprofile kernel support. If the kernel provides hardware event counting, you should see something like the following for the kernel perf tool (the cycles:u, instructions:u, branches:u, and branch-misses:u): $ perf stat true  Performance counter stats for 'true':          9.324083     task-clock:u (msec)      #   0.339 CPUs utilized                         0     context-switches:u       #   0.000 K/sec                                 0     cpu-migrations:u         #   0.000 K/sec                                38     page-faults:u            #   0.004 M/sec                           454,860     cycles:u                 #   0.049 GHz                             174,579     instructions:u           #   0.38 insn per cycle                   16,555     branches:u               #   1.776 M/sec                             5,739     branch-misses:u          #  34.67% of all branches             0.027514525 seconds time elapsed I suspect that you will need to compile the kernel with the following configure settings to provide pmu counters to operf: CONFIG_PERF_EVENTS=y CONFIG_HW_PERF_EVENTS=y -Will > > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > oprofile-list mailing list > oprofile-list@... > https://lists.sourceforge.net/lists/listinfo/oprofile-list |
From: First Strike <first010strike@gm...> - 2018-04-20 22:02:13
|
To add, I am building the kernel with following configs: CONFIG_OPROFILE=y CONFIG_HAVE_OPROFILE=y CONFIG_TRACING=y CONFIG_TRACING_SUPPORT=y On Fri, Apr 20, 2018 at 2:48 PM, First Strike <first010strike@...> wrote: > Folks, > > I am running Windriver linux (4.8.22-WR9) on ARM Cortex A9 CPU with > # operf -v > operf: oprofile 1.1.0 > > I ran 'operf --system-wide' as well as for a specific process for approx > 5mins followed by opreport. It complains with error "No Sample found". > > Can someone let me know what I could be missing out? > > |
From: First Strike <first010strike@gm...> - 2018-04-20 21:48:53
|
Folks, I am running Windriver linux (4.8.22-WR9) on ARM Cortex A9 CPU with # operf -v operf: oprofile 1.1.0 I ran 'operf --system-wide' as well as for a specific process for approx 5mins followed by opreport. It complains with error "No Sample found". Can someone let me know what I could be missing out? |
From: Matt Redfearn <matt.redfearn@mi...> - 2018-04-20 10:36:24
|
The presence of per TC performance counters is now detected by cpu-probe.c and indicated by MIPS_CPU_MT_PER_TC_PERF_COUNTERS in cpu_data. Switch detection of the feature to use this new flag rather than blindly testing the implementation specific config7 register with a magic number. Signed-off-by: Matt Redfearn <matt.redfearn@...> --- Changes in v3: Use flag in cpu_data set by cpu_probe.c to indicate feature presence. Changes in v2: None arch/mips/include/asm/cpu-features.h | 7 +++++++ arch/mips/kernel/perf_event_mipsxx.c | 3 --- arch/mips/oprofile/op_model_mipsxx.c | 2 -- 3 files changed, 7 insertions(+), 5 deletions(-) diff --git a/arch/mips/include/asm/cpu-features.h b/arch/mips/include/asm/cpu-features.h index 721b698bfe3c..69755d900c69 100644 --- a/arch/mips/include/asm/cpu-features.h +++ b/arch/mips/include/asm/cpu-features.h @@ -534,6 +534,13 @@ # define cpu_has_shared_ftlb_entries 0 #endif +#ifdef CONFIG_MIPS_MT_SMP +# define cpu_has_mipsmt_pertccounters \ + (cpu_data[0].options & MIPS_CPU_MT_PER_TC_PERF_COUNTERS) +#else +# define cpu_has_mipsmt_pertccounters 0 +#endif /* CONFIG_MIPS_MT_SMP */ + /* * Guest capabilities */ diff --git a/arch/mips/kernel/perf_event_mipsxx.c b/arch/mips/kernel/perf_event_mipsxx.c index 6668f67a61c3..0595a974bc81 100644 --- a/arch/mips/kernel/perf_event_mipsxx.c +++ b/arch/mips/kernel/perf_event_mipsxx.c @@ -129,8 +129,6 @@ static struct mips_pmu mipspmu; #ifdef CONFIG_MIPS_PERF_SHARED_TC_COUNTERS -static int cpu_has_mipsmt_pertccounters; - static DEFINE_RWLOCK(pmuint_rwlock); #if defined(CONFIG_CPU_BMIPS5000) @@ -1723,7 +1721,6 @@ init_hw_perf_events(void) } #ifdef CONFIG_MIPS_PERF_SHARED_TC_COUNTERS - cpu_has_mipsmt_pertccounters = read_c0_config7() & (1<<19); if (!cpu_has_mipsmt_pertccounters) counters = counters_total_to_per_cpu(counters); #endif diff --git a/arch/mips/oprofile/op_model_mipsxx.c b/arch/mips/oprofile/op_model_mipsxx.c index c3e4c18ef8d4..7c04b17f4a48 100644 --- a/arch/mips/oprofile/op_model_mipsxx.c +++ b/arch/mips/oprofile/op_model_mipsxx.c @@ -36,7 +36,6 @@ static int perfcount_irq; #endif #ifdef CONFIG_MIPS_MT_SMP -static int cpu_has_mipsmt_pertccounters; #define WHAT (MIPS_PERFCTRL_MT_EN_VPE | \ M_PERFCTL_VPEID(cpu_vpe_id(¤t_cpu_data))) #define vpe_id() (cpu_has_mipsmt_pertccounters ? \ @@ -326,7 +325,6 @@ static int __init mipsxx_init(void) } #ifdef CONFIG_MIPS_MT_SMP - cpu_has_mipsmt_pertccounters = read_c0_config7() & (1<<19); if (!cpu_has_mipsmt_pertccounters) counters = counters_total_to_per_cpu(counters); #endif -- 2.7.4 |
From: Matt Redfearn <matt.redfearn@mi...> - 2018-04-20 10:35:56
|
This series addresses a few issues with how the MIPS performance counters code supports the hardware multithreading MT ASE. Firstly, implementations of the MT ASE may implement performance counters per core or per thread(TC). MIPS Techologies implementations signal this via a bit in the implmentation specific CONFIG7 register. Since this register is implementation specific, checking it should be guarded by a PRID check. This also replaces a bit defined by a magic number. Secondly, the code currently uses vpe_id(), defined as smp_processor_id(), divided by 2, to share core performance counters between VPEs. This relies on a couple of assumptions of the hardware implementation to function correctly (always 2 VPEs per core, and the hardware reading only the least significant bit). Finally, the method of sharing core performance counters between VPEs is suboptimal since it does not allow one process running on a VPE to use all of the performance counters available to it, because the kernel will reserve half of the coutners for the other VPE even if it may never use them. This reservation at counter probe is replaced with an allocation on use strategy. Tested on a MIPS Creator CI40 (2C2T MIPS InterAptiv with per-TC counters, though for the purposes of testing the per-TC availability was hardcoded to allow testing both paths). Series applies to v4.16 Changes in v3: New patch to detect feature presence in cpu-probe.c Use flag in cpu_data set by cpu_probe.c to indicate feature presence. - rebase on new feature detection Changes in v2: Fix mipsxx_pmu_enable_event for !#ifdef CONFIG_MIPS_MT_SMP - Fix !#ifdef CONFIG_MIPS_PERF_SHARED_TC_COUNTERS build - re-use cpuc variable in mipsxx_pmu_alloc_counter, mipsxx_pmu_free_counter rather than having sibling_ version. Since BMIPS5000 does not implement per TC counters, we can remove the check on cpu_has_mipsmt_pertccounters. New patch to fix BMIPS5000 system mode perf. Matt Redfearn (7): MIPS: Probe for MIPS MT perf counters per TC MIPS: perf: More robustly probe for the presence of per-tc counters MIPS: perf: Use correct VPE ID when setting up VPE tracing MIPS: perf: Fix perf with MT counting other threads MIPS: perf: Allocate per-core counters on demand MIPS: perf: Fold vpe_id() macro into it's one last usage MIPS: perf: Fix BMIPS5000 system mode counting arch/mips/include/asm/cpu-features.h | 7 ++ arch/mips/include/asm/cpu.h | 2 + arch/mips/include/asm/mipsregs.h | 6 + arch/mips/kernel/cpu-probe.c | 12 ++ arch/mips/kernel/perf_event_mipsxx.c | 232 +++++++++++++++++++---------------- arch/mips/oprofile/op_model_mipsxx.c | 2 - 6 files changed, 150 insertions(+), 111 deletions(-) -- 2.7.4 |
From: Michael Petlan <mpetlan@re...> - 2018-04-05 22:44:18
|
Hi. The error you're facing means the following: "In the sample dir there appear to be no samples for /bin/abc." That may happen for several reasons. Let's try to narrow the problem down. 1) What does simple "./opreport" print? Does it print any other samples? --> YES: Everything is OK, just /bin/abc was not hit during profiling. ----> Should /bin/abc be hit? I.e. is it expected to be a heavy load considering the used event (*)? ------> YES: Try to profile only /bin/abc (in case you profiled system-wide). ------> Try to run `ocount /bin/abc` using the same event. This should give you much bigger number than the "count" of the event you use for profiling (**) ------> NO: You might try to use different event or decrease the used count (**). --> NO: No samples were found, no samples were recorded at all. Try to run ocount against the same load with the same event. Does it produce any reasonable results? ----> YES: Could the problem be in (**)? ----> NO: OK, so the event does not get hit at all. What is the event you use? Should it be even hit (see (*))? Could it be hit under a different load? ------> If the event should be hit and cannot, it might be a bug in kernel, oprofile or even in hardware... This is just a crossroads that might help you narrowing down the issue. If you provide more info, e.g. what had been the operf command line before you ran the `opreport`? (Was there any? If not, you have to do the profiling first!). Which event do you use? What is the /bin/abc? What is the listing of /lib/oprofile/bin/oprofile_data/samples/ (do `find /lib/oprofile/bin/oprofile_data/samples/ > samples_tree.log` and share the samples_tree.log file)? Etc. ... Without further info I cannot help more. Cheers, Michael (*) I.e. an app doing lots of computations should produce lots of "CPU_CLK_UNHALTED" event occurrences, however, possibly just very little LLC cache misses... Especially, if you profile system-wide, it might be well understandable why some program is not even hit. (**) E.g. I have an event CPU_CLK_UNHALTED which has let's say counter 100000. That means that when profiling, every 100000th event hit results in a sample taken. Let's suppose that my app needs 25000 CPU cycles to run (it is some simple app). For such an app, it is very probable that it won't get hit by any sample when profiled. This is not necessarily your case, just a possible explanation. You didn't provide any more concrete info, so I am just guessing. On Thu, 5 Apr 2018, Vinoth Natarajan wrote: > Hello Team, > opreport on oprofile-1.2.0 is throwing the following error. > > ./opreport -l /bin/abc > > Using /lib/oprofile/bin/oprofile_data/samples/ for samples directory. > > error: no sample files found: profile specification too strict ? > > > same was working fine in oprofile-0.9.9. > > > I have added all the dependencies and kernel configs . > > Please share your thoughts on this. > > > Thanks and Regards, > > Vinoth Natarajan. > > > > On Tue, Mar 20, 2018 at 9:44 PM, Michael Petlan <mpetlan@...> wrote: > Hi Vinoth! > > This looks good, your machine's PMU and kernel seems to be OK. > > You need to do `make install` to have all the sub-tools installed > in $PATH. Your operf wants to run `ophelp` to find the default > event to be used. It does not find it in path, so it fails. I'd > recommend to do the full installation process. You can specify > various things to ./configure (target prefixes, etc.). > > Cheers, > Michael > > On Tue, 20 Mar 2018, Vinoth Natarajan wrote: > > Hello Michael, > > > > Good Day!!! > > > > Tried running the oprofile-1.2.0 on different ARM hardware which supports PMU. > > But when we try to run operf binary,it show the following error. > > > > # ./operf --system-wide > > sh: /home/oprofile/bin/ophelp: not found > > Unable to find info for event CPU_CYCLES > > I have tried in internet about this error, No luck. > > Could you please let us know about this error. > > > > Note :- > > Following are the kernel configs related to PERF enabled on this 4.1 kernel. > > CONFIG_HAVE_PERF_EVENTS=y > > CONFIG_PERF_USE_VMALLOC=y > > CONFIG_PERF_EVENTS=y > > # CONFIG_DEBUG_PERF_USE_VMALLOC is not set > > CONFIG_HAVE_PERF_REGS=y > > CONFIG_HAVE_PERF_USER_STACK_DUMP=y > > # CONFIG_PCIEASPM_PERFORMANCE is not set > > CONFIG_HW_PERF_EVENTS=y > > > > > > Code given from you is able to get the expected output from the new hardware. > > > > ioctl(fd, PERF_EVENT_IOC_RESET, 0); > > ioctl(fd, PERF_EVENT_IOC_ENABLE, 0); > > > > printf("Measuring instruction count for this printf\n"); > > > > ioctl(fd, PERF_EVENT_IOC_DISABLE, 0); > > read(fd, &count, sizeof(long long)); > > > > printf("Used %lld instructions\n", count); > > # ./hello_test_oprofile.o > > Measuring instruction count for this printf > > Used 3660 instructions > > > > On Tue, Feb 20, 2018 at 11:11 AM, Vinoth Natarajan <nvinothlive@...> wrote: > >    Hello Michael, > > Thanks so much for your valuable support. > > > > For time being am planning to use oprofile-0.9.9 version itself. > > Could you please share the test cases you have used to test the oprofile functionalities to its full potential. > > > > Kindly share all the test cases you have used, so that i dont miss on any test case/functionality of oprofile while i test. > > > > Thanks in advance!!! > > > > Thanks and Regards, > > Vinoth Natarajan. > > > > > > |
From: Vinoth Natarajan <nvinothlive@gm...> - 2018-04-05 14:14:18
|
Hello Team, opreport on oprofile-1.2.0 is throwing the following error. ./opreport -l /bin/abc Using /lib/oprofile/bin/oprofile_data/samples/ for samples directory. error: no sample files found: profile specification too strict ? same was working fine in oprofile-0.9.9. I have added all the dependencies and kernel configs . Please share your thoughts on this. Thanks and Regards, Vinoth Natarajan. On Tue, Mar 20, 2018 at 9:44 PM, Michael Petlan <mpetlan@...> wrote: > Hi Vinoth! > > This looks good, your machine's PMU and kernel seems to be OK. > > You need to do `make install` to have all the sub-tools installed > in $PATH. Your operf wants to run `ophelp` to find the default > event to be used. It does not find it in path, so it fails. I'd > recommend to do the full installation process. You can specify > various things to ./configure (target prefixes, etc.). > > Cheers, > Michael > > On Tue, 20 Mar 2018, Vinoth Natarajan wrote: > > Hello Michael, > > > > Good Day!!! > > > > Tried running the oprofile-1.2.0 on different ARM hardware which > supports PMU. > > But when we try to run operf binary,it show the following error. > > > > # ./operf --system-wide > > sh: /home/oprofile/bin/ophelp: not found > > Unable to find info for event CPU_CYCLES > > I have tried in internet about this error, No luck. > > Could you please let us know about this error. > > > > Note :- > > Following are the kernel configs related to PERF enabled on this 4.1 > kernel. > > CONFIG_HAVE_PERF_EVENTS=y > > CONFIG_PERF_USE_VMALLOC=y > > CONFIG_PERF_EVENTS=y > > # CONFIG_DEBUG_PERF_USE_VMALLOC is not set > > CONFIG_HAVE_PERF_REGS=y > > CONFIG_HAVE_PERF_USER_STACK_DUMP=y > > # CONFIG_PCIEASPM_PERFORMANCE is not set > > CONFIG_HW_PERF_EVENTS=y > > > > > > Code given from you is able to get the expected output from the new > hardware. > > > > ioctl(fd, PERF_EVENT_IOC_RESET, 0); > > ioctl(fd, PERF_EVENT_IOC_ENABLE, 0); > > > > printf("Measuring instruction count for this printf\n"); > > > > ioctl(fd, PERF_EVENT_IOC_DISABLE, 0); > > read(fd, &count, sizeof(long long)); > > > > printf("Used %lld instructions\n", count); > > # ./hello_test_oprofile.o > > Measuring instruction count for this printf > > Used 3660 instructions > > > > On Tue, Feb 20, 2018 at 11:11 AM, Vinoth Natarajan < > nvinothlive@...> wrote: > > Hello Michael, > > Thanks so much for your valuable support. > > > > For time being am planning to use oprofile-0.9.9 version itself. > > Could you please share the test cases you have used to test the oprofile > functionalities to its full potential. > > > > Kindly share all the test cases you have used, so that i dont miss on > any test case/functionality of oprofile while i test. > > > > Thanks in advance!!! > > > > Thanks and Regards, > > Vinoth Natarajan. > > > |
From: William Cohen <wcohen@nc...> - 2018-04-02 19:59:01
|
On 03/27/2018 04:07 PM, Carl Love wrote: > Will: > > I redid the patch as follows per your suggestions. I was able to get > on to a system where the issue occurs and test the patch. The patch > seems to work fine. > > Carl Love Thanks for the patch. It has been merged into the upstream oprofile. -Will > > ----------------------------------------------------------------------- > > The processor type for some Power 9 systems had a comma after POWER9. > Remove the comma before returning the string for the CPU. > --- > libop/op_cpu_type.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/libop/op_cpu_type.c b/libop/op_cpu_type.c > index feea948..d2babd1 100644 > --- a/libop/op_cpu_type.c > +++ b/libop/op_cpu_type.c > @@ -154,17 +154,17 @@ static char * _get_cpuinfo_cpu_type_line(char * buf, int len, const char * prefi > /* if token param 0 then read the whole line else > * first token only. */ > if (token == 0) { > - /* Trim trailing whitespace */ > + /* Trim trailing whitespace and commas */ > end = buf + strlen(buf) - 1; > - while (isspace(*end)) > + while (isspace(*end) || *end == ',') > --end; > *(++end) = '\0'; > break; > } else { > /* Scan ahead to the end of the token */ > - while (*buf && !isspace(*buf)) > + while (*buf && !(isspace(*buf) || *buf == ',')) > ++buf; > - /* Trim trailing whitespace */ > + /* Trim trailing whitespace and commas */ > *buf = '\0'; > break; > } |
From: Carl Love <cel@us...> - 2018-03-27 21:14:21
|
Will: I redid the patch as follows per your suggestions. I was able to get on to a system where the issue occurs and test the patch. The patch seems to work fine. Carl Love ----------------------------------------------------------------------- The processor type for some Power 9 systems had a comma after POWER9. Remove the comma before returning the string for the CPU. --- libop/op_cpu_type.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libop/op_cpu_type.c b/libop/op_cpu_type.c index feea948..d2babd1 100644 --- a/libop/op_cpu_type.c +++ b/libop/op_cpu_type.c @@ -154,17 +154,17 @@ static char * _get_cpuinfo_cpu_type_line(char * buf, int len, const char * prefi /* if token param 0 then read the whole line else * first token only. */ if (token == 0) { - /* Trim trailing whitespace */ + /* Trim trailing whitespace and commas */ end = buf + strlen(buf) - 1; - while (isspace(*end)) + while (isspace(*end) || *end == ',') --end; *(++end) = '\0'; break; } else { /* Scan ahead to the end of the token */ - while (*buf && !isspace(*buf)) + while (*buf && !(isspace(*buf) || *buf == ',')) ++buf; - /* Trim trailing whitespace */ + /* Trim trailing whitespace and commas */ *buf = '\0'; break; } -- 2.7.4 ---------------------------------------------------------------------- On Thu, 2018-03-22 at 15:33 -0400, William Cohen wrote: > On 03/16/2018 03:54 PM, Carl Love wrote: > > OProfile maintainers: > > > > A recent kernel for a Power 9 platform has the following entry in > > /proc/cpuinfo for the cpu, "POWER9, altivec supported".  The comma > > after the name POWER9 is being returned as part of the CPU > > type  string > > by the function _get_cpuinfo_cpu_type_line in op_cpu_type.c.  This > > results in the call to op_get_cpu_number() in the Power specific > > function _get_ppc64_cpu_type() to not find the processor type.  The > > net > > effect is operf and ophelp exit on an invalid CPU type.  The > > following > > patch removes any trailing commas in the Power processor cpu name. > > > > The patch has been tested on a Power 8LE and a Power9 system. > > > > Please let me know if the patch is acceptable.  Thanks. > > > >                         Carl Love > > > > > > ---------------------------------------- > > PowerPC: Remove trailing comma in cpu_name. > > > > The processor type for some Power 9 systems had a comma after > > POWER9. > > Remove the comma before returning the string for the CPU. > > --- > >  libop/op_cpu_type.c | 5 +++++ > >  1 file changed, 5 insertions(+) > > > > diff --git a/libop/op_cpu_type.c b/libop/op_cpu_type.c > > index feea948..e96360f 100644 > > --- a/libop/op_cpu_type.c > > +++ b/libop/op_cpu_type.c > > @@ -171,6 +171,11 @@ static char * _get_cpuinfo_cpu_type_line(char > > * buf, int len, const char * prefi > >  } > >  } > >  > > + /* Remove comma the end of the name if it exists.   */ > > + end = buf; > > + if (*(--end) == ',') > > + *(--buf) = '\0'; > > + > >  fclose(fp); > >  return ret; > >  } > > Hi Carl, > > Would it be clearer fold this comma removal into the existing loops > for trimming trailing white space? Or are there cases where the might > be a ',' somewhere other than the end of the buffer? Something like > the the attached. It compiles, but has not been tested. > > -Will > > > ------------------------------------------------------------------- > ----------- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > oprofile-list mailing list > oprofile-list@... > https://lists.sourceforge.net/lists/listinfo/oprofile-list |
From: William Cohen <wcohen@nc...> - 2018-03-22 19:34:20
|
On 03/16/2018 03:54 PM, Carl Love wrote: > OProfile maintainers: > > A recent kernel for a Power 9 platform has the following entry in > /proc/cpuinfo for the cpu, "POWER9, altivec supported". The comma > after the name POWER9 is being returned as part of the CPU type string > by the function _get_cpuinfo_cpu_type_line in op_cpu_type.c. This > results in the call to op_get_cpu_number() in the Power specific > function _get_ppc64_cpu_type() to not find the processor type. The net > effect is operf and ophelp exit on an invalid CPU type. The following > patch removes any trailing commas in the Power processor cpu name. > > The patch has been tested on a Power 8LE and a Power9 system. > > Please let me know if the patch is acceptable. Thanks. > > Carl Love > > > ---------------------------------------- > PowerPC: Remove trailing comma in cpu_name. > > The processor type for some Power 9 systems had a comma after POWER9. > Remove the comma before returning the string for the CPU. > --- > libop/op_cpu_type.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/libop/op_cpu_type.c b/libop/op_cpu_type.c > index feea948..e96360f 100644 > --- a/libop/op_cpu_type.c > +++ b/libop/op_cpu_type.c > @@ -171,6 +171,11 @@ static char * _get_cpuinfo_cpu_type_line(char * buf, int len, const char * prefi > } > } > > + /* Remove comma the end of the name if it exists. */ > + end = buf; > + if (*(--end) == ',') > + *(--buf) = '\0'; > + > fclose(fp); > return ret; > } Hi Carl, Would it be clearer fold this comma removal into the existing loops for trimming trailing white space? Or are there cases where the might be a ',' somewhere other than the end of the buffer? Something like the the attached. It compiles, but has not been tested. -Will |
From: Michael Petlan <mpetlan@re...> - 2018-03-20 16:15:03
|
Hi Vinoth! This looks good, your machine's PMU and kernel seems to be OK. You need to do `make install` to have all the sub-tools installed in $PATH. Your operf wants to run `ophelp` to find the default event to be used. It does not find it in path, so it fails. I'd recommend to do the full installation process. You can specify various things to ./configure (target prefixes, etc.). Cheers, Michael On Tue, 20 Mar 2018, Vinoth Natarajan wrote: > Hello Michael, > > Good Day!!! > > Tried running the oprofile-1.2.0 on different ARM hardware which supports PMU. > But when we try to run operf binary,it show the following error. > > # ./operf --system-wide > sh: /home/oprofile/bin/ophelp: not found > Unable to find info for event CPU_CYCLES > I have tried in internet about this error, No luck. > Could you please let us know about this error. > > Note :- > Following are the kernel configs related to PERF enabled on this 4.1 kernel. > CONFIG_HAVE_PERF_EVENTS=y > CONFIG_PERF_USE_VMALLOC=y > CONFIG_PERF_EVENTS=y > # CONFIG_DEBUG_PERF_USE_VMALLOC is not set > CONFIG_HAVE_PERF_REGS=y > CONFIG_HAVE_PERF_USER_STACK_DUMP=y > # CONFIG_PCIEASPM_PERFORMANCE is not set > CONFIG_HW_PERF_EVENTS=y > > > Code given from you is able to get the expected output from the new hardware. > > ioctl(fd, PERF_EVENT_IOC_RESET, 0); > ioctl(fd, PERF_EVENT_IOC_ENABLE, 0); > > printf("Measuring instruction count for this printf\n"); > > ioctl(fd, PERF_EVENT_IOC_DISABLE, 0); > read(fd, &count, sizeof(long long)); > > printf("Used %lld instructions\n", count); > # ./hello_test_oprofile.o > Measuring instruction count for this printf > Used 3660 instructions > > On Tue, Feb 20, 2018 at 11:11 AM, Vinoth Natarajan <nvinothlive@...> wrote: > Hello Michael, > Thanks so much for your valuable support. > > For time being am planning to use oprofile-0.9.9 version itself. > Could you please share the test cases you have used to test the oprofile functionalities to its full potential. > > Kindly share all the test cases you have used, so that i dont miss on any test case/functionality of oprofile while i test. > > Thanks in advance!!! > > Thanks and Regards, > Vinoth Natarajan. > |
From: Vinoth Natarajan <nvinothlive@gm...> - 2018-03-20 13:43:39
|
Hello Michael, Good Day!!! *Tried running the oprofile-1.2.0 on different ARM hardware which supports PMU.* *But when we try to run operf binary,it show the following error.* *# ./operf --system-wide* * sh: /home/oprofile/bin/ophelp: not found* * Unable to find info for event CPU_CYCLES* I have tried in internet about this error, No luck. Could you please let us know about this error. Note :- Following are the kernel configs related to PERF enabled on this 4.1 kernel. CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_USE_VMALLOC=y CONFIG_PERF_EVENTS=y # CONFIG_DEBUG_PERF_USE_VMALLOC is not set CONFIG_HAVE_PERF_REGS=y CONFIG_HAVE_PERF_USER_STACK_DUMP=y # CONFIG_PCIEASPM_PERFORMANCE is not set CONFIG_HW_PERF_EVENTS=y Code given from you is able to get the expected output from the new hardware. ioctl(fd, PERF_EVENT_IOC_RESET, 0); ioctl(fd, PERF_EVENT_IOC_ENABLE, 0); printf("Measuring instruction count for this printf\n"); ioctl(fd, PERF_EVENT_IOC_DISABLE, 0); read(fd, &count, sizeof(long long)); printf("Used %lld instructions\n", count); # ./hello_test_oprofile.o Measuring instruction count for this printf Used 3660 instructions On Tue, Feb 20, 2018 at 11:11 AM, Vinoth Natarajan <nvinothlive@...> wrote: > Hello Michael, > > Thanks so much for your valuable support. > > For time being am planning to use oprofile-0.9.9 version itself. > Could you please share the test cases you have used to test the oprofile > functionalities to its full potential. > > Kindly share all the test cases you have used, so that i dont miss on any > test case/functionality of oprofile while i test. > > Thanks in advance!!! > > Thanks and Regards, > Vinoth Natarajan. > > On Fri, Feb 16, 2018 at 8:39 PM, Michael Petlan <mpetlan@...> > wrote: > >> On Fri, 16 Feb 2018, Vinoth Natarajan wrote: >> > No, it doesn't Michael. it threw "Error opening leader 1" Error.. >> >> This error means that the syscall requesting perf even opening in kernel >> fails. Since it is the simplest call possible, it probably means that >> your kernel is still not configured OK or it really does not know the >> CPU. I don't know much about arm32 stuff, similar to armv7. I have been >> testing oprofile on some armv8 aarch64 processors only (wrt ARM). >> >> Michael >> > >> > Thanks and Regards, >> > Vinoth Natarajan. >> > >> > On 16-Feb-2018 8:10 PM, "Michael Petlan" <mpetlan@...> wrote: >> > Does my hello.c work with the kernel rebuilt with >> CONFIG_HW_PERF_EVENTS=y ? >> > >> > On Fri, 16 Feb 2018, Vinoth Natarajan wrote: >> > > Hello Michael, >> > > I have enabled the CONFIG_HW_PERF_EVENTS and tried oprofile >> -1.2.0 in the target. >> > > >> > > Still the old error persists " ./operf >> > > Your kernel's Performance Events Subsystem does not support >> your processor type." >> > > >> > > dmesg | grep -i -e perf -e pmu >> > > oprofile: no performance counters >> > > >> > > In dmesg logs, it shows as no performance counters >> > > >> > > Could you please share your feedback. >> > > >> > > Thanks in Advance!!! >> > > >> > > Thanks and Regards, >> > > Vinoth Natarajan. >> > > >> > > On Thu, Feb 15, 2018 at 9:37 PM, Michael Petlan < >> mpetlan@...> wrote: >> > > On Thu, 15 Feb 2018, Vinoth Natarajan wrote: >> > > > Hello Michael, >> > > > Thanks so much for the help. >> > > > >> > > > Cross compiled the hello.c with >> crosstools-arm-gcc-5.3-linux-4.1-glibc-2.22 >> > > > and tested the executable on the target(arm32) >> > > > >> > > > Received the following error >> > > > " ./hello >> > > > Error opening leader 1" >> > > > >> > > >> > > This points to the kernel perf subsystem. It cannot even >> open a simple event. >> > > Not an OProfile's fault. >> > > >> > > > >> > > > Following are the kernel configs related to PERF in >> target >> > > > >> > > > cat /tmp/test |grep PERF >> > > > >> > > > CONFIG_HAVE_PERF_EVENTS=y >> > > > CONFIG_PERF_USE_VMALLOC=y >> > > > CONFIG_PERF_EVENTS=y >> > > > # CONFIG_DEBUG_PERF_USE_VMALLOC is not set >> > > > CONFIG_HAVE_PERF_REGS=y >> > > > CONFIG_HAVE_PERF_USER_STACK_DUMP=y >> > > > # CONFIG_PCIEASPM_PERFORMANCE is not set >> > > > # CONFIG_HW_PERF_EVENTS is not set >> > > >> > > I believe you need CONFIG_HW_PERF_EVENTS=y on ARM. >> > > >> > > > # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set >> > > > # CONFIG_CPU_FREQ_GOV_PERFORMANCE is not set >> > > > # CONFIG_CLS_U32_PERF is not set >> > > > >> > > > Could you please share your feedback on this. >> > > >> > > You may also try to grep for perf in logs: >> > > >> > > # dmesg | grep -i -e perf -e pmu >> > > [ 1.375699] hw perfevents: enabled with armv8_pmuv3_0 >> PMU driver, 5 counters available >> > > [ 1.403155] kvm [1]: GICV region size/alignment is >> unsafe, using trapping (reduced performance) >> > > [ 2.036285] xgene-pmu APMC0D5C:00: X-Gene PMU version 2 >> > > >> > > ^^^ This is a log from the moment when my kernel >> identified and initialized >> > > the PMU. You should see something like that too. Or >> better, after recompiling >> > > your kernel with CONFIG_HW_PERF_EVENTS=y and booting, you >> should see something >> > > like this (PMU-related logs). If there is some error in >> PMU init, you will see >> > > it in the logs. >> > > >> > > I am afraid that without CONFIG_HW_PERF_EVENTS=y you >> cannot use the events. >> > > >> > > However, I don't guarantee that with >> CONFIG_HW_PERF_EVENTS=y it works. There >> > > can be some firmware issues, ACPI issues, etc. I roughly >> remember some issue >> > > when you'd need to boot with acpi=off to access the >> events, etc. >> > > >> > > Cheers, >> > > Michael >> > > >> > > > >> > > > Thanks in Advance!!! >> > > > >> > > > Thanks and Regards, >> > > > Vinoth Natarajan. >> > > > >> > > [...] >> > > >> > > >> > > >> > > >> > >> > >> > >> > > |
From: Fengguang Wu <fengguang.wu@in...> - 2018-03-17 07:33:11
|
On Thu, Mar 15, 2018 at 09:04:04AM +0100, Arnd Bergmann wrote: >On Thu, Mar 15, 2018 at 3:51 AM, Deepa Dinamani <deepa.kernel@...> wrote: >> On Wed, Mar 14, 2018 at 1:52 PM, Arnd Bergmann <arnd@...> wrote: >>> On Wed, Mar 14, 2018 at 4:50 AM, Deepa Dinamani <deepa.kernel@...> wrote: >>>> The file arch/arm64/kernel/process.c needs asm/compat.h also to be >>>> included directly since this is included conditionally from >>>> include/compat.h. This does seem to be typical of arm64 as I was not >>>> completely able to get rid of asm/compat.h includes for arm64 in this >>>> series. My plan is to have separate patches to get rid of asm/compat.h >>>> includes for the architectures that are not straight forward to keep >>>> this series simple. >>>> I will fix this and update the series. >>>> >>> >>> I ran across the same thing in two more files during randconfig testing on >>> arm64 now, adding this fixup on top for the moment, but maybe there >>> is a better way: >> >> I was looking at how Al tested his uaccess patches: >> https://www.spinics.net/lists/linux-fsdevel/msg108752.html >> >> He seems to be running the kbuild bot tests on his own git. >> Is it possible to verify it this way on the 2038 tree? Or, I could >> host a tree also. > >The kbuild bot should generally pick up any branch on git.kernel.org, >and the patches sent to the mailing list. It tests a lot of things >configurations, but I tend to find some things that it doesn't find >by doing lots of randconfig builds on fewer target architectures >(I only build arm, arm64 and x86 regularly). > >I remember that there was some discussion about a method >to get the bot to test other branches (besides asking Fengguang >to add it manually), but I don't remember what came out of that. People can send email to me or lkp@... for adding new git URLs to 0day tests. Such requests are very welcome. Server load is not a problem -- don't worry about your git pushes adding our test load. By default all branches in a git tree will be tested, unless there are explicit blacklist/whitelist. We also have scripts to scan git.kernel.org/github/LKML looking for possible new git URLs to add to 0day kbuild tests. However depending on the team's maintenance pressure they may or may not run frequently. Thanks, Fengguang |
From: Carl Love <cel@us...> - 2018-03-16 19:54:45
|
OProfile maintainers: A recent kernel for a Power 9 platform has the following entry in /proc/cpuinfo for the cpu, "POWER9, altivec supported". The comma after the name POWER9 is being returned as part of the CPU type string by the function _get_cpuinfo_cpu_type_line in op_cpu_type.c. This results in the call to op_get_cpu_number() in the Power specific function _get_ppc64_cpu_type() to not find the processor type. The net effect is operf and ophelp exit on an invalid CPU type. The following patch removes any trailing commas in the Power processor cpu name. The patch has been tested on a Power 8LE and a Power9 system. Please let me know if the patch is acceptable. Thanks. Carl Love ---------------------------------------- PowerPC: Remove trailing comma in cpu_name. The processor type for some Power 9 systems had a comma after POWER9. Remove the comma before returning the string for the CPU. --- libop/op_cpu_type.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/libop/op_cpu_type.c b/libop/op_cpu_type.c index feea948..e96360f 100644 --- a/libop/op_cpu_type.c +++ b/libop/op_cpu_type.c @@ -171,6 +171,11 @@ static char * _get_cpuinfo_cpu_type_line(char * buf, int len, const char * prefi } } + /* Remove comma the end of the name if it exists. */ + end = buf; + if (*(--end) == ',') + *(--buf) = '\0'; + fclose(fp); return ret; } -- 2.7.4 |
From: Arnd Bergmann <arnd@ar...> - 2018-03-15 08:04:12
|
On Thu, Mar 15, 2018 at 3:51 AM, Deepa Dinamani <deepa.kernel@...> wrote: > On Wed, Mar 14, 2018 at 1:52 PM, Arnd Bergmann <arnd@...> wrote: >> On Wed, Mar 14, 2018 at 4:50 AM, Deepa Dinamani <deepa.kernel@...> wrote: >>> The file arch/arm64/kernel/process.c needs asm/compat.h also to be >>> included directly since this is included conditionally from >>> include/compat.h. This does seem to be typical of arm64 as I was not >>> completely able to get rid of asm/compat.h includes for arm64 in this >>> series. My plan is to have separate patches to get rid of asm/compat.h >>> includes for the architectures that are not straight forward to keep >>> this series simple. >>> I will fix this and update the series. >>> >> >> I ran across the same thing in two more files during randconfig testing on >> arm64 now, adding this fixup on top for the moment, but maybe there >> is a better way: > > I was looking at how Al tested his uaccess patches: > https://www.spinics.net/lists/linux-fsdevel/msg108752.html > > He seems to be running the kbuild bot tests on his own git. > Is it possible to verify it this way on the 2038 tree? Or, I could > host a tree also. The kbuild bot should generally pick up any branch on git.kernel.org, and the patches sent to the mailing list. It tests a lot of things configurations, but I tend to find some things that it doesn't find by doing lots of randconfig builds on fewer target architectures (I only build arm, arm64 and x86 regularly). I remember that there was some discussion about a method to get the bot to test other branches (besides asking Fengguang to add it manually), but I don't remember what came out of that. Arnd |
From: Deepa Dinamani <deepa.kernel@gm...> - 2018-03-15 02:51:39
|
On Wed, Mar 14, 2018 at 1:52 PM, Arnd Bergmann <arnd@...> wrote: > On Wed, Mar 14, 2018 at 4:50 AM, Deepa Dinamani <deepa.kernel@...> wrote: >> The file arch/arm64/kernel/process.c needs asm/compat.h also to be >> included directly since this is included conditionally from >> include/compat.h. This does seem to be typical of arm64 as I was not >> completely able to get rid of asm/compat.h includes for arm64 in this >> series. My plan is to have separate patches to get rid of asm/compat.h >> includes for the architectures that are not straight forward to keep >> this series simple. >> I will fix this and update the series. >> > > I ran across the same thing in two more files during randconfig testing on > arm64 now, adding this fixup on top for the moment, but maybe there > is a better way: I was looking at how Al tested his uaccess patches: https://www.spinics.net/lists/linux-fsdevel/msg108752.html He seems to be running the kbuild bot tests on his own git. Is it possible to verify it this way on the 2038 tree? Or, I could host a tree also. Thanks, Deepa |
From: Arnd Bergmann <arnd@ar...> - 2018-03-14 20:52:29
|
On Wed, Mar 14, 2018 at 4:50 AM, Deepa Dinamani <deepa.kernel@...> wrote: > The file arch/arm64/kernel/process.c needs asm/compat.h also to be > included directly since this is included conditionally from > include/compat.h. This does seem to be typical of arm64 as I was not > completely able to get rid of asm/compat.h includes for arm64 in this > series. My plan is to have separate patches to get rid of asm/compat.h > includes for the architectures that are not straight forward to keep > this series simple. > I will fix this and update the series. > I ran across the same thing in two more files during randconfig testing on arm64 now, adding this fixup on top for the moment, but maybe there is a better way: commit 4f3e9e1211799a79b201a1af309a1ec3864147ec Author: Arnd Bergmann <arnd@...> Date: Wed Mar 14 18:23:16 2018 +0100 arm64: fix perf_regs.c arch/arm64/kernel/perf_regs.c: In function 'perf_reg_abi': arch/arm64/kernel/perf_regs.c:50:6: error: implicit declaration of function 'is_compat_thread'; did you mean 'is_compat_task'? [-Werror=implicit-function-declaration] arch/arm64/kernel/hw_breakpoint.c: In function 'is_compat_bp': arch/arm64/kernel/hw_breakpoint.c:182:16: error: implicit declaration of function 'is_compat_thread'; did you mean 'is_compat_task'? [-Werror=implicit-function-declaration] Signed-off-by: Arnd Bergmann <arnd@...> diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c index 413dbe530da8..74bb56f656ef 100644 --- a/arch/arm64/kernel/hw_breakpoint.c +++ b/arch/arm64/kernel/hw_breakpoint.c @@ -30,6 +30,7 @@ #include <linux/smp.h> #include <linux/uaccess.h> +#include <asm/compat.h> #include <asm/current.h> #include <asm/debug-monitors.h> #include <asm/hw_breakpoint.h> diff --git a/arch/arm64/kernel/perf_regs.c b/arch/arm64/kernel/perf_regs.c index 0bbac612146e..1b463a4efe49 100644 --- a/arch/arm64/kernel/perf_regs.c +++ b/arch/arm64/kernel/perf_regs.c @@ -6,6 +6,7 @@ #include <linux/bug.h> #include <linux/sched/task_stack.h> +#include <asm/compat.h> #include <asm/perf_regs.h> #include <asm/ptrace.h> |
From: Arnd Bergmann <arnd@ar...> - 2018-03-14 16:12:52
|
On Wed, Mar 14, 2018 at 5:03 AM, Deepa Dinamani <deepa.kernel@...> wrote: > The series is a preparation series for individual architectures > to use 64 bit time_t syscalls in compat and 32 bit emulation modes. > > This is a follow up to the series Arnd Bergmann posted: > https://sourceware.org/ml/libc-alpha/2015-05/msg00070.html [1] > > Thomas, Arnd, this seems ready to be merged now. > Can you help get this merged? > > Big picture is as per the lwn article: > https://lwn.net/Articles/643234/ [2] > > The series is directed at converting posix clock syscalls: > clock_gettime, clock_settime, clock_getres and clock_nanosleep > to use a new data structure __kernel_timespec at syscall boundaries. > __kernel_timespec maintains 64 bit time_t across all execution modes. > > vdso will be handled as part of each architecture when they enable > support for 64 bit time_t. > > The compat syscalls are repurposed to provide backward compatibility > by using them as native syscalls as well for 32 bit architectures. > They will continue to use timespec at syscall boundaries. > > CONFIG_64_BIT_TIME controls whether the syscalls use __kernel_timespec > or timespec at syscall boundaries. > > The series does the following: > 1. Enable compat syscalls on 32 bit architectures. > 2. Add a new __kernel_timespec type to be used as the data structure > for all the new syscalls. > 3. Add new config CONFIG_64BIT_TIME(intead of the CONFIG_COMPAT_TIME in > [1] and [2] to switch to new definition of __kernel_timespec. It is > the same as struct timespec otherwise. > 4. Add new CONFIG_32BIT_TIME to conditionally compile compat syscalls. I've applied all 10 patches to my y2038 git branch [1], which is part of linux-next, to give it a little wider testing. If everything goes well, I'd send a pull request to Thomas next week so he can integrate it into tip from there, or (if he prefers) send it directly to Linus in the merge window. Thanks a lot for your persistence and your work on this! Arnd [1] git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git#y2038 |
From: Deepa Dinamani <deepa.kernel@gm...> - 2018-03-14 04:05:07
|
All the current architecture specific defines for these are the same. Refactor these common defines to a common header file. The new common linux/compat_time.h is also useful as it will eventually be used to hold all the defines that are needed for compat time types that support non y2038 safe types. New architectures need not have to define these new types as they will only use new y2038 safe syscalls. This file can be deleted after y2038 when we stop supporting non y2038 safe syscalls. The patch also requires an operation similar to: git grep "asm/compat\.h" | cut -d ":" -f 1 | xargs -n 1 sed -i -e "s%asm/compat.h%linux/compat.h%g" Cc: acme@... Cc: benh@... Cc: borntraeger@... Cc: catalin.marinas@... Cc: cmetcalf@... Cc: cohuck@... Cc: davem@... Cc: deller@... Cc: devel@... Cc: gerald.schaefer@... Cc: gregkh@... Cc: heiko.carstens@... Cc: hoeppner@... Cc: hpa@... Cc: jejb@... Cc: jwi@... Cc: linux-kernel@... Cc: linux-mips@... Cc: linux-parisc@... Cc: linuxppc-dev@... Cc: linux-s390@... Cc: mark.rutland@... Cc: mingo@... Cc: mpe@... Cc: oberpar@... Cc: oprofile-list@... Cc: paulus@... Cc: peterz@... Cc: ralf@... Cc: rostedt@... Cc: rric@... Cc: schwidefsky@... Cc: sebott@... Cc: sparclinux@... Cc: sth@... Cc: ubraun@... Cc: will.deacon@... Cc: x86@... Signed-off-by: Arnd Bergmann <arnd@...> Signed-off-by: Deepa Dinamani <deepa.kernel@...> Acked-by: Steven Rostedt (VMware) <rostedt@...> Acked-by: Catalin Marinas <catalin.marinas@...> Acked-by: James Hogan <jhogan@...> Acked-by: Helge Deller <deller@...> --- arch/arm64/include/asm/compat.h | 11 ----------- arch/arm64/include/asm/stat.h | 1 + arch/arm64/kernel/hw_breakpoint.c | 1 - arch/arm64/kernel/perf_regs.c | 2 +- arch/mips/include/asm/compat.h | 11 ----------- arch/mips/kernel/signal32.c | 2 +- arch/parisc/include/asm/compat.h | 11 ----------- arch/powerpc/include/asm/compat.h | 11 ----------- arch/powerpc/kernel/asm-offsets.c | 2 +- arch/powerpc/oprofile/backtrace.c | 1 + arch/s390/hypfs/hypfs_sprp.c | 1 - arch/s390/include/asm/compat.h | 11 ----------- arch/s390/include/asm/elf.h | 4 ++-- arch/s390/kvm/priv.c | 1 - arch/s390/pci/pci_clp.c | 1 - arch/sparc/include/asm/compat.h | 11 ----------- arch/tile/include/asm/compat.h | 11 ----------- arch/x86/events/core.c | 2 +- arch/x86/include/asm/compat.h | 11 ----------- arch/x86/include/asm/ftrace.h | 2 +- arch/x86/include/asm/sys_ia32.h | 2 +- arch/x86/kernel/sys_x86_64.c | 2 +- drivers/s390/block/dasd_ioctl.c | 1 - drivers/s390/char/fs3270.c | 1 - drivers/s390/char/sclp_ctl.c | 1 - drivers/s390/char/vmcp.c | 1 - drivers/s390/cio/chsc_sch.c | 1 - drivers/s390/net/qeth_core_main.c | 2 +- include/linux/compat.h | 1 + include/linux/compat_time.h | 19 +++++++++++++++++++ 30 files changed, 32 insertions(+), 107 deletions(-) create mode 100644 include/linux/compat_time.h diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h index c00c62e1a4a3..0030f79808b3 100644 --- a/arch/arm64/include/asm/compat.h +++ b/arch/arm64/include/asm/compat.h @@ -34,7 +34,6 @@ typedef u32 compat_size_t; typedef s32 compat_ssize_t; -typedef s32 compat_time_t; typedef s32 compat_clock_t; typedef s32 compat_pid_t; typedef u16 __compat_uid_t; @@ -66,16 +65,6 @@ typedef u32 compat_ulong_t; typedef u64 compat_u64; typedef u32 compat_uptr_t; -struct compat_timespec { - compat_time_t tv_sec; - s32 tv_nsec; -}; - -struct compat_timeval { - compat_time_t tv_sec; - s32 tv_usec; -}; - struct compat_stat { #ifdef __AARCH64EB__ short st_dev; diff --git a/arch/arm64/include/asm/stat.h b/arch/arm64/include/asm/stat.h index 15e35598ac40..eab738019707 100644 --- a/arch/arm64/include/asm/stat.h +++ b/arch/arm64/include/asm/stat.h @@ -20,6 +20,7 @@ #ifdef CONFIG_COMPAT +#include <linux/compat_time.h> #include <asm/compat.h> /* diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c index 74bb56f656ef..413dbe530da8 100644 --- a/arch/arm64/kernel/hw_breakpoint.c +++ b/arch/arm64/kernel/hw_breakpoint.c @@ -30,7 +30,6 @@ #include <linux/smp.h> #include <linux/uaccess.h> -#include <asm/compat.h> #include <asm/current.h> #include <asm/debug-monitors.h> #include <asm/hw_breakpoint.h> diff --git a/arch/arm64/kernel/perf_regs.c b/arch/arm64/kernel/perf_regs.c index 1d091d048d04..0bbac612146e 100644 --- a/arch/arm64/kernel/perf_regs.c +++ b/arch/arm64/kernel/perf_regs.c @@ -1,11 +1,11 @@ // SPDX-License-Identifier: GPL-2.0 +#include <linux/compat.h> #include <linux/errno.h> #include <linux/kernel.h> #include <linux/perf_event.h> #include <linux/bug.h> #include <linux/sched/task_stack.h> -#include <asm/compat.h> #include <asm/perf_regs.h> #include <asm/ptrace.h> diff --git a/arch/mips/include/asm/compat.h b/arch/mips/include/asm/compat.h index 9a0fa66b81ac..3e548ee99a2f 100644 --- a/arch/mips/include/asm/compat.h +++ b/arch/mips/include/asm/compat.h @@ -14,7 +14,6 @@ typedef u32 compat_size_t; typedef s32 compat_ssize_t; -typedef s32 compat_time_t; typedef s32 compat_clock_t; typedef s32 compat_suseconds_t; @@ -46,16 +45,6 @@ typedef u32 compat_ulong_t; typedef u64 compat_u64; typedef u32 compat_uptr_t; -struct compat_timespec { - compat_time_t tv_sec; - s32 tv_nsec; -}; - -struct compat_timeval { - compat_time_t tv_sec; - s32 tv_usec; -}; - struct compat_stat { compat_dev_t st_dev; s32 st_pad1[3]; diff --git a/arch/mips/kernel/signal32.c b/arch/mips/kernel/signal32.c index c4db910a8794..b5d9e1784aff 100644 --- a/arch/mips/kernel/signal32.c +++ b/arch/mips/kernel/signal32.c @@ -8,13 +8,13 @@ * Copyright (C) 1999, 2000 Silicon Graphics, Inc. * Copyright (C) 2016, Imagination Technologies Ltd. */ +#include <linux/compat.h> #include <linux/compiler.h> #include <linux/errno.h> #include <linux/kernel.h> #include <linux/signal.h> #include <linux/syscalls.h> -#include <asm/compat.h> #include <asm/compat-signal.h> #include <linux/uaccess.h> #include <asm/unistd.h> diff --git a/arch/parisc/include/asm/compat.h b/arch/parisc/include/asm/compat.h index c22db5323244..6f256e7b95e3 100644 --- a/arch/parisc/include/asm/compat.h +++ b/arch/parisc/include/asm/compat.h @@ -13,7 +13,6 @@ typedef u32 compat_size_t; typedef s32 compat_ssize_t; -typedef s32 compat_time_t; typedef s32 compat_clock_t; typedef s32 compat_pid_t; typedef u32 __compat_uid_t; @@ -40,16 +39,6 @@ typedef u32 compat_ulong_t; typedef u64 compat_u64; typedef u32 compat_uptr_t; -struct compat_timespec { - compat_time_t tv_sec; - s32 tv_nsec; -}; - -struct compat_timeval { - compat_time_t tv_sec; - s32 tv_usec; -}; - struct compat_stat { compat_dev_t st_dev; /* dev_t is 32 bits on parisc */ compat_ino_t st_ino; /* 32 bits */ diff --git a/arch/powerpc/include/asm/compat.h b/arch/powerpc/include/asm/compat.h index 62168e1158f1..b4773c81f7d5 100644 --- a/arch/powerpc/include/asm/compat.h +++ b/arch/powerpc/include/asm/compat.h @@ -17,7 +17,6 @@ typedef u32 compat_size_t; typedef s32 compat_ssize_t; -typedef s32 compat_time_t; typedef s32 compat_clock_t; typedef s32 compat_pid_t; typedef u32 __compat_uid_t; @@ -45,16 +44,6 @@ typedef u32 compat_ulong_t; typedef u64 compat_u64; typedef u32 compat_uptr_t; -struct compat_timespec { - compat_time_t tv_sec; - s32 tv_nsec; -}; - -struct compat_timeval { - compat_time_t tv_sec; - s32 tv_usec; -}; - struct compat_stat { compat_dev_t st_dev; compat_ino_t st_ino; diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c index ea5eb91b836e..4a314620344f 100644 --- a/arch/powerpc/kernel/asm-offsets.c +++ b/arch/powerpc/kernel/asm-offsets.c @@ -13,6 +13,7 @@ * 2 of the License, or (at your option) any later version. */ +#include <linux/compat.h> #include <linux/signal.h> #include <linux/sched.h> #include <linux/kernel.h> @@ -42,7 +43,6 @@ #include <asm/paca.h> #include <asm/lppaca.h> #include <asm/cache.h> -#include <asm/compat.h> #include <asm/mmu.h> #include <asm/hvcall.h> #include <asm/xics.h> diff --git a/arch/powerpc/oprofile/backtrace.c b/arch/powerpc/oprofile/backtrace.c index ecc66d5f02c9..ad054dd0d666 100644 --- a/arch/powerpc/oprofile/backtrace.c +++ b/arch/powerpc/oprofile/backtrace.c @@ -7,6 +7,7 @@ * 2 of the License, or (at your option) any later version. **/ +#include <linux/compat_time.h> #include <linux/oprofile.h> #include <linux/sched.h> #include <asm/processor.h> diff --git a/arch/s390/hypfs/hypfs_sprp.c b/arch/s390/hypfs/hypfs_sprp.c index ae0ed8dd5f1b..5d85a039391c 100644 --- a/arch/s390/hypfs/hypfs_sprp.c +++ b/arch/s390/hypfs/hypfs_sprp.c @@ -13,7 +13,6 @@ #include <linux/string.h> #include <linux/types.h> #include <linux/uaccess.h> -#include <asm/compat.h> #include <asm/diag.h> #include <asm/sclp.h> #include "hypfs.h" diff --git a/arch/s390/include/asm/compat.h b/arch/s390/include/asm/compat.h index 9830fb6b076e..501aaff85304 100644 --- a/arch/s390/include/asm/compat.h +++ b/arch/s390/include/asm/compat.h @@ -53,7 +53,6 @@ typedef u32 compat_size_t; typedef s32 compat_ssize_t; -typedef s32 compat_time_t; typedef s32 compat_clock_t; typedef s32 compat_pid_t; typedef u16 __compat_uid_t; @@ -97,16 +96,6 @@ typedef struct { u32 gprs_high[NUM_GPRS]; } s390_compat_regs_high; -struct compat_timespec { - compat_time_t tv_sec; - s32 tv_nsec; -}; - -struct compat_timeval { - compat_time_t tv_sec; - s32 tv_usec; -}; - struct compat_stat { compat_dev_t st_dev; u16 __pad1; diff --git a/arch/s390/include/asm/elf.h b/arch/s390/include/asm/elf.h index 1a61b1b997f2..7d22a474a040 100644 --- a/arch/s390/include/asm/elf.h +++ b/arch/s390/include/asm/elf.h @@ -125,8 +125,9 @@ * ELF register definitions.. */ +#include <linux/compat.h> + #include <asm/ptrace.h> -#include <asm/compat.h> #include <asm/syscall.h> #include <asm/user.h> @@ -136,7 +137,6 @@ typedef s390_regs elf_gregset_t; typedef s390_fp_regs compat_elf_fpregset_t; typedef s390_compat_regs compat_elf_gregset_t; -#include <linux/compat.h> #include <linux/sched/mm.h> /* for task_struct */ #include <asm/mmu_context.h> diff --git a/arch/s390/kvm/priv.c b/arch/s390/kvm/priv.c index ebfa0442e569..a3bce0e84346 100644 --- a/arch/s390/kvm/priv.c +++ b/arch/s390/kvm/priv.c @@ -26,7 +26,6 @@ #include <asm/gmap.h> #include <asm/io.h> #include <asm/ptrace.h> -#include <asm/compat.h> #include <asm/sclp.h> #include "gaccess.h" #include "kvm-s390.h" diff --git a/arch/s390/pci/pci_clp.c b/arch/s390/pci/pci_clp.c index 93cd0f1ca12b..19b2d2a9b43d 100644 --- a/arch/s390/pci/pci_clp.c +++ b/arch/s390/pci/pci_clp.c @@ -19,7 +19,6 @@ #include <linux/uaccess.h> #include <asm/pci_debug.h> #include <asm/pci_clp.h> -#include <asm/compat.h> #include <asm/clp.h> #include <uapi/asm/clp.h> diff --git a/arch/sparc/include/asm/compat.h b/arch/sparc/include/asm/compat.h index 615283e16f22..844a89739e76 100644 --- a/arch/sparc/include/asm/compat.h +++ b/arch/sparc/include/asm/compat.h @@ -11,7 +11,6 @@ typedef u32 compat_size_t; typedef s32 compat_ssize_t; -typedef s32 compat_time_t; typedef s32 compat_clock_t; typedef s32 compat_pid_t; typedef u16 __compat_uid_t; @@ -39,16 +38,6 @@ typedef u32 compat_ulong_t; typedef u64 compat_u64; typedef u32 compat_uptr_t; -struct compat_timespec { - compat_time_t tv_sec; - s32 tv_nsec; -}; - -struct compat_timeval { - compat_time_t tv_sec; - s32 tv_usec; -}; - struct compat_stat { compat_dev_t st_dev; compat_ino_t st_ino; diff --git a/arch/tile/include/asm/compat.h b/arch/tile/include/asm/compat.h index 769ff6ac0bf5..06188e0da2de 100644 --- a/arch/tile/include/asm/compat.h +++ b/arch/tile/include/asm/compat.h @@ -29,7 +29,6 @@ typedef u32 compat_ulong_t; typedef u32 compat_size_t; typedef s32 compat_ssize_t; typedef s32 compat_off_t; -typedef s32 compat_time_t; typedef s32 compat_clock_t; typedef u32 compat_ino_t; typedef u32 compat_caddr_t; @@ -59,16 +58,6 @@ typedef unsigned long compat_elf_greg_t; #define COMPAT_ELF_NGREG (sizeof(struct pt_regs) / sizeof(compat_elf_greg_t)) typedef compat_elf_greg_t compat_elf_gregset_t[COMPAT_ELF_NGREG]; -struct compat_timespec { - compat_time_t tv_sec; - s32 tv_nsec; -}; - -struct compat_timeval { - compat_time_t tv_sec; - s32 tv_usec; -}; - #define compat_stat stat #define compat_statfs statfs diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index 140d33288e78..6b8961912781 100644 --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -2391,7 +2391,7 @@ static unsigned long get_segment_base(unsigned int segment) #ifdef CONFIG_IA32_EMULATION -#include <asm/compat.h> +#include <linux/compat.h> static inline int perf_callchain_user32(struct pt_regs *regs, struct perf_callchain_entry_ctx *entry) diff --git a/arch/x86/include/asm/compat.h b/arch/x86/include/asm/compat.h index e1c8dab86670..7cd314b71c51 100644 --- a/arch/x86/include/asm/compat.h +++ b/arch/x86/include/asm/compat.h @@ -17,7 +17,6 @@ typedef u32 compat_size_t; typedef s32 compat_ssize_t; -typedef s32 compat_time_t; typedef s32 compat_clock_t; typedef s32 compat_pid_t; typedef u16 __compat_uid_t; @@ -46,16 +45,6 @@ typedef u32 compat_u32; typedef u64 __attribute__((aligned(4))) compat_u64; typedef u32 compat_uptr_t; -struct compat_timespec { - compat_time_t tv_sec; - s32 tv_nsec; -}; - -struct compat_timeval { - compat_time_t tv_sec; - s32 tv_usec; -}; - struct compat_stat { compat_dev_t st_dev; u16 __pad1; diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h index 09ad88572746..db25aa15b705 100644 --- a/arch/x86/include/asm/ftrace.h +++ b/arch/x86/include/asm/ftrace.h @@ -49,7 +49,7 @@ int ftrace_int3_handler(struct pt_regs *regs); #if !defined(__ASSEMBLY__) && !defined(COMPILE_OFFSETS) #if defined(CONFIG_FTRACE_SYSCALLS) && defined(CONFIG_IA32_EMULATION) -#include <asm/compat.h> +#include <linux/compat.h> /* * Because ia32 syscalls do not map to x86_64 syscall numbers diff --git a/arch/x86/include/asm/sys_ia32.h b/arch/x86/include/asm/sys_ia32.h index 82c34ee25a65..8c4083dcd901 100644 --- a/arch/x86/include/asm/sys_ia32.h +++ b/arch/x86/include/asm/sys_ia32.h @@ -12,11 +12,11 @@ #ifdef CONFIG_COMPAT +#include <linux/compat.h> #include <linux/compiler.h> #include <linux/linkage.h> #include <linux/types.h> #include <linux/signal.h> -#include <asm/compat.h> #include <asm/ia32.h> /* ia32/sys_ia32.c */ diff --git a/arch/x86/kernel/sys_x86_64.c b/arch/x86/kernel/sys_x86_64.c index 676774b9bb8d..6cba5755958c 100644 --- a/arch/x86/kernel/sys_x86_64.c +++ b/arch/x86/kernel/sys_x86_64.c @@ -1,4 +1,5 @@ // SPDX-License-Identifier: GPL-2.0 +#include <linux/compat.h> #include <linux/errno.h> #include <linux/sched.h> #include <linux/sched/mm.h> @@ -19,7 +20,6 @@ #include <linux/elf.h> #include <asm/elf.h> -#include <asm/compat.h> #include <asm/ia32.h> #include <asm/syscalls.h> #include <asm/mpx.h> diff --git a/drivers/s390/block/dasd_ioctl.c b/drivers/s390/block/dasd_ioctl.c index 7bdc6aaa0ba3..2016e0ed5865 100644 --- a/drivers/s390/block/dasd_ioctl.c +++ b/drivers/s390/block/dasd_ioctl.c @@ -18,7 +18,6 @@ #include <linux/fs.h> #include <linux/blkpg.h> #include <linux/slab.h> -#include <asm/compat.h> #include <asm/ccwdev.h> #include <asm/schid.h> #include <asm/cmb.h> diff --git a/drivers/s390/char/fs3270.c b/drivers/s390/char/fs3270.c index 61822480a2a0..16a4e8528bbc 100644 --- a/drivers/s390/char/fs3270.c +++ b/drivers/s390/char/fs3270.c @@ -19,7 +19,6 @@ #include <linux/slab.h> #include <linux/types.h> -#include <asm/compat.h> #include <asm/ccwdev.h> #include <asm/cio.h> #include <asm/ebcdic.h> diff --git a/drivers/s390/char/sclp_ctl.c b/drivers/s390/char/sclp_ctl.c index a78cea0c3a09..248b5db3eaa8 100644 --- a/drivers/s390/char/sclp_ctl.c +++ b/drivers/s390/char/sclp_ctl.c @@ -14,7 +14,6 @@ #include <linux/init.h> #include <linux/ioctl.h> #include <linux/fs.h> -#include <asm/compat.h> #include <asm/sclp_ctl.h> #include <asm/sclp.h> diff --git a/drivers/s390/char/vmcp.c b/drivers/s390/char/vmcp.c index 17e411c57576..948ce82a7725 100644 --- a/drivers/s390/char/vmcp.c +++ b/drivers/s390/char/vmcp.c @@ -23,7 +23,6 @@ #include <linux/mutex.h> #include <linux/cma.h> #include <linux/mm.h> -#include <asm/compat.h> #include <asm/cpcmd.h> #include <asm/debug.h> #include <asm/vmcp.h> diff --git a/drivers/s390/cio/chsc_sch.c b/drivers/s390/cio/chsc_sch.c index 0015729d917d..8d9f36625ba5 100644 --- a/drivers/s390/cio/chsc_sch.c +++ b/drivers/s390/cio/chsc_sch.c @@ -16,7 +16,6 @@ #include <linux/miscdevice.h> #include <linux/kernel_stat.h> -#include <asm/compat.h> #include <asm/cio.h> #include <asm/chsc.h> #include <asm/isc.h> diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c index c8b308cfabf1..d3529ef6e0f7 100644 --- a/drivers/s390/net/qeth_core_main.c +++ b/drivers/s390/net/qeth_core_main.c @@ -10,6 +10,7 @@ #define KMSG_COMPONENT "qeth" #define pr_fmt(fmt) KMSG_COMPONENT ": " fmt +#include <linux/compat.h> #include <linux/module.h> #include <linux/moduleparam.h> #include <linux/string.h> @@ -32,7 +33,6 @@ #include <asm/chpid.h> #include <asm/io.h> #include <asm/sysinfo.h> -#include <asm/compat.h> #include <asm/diag.h> #include <asm/cio.h> #include <asm/ccwdev.h> diff --git a/include/linux/compat.h b/include/linux/compat.h index bdf1908a392e..0eb4a3a8f62e 100644 --- a/include/linux/compat.h +++ b/include/linux/compat.h @@ -7,6 +7,7 @@ */ #include <linux/types.h> +#include <linux/compat_time.h> #include <linux/stat.h> #include <linux/param.h> /* for HZ */ diff --git a/include/linux/compat_time.h b/include/linux/compat_time.h new file mode 100644 index 000000000000..56a54a1e4355 --- /dev/null +++ b/include/linux/compat_time.h @@ -0,0 +1,19 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _LINUX_COMPAT_TIME_H +#define _LINUX_COMPAT_TIME_H + +#include <linux/types.h> + +typedef s32 compat_time_t; + +struct compat_timespec { + compat_time_t tv_sec; + s32 tv_nsec; +}; + +struct compat_timeval { + compat_time_t tv_sec; + s32 tv_usec; +}; + +#endif /* _LINUX_COMPAT_TIME_H */ -- 2.14.1 |
From: Deepa Dinamani <deepa.kernel@gm...> - 2018-03-14 04:04:28
|
The series is a preparation series for individual architectures to use 64 bit time_t syscalls in compat and 32 bit emulation modes. This is a follow up to the series Arnd Bergmann posted: https://sourceware.org/ml/libc-alpha/2015-05/msg00070.html [1] Thomas, Arnd, this seems ready to be merged now. Can you help get this merged? Big picture is as per the lwn article: https://lwn.net/Articles/643234/ [2] The series is directed at converting posix clock syscalls: clock_gettime, clock_settime, clock_getres and clock_nanosleep to use a new data structure __kernel_timespec at syscall boundaries. __kernel_timespec maintains 64 bit time_t across all execution modes. vdso will be handled as part of each architecture when they enable support for 64 bit time_t. The compat syscalls are repurposed to provide backward compatibility by using them as native syscalls as well for 32 bit architectures. They will continue to use timespec at syscall boundaries. CONFIG_64_BIT_TIME controls whether the syscalls use __kernel_timespec or timespec at syscall boundaries. The series does the following: 1. Enable compat syscalls on 32 bit architectures. 2. Add a new __kernel_timespec type to be used as the data structure for all the new syscalls. 3. Add new config CONFIG_64BIT_TIME(intead of the CONFIG_COMPAT_TIME in [1] and [2] to switch to new definition of __kernel_timespec. It is the same as struct timespec otherwise. 4. Add new CONFIG_32BIT_TIME to conditionally compile compat syscalls. * Changes since v4: * Fixed up kbuild errors for arm64 and powerpc non compat configs * Changes since v3: * Updated include file ordering * Changes since v2: * Dropped the ARCH_HAS_64BIT_TIME config. * Fixed zeroing out of higher order bits of tv_nsec for real. * Addressed minor review comments from v1. * Changes since v1: * Introduce CONFIG_32BIT_TIME * Fixed zeroing out of higher order bits of tv_nsec * Included Arnd's changes to fix up use of compat headers I decided against using LEGACY_TIME_SYSCALLS to conditionally compile legacy time syscalls such as sys_nanosleep because this will need to enclose compat_sys_nanosleep as well. So, defining it as config LEGACY_TIME_SYSCALLS def_bool 64BIT || !64BIT_TIME will not include compat_sys_nanosleep. We will instead need a new config to exclusively mark legacy syscalls. Deepa Dinamani (10): compat: Make compat helpers independent of CONFIG_COMPAT include: Move compat_timespec/ timeval to compat_time.h compat: enable compat_get/put_timespec64 always arch: introduce CONFIG_64BIT_TIME arch: Introduce CONFIG_COMPAT_32BIT_TIME posix-clocks: Make compat syscalls depend on CONFIG_COMPAT_32BIT_TIME include: Add new y2038 safe __kernel_timespec fix get_timespec64() for y2038 safe compat interfaces change time types to new y2038 safe __kernel_* types nanosleep: change time types to safe __kernel_* types arch/Kconfig | 15 +++++++++ arch/arm64/include/asm/compat.h | 11 ------- arch/arm64/include/asm/stat.h | 1 + arch/arm64/kernel/hw_breakpoint.c | 1 - arch/arm64/kernel/perf_regs.c | 2 +- arch/mips/include/asm/compat.h | 11 ------- arch/mips/kernel/signal32.c | 2 +- arch/parisc/include/asm/compat.h | 11 ------- arch/powerpc/include/asm/compat.h | 11 ------- arch/powerpc/kernel/asm-offsets.c | 2 +- arch/powerpc/oprofile/backtrace.c | 1 + arch/s390/hypfs/hypfs_sprp.c | 1 - arch/s390/include/asm/compat.h | 11 ------- arch/s390/include/asm/elf.h | 4 +-- arch/s390/kvm/priv.c | 1 - arch/s390/pci/pci_clp.c | 1 - arch/sparc/include/asm/compat.h | 11 ------- arch/tile/include/asm/compat.h | 11 ------- arch/x86/events/core.c | 2 +- arch/x86/include/asm/compat.h | 11 ------- arch/x86/include/asm/ftrace.h | 2 +- arch/x86/include/asm/sys_ia32.h | 2 +- arch/x86/kernel/sys_x86_64.c | 2 +- drivers/s390/block/dasd_ioctl.c | 1 - drivers/s390/char/fs3270.c | 1 - drivers/s390/char/sclp_ctl.c | 1 - drivers/s390/char/vmcp.c | 1 - drivers/s390/cio/chsc_sch.c | 1 - drivers/s390/net/qeth_core_main.c | 2 +- include/linux/compat.h | 11 ++++--- include/linux/compat_time.h | 23 ++++++++++++++ include/linux/restart_block.h | 7 ++-- include/linux/syscalls.h | 12 +++---- include/linux/time.h | 4 +-- include/linux/time64.h | 10 +++++- include/uapi/asm-generic/posix_types.h | 1 + include/uapi/linux/time.h | 7 ++++ kernel/compat.c | 52 +++++------------------------- kernel/time/hrtimer.c | 10 ++++-- kernel/time/posix-stubs.c | 12 ++++--- kernel/time/posix-timers.c | 24 ++++++++++---- kernel/time/time.c | 58 +++++++++++++++++++++++++++++++--- 42 files changed, 177 insertions(+), 188 deletions(-) create mode 100644 include/linux/compat_time.h base-commit: 61530b14b059d4838dcc2186e9de9d57e195ce55 -- 2.14.1 Cc: acme@... Cc: benh@... Cc: borntraeger@... Cc: catalin.marinas@... Cc: cmetcalf@... Cc: cohuck@... Cc: davem@... Cc: deller@... Cc: devel@... Cc: gerald.schaefer@... Cc: gregkh@... Cc: heiko.carstens@... Cc: hoeppner@... Cc: hpa@... Cc: jejb@... Cc: jwi@... Cc: linux-api@... Cc: linux-arch@... Cc: linux-kernel@... Cc: linux-mips@... Cc: linux-parisc@... Cc: linuxppc-dev@... Cc: linux-s390@... Cc: mark.rutland@... Cc: mingo@... Cc: mpe@... Cc: oberpar@... Cc: oprofile-list@... Cc: paulus@... Cc: peterz@... Cc: ralf@... Cc: rostedt@... Cc: rric@... Cc: schwidefsky@... Cc: sebott@... Cc: sparclinux@... Cc: sth@... Cc: ubraun@... Cc: will.deacon@... Cc: x86@... |
From: Deepa Dinamani <deepa.kernel@gm...> - 2018-03-14 03:56:27
|
This is again a tricky include file ordering when linux/compat.h is included instead of asm/compat.h. is_compat_task() is unconditionally defined in linux/compat.h as a macro which conflicts with inline function define in asm/compat.h for this arch. As before, I will do the simple thing here and leave the asm/compat.h to keep this series simple. I will submit follow up patches to eliminate direct inclusion asm/compat.h. I will include this also in the update. -Deepa On Tue, Mar 13, 2018 at 8:30 AM, kbuild test robot <lkp@...> wrote: > Hi Deepa, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on ] > > url: https://github.com/0day-ci/linux/commits/Deepa-Dinamani/posix_clocks-Prepare-syscalls-for-64-bit-time_t-conversion/20180313-203305 > base: > config: powerpc-iss476-smp_defconfig (attached as .config) > compiler: powerpc-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 > reproduce: > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > make.cross ARCH=powerpc > > All errors (new ones prefixed by >>): > > arch/powerpc/oprofile/backtrace.c: In function 'user_getsp32': >>> arch/powerpc/oprofile/backtrace.c:31:19: error: implicit declaration of function 'compat_ptr'; did you mean 'complete'? [-Werror=implicit-function-declaration] > void __user *p = compat_ptr(sp); > ^~~~~~~~~~ > complete >>> arch/powerpc/oprofile/backtrace.c:31:19: error: initialization makes pointer from integer without a cast [-Werror=int-conversion] > cc1: all warnings being treated as errors > > vim +31 arch/powerpc/oprofile/backtrace.c > > 6c6bd754 Brian Rogan 2006-03-27 27 > 6c6bd754 Brian Rogan 2006-03-27 28 static unsigned int user_getsp32(unsigned int sp, int is_first) > 6c6bd754 Brian Rogan 2006-03-27 29 { > 6c6bd754 Brian Rogan 2006-03-27 30 unsigned int stack_frame[2]; > 62034f03 Al Viro 2006-09-23 @31 void __user *p = compat_ptr(sp); > 6c6bd754 Brian Rogan 2006-03-27 32 > 62034f03 Al Viro 2006-09-23 33 if (!access_ok(VERIFY_READ, p, sizeof(stack_frame))) > 6c6bd754 Brian Rogan 2006-03-27 34 return 0; > 6c6bd754 Brian Rogan 2006-03-27 35 > 6c6bd754 Brian Rogan 2006-03-27 36 /* > 6c6bd754 Brian Rogan 2006-03-27 37 * The most likely reason for this is that we returned -EFAULT, > 6c6bd754 Brian Rogan 2006-03-27 38 * which means that we've done all that we can do from > 6c6bd754 Brian Rogan 2006-03-27 39 * interrupt context. > 6c6bd754 Brian Rogan 2006-03-27 40 */ > 62034f03 Al Viro 2006-09-23 41 if (__copy_from_user_inatomic(stack_frame, p, sizeof(stack_frame))) > 6c6bd754 Brian Rogan 2006-03-27 42 return 0; > 6c6bd754 Brian Rogan 2006-03-27 43 > 6c6bd754 Brian Rogan 2006-03-27 44 if (!is_first) > 6c6bd754 Brian Rogan 2006-03-27 45 oprofile_add_trace(STACK_LR32(stack_frame)); > 6c6bd754 Brian Rogan 2006-03-27 46 > 6c6bd754 Brian Rogan 2006-03-27 47 /* > 6c6bd754 Brian Rogan 2006-03-27 48 * We do not enforce increasing stack addresses here because > 6c6bd754 Brian Rogan 2006-03-27 49 * we may transition to a different stack, eg a signal handler. > 6c6bd754 Brian Rogan 2006-03-27 50 */ > 6c6bd754 Brian Rogan 2006-03-27 51 return STACK_SP(stack_frame); > 6c6bd754 Brian Rogan 2006-03-27 52 } > 6c6bd754 Brian Rogan 2006-03-27 53 > > :::::: The code at line 31 was first introduced by commit > :::::: 62034f03380a64c0144b6721f4a2aa55d65346c1 [POWERPC] powerpc oprofile __user annotations > > :::::: TO: Al Viro <viro@...> > :::::: CC: Paul Mackerras <paulus@...> > > --- > 0-DAY kernel test infrastructure Open Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation |
From: Deepa Dinamani <deepa.kernel@gm...> - 2018-03-14 03:50:41
|
The file arch/arm64/kernel/process.c needs asm/compat.h also to be included directly since this is included conditionally from include/compat.h. This does seem to be typical of arm64 as I was not completely able to get rid of asm/compat.h includes for arm64 in this series. My plan is to have separate patches to get rid of asm/compat.h includes for the architectures that are not straight forward to keep this series simple. I will fix this and update the series. -Deepa On Tue, Mar 13, 2018 at 8:22 AM, kbuild test robot <lkp@...> wrote: > Hi Deepa, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on ] > > url: https://github.com/0day-ci/linux/commits/Deepa-Dinamani/posix_clocks-Prepare-syscalls-for-64-bit-time_t-conversion/20180313-203305 > base: > config: arm64-allnoconfig (attached as .config) > compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 > reproduce: > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > make.cross ARCH=arm64 > > All errors (new ones prefixed by >>): > > arch/arm64/kernel/process.c: In function 'copy_thread': >>> arch/arm64/kernel/process.c:342:8: error: implicit declaration of function 'is_compat_thread'; did you mean 'is_compat_task'? [-Werror=implicit-function-declaration] > if (is_compat_thread(task_thread_info(p))) > ^~~~~~~~~~~~~~~~ > is_compat_task > cc1: some warnings being treated as errors > > vim +342 arch/arm64/kernel/process.c > > b3901d54d Catalin Marinas 2012-03-05 307 > b3901d54d Catalin Marinas 2012-03-05 308 int copy_thread(unsigned long clone_flags, unsigned long stack_start, > afa86fc42 Al Viro 2012-10-22 309 unsigned long stk_sz, struct task_struct *p) > b3901d54d Catalin Marinas 2012-03-05 310 { > b3901d54d Catalin Marinas 2012-03-05 311 struct pt_regs *childregs = task_pt_regs(p); > b3901d54d Catalin Marinas 2012-03-05 312 > c34501d21 Catalin Marinas 2012-10-05 313 memset(&p->thread.cpu_context, 0, sizeof(struct cpu_context)); > c34501d21 Catalin Marinas 2012-10-05 314 > bc0ee4760 Dave Martin 2017-10-31 315 /* > bc0ee4760 Dave Martin 2017-10-31 316 * Unalias p->thread.sve_state (if any) from the parent task > bc0ee4760 Dave Martin 2017-10-31 317 * and disable discard SVE state for p: > bc0ee4760 Dave Martin 2017-10-31 318 */ > bc0ee4760 Dave Martin 2017-10-31 319 clear_tsk_thread_flag(p, TIF_SVE); > bc0ee4760 Dave Martin 2017-10-31 320 p->thread.sve_state = NULL; > bc0ee4760 Dave Martin 2017-10-31 321 > 071b6d4a5 Dave Martin 2017-12-05 322 /* > 071b6d4a5 Dave Martin 2017-12-05 323 * In case p was allocated the same task_struct pointer as some > 071b6d4a5 Dave Martin 2017-12-05 324 * other recently-exited task, make sure p is disassociated from > 071b6d4a5 Dave Martin 2017-12-05 325 * any cpu that may have run that now-exited task recently. > 071b6d4a5 Dave Martin 2017-12-05 326 * Otherwise we could erroneously skip reloading the FPSIMD > 071b6d4a5 Dave Martin 2017-12-05 327 * registers for p. > 071b6d4a5 Dave Martin 2017-12-05 328 */ > 071b6d4a5 Dave Martin 2017-12-05 329 fpsimd_flush_task_state(p); > 071b6d4a5 Dave Martin 2017-12-05 330 > 9ac080021 Al Viro 2012-10-21 331 if (likely(!(p->flags & PF_KTHREAD))) { > 9ac080021 Al Viro 2012-10-21 332 *childregs = *current_pt_regs(); > b3901d54d Catalin Marinas 2012-03-05 333 childregs->regs[0] = 0; > d00a3810c Will Deacon 2015-05-27 334 > b3901d54d Catalin Marinas 2012-03-05 335 /* > b3901d54d Catalin Marinas 2012-03-05 336 * Read the current TLS pointer from tpidr_el0 as it may be > b3901d54d Catalin Marinas 2012-03-05 337 * out-of-sync with the saved value. > b3901d54d Catalin Marinas 2012-03-05 338 */ > adf758999 Mark Rutland 2016-09-08 339 *task_user_tls(p) = read_sysreg(tpidr_el0); > d00a3810c Will Deacon 2015-05-27 340 > e0fd18ce1 Al Viro 2012-10-18 341 if (stack_start) { > d00a3810c Will Deacon 2015-05-27 @342 if (is_compat_thread(task_thread_info(p))) > d00a3810c Will Deacon 2015-05-27 343 childregs->compat_sp = stack_start; > d00a3810c Will Deacon 2015-05-27 344 else > b3901d54d Catalin Marinas 2012-03-05 345 childregs->sp = stack_start; > b3901d54d Catalin Marinas 2012-03-05 346 } > d00a3810c Will Deacon 2015-05-27 347 > c34501d21 Catalin Marinas 2012-10-05 348 /* > c34501d21 Catalin Marinas 2012-10-05 349 * If a TLS pointer was passed to clone (4th argument), use it > c34501d21 Catalin Marinas 2012-10-05 350 * for the new thread. > c34501d21 Catalin Marinas 2012-10-05 351 */ > b3901d54d Catalin Marinas 2012-03-05 352 if (clone_flags & CLONE_SETTLS) > d00a3810c Will Deacon 2015-05-27 353 p->thread.tp_value = childregs->regs[3]; > c34501d21 Catalin Marinas 2012-10-05 354 } else { > c34501d21 Catalin Marinas 2012-10-05 355 memset(childregs, 0, sizeof(struct pt_regs)); > c34501d21 Catalin Marinas 2012-10-05 356 childregs->pstate = PSR_MODE_EL1h; > 57f4959ba James Morse 2016-02-05 357 if (IS_ENABLED(CONFIG_ARM64_UAO) && > a4023f682 Suzuki K Poulose 2016-11-08 358 cpus_have_const_cap(ARM64_HAS_UAO)) > 57f4959ba James Morse 2016-02-05 359 childregs->pstate |= PSR_UAO_BIT; > c34501d21 Catalin Marinas 2012-10-05 360 p->thread.cpu_context.x19 = stack_start; > c34501d21 Catalin Marinas 2012-10-05 361 p->thread.cpu_context.x20 = stk_sz; > c34501d21 Catalin Marinas 2012-10-05 362 } > c34501d21 Catalin Marinas 2012-10-05 363 p->thread.cpu_context.pc = (unsigned long)ret_from_fork; > c34501d21 Catalin Marinas 2012-10-05 364 p->thread.cpu_context.sp = (unsigned long)childregs; > b3901d54d Catalin Marinas 2012-03-05 365 > b3901d54d Catalin Marinas 2012-03-05 366 ptrace_hw_copy_thread(p); > b3901d54d Catalin Marinas 2012-03-05 367 > b3901d54d Catalin Marinas 2012-03-05 368 return 0; > b3901d54d Catalin Marinas 2012-03-05 369 } > b3901d54d Catalin Marinas 2012-03-05 370 > > :::::: The code at line 342 was first introduced by commit > :::::: d00a3810c16207d2541b7796a73cca5a24ea3742 arm64: context-switch user tls register tpidr_el0 for compat tasks > > :::::: TO: Will Deacon <will.deacon@...> > :::::: CC: Catalin Marinas <catalin.marinas@...> > > --- > 0-DAY kernel test infrastructure Open Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation > _______________________________________________ > Y2038 mailing list > Y2038@... > https://lists.linaro.org/mailman/listinfo/y2038 |
From: kbuild test robot <lkp@in...> - 2018-03-13 15:31:28
|
Hi Deepa, Thank you for the patch! Yet something to improve: [auto build test ERROR on ] url: https://github.com/0day-ci/linux/commits/Deepa-Dinamani/posix_clocks-Prepare-syscalls-for-64-bit-time_t-conversion/20180313-203305 base: config: powerpc-iss476-smp_defconfig (attached as .config) compiler: powerpc-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=powerpc All errors (new ones prefixed by >>): arch/powerpc/oprofile/backtrace.c: In function 'user_getsp32': >> arch/powerpc/oprofile/backtrace.c:31:19: error: implicit declaration of function 'compat_ptr'; did you mean 'complete'? [-Werror=implicit-function-declaration] void __user *p = compat_ptr(sp); ^~~~~~~~~~ complete >> arch/powerpc/oprofile/backtrace.c:31:19: error: initialization makes pointer from integer without a cast [-Werror=int-conversion] cc1: all warnings being treated as errors vim +31 arch/powerpc/oprofile/backtrace.c 6c6bd754 Brian Rogan 2006-03-27 27 6c6bd754 Brian Rogan 2006-03-27 28 static unsigned int user_getsp32(unsigned int sp, int is_first) 6c6bd754 Brian Rogan 2006-03-27 29 { 6c6bd754 Brian Rogan 2006-03-27 30 unsigned int stack_frame[2]; 62034f03 Al Viro 2006-09-23 @31 void __user *p = compat_ptr(sp); 6c6bd754 Brian Rogan 2006-03-27 32 62034f03 Al Viro 2006-09-23 33 if (!access_ok(VERIFY_READ, p, sizeof(stack_frame))) 6c6bd754 Brian Rogan 2006-03-27 34 return 0; 6c6bd754 Brian Rogan 2006-03-27 35 6c6bd754 Brian Rogan 2006-03-27 36 /* 6c6bd754 Brian Rogan 2006-03-27 37 * The most likely reason for this is that we returned -EFAULT, 6c6bd754 Brian Rogan 2006-03-27 38 * which means that we've done all that we can do from 6c6bd754 Brian Rogan 2006-03-27 39 * interrupt context. 6c6bd754 Brian Rogan 2006-03-27 40 */ 62034f03 Al Viro 2006-09-23 41 if (__copy_from_user_inatomic(stack_frame, p, sizeof(stack_frame))) 6c6bd754 Brian Rogan 2006-03-27 42 return 0; 6c6bd754 Brian Rogan 2006-03-27 43 6c6bd754 Brian Rogan 2006-03-27 44 if (!is_first) 6c6bd754 Brian Rogan 2006-03-27 45 oprofile_add_trace(STACK_LR32(stack_frame)); 6c6bd754 Brian Rogan 2006-03-27 46 6c6bd754 Brian Rogan 2006-03-27 47 /* 6c6bd754 Brian Rogan 2006-03-27 48 * We do not enforce increasing stack addresses here because 6c6bd754 Brian Rogan 2006-03-27 49 * we may transition to a different stack, eg a signal handler. 6c6bd754 Brian Rogan 2006-03-27 50 */ 6c6bd754 Brian Rogan 2006-03-27 51 return STACK_SP(stack_frame); 6c6bd754 Brian Rogan 2006-03-27 52 } 6c6bd754 Brian Rogan 2006-03-27 53 :::::: The code at line 31 was first introduced by commit :::::: 62034f03380a64c0144b6721f4a2aa55d65346c1 [POWERPC] powerpc oprofile __user annotations :::::: TO: Al Viro <viro@...> :::::: CC: Paul Mackerras <paulus@...> --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation |
From: kbuild test robot <lkp@in...> - 2018-03-13 15:23:28
|
Hi Deepa, Thank you for the patch! Yet something to improve: [auto build test ERROR on ] url: https://github.com/0day-ci/linux/commits/Deepa-Dinamani/posix_clocks-Prepare-syscalls-for-64-bit-time_t-conversion/20180313-203305 base: config: arm64-allnoconfig (attached as .config) compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm64 All errors (new ones prefixed by >>): arch/arm64/kernel/process.c: In function 'copy_thread': >> arch/arm64/kernel/process.c:342:8: error: implicit declaration of function 'is_compat_thread'; did you mean 'is_compat_task'? [-Werror=implicit-function-declaration] if (is_compat_thread(task_thread_info(p))) ^~~~~~~~~~~~~~~~ is_compat_task cc1: some warnings being treated as errors vim +342 arch/arm64/kernel/process.c b3901d54d Catalin Marinas 2012-03-05 307 b3901d54d Catalin Marinas 2012-03-05 308 int copy_thread(unsigned long clone_flags, unsigned long stack_start, afa86fc42 Al Viro 2012-10-22 309 unsigned long stk_sz, struct task_struct *p) b3901d54d Catalin Marinas 2012-03-05 310 { b3901d54d Catalin Marinas 2012-03-05 311 struct pt_regs *childregs = task_pt_regs(p); b3901d54d Catalin Marinas 2012-03-05 312 c34501d21 Catalin Marinas 2012-10-05 313 memset(&p->thread.cpu_context, 0, sizeof(struct cpu_context)); c34501d21 Catalin Marinas 2012-10-05 314 bc0ee4760 Dave Martin 2017-10-31 315 /* bc0ee4760 Dave Martin 2017-10-31 316 * Unalias p->thread.sve_state (if any) from the parent task bc0ee4760 Dave Martin 2017-10-31 317 * and disable discard SVE state for p: bc0ee4760 Dave Martin 2017-10-31 318 */ bc0ee4760 Dave Martin 2017-10-31 319 clear_tsk_thread_flag(p, TIF_SVE); bc0ee4760 Dave Martin 2017-10-31 320 p->thread.sve_state = NULL; bc0ee4760 Dave Martin 2017-10-31 321 071b6d4a5 Dave Martin 2017-12-05 322 /* 071b6d4a5 Dave Martin 2017-12-05 323 * In case p was allocated the same task_struct pointer as some 071b6d4a5 Dave Martin 2017-12-05 324 * other recently-exited task, make sure p is disassociated from 071b6d4a5 Dave Martin 2017-12-05 325 * any cpu that may have run that now-exited task recently. 071b6d4a5 Dave Martin 2017-12-05 326 * Otherwise we could erroneously skip reloading the FPSIMD 071b6d4a5 Dave Martin 2017-12-05 327 * registers for p. 071b6d4a5 Dave Martin 2017-12-05 328 */ 071b6d4a5 Dave Martin 2017-12-05 329 fpsimd_flush_task_state(p); 071b6d4a5 Dave Martin 2017-12-05 330 9ac080021 Al Viro 2012-10-21 331 if (likely(!(p->flags & PF_KTHREAD))) { 9ac080021 Al Viro 2012-10-21 332 *childregs = *current_pt_regs(); b3901d54d Catalin Marinas 2012-03-05 333 childregs->regs[0] = 0; d00a3810c Will Deacon 2015-05-27 334 b3901d54d Catalin Marinas 2012-03-05 335 /* b3901d54d Catalin Marinas 2012-03-05 336 * Read the current TLS pointer from tpidr_el0 as it may be b3901d54d Catalin Marinas 2012-03-05 337 * out-of-sync with the saved value. b3901d54d Catalin Marinas 2012-03-05 338 */ adf758999 Mark Rutland 2016-09-08 339 *task_user_tls(p) = read_sysreg(tpidr_el0); d00a3810c Will Deacon 2015-05-27 340 e0fd18ce1 Al Viro 2012-10-18 341 if (stack_start) { d00a3810c Will Deacon 2015-05-27 @342 if (is_compat_thread(task_thread_info(p))) d00a3810c Will Deacon 2015-05-27 343 childregs->compat_sp = stack_start; d00a3810c Will Deacon 2015-05-27 344 else b3901d54d Catalin Marinas 2012-03-05 345 childregs->sp = stack_start; b3901d54d Catalin Marinas 2012-03-05 346 } d00a3810c Will Deacon 2015-05-27 347 c34501d21 Catalin Marinas 2012-10-05 348 /* c34501d21 Catalin Marinas 2012-10-05 349 * If a TLS pointer was passed to clone (4th argument), use it c34501d21 Catalin Marinas 2012-10-05 350 * for the new thread. c34501d21 Catalin Marinas 2012-10-05 351 */ b3901d54d Catalin Marinas 2012-03-05 352 if (clone_flags & CLONE_SETTLS) d00a3810c Will Deacon 2015-05-27 353 p->thread.tp_value = childregs->regs[3]; c34501d21 Catalin Marinas 2012-10-05 354 } else { c34501d21 Catalin Marinas 2012-10-05 355 memset(childregs, 0, sizeof(struct pt_regs)); c34501d21 Catalin Marinas 2012-10-05 356 childregs->pstate = PSR_MODE_EL1h; 57f4959ba James Morse 2016-02-05 357 if (IS_ENABLED(CONFIG_ARM64_UAO) && a4023f682 Suzuki K Poulose 2016-11-08 358 cpus_have_const_cap(ARM64_HAS_UAO)) 57f4959ba James Morse 2016-02-05 359 childregs->pstate |= PSR_UAO_BIT; c34501d21 Catalin Marinas 2012-10-05 360 p->thread.cpu_context.x19 = stack_start; c34501d21 Catalin Marinas 2012-10-05 361 p->thread.cpu_context.x20 = stk_sz; c34501d21 Catalin Marinas 2012-10-05 362 } c34501d21 Catalin Marinas 2012-10-05 363 p->thread.cpu_context.pc = (unsigned long)ret_from_fork; c34501d21 Catalin Marinas 2012-10-05 364 p->thread.cpu_context.sp = (unsigned long)childregs; b3901d54d Catalin Marinas 2012-03-05 365 b3901d54d Catalin Marinas 2012-03-05 366 ptrace_hw_copy_thread(p); b3901d54d Catalin Marinas 2012-03-05 367 b3901d54d Catalin Marinas 2012-03-05 368 return 0; b3901d54d Catalin Marinas 2012-03-05 369 } b3901d54d Catalin Marinas 2012-03-05 370 :::::: The code at line 342 was first introduced by commit :::::: d00a3810c16207d2541b7796a73cca5a24ea3742 arm64: context-switch user tls register tpidr_el0 for compat tasks :::::: TO: Will Deacon <will.deacon@...> :::::: CC: Catalin Marinas <catalin.marinas@...> --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation |
From: Deepa Dinamani <deepa.kernel@gm...> - 2018-03-12 18:00:01
|
I posted the updated series. I fixed up the order of include files where I could find some order. There have been other commits that used scripts to do such replacements and have already stomped on the order. For example: commit 7c0f6ba682b9c7632072ffbedf8d328c8f3c42ba Author: Linus Torvalds <torvalds@...> Replace <asm/uaccess.h> with <linux/uaccess.h> globally -Deepa On Tue, Mar 6, 2018 at 2:58 PM, Deepa Dinamani <deepa.kernel@...> wrote: > On Tue, Mar 6, 2018 at 4:48 AM, Christian Borntraeger > <borntraeger@...> wrote: >> >> >> On 03/06/2018 01:46 PM, Arnd Bergmann wrote: >>> On Mon, Mar 5, 2018 at 10:30 AM, Christian Borntraeger >>> <borntraeger@...> wrote: >>>> On 01/16/2018 03:18 AM, Deepa Dinamani wrote: >>>>> All the current architecture specific defines for these >>>>> are the same. Refactor these common defines to a common >>>>> header file. >>>>> >>>>> The new common linux/compat_time.h is also useful as it >>>>> will eventually be used to hold all the defines that >>>>> are needed for compat time types that support non y2038 >>>>> safe types. New architectures need not have to define these >>>>> new types as they will only use new y2038 safe syscalls. >>>>> This file can be deleted after y2038 when we stop supporting >>>>> non y2038 safe syscalls. >>>> >>>> You are now include a <linux/*.h> from several asm files >>>> ( >>>> arch/arm64/include/asm/stat.h >>>> arch/s390/include/asm/elf.h >>>> arch/x86/include/asm/ftrace.h >>>> arch/x86/include/asm/sys_ia32.h >>>> ) >>>> It works, and it is done in many places, but it looks somewhat weird. >>>> Would it make sense to have an asm-generic/compate-time.h instead? Asking for >>>> opinions here. >>> >>> I don't think we have such a rule. If a header file is common to all >>> architectures (i.e. no architecture uses a different implementation), >>> it should be in include/linux rather than include/asm-generic, regardless >>> of whether it can be used by assembler files or not. >>> >>>>> --- a/drivers/s390/net/qeth_core_main.c >>>>> +++ b/drivers/s390/net/qeth_core_main.c >>>>> @@ -32,7 +32,7 @@ >>>>> #include <asm/chpid.h> >>>>> #include <asm/io.h> >>>>> #include <asm/sysinfo.h> >>>>> -#include <asm/compat.h> >>>>> +#include <linux/compat.h> >>>>> #include <asm/diag.h> >>>>> #include <asm/cio.h> >>>>> #include <asm/ccwdev.h> >>>> >>>> Can you move that into the other includes (where all the other <linux/*> includes are. >>> >>> Good catch, this is definitely a rule we have ;-) >> >> FWIW, this was also broken for >> arch/x86/include/asm/sys_ia32.h > > The reason that this was done this way is because of the sed script > mentioned in the commit text. > I was trying to make minimal change apart from the script so that we > don't have other changes like moving the lines to keep the patch > simpler. > I will fix this by hand since this is preferred. > I will post an update. > > -Deepa |