October 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

Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding.
by Greg KH Nov. 12, 2015

Nov. 12, 2015

On Fri, Sep 25, 2015 at 07:08:32PM +0000, Rob Groner wrote: > > -----Original Message----- > > From: Greg KH [mailto:greg@kroah.com] > > Sent: Friday, September 25, 2015 2:37 PM > > To: Rob Groner <rgroner(a)RTD.com> > > Cc: Valdis.Kletnieks(a)vt.edu; kernelnewbies(a)kernelnewbies.org > > Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. > > > > On Fri, Sep 25, 2015 at 05:37:03PM +0000, Rob Groner wrote: > > > > > > > -----Original Message----- > > > > From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] > > > > Sent: Friday, September 25, 2015 12:48 PM > > > > To: Rob Groner <rgroner(a)RTD.com> > > > > Cc: kernelnewbies(a)kernelnewbies.org > > > > Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. > > > > > > > > On Fri, 25 Sep 2015 11:46:29 -0400, Rob Groner said: > > > > > Serial boards made by RTD using the Exar XR17V358 chip rely on the > > > > > extra capabilities of the Exar-provided driver to allow > > > > > configuration of the board. When support for the Exar chip was > > > > > added to the kernel 8250_pci driver, this then prevented easy use > > > > > of the board by customers for anything other than standard serial usage > > in RS232 mode. > > > > > > > > Was it your intent to also prevent the use of this board in standard > > > > serial usage in RS232 mode (which I'd expect is the most common use > > case)? > > > > > > That is a byproduct of giving the non-average user the ability to > > > reconfigure their board. This will basically move us back to pre-3.8, > > > where the customer would simply have to insmod the provided Exar > > > driver. The small inconvenience to that more common user seems (to us > > > in Tech Support) outweighed by the much greater inconvenience to the > > > user who wants to reconfigure. > > > > Where is the exar driver, in the kernel already? > > > > confused, > > I'm sorry for the confusion. Let me summup: > > We produce a serial port board that uses the Exar XR17V358 chip. The board features a jumperless configuration so that to change the board from RS232 to RS422/RS485, you use the GPIO available on the Exar chip, via the Exar driver. That driver is provided by Exar (from their website, and repackaged on our website and with the board). > > Recently, we began to hear from customers who purchased the board but could not get the driver to find the board (and thus could not reconfigure it, nor use the non-standard high baud rates the chip is capable of). We discovered that in 3.8, support for the Exar chip was added to the 8250_pci driver, thus binding it to the kernel. > > Until (and probably if) Exar decides to submit their driver to the kernel, then it leaves us with a problem that we didn't have prior to 3.8...namely that the board won't do what it is advertised to do unless the customer rebuilds the kernel (that is the only supported workaround from Exar). The only other workaround we know of (unbind) has met with mixed success which I won't go into unless you want me to, and is already resisted by some customers. > > The goal of this patch is to get to a point where a customer can install Linux and have full use of this RTD board (using the driver Exar/RTD provides). No one who has an RTD board is going to feel this is an inconvenience. Can you point me at the driver and I'll be glad to add it to the kernel so that the proper driver will bind to the device and this will not be an issue for users? thanks, greg k-h

4 14

[PATCH v3 0/4] SysFS driver for QEMU fw_cfg device
by Gabriel L. Somlo Nov. 4, 2015

Nov. 4, 2015

From: "Gabriel Somlo" <somlo(a)cmu.edu> Allow access to QEMU firmware blobs, passed into the guest VM via the fw_cfg device, through SysFS entries. Blob meta-data (e.g. name, size, and fw_cfg key), as well as the raw binary blob data may be accessed. The SysFS access location is /sys/firmware/qemu_fw_cfg/... and was selected based on overall similarity to the type of information exposed under /sys/firmware/dmi/entries/... NEW (since v2): Using ACPI to detect the presence and details of the fw_cfg virtual hardware device. Device Tree has been suggested by Ard as a comment on v2 of this patch, but after some deliberation I decided to go with ACPI, since it's supported on both x86 and some (uefi-enabled) versions of aarch64. I really don't see how I'd reasonably use *both* DT (on ARM) *and* ACPI (on x86), and after all I'm mostly concerned with x86, but originally wanted to maximize portability (which is where the register probing in earlier versions came from). A patch set generating an ACPI device node for qemu's fw_cfg is currently under review on the qemu-devel list: http://lists.nongnu.org/archive/html/qemu-devel/2015-09/msg06946.html (sorry, gmane appears down at the moment...) In consequence: - Patch 1/4 is mostly the same as in v2; - Patch 2/4 switches device initialization from register probing to using ACPI; this is a separate patch only to illustrate the transition from probing to ACPI, and I'm assuming it will end up squashed on top of patch 1/4 in the final version. - Patches 3/4 and 4/4 add a "human-readable" directory hierarchy built from tokenizing fw_cfg blob names into '/'-separated components, with symlinks to each 'by_key' blob folder (same as in earlier versions). At Greg's suggestion I tried to build this folder hierarchy and leaf symlinks using udev rules, but so far I haven't been successful in figuring that out. If udev turns out to be applicable after all, these two patches can be dropped from this series. In other words, patches 1 and 2 give us the following "by_key" listing of blobs contained in the qemu fw_cfg device (example pulled from a PC qemu guest running Fedora 22), with the value of each "name" attribute shown on the right: $ tree /sys/firmware/qemu_fw_cfg/ /sys/firmware/qemu_fw_cfg/ |-- by_key | |-- 32 | | |-- key | | |-- name ("etc/boot-fail-wait") | | |-- raw | | `-- size | |-- 33 | | |-- key | | |-- name ("etc/smbios/smbios-tables") | | |-- raw | | `-- size | |-- 34 | | |-- key | | |-- name ("etc/smbios/smbios-anchor") | | |-- raw | | `-- size | |-- 35 | | |-- key | | |-- name ("etc/e820") | | |-- raw | | `-- size | |-- 36 | | |-- key | | |-- name ("genroms/kvmvapic.bin") | | |-- raw | | `-- size | |-- 37 | | |-- key | | |-- name ("etc/system-states") | | |-- raw | | `-- size | |-- 38 | | |-- key | | |-- name ("etc/acpi/tables") | | |-- raw | | `-- size | |-- 39 | | |-- key | | |-- name ("etc/table-loader") | | |-- raw | | `-- size | |-- 40 | | |-- key | | |-- name ("etc/tpm/log") | | |-- raw | | `-- size | |-- 41 | | |-- key | | |-- name ("etc/acpi/rsdp") | | |-- raw | | `-- size | `-- 42 | |-- key | |-- name ("bootorder") | |-- raw | `-- size | ... Additionally, patches 3 and 4 (mostly 4) give us the following "user friendly" directory hierarchy as a complement to the above, based on tokenizing each blob name into symlink-tipped (sub)directories: ... |-- by_name | |-- bootorder -> ../by_key/42 | |-- etc | | |-- acpi | | | |-- rsdp -> ../../../by_key/41 | | | `-- tables -> ../../../by_key/38 | | |-- boot-fail-wait -> ../../by_key/32 | | |-- e820 -> ../../by_key/35 | | |-- smbios | | | |-- smbios-anchor -> ../../../by_key/34 | | | `-- smbios-tables -> ../../../by_key/33 | | |-- system-states -> ../../by_key/37 | | |-- table-loader -> ../../by_key/39 | | `-- tpm | | `-- log -> ../../../by_key/40 | `-- genroms | `-- kvmvapic.bin -> ../../by_key/36 `-- rev The trick is to figure out how to replace patches 3 and 4 with a udev rule that would read the contents of each "name" attribute, and build the "by_name" hierarchy and symlinks in userspace. I tried: $ udevadm info -a -p /sys/firmware/qemu_fw_cfg/by_key/33 looking at device '/firmware/qemu_fw_cfg/by_key/33': KERNEL=="33" SUBSYSTEM=="" DRIVER=="" ATTR{key}=="33" ATTR{name}=="etc/smbios/smbios-tables" ATTR{size}=="388" looking at parent device '/firmware/qemu_fw_cfg/by_key': KERNELS=="by_key" SUBSYSTEMS=="" DRIVERS=="" looking at parent device '/firmware/qemu_fw_cfg': KERNELS=="qemu_fw_cfg" SUBSYSTEMS=="" DRIVERS=="" ATTRS{rev}=="1" Then I tried creating a file, /usr/lib/udev/rules.d/99-qemu-fw-cfg.rules containing the following line: KERNELS=="qemu_fw_cfg", ATTRS{rev}=="1", SYMLINK="%p/%s{name}" but NOTHING happens when I insert/remove qemu_fw_cfg.ko. I also tried: KERNELS=="qemu_fw_cfg", ATTRS{rev}=="1", PROGRAM="/foo %k" where "/foo" basically did "echo $* > /tmp/bar", but no /tmp/bar file ever showed up as a consequence of inserting/removing the qemu_fw_cfg.ko module. At this point, I need help figuring out whether udev is really what would get the second, user-friendly, "by_name" /sysfs directory tree created, and how I'd go about that... Thanks much, --Gabriel Gabriel Somlo (4): firmware: introduce sysfs driver for QEMU's fw_cfg device firmware: use acpi to detect QEMU fw_cfg device for sysfs fw_cfg driver kobject: export kset_find_obj() for module use firmware: create directory hierarchy for sysfs fw_cfg entries .../ABI/testing/sysfs-firmware-qemu_fw_cfg | 213 ++++++++ drivers/firmware/Kconfig | 10 + drivers/firmware/Makefile | 1 + drivers/firmware/qemu_fw_cfg.c | 575 +++++++++++++++++++++ lib/kobject.c | 1 + 5 files changed, 800 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg create mode 100644 drivers/firmware/qemu_fw_cfg.c -- 2.4.3

8 16

strange comment in load_elf_binary
by 慕冬亮 Oct. 30, 2015

Oct. 30, 2015

I see something strange in the load_elf_binary. /* This is the program interpreter used for * shared libraries - for now assume that this * is an a.out format binary */ This comment is in the load_elf_binary. I don't know why it "assume that this is an a.out format binary". a.out and elf are two different file formats. If I misunderstand something, please let me know. Thanks. - mudongliang

3 2

How to store the data in disk directly in kernel module ?
by lx Oct. 30, 2015

Oct. 30, 2015

hi all: I capture the TCP packet in function of netif_receive_skb , I want to store the playload of TCP packet in disk directly. we can't read/write the file in kernel module, so store in disk directly maybe a way? This is a good way, or other suggestions? Thank you.

1 0

Re: Two questions
by Anuz Pratap Singh Tomar Oct. 28, 2015

Oct. 28, 2015

On Wed, Oct 28, 2015 at 4:08 PM, Albino B Neto <bino(a)bino.us> wrote: > 2015-10-28 13:57 GMT-02:00 Anuz Pratap Singh Tomar < > chambilkethakur(a)gmail.com>: > > 1. Is this book still relevant? > > Linux Kernel in Nutshell by GKH > > http://www.kroah.com/lkn/ > > Yes. You read here also [0]. > > 0 - https://www.kernel.org/doc/Documentation/ Thanks, I am aware of documentation. My question was wrt the changing nature of kernel and book has not been changed for quite few years now. > > > > 2. Which is the official mailing list discussion on staging tree/driver? > > Mailing[1] of Linux. > > 1 - http://vger.kernel.org/vger-lists.html I have searched for a bit before asking the question. Which particular one is for staging tree/driver? As quick Ctrl+f with staging yields no results. > > > > Albino > -- Thank you Warm Regards Anuz

2 1

Two questions
by Anuz Pratap Singh Tomar Oct. 28, 2015

Oct. 28, 2015

1. Is this book still relevant? Linux Kernel in Nutshell by GKH http://www.kroah.com/lkn/ 2. Which is the official mailing list discussion on staging tree/driver? -- Thank you Warm Regards Anuz

3 2

(no subject)
by Shraddha Barke Oct. 28, 2015

Oct. 28, 2015

I updated my local kernel repository with all recent commits using the following commands- git checkout staging-next git pull After that when I try to compile, I'm getting an error scripts/sign-file.c:20:25: fatal error: openssl/bio.h: No such file or directory #include <openssl/bio.h> ^ compilation terminated. scripts/Makefile.host:91: recipe for target 'scripts/sign-file' failed make[1]: *** [scripts/sign-file] Error 1 Makefile:545: recipe for target 'scripts' failed make: *** [scripts] Error 2 What should I do to fix it? Thanks in advance.

3 3

where struct pci_device_id is defined ?
by Ramon Fried Oct. 27, 2015

Oct. 27, 2015

Hi. I'm trying to find the definition of "struct pci_device_id" , but I only get forward declarations. I tried grepping the entire tree, and nothing matches. Am I missing something ? Thanks. Ramon

3 2

How the "<linux/version.h>" file is generated?
by Nan Xiao Oct. 27, 2015

Oct. 27, 2015

Hi all, After browsing http://lxr.free-electrons.com/source/include/linux/, I can't find version.h file. So I am curious about how the "<linux/version.h>" file is generated? Thanks very much in advance! Best Regards Nan Xiao

2 2