January 2015 - kernelnewbies@kernelnewbies.org

How to handle Hotplug with UIO userspace driver
by Mandeep Sandhu Sept. 28, 2017

Sept. 28, 2017

Hi All, We're working on a custom PCIe based hardware, which can be hotplugged into the system. We're using the UIO approach of having a minimal kernel driver which basically handles the interrupt and provides a mmap of the device memory to userspace and userspace driver which mmap's the provided memory and manages the device. We're using systemd and udev rules to spawn off a user process whenever the hardware is plugged into the system. Now my question is, how can we gracefully inform the userspace process if someone pulls out the hardware (sitting on a PCI slot). Even with full hotplug support, there can always be a case of "surprise removal", where someone yanks the board without going through the whole "attention button" routine. While the kernel driver has no problem with hot-removal, I see that if I "unregister" our UIO driver in response to the removal, then the mapping for the hardware's physical memory would become "invalid" (done by UIO on unregsiter). This could possibly cause the user-space process to crash due to illegal memory access. Is there a "standard" way to handle this scenario, i.e for hotpluggable hardware using UIO? Basically, we'd want to "unregister" the UIO device only after the userspace process is informed of the removal so that it could unmap/close the device and exit gracefully. We could try doing it using some systemd trick, where we put a dependency on one of the UIO created files (/dev/uioX), so that when the file is destroyed, systemd could kill/shutdown the process. Although, there's no guarantee that the userspace process won't try to access the mmaped space during that interval, so this isn't a reliable solution either. Any hints, thoughts? Thanks., -mandeep

3 7

How to get the inode - no path_lookup
by Rishi Agrawal Sept. 17, 2015

Sept. 17, 2015

Hi All, I had a module which used the path_lookup function to print the details of any file's inode. I now want to rewrite that module in order to show some juniors how to write some code in kernel. I am using 3.4.6 kernel, I tried finding out path_lookup but google showed that it has been removed. I tried the following code then which did not work . . . dentry = kern_path_create(AT_FDCWD, filename, &path, 1); if (IS_ERR(dentry)) { printk("Failed to obtain the dentry"); return; } its not returning dentry I again tried after seeing the implementation of vfs_stat function user_path_at(AT_FDCWD, filename, lookup_flags, &path); but this also fails. I am using a proc interface to pass the filename, and copying the filename into a kernel buffer. How can I get a copy of vfs inode for a file name. -- Regards, Rishi Agrawal

4 8

Is it all right for Netfilter modules to use control buffers (skb->cb)?
by Alberto Leiva April 28, 2015

April 28, 2015

Hi I was assuming yes, since I've seen at least one module doing this. An example is nf_defrag_ipv6 (ipv6_defrag() calls nf_ct_frag6_gather() which calls NFCT_FRAG6_CB()). What confuses me is that the IPv6 subsystem seems to have its own control buffer: - ipv6_rcv() calls IP6CB(): http://lxr.free-electrons.com/source/net/ipv6/ip6_input.c?v=3.17#L102 - then it calls the netfilter chain, which might include nf_defrag_ipv6: http://lxr.free-electrons.com/source/net/ipv6/ip6_input.c?v=3.17#L186 - then ip6_rcv_finish() comes into play, which calls dst_input(), which might well call ip6_input(), which calls ip6_input_finish(). - ip6_input_finish() once again dereferences the IPv6 version of the control buffer: http://lxr.free-electrons.com/source/net/ipv6/ip6_input.c?v=3.17#L219 If Netfilter modules are allowed to wash out control buffers, how does the IPv6 private data seems to be surviving the Netfilter chain? Thanks

1 1

Question about switch_mm function
by Sreejith M M March 25, 2015

March 25, 2015

Hi, I was trying to understand the difference in scheduling between processes and threads(belong to same process). I was thinking that, when kernel has to switch to a task which belong to the same process, it does not have to clear / replace page global directories and other memory related information. But in switch_mm function some code is put under CONFIG_SMP function. What is its signigicance? Code is below(http://lxr.free-electrons.com/source/arch/x86/include/asm/mmu_context… . What I infer is that the code is doing flush tlb, reload page table directories etc in multiprocessor mode(obviously) but I believe this code may never be executed . Can anyone help to understand what this part of the function supposed to do? 60 #ifdef CONFIG_SMP 61 else { 62 this_cpu_write(cpu_tlbstate.state, TLBSTATE_OK); 63 BUG_ON(this_cpu_read(cpu_tlbstate.active_mm) != next); 64 65 if (!cpumask_test_cpu(cpu, mm_cpumask(next))) { 66 /* 67 * On established mms, the mm_cpumask is only changed 68 * from irq context, from ptep_clear_flush() while in 69 * lazy tlb mode, and here. Irqs are blocked during 70 * schedule, protecting us from simultaneous changes. 71 */ 72 cpumask_set_cpu(cpu, mm_cpumask(next)); 73 /* 74 * We were in lazy tlb mode and leave_mm disabled 75 * tlb flush IPI delivery. We must reload CR3 76 * to make sure to use no freed page tables. 77 */ 78 load_cr3(next->pgd); 79 trace_tlb_flush(TLB_FLUSH_ON_TASK_SWITCH, TLB_FLUSH_ALL); 80 load_LDT_nolock(&next->context); 81 } 82 } 83 #endif -- Regards, Sreejith

3 5

Is this a good first patch for enabling screen rotation?
by Brock York Feb. 11, 2015

Feb. 11, 2015

Hello This is my first patch and after speaking to a few kernel devs at LCA2015 I thought I would ask here for some advice on if I have followed the newbie guide correctly. The patch is to get automatic screen rotation working on a acer iconia w500 tablet. The patch was made against linux-next branch next-20150129 and successfully built and ran. Do you think this is a succificient patch to get accepted by the platform-x86 maintainers? I used get_maintainer.pl and it suggested the platform-x86 mailing list. Thank you, any help is much appreciated. Regards Brock York. BEGIN PATCH BELOW------------ Subject: [PATCH] acer-wmi: Enable screen auto-rotation via udev Emit udev event via kobject_uevent when accelerometer position is updated. This is to allow userspace to grab the accelerometer position and rotate the screen accordingly. Swap the x and y values and negate the x value converting the accelerometers coordinate system into the coordinate system userspace udev expects. Accelerometer Expected Coordinates Coordinates x+ y+ ^ ^ | | | | y+<----/ /---->x+ / / z+ z+ Screen Orientation ________ | | | | |________| Tested on a Acer Iconia W500 tablet with Gnome 3 Signed-off-by: Brock York <twunknown(a)gmail.com> --- drivers/platform/x86/acer-wmi.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c index 3ac29a1..d5678e4 100644 --- a/drivers/platform/x86/acer-wmi.c +++ b/drivers/platform/x86/acer-wmi.c @@ -1491,12 +1491,14 @@ static int acer_gsensor_event(void) return -1; input_report_abs(acer_wmi_accel_dev, ABS_X, - (s16)out_obj->package.elements[0].integer.value); + -(s16)out_obj->package.elements[1].integer.value); input_report_abs(acer_wmi_accel_dev, ABS_Y, - (s16)out_obj->package.elements[1].integer.value); + (s16)out_obj->package.elements[0].integer.value); input_report_abs(acer_wmi_accel_dev, ABS_Z, (s16)out_obj->package.elements[2].integer.value); input_sync(acer_wmi_accel_dev); + + kobject_uevent(&acer_wmi_accel_dev->dev.kobj, KOBJ_CHANGE); return 0; } -- 2.2.2

2 2

Propper use of pci_map_sg
by Malte Vesper Feb. 3, 2015

Feb. 3, 2015

Hi, I am trying to use pci_map_sg in combination with get_user_pages_fast for a driver. However my code screws the processes memory map over. For easier testing I bundled the piinin/unpinning and mapping unmapping into one ioctl call. The following code misses all the checks on return values, since it is only inteneded as a MWE. When I run my code I get a "*BUG: Bad page map in process ...*", after "Done" is printed. I tried following DMA-API-howto.txt and looking at other code, but I fail to see where I go wrong. Regards, Ted Code from the IOCTL handler: case IOCTL_FPGA_PIN_PAGE: { struct pageInfo pageInfo; dev_dbg(&pcidev->dev, pr_fmt("IOCTL: IOCTL_FPGA_PIN_PAGE\n")); if(!copy_from_user(&pageInfo, (void*)arg, sizeof(struct pageInfo))) { //horrible test const int noPages = pageInfo.size/PAGE_SIZE; int pinned; int mapped = 0; struct scatterlist* scatterlist; printk("Test start\n"); //userspacestartpointer, nopages, write?, page* array struct page** pages=kmalloc(sizeof(struct page*)*noPages, GFP_KERNEL); pinned=*get_user_pages_fast*((unsigned long)pageInfo.start, noPages, 1, pages); scatterlist = kmalloc(sizeof(struct scatterlist)*pinned, GFP_KERNEL); for(int i=0; i<pinned; ++i) { sg_set_page(&scatterlist[i], pages[i], PAGE_SIZE, 0); } mapped =*pci_map_sg*(pcidev, scatterlist, pinned, DMA_BIDIRECTIONAL); *pci_unmap_sg*(pcidev, scatterlist, pinned, DMA_BIDIRECTIONAL); for(int i=0; i<pinned; ++i) { *put_page*(pages[i]); //I did place a print here and got two pages unpinned as I expected } kfree(scatterlist); kfree(pages); printk("Done\n"); /*pageInfo.pageId = getPageId(getArea(&pageInfo)); copy_to_user((void*)arg, &pageInfo, sizeof(struct pageInfo));*/ return pageInfo.pageId; } else { return -EFAULT; } } break; P.S.: I used the following code to allocate the memory in userspace, and I use chunk and chunksize to fill pageInfo.start and pageInfo.size respectivly: const int pagesize = sysconf(_SC_PAGESIZE); const int chunksize = 2*pagesize; void* chunk; if(int error = posix_memalign(&chunk, pagesize, chunksize)) { std::cout << "Could not get a page." << std::endl; return error; }

1 2

Looking for ARM SoC porting guidelines
by Mike Thompson Feb. 2, 2015

Feb. 2, 2015

I'm working on a port the latest Linux kernel to a Nuvoton N32905 - a very inexpensive ARM9 based SoC similar to the Freescale iMX23 in many respects. My hope is that my code for this SoC will eventually reach the mainline kernel, but the whole process a fairly daunting task to a kernel newbie such as myself. I do have a six year old port of the 2.6.35 kernel to this SoC to help as a reference, but it's pretty much a rewrite to support devicetree, the common clock framework, and a myriad of changes needed to get a new SoC supported in the mainline kernel. Not to mention all the 2.6.35 code added for this chip isn't even close to the coding standards for the Kernel. So far I got the 3.17 kernel running pretty well the baseline peripherals such as clocks, interrupt controller, UART, GPIO & pin muxing along with hire level peripherals such as MMC/SD card support, MTD NAND and NOR flash and USB host support. As a guide, I've been using other ARM SoCs for examples and a number of very useful presentations on ARM SoC support from the Free Electron folks. Although presentations such as the "ARM SoC Linux Support Check-list" are very useful, they don't go into much detail. My question is two fold. Is there detailed information of all the things that need to be covered in the code to introduce a new ARM SoC into the kernel? Then, is there a description of how I start to go about contributing support for this chip into the Linux kernel? I honestly don't really know where to begin. Any advice or pointers would be sincerely appreciated. Mike Thompson BTW, my git reposity for this SoC is: https://github.com/mpthompson/linux/tree/n329

3 7

what should be a simple question about sysfs attributes ...
by Robert P. J. Day Feb. 1, 2015

Feb. 1, 2015

... but will take a while to set up. i want to write a short tutorial on kobjects, sysfs and attributes so i want to make absolutely sure i understand them (which is something i should understand anyway. :-) from sysfs.h and kobject.h, we have the definition of the generic kernel-wide "attribute" and "kobj_attribute" structures: struct attribute { const char *name; umode_t mode; #ifdef CONFIG_DEBUG_LOCK_ALLOC bool ignore_lockdep:1; struct lock_class_key *key; struct lock_class_key skey; #endif }; and struct kobj_attribute { struct attribute attr; ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr, char *buf); ssize_t (*store)(struct kobject *kobj, struct kobj_attribute *attr, const char *buf, size_t count); }; so what the above shows is that a "kobj_attribute" contains an "attribute" and has, as its internal callback routines, functions that deal only with completely generic kobject and kobj_attribute pointers. so if i'm creating a number of attributes for some kobject i've created, and i'm associating show and store routines with each one, those show and store routines must have that prototype. for example, look at mm/ksm.c and how the attributes and callback routines are defined -- here's one: //////// static ssize_t full_scans_show(struct kobject *kobj, struct kobj_attribute *attr, char *buf) { return sprintf(buf, "%lu\n", ksm_scan.seqnr); } KSM_ATTR_RO(full_scans); static struct attribute *ksm_attrs[] = { &sleep_millisecs_attr.attr, &pages_to_scan_attr.attr, &run_attr.attr, &pages_shared_attr.attr, &pages_sharing_attr.attr, &pages_unshared_attr.attr, &pages_volatile_attr.attr, &full_scans_attr.attr, #ifdef CONFIG_NUMA &merge_across_nodes_attr.attr, #endif NULL, }; static struct attribute_group ksm_attr_group = { .attrs = ksm_attrs, .name = "ksm", }; //////// so the way i've always interpreted the above is that, when i finally register the attributes with the kernel, i am registering really just the underlying generic "attribute" structure and, when i try to access that attribute file, it automatically dereferences to the enclosing kobj_attribute structure to pick up the corresponding show() and store() routines associated with that attribute. so the first question is, is my understanding correct? if, in the above case, whenever i try to access one of the ksm attributes in /sys/kernel/mm/ksm, does the kernel take the reference to that *generic* attribute and automatically dereference/container_of() on it to get the enclosing kobj_attribute structure to pick up the corresponding show() and store() routines? asked a shorter way, is it assumed that a kobject attribute is *always* contained inside a kobj_attribute structure? and that the code in mm/ksm.c is an example of how to add individual show() and store() routines to such attributes? now here's part 2, and it's just a followup from the above. the second variation for attributes is what you see in cpufreq.c. rather than each attribute having its own callback routines, that code defines a prototype for cpufreq-*specific* show and store routines and a cpufreq-specific "freq_attr": struct freq_attr { struct attribute attr; ssize_t (*show)(struct cpufreq_policy *, char *); ssize_t (*store)(struct cpufreq_policy *, const char *, size_t count); }; *however* (and here's the thing i want to make sure i understand), when you register all of the cpufreq attribute files, each one still has to be interpreted as if it's part of a generic kobj_attribute structure with generic show() and store() routines, so what cpufreq does is define two generic show() and store() routines, and a couple helper macros that allow those two routines to then dereference to the appropriate cpufreq_policy and freq_attr pointers, then call the attribute-specific show() and store() routines: ////////// #define to_policy(k) container_of(k, struct cpufreq_policy, kobj) #define to_attr(a) container_of(a, struct freq_attr, attr) static ssize_t show(struct kobject *kobj, struct attribute *attr, char *buf) { struct cpufreq_policy *policy = to_policy(kobj); struct freq_attr *fattr = to_attr(attr); ... snip ... } static ssize_t store(struct kobject *kobj, struct attribute *attr, const char *buf, size_t count) { struct cpufreq_policy *policy = to_policy(kobj); struct freq_attr *fattr = to_attr(attr); ... snip ... } ////////// and at the end of that file, the attributes are all registered with: static const struct sysfs_ops sysfs_ops = { .show = show, .store = store, }; static struct kobj_type ktype_cpufreq = { .sysfs_ops = &sysfs_ops, .default_attrs = default_attrs, .release = cpufreq_sysfs_release, }; which i interpret as saying that all of those attributes should be registered with the same single show() and store() routines (as opposed to ksm, which used different show() and store() routines for each attribute. in closing(?), as i understand it, when i access a kobject attribute file, it is assumed that that attribute is enclosed in a kobj_attribute structure, which contains the generic show() and store() routines, and i've seen two patterns for that: 1) in mm/ksm.c, each attribute is *directly* registered with callback routines with that prototype specific to that attribute, or 2) in cpufreq.c, all attributes are, in one operation, all registered with the *same* pair of generic callback functions, and those functions are then required to dereference the generic pointers to be able to call the appropriate callbacks for the given attribute. do i have this about right? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

2 3

Mount Compressed File like a Folder
by Lucas Tanure Feb. 1, 2015

Feb. 1, 2015

Hi, There is a way to mount a xz or gz file , update it, and umount ? Like, this file will be folder that is compressed and I can mount, update the files, and close ? Thanks -- Lucas Tanure +55 (19) 988176559

2 1

Re: Eudyptula Challenge response submission
by Jonathan Jin Jan. 31, 2015

Jan. 31, 2015

On Sat, Jan 31, 2015 at 11:40:13PM +0530, Alisha Jain wrote: > I just want to know what proof should I give? Re-adding this discussion back to the mailing list. When you respond to someone on the mailing list, be sure to also CC the list itself, so as to include everybody in the conversation and get as many voices involved as possible. That said, in terms of proof, Little leaves it, to my understanding, very much up to your personal judgment. Maybe you could consider attaching some form of logging output to your submission email? -- Jonathan Jin jjin.me

2 2