lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 30 Sep 2013 09:33:35 +0800 From: Chen Gang <gang.chen@...anux.com> To: paulmck@...ux.vnet.ibm.com CC: mingo@...nel.org, laijs@...fujitsu.com, dipankar@...ibm.com, akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com, josh@...htriplett.org, niv@...ibm.com, tglx@...utronix.de, peterz@...radead.org, rostedt@...dmis.org, dhowells@...hat.com, edumazet@...gle.com, darren@...art.com, fweisbec@...il.com, sbw@....edu, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: [PATCH tip/core/rcu 08/11] rcu: Micro-optimize rcu_cpu_has_callbacks() On 09/30/2013 04:23 AM, Paul E. McKenney wrote: > On Sun, Sep 29, 2013 at 12:24:52PM +0800, Chen Gang wrote: >> On 09/27/2013 10:29 AM, Chen Gang wrote: >>> On 09/27/2013 02:33 AM, Paul E. McKenney wrote: >>>> On Thu, Sep 26, 2013 at 10:57:39AM +0800, Chen Gang wrote: >>>>> On 09/26/2013 04:16 AM, Paul E. McKenney wrote: >>>>>> On Wed, Sep 25, 2013 at 10:55:30AM +0800, Chen Gang wrote: >>>>>>> >>>>>>> Thank you for your whole work, firstly :-). >>>>>>> >>>>>>> And your suggestion about testing (in our discussion) is also valuable >>>>>>> to me. >>>>>>> >>>>>>> I need start LTP in q4. After referenced your suggestion, my first step >>>>>>> for using/learning LTP is not mainly for finding kernel issues, but for >>>>>>> testing kernel (to improve my kernel testing efficiency). >>>>>>> >>>>>>> When I want to find issues by reading code, I will consider about LTP >>>>>>> too (I will try to find issues which can be tested by LTP). >>>>>> >>>>>> Doing more testing will be good! You will probably need more tests >>>>>> than just LTP, but you must of course start somewhere. >>>>> >>>>> Give more testing is good, but also mean more time resources cost. If >>>>> spend the 'cost', also need get additional 'contributions' (not only >>>>> prove an issue), or the 'efficiency' can not be 'acceptable'. >>>>> >>>>> When "I need more tests than just LTP", firstly I need perform this >>>>> test, and then, also try to send "test case" to LTP (I guess, these >>>>> kinds of mails are welcomed by LTP). >>>>> >>>>> And LTP is also a way to find kernel issues, although I will not mainly >>>>> depend on it now (but maybe in future), it is better to familiar with it >>>>> step by step. >>>>> >>>>> LTP (Linux Test Project) is one of main kernel mad user at downstream. >>>>> Tool chain (GCC/Binutils) is one of kernel main mad tools at upstream. >>>>> If we face to the whole kernel, suggest to use them. ;-) >>>> >>>> Yep, starting with just LTP is OK. But if by this time next year you >>>> really should be using more than just LTP. >>>> >> >> What I have done is trying to fully use other members contributions, not trying to instead of them. >> >> >> And the reason why I want/try to 'open' my 'ideas' to public: >> >> get more suggestions, and completions from other members. >> >> share my ideas, it can let other members provide more contributions (e.g. I am glad, if find other members also try 'allmodconfig' on all architectures). >> >> If some members replicate me, I will save my current time resources and devote them to another things (which also based on other members contributions). >> >> >> In my opinion: >> >> "Open and Share" are both important and urgent to everyone, although it may not be noticed directly. Like "Air and Water" which God have blessed to everyone. > Firstly, thank you very much for your details reply. > In a general sense, of course. > > In many specific cases, effective sharing can require quite a bit of > preparation. For but one example, in Dipankar's and my case, it took > about two years of work (mostly Dipankar's work) to get the initial > implementation of RCU accepted into the Linux kernel. > > In your case, you can invest an average of three days per accepted > patch if you are to achieve your goal of ten patches accepted per month > (if I remember correctly). Of course, not every patch will be accepted, > which reduces your per-patch time. For example, if 50% of your patches > are accepted, you can invest an average of about 1.5 days per patch. > > Of course, investing in learning about test frameworks or specific > kernel subsystems further reduces your time available per patch. > > But if you don't invest in your learning, you will be limited in what > you can effectively contribute. This might be OK, for all I know. > After all, in the 15 million lines of Linux kernel code, there is > probably a very large number of point-problems waiting to be fixed. > > But suppose that you run out of easily found point problems? Or that > you want to do something more wide-ranging than fixes for point problems? > What can you do? > > Here are a few options. If you think more about it, I am sure that you > can come up with others. > > 1. Put the ten-patches-per-month quota aside for a month (or two or > three or whatever is required and appropriate). Spend this time > studying a given kernel subsystem or a given test framework. > (Which kernel subsystem? The best candidates would be those > having bugs but no active maintainer, but which you have the > hardware needed to adequately test.) > > 2. Add a review and/or test component to your monthly quota, so > that a given patch could be substituted for by some number of > Reviewed-by or Tested-by flags. Of course, this gives your > a chicken-and-egg problem because you cannot adequately review > or test without some understanding of the subsystem in question. > (At least not efficiently enough to get enough Tested-by or > Reviewed-by flags.) > > 3. Set aside a fixed amount of time each week (or each month) to > learn. This time needs to be a contiguous block of at least > four hours. If you focus your learning appropriately, you might > be able to contribute more deeply to whatever you learned about > over time. > > For whatever it is worth, just staring at code is for most people > an inefficient way to learn. Exercising the code using tools > like ftrace or userspace scaffolding can help speed up the > learning. > At least for me, what you said is valuable. In fact, I am just trying in this way for Tool Chain (GCC/Binutils), and use Linux Kernel as the test object of Tool Chain. ;-) > 4. Your idea here... > 'Ways' depends on your goal. For Tool Chain and LTP, I only want to use them for kernel, so I need familiar with their features details which related with Linux Kernel, (in fact, GCC is not easy for me, too). But for Linux Kernel, I want to face the whole kernel (it is my main goal), so I start from Interface: kernel's upstream (e.g. Tool Chain), kernel's downstream (e.g. LTP), and Reading Code/Docs. So what I have done to Linux kernel, is just only starting, it can be followed with many many next steps. > Your current approach seems to be to submit patches and hope that the > maintainer takes it upon himself or herself to teach you. Unfortunately, > as you might have noticed, a given maintainer might not have the time > or energy to take on full responsibility for your education. > In my opinion, teaching and educating are not quite efficient: I am not graduated from University (no bachelor's degree, not computer science major, either), although I come from China Zhe Jiang University. When I send a patch to the related maintainer (or integrator), I don't intend to let them 'teach' me (it is not quite efficient), I only want to work together which can improve the whole efficiency. e.g. if the maintainers already know about it, we don't need wast time again. e.g. if no related maintainer, I should try and let integrator check and provide him/her suggestions for what I have done. > Thanx, Paul > > > Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists