June 2013 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

printk and kernel log
by Kevin Wilson June 27, 2013

June 27, 2013

Hi, When I add printk messages, and then try to read /var/log/messages, I see this: Jun 24 03:43:06 localhost kernel: [ 1858.148661] in my_func1 Jun 24 03:44:03 localhost kernel: [ 1915.150953] in my_func2 What are the numbers is square brackets ? like [ 1858.148661] or [ 1915.150953] ? Is there a way I can get rid of them ? Regards, Kevin

5 10

File-system driver issue
by Saket Sinha June 26, 2013

June 26, 2013

I have to port a driver from 2.6.18 to 3.8.3 Look at the below declaration of current http://lxr.free-electrons.com/source/scripts/kconfig/gconf.c#L62 Where struct menu is http://lxr.free-electrons.com/source/scripts/kconfig/expr.h#L159 The above one is in kconfig while the lower one is in the kernel. So would they be able to affect each other? I guess NO NOW in the driver to be ported- current is defined as: struct task_struct *task = current; but is still able to excess the field members of task_struct http://lxr.linux.no/linux+v2.6.18/include/linux/sched.h#L767 like attr.ia_uid = current->uid; attr.ia_gid = current->gid; though it has not been initialized or assigned or typecasted to this task_struct. HOW? I searched on the entire lxr but could not find the solution. Kindly help. PS: This driver is built on 2.6.28 kernel so use lxr from 2.6.18 kernel only like http://lxr.linux.no/linux+v2.6.18/<http://lxr.linux.no/linux+v2.6.18/include/linux/sched.h#L767>

2 4

File system query
by Dibyayan Chakraborty June 25, 2013

June 25, 2013

Hi, I came by a really weird macro code in linux/jbd.h<http://lxr.free-electrons.com/source/include/linux/jbd.h#L1029>which is BUFFER_TRACE(bh,info) do{} while(0). Please explain the necessity of this. -- With Regards Dibyayan Chakraborty

3 2

any value in "pci_request_region_exclusive()" routine?
by Robert P. J. Day June 25, 2013

June 25, 2013

poking around in memory allocation code and ran across this in drivers/pci/pci.c. first, there's this generic region request routine that accepts a final parameter as to whether it's an "exclusive" request: static int __pci_request_region(struct pci_dev *pdev, int bar, const char *res_name, int exclusive) { struct pci_devres *dr; ... and, not surprisingly, there are a couple more user-friendly routines that wrap around it: int pci_request_region(struct pci_dev *pdev, int bar, const char *res_name) { return __pci_request_region(pdev, bar, res_name, 0); } ... snip ... int pci_request_region_exclusive(struct pci_dev *pdev, int bar, const char *res_name) { return __pci_request_region(pdev, bar, res_name, IORESOURCE_EXCLUSIVE); } the above would normally suggest that, since the generic routine's name begins with "__", it's typically a lower-level routine that wouldn't be called directly, and one would expect to see calls to the wrapper routines: * pci_request_reqion() * pci_request_region_exclusive() scattered throughout the kernel source tree. there are certainly enough calls to the first (non-exclusive) routine, but this is it for the second: $ grep -rw pci_request_region_exclusive * drivers/pci/pci.c: * pci_request_region_exclusive - Reserved PCI I/O and memory resource drivers/pci/pci.c:int pci_request_region_exclusive(struct pci_dev *pdev, int bar, const char *res_name) drivers/pci/pci.c:EXPORT_SYMBOL(pci_request_region_exclusive); include/linux/pci.h:int __must_check pci_request_region_exclusive(struct pci_dev *, int, const char *); $ in short, *nobody* appears to call that second routine for exclusive access. am i missing something here? if you search for calls to the generic routine, this is all you find: $ grep -rw __pci_request_region * drivers/pci/pci.c: * __pci_request_region - Reserved PCI I/O and memory resource drivers/pci/pci.c:static int __pci_request_region(struct pci_dev *pdev, int bar, const char *res_name, drivers/pci/pci.c: return __pci_request_region(pdev, bar, res_name, 0); drivers/pci/pci.c: return __pci_request_region(pdev, bar, res_name, IORESOURCE_EXCLUSIVE); drivers/pci/pci.c: if (__pci_request_region(pdev, i, res_name, excl)) $ so what's the value of that "exclusive" wrapper routine? 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

Fwd: How to calculate the TCP checksum
by Adel Qodmani June 25, 2013

June 25, 2013

On Tue, Jun 25, 2013 at 6:19 AM, Peter Teoh <htmldeveloper(a)gmail.com> wrote: > c. if your hardware is not capable to do TCP offloading, then the LONG > way is to start from beginning of packet to end of packet, and calculate > checksum. > I've tested that, my hardware apparently doesn't support TCP offloading. > d. if u keep the previous checksum, ie (th->checksum=0 is not needed > at all), and u know exactly which byte u modify, then just do a xor of the > modified byte with the previous checksum, and u get the new > checksum.....this is the preferred and fastest way. > > so in summary: > > th->check = 0; > th->check = csum_tcpudp_magic(iph->saddr, iph->daddr, > datalen, iph->protocol, > csum_partial((char *)th, datalen, 0)); > skb->ip_summed = CHECKSUM_UNNECESSARY; > > your setting of "0" above is correct, is because u want to calculate the > checksum OVERALL....ie, packet start to packet end......demarcate correctly > and u should get the answer....NOT csum_partial().....partial checksumming > does not apply here. > > -- > Regards, > Peter Teoh > Well, the problem is now solved, it seems that the error was with the fact that some skbs are not linear and I was ignoring this fact. Fixed it by the following: tcph = tcp_hdr(skb); if(skb_is_nonlinear(skb)) skb_linearize(skb) tcplen = (skb->len - (iph->ihl << 2));/* tcplen is the length of the skb - the ip-header length */ tcph->check = 0; tcph->check = tcp_v4_check(tcplen, iph->saddr, iph->daddr, csum_partial((char*) tcph, tcplen, 0)); skb->ip_summed = CHECKSUM_NONE;/* in case another hardware has TCP offloading */ Thanks a lot, anyhow :D

1 0

High Latency during packet transmission
by Michael Krysiak June 22, 2013

June 22, 2013

I've been trying to identify why we're seeing frequent stalls during packet transmission in our GPFS cluster in the bnx2 driver (as well as other NICs/drivers), but I am at the limit of my current knowledge. I used perf netdev events (as described in http://lwn.net/Articles/397654/) to measure the tx times, and see spikes such as the following: dev len Qdisc netdevice free em2 98 807740.878085sec 0.002msec 0.061msec em2 98 807740.878119sec 0.002msec 0.029msec em2 98 807741.140600sec 0.005msec 0.092msec em2 65226 807742.763833sec 0.007msec 0.436msec em2 66 807727.081712sec 0.001msec 16246.072msec em2 66 807740.882741sec 0.001msec 3457.625msec Based on the source for netdev-times.py, the "free" column is the difference between trace_net_dev_xmit() and trace_kfree_skb() in net/core/dev.c, but I'm not sure how to dig any deeper. Are there any common causes for this behavior? What's the best way to further break down the time difference between the xmit and kfree trace points?

2 2

another couple questions regarding wait queues
by Robert P. J. Day June 22, 2013

June 22, 2013

while i'm immersed in the code, might as well toss out a couple more questions, these related to some code in drivers/mtd/mtdblock.c: ===== static int erase_write (struct mtd_info *mtd, unsigned long pos, int len, const char *buf) { struct erase_info erase; DECLARE_WAITQUEUE(wait, current); wait_queue_head_t wait_q; size_t retlen; int ret; /* * First, let's erase the flash block. */ init_waitqueue_head(&wait_q); ... snip ... ===== this code seems a bit confusing. there are two ways to define both wait queue heads and wait queues -- at compile time, and at run time. above, the wait queue is defined at compile time with: DECLARE_WAITQUEUE(wait, current); which seems fine, but the wait queue head itself uses the *run-time* declaration, which seems unnecessary -- why couldn't that have been declared at compile time as well? is there something subtle going on that i'm just not seeing? wait.h provides: #define DECLARE_WAIT_QUEUE_HEAD(name) \ wait_queue_head_t name = __WAIT_QUEUE_HEAD_INITIALIZER(name) and i don't see why that wouldn't have worked just fine. thoughts? 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

some questions/oddities regarding "exclusive" wait queues
by Robert P. J. Day June 22, 2013

June 22, 2013

currently digging through the code regarding wait queues and i ran across some oddities that i figure someone here can explain, so here goes. first, according to wait.h, there appears to be only one "flag" for a wait queue object: ===== struct __wait_queue { unsigned int flags; #define WQ_FLAG_EXCLUSIVE 0x01 void *private; wait_queue_func_t func; struct list_head task_list; }; ===== that's it -- WQ_FLAG_EXCLUSIVE appears to be the only possible flag setting for a "__wait_queue". am i missing any others? i certainly don't see any. next, as i read the code, it's possible to add both exclusive and non-exclusive wait queues to a wait queue head, and those operations are done in an interesting way in kernel/wait.c: ===== void add_wait_queue(wait_queue_head_t *q, wait_queue_t *wait) { unsigned long flags; wait->flags &= ~WQ_FLAG_EXCLUSIVE; spin_lock_irqsave(&q->lock, flags); __add_wait_queue(q, wait); spin_unlock_irqrestore(&q->lock, flags); } EXPORT_SYMBOL(add_wait_queue); void add_wait_queue_exclusive(wait_queue_head_t *q, wait_queue_t *wait) { unsigned long flags; wait->flags |= WQ_FLAG_EXCLUSIVE; spin_lock_irqsave(&q->lock, flags); __add_wait_queue_tail(q, wait); spin_unlock_irqrestore(&q->lock, flags); } EXPORT_SYMBOL(add_wait_queue_exclusive); ===== note carefully the difference -- "exclusive" wait queues are added at the *tail* end of the list, which is important for what happens next, since this is how an entire wait queue is woken by the core wakeup function in kernel/sched/core.c: ===== /* * The core wakeup function. Non-exclusive wakeups (nr_exclusive == 0) just * wake everything up. If it's an exclusive wakeup (nr_exclusive == small +ve * number) then we wake all the non-exclusive tasks and one exclusive task. * * There are circumstances in which we can try to wake a task which has already * started to run but is not in state TASK_RUNNING. try_to_wake_up() returns * zero in this (rare) case, and we handle it by continuing to scan the queue. */ static void __wake_up_common(wait_queue_head_t *q, unsigned int mode, int nr_exclusive, int wake_flags, void *key) { wait_queue_t *curr, *next; list_for_each_entry_safe(curr, next, &q->task_list, task_list) { unsigned flags = curr->flags; if (curr->func(curr, mode, wake_flags, key) && (flags & WQ_FLAG_EXCLUSIVE) && !--nr_exclusive) break; } } ===== first, the comment above that function seems wrong -- that routine will not simply wake "one exclusive task", it will wake "int nr_exclusive" exclusive tasks, will it not? (perhaps an earlier version woke only one, and the code was extended without adjusting the comment.) also, now it's clear why exclusive tasks are added at the *end* of the list -- all of the non-exclusive tasks must be processed first before counting off "nr_exclusive" tasks to be processed, does that seem correct? finally, if i understand all of the above correctly, there's one more curiosity back in wait.h -- a second form of the wait exclusive routine: ===== /* * Used for wake-one threads: */ static inline void __add_wait_queue_exclusive(wait_queue_head_t *q, wait_queue_t *wait) { wait->flags |= WQ_FLAG_EXCLUSIVE; __add_wait_queue(q, wait); } ===== note that that variation adds an exclusive wait queue, but *not* at the end, because it's apparently some sort of "wake-one thread", but i don't see a real distinction here. is it really necessary to recognize that distinction? a search of the entire kernel source tree shows only this: $ grep -rw "__add_wait_queue_exclusive" * fs/eventpoll.c: __add_wait_queue_exclusive(&ep->wq, &wait); include/linux/wait.h:static inline void __add_wait_queue_exclusive(wait_queue_head_t *q, $ that is, all of *one* usage in fs/eventpoll.c. does eventpoll.c genuinely need a unique interface for exclusive wait queues? anyway, feel free to tackle any of the above. more to come, i'm sure. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

2 2

File system query
by Dibyayan Chakraborty June 21, 2013

June 21, 2013

Hi, I am working on a project which requires to implement a file system with journaling capability. While i found a number of simple implementations of file systems , they all were lacking the journaling capability. like https://github.com/raczzoli/testfs or http://hi.baidu.com/yanyulou/item/e31a15f3b559ae49932af287 Now that i have implemented the formating procedures for the file system i think the next step would be to implement super_block operations , file operations for the VFS. I came to know that ext3/ext4 uses a jbd interface which implements the journaling capability in a file system independent way. But i could not find any documentation or details for using the jbd interface. So, any help which points out to the specific details of jbd interface or any comments which might be helpful in implementing the journaling capability is welcome. -- With Regards Dibyayan Chakraborty

3 5

Re: On creation of irq_desc and irq_data.
by mind entropy June 21, 2013

June 21, 2013

> Hi, > > I am reading through mini2440 code. I am going through the init_irq > (http://lxr.free-electrons.com/source/arch/arm/mach-s3c24xx/mach-mini2440.c#…) > code. In it (http://lxr.free-electrons.com/source/arch/arm/mach-s3c24xx/irq.c#L446) > there is irq_domain_add_legacy(..) which references irq_desc and > irq_data. I am not sure where these descriptors are created? In the > irq_domain_add_legacy there is a lookup for irq_data from the number. > Could someone tell where these descriptors are created? > > Thanks. I think it is statically created here https://github.com/torvalds/linux/blob/master/kernel/irq/irqdesc.c#L243 and the initialization happens in early_irq_init(..) here https://github.com/torvalds/linux/blob/master/kernel/irq/irqdesc.c#L251. Please correct me if I am wrong. Thanks.

2 1