- kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

Walking a wait_queue_t list of tasks blocked on pipe
by W. Michael Petullo Jan. 13, 2016

Jan. 13, 2016

I am trying to walk a wait_queue_t list as part of a LSM file_permission function. The purpose is to act on each task which has blocked while trying to read from a pipe. I have modeled my code on __wake_up_common() in kernel/sched/core.c, and it looks something like this: if (i_pipe->reader <= 0) { return; } list_for_each_entry_safe(curr, next, &i_pipe->wait.task, task_list) { [...] struct task_struct *blocked = curr->private; [...] } I have tried to wrap this with: spin_lock_irqsave(&i_pipe->wait.lock, flags) spin_unlock_irqrestore[...] and also: write_lock_irq(&tasklist_lock). write_unlock_irq[...] Despite this, I sometimes find that blocked (AKA curr->private) == NULL during an iteration of the list_for_each_entry_safe loop, and this surprises me. Why would there be en entry in the wait_queue_t list which does not have a process associated with it? Is the data structure moving out from under me? Is there something else I should lock? Thank you, -- Mike :wq

1 0

What are need to makes humidifier?
by 윤영석 Jan. 12, 2016

Jan. 12, 2016

Hi, I want to make own humidifier. What sensor need when making humidifier?? humidity indicator (detecting humidity), ultrasonic waves maker?? Please shares your wisdom to me. Thanks. Best regards.

2 1

CFS: quantifying effect of nice value on scheduled CPU time
by John Locke Jan. 11, 2016

Jan. 11, 2016

CFS: >From my reading of the source, the 'nice'/static priority of a SCHED_NORMAL task is used by the CFS scheduler by mapping it to a weight (https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/k…) This weight comes in to play in 2 main areas: 1) When adjusting the currently running task's 'vruntime' : https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/k… When the 'vruntime' is being updated for a task I see that if the task's 'nice' value is less than 0 the execution time delta added to its 'vruntime' is less than its actual execution time. Similarly, for task's with 'nice' values greater than 0 the execution time delta added to its 'vruntime' is larger than its actual execution time. Essentially, vruntime = actual_execution_delta * NICE_0_LOAD / task_weight 2) When computing the ideal amount of time a task should execute within a scheduling period: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/k… It seems a task's ideal execution time is determined by its weight relative to the total weight of all tasks on the same runqueue: ideal_execution_time = scheduling_period * task_weight / total_weight_of_all_tasks_on_runqueue With (1) and (2) above I don't exactly see how the comments above the weight array definition are consistent with this: /* * Nice levels are multiplicative, with a gentle 10% change for every * nice level changed. I.e. when a CPU-bound task goes from nice 0 to * nice 1, it will get ~10% less CPU time than another CPU-bound task * that remained on nice 0. * * The "10% effect" is relative and cumulative: from _any_ nice level, * if you go up 1 level, it's -10% CPU usage, if you go down 1 level * it's +10% CPU usage. (to achieve that we use a multiplier of 1.25. * If a task goes up by ~10% and another task goes down by ~10% then * the relative distance between them is ~25%.) */ static const int prio_to_weight[40] = { If I take an example of 2 tasks both with weight=1024 (NICE_0) they should each get 50% of the CPU time. If 1 of the tasks is reniced to NICE_1 then the NICE_0 task will get 1024/(1024+820)=56% of the CPU time and the NICE_1 task will get 44% of the CPU time. I'm obviously not understanding something since I can't come at those 10% figures in the comments. tl;dr: How does going from 1 nice level to the next get you to the 10% figure mentioned in the comments of the 'prio_to_weight[]' above? Thanks.

1 0

taskstats in kernel and in userspace
by Kevin Wilson Jan. 9, 2016

Jan. 9, 2016

Hi, According to http://lxr.free-electrons.com/source/kernel/taskstats.c there is a netlink interface for taskstats. It is not new, it is at least from kernel 3.7 Is there a netlink based utility which uses it ? Regards, Kevin

1 0

Does the Community use Coverity ?
by pavi1729 Jan. 7, 2016

Jan. 7, 2016

Hi, May I know if the community uses the Coverity tool and, if yes where can I find a repo of Coverity scans of kernels and IGNORE LIST; cause there obviously would be false positives. Cheers, Pavi

5 6

Drivers in staging folder
by James Miller Jan. 6, 2016

Jan. 6, 2016

Hi All, I've had a look at the TODO files but I'm having some difficulty with finding out which devices each of the drivers support. My plan was to find a driver in staging, get a device off ebay which uses the driver and then start working on the TODO. Is this the right approach and is the actual device (for testing) needed in order to do cleanups in TODO files? Any help would be really appriciated. Thanks, James

3 2

skb_clone related query
by pavi1729 Jan. 5, 2016

Jan. 5, 2016

Hi, Just out of curisity, I was looking at Kernel 3.14, skb_clone function in f_ncm.c http://lxr.free-electrons.com/source/drivers/usb/gadget/f_ncm.c?v=3.14#L1063 QUERY : Shouldn't a kfree_skb(skb2); happen before goto err @1070 ? Is this not a memleak ? 1068 if (!skb_pull(skb2, index)) { 1069 ret = -EOVERFLOW; 1070 goto err; 1071 } Thanks, Pavi

2 3

should "get_user_pages()" really be phased out?
by Robert P. J. Day Jan. 4, 2016

Jan. 4, 2016

poking around mm/gup.c at "get_user_pages()" and related routines, and noticed this: * get_user_pages should be phased out in favor of * get_user_pages_locked|unlocked or get_user_pages_fast. Nothing * should use get_user_pages because it cannot pass * FAULT_FLAG_ALLOW_RETRY to handle_mm_fault. so does that mean what it seems to mean ... that nothing outside of memory management should call get_user_pages() directly? i can see that some of those other routines are implemented in terms of get_user_pages() -- does that mean that get_user_pages() should be made static so that only those routines are allowed to call it, and everyone else should invoke one of the other routines? just trying to understand the eventual desired fate of get_user_pages(). rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

1 0

Upping baud rate for ttyS0
by John Chludzinski Jan. 4, 2016

Jan. 4, 2016

I've downloaded the source RPM for the 3.10 kernel. I'm looking for the driver code that I need to modify to support higher baud rates than that permitted by the current serial driver (B115200 when using stty or cfsetispeed() + tcsetattr()). I've looked in the drivers/tty/serial/ source files but am uncertain where to begin. Any pointer would be appreciated. ---John

1 0

Re: eudyptula challenge, stuck at task 06 - no reply for four weeks
by chuckleberryfinn Dec. 31, 2015

Dec. 31, 2015

I had some replies in November. He's still alive for sure. :) Patience is the biggest requirement for the challenge! ;) > From: "Geyslan G. Bem" <geyslan(a)gmail.com> > Subject: Re: eudyptula challenge, stuck at task 06 - no reply for four > weeks > To: Abner Silva <abnerf(a)gmail.com> > Cc: kernelnewbies <kernelnewbies(a)kernelnewbies.org> > Message-ID: > <CAGG-pURmn_%2BW4Tr6kM0kqhx8ucVfx%3Dbuv_oueV%3DCPPipKy%3Dt%2BQ(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > 2015-12-31 12:27 GMT-03:00 Abner Silva <abnerf(a)gmail.com>: >> Anyone heard from Little recently? Got nothing since beginning of Oct. > Mine is stucked in task 6 too. No reply until now. > >> >> On 11/21/2015 12:57 AM, Karthik Nayak wrote: >>> Thanks, I'll check them out. >>> >>> >>> On Sat, Nov 21, 2015, 1:34 AM Drew Fustini <pdp7pdp7(a)gmail.com >>> <mailto:pdp7pdp7@gmail.com>> wrote: >>> >>> yup, that advice has served me well during the challenge. >>> >>> I highly recommend Free Electrons's Embedded Linux kernel and driver >>> development training: >>> >>> slides: >>> http://free-electrons.com/doc/training/linux-kernel/linux-kernel-slides.pdf >>> labs: >>> http://free-electrons.com/doc/training/linux-kernel/linux-kernel-labs.pdf >>> code: >>> http://free-electrons.com/doc/training/linux-kernel/linux-kernel-labs.tar.xz >>> >>> cheers, >>> drew >>> >>> On Fri, Nov 20, 2015 at 7:57 AM, Karthik Nayak >>> <karthik.188(a)gmail.com <mailto:karthik.188@gmail.com>> wrote: >>> > Just wait you'll get it, in the meantime continue reading about >>> Linux =) >>> > >>> > >>> > On Fri, Nov 20, 2015, 6:38 PM Lucas Tanure <tanure(a)linux.com >>> <mailto:tanure@linux.com>> wrote: >>> >> >>> >> Hi, >>> >> >>> >> I'm waiting for task 8 since September 05: >>> >> " Just to provide some information, you are currently number 9 in >>> >> line, and the response that is next is from "05 Sep 2015 >>> 00:53:31 -0400" >>> >> so be aware of the potential wait time. " >>> >> >>> >> Thanks >>> >> >>> >> -- >>> >> Lucas Tanure >>> >> +55 (19) 988176559 >>> >> >>> >> On Thu, Nov 19, 2015 at 11:36 PM, Alexander Ivanov >>> <amivanov(a)gmail.com <mailto:amivanov@gmail.com>> >>> >> wrote: >>> >>> >>> >>> Hi there, >>> >>> >>> >>> Is there anybody stuck at task 06 too? >>> >>> >>> >>> --ami >>> >>> >>> >>> _______________________________________________ >>> >>> Kernelnewbies mailing list >>> >>> Kernelnewbies(a)kernelnewbies.org >>> <mailto:Kernelnewbies@kernelnewbies.org> >>> >>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>> >> >>> >> >>> >> _______________________________________________ >>> >> Kernelnewbies mailing list >>> >> Kernelnewbies(a)kernelnewbies.org >>> <mailto:Kernelnewbies@kernelnewbies.org> >>> >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>> > >>> > -- >>> > >>> > Regards, >>> > Karthik >>> > >>> > >>> > _______________________________________________ >>> > Kernelnewbies mailing list >>> > Kernelnewbies(a)kernelnewbies.org >>> <mailto:Kernelnewbies@kernelnewbies.org> >>> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>> > >>> >>> -- >>> >>> Regards, >>> Karthik >>> >>> >>> >>> _______________________________________________ >>> Kernelnewbies mailing list >>> Kernelnewbies(a)kernelnewbies.org >>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>> >> >> _______________________________________________ >> Kernelnewbies mailing list >> Kernelnewbies(a)kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > >

4 4