August 2015 - kernelnewbies@kernelnewbies.org

how it the linux implementation of double linked lists useful
by Ahmed Soliman Aug. 2, 2015

Aug. 2, 2015

while reading through linux/list.h I noticed that the linked list structure is really simple with only pointer to the previous node and pointer to next node with no other data (It can't handle anything inside it ) I started to wonder how such linked list can be useful to the kernel or (useful in general) ! thanks

2 1

System can't boot properly coz of block device state
by Alvin Abitria Aug. 1, 2015

Aug. 1, 2015

I'm having a problem where the server system hosting a pci device we're developing messes up in boot and can't get to the login screen. I'm developing a linux driver for that pci device (a block device/ssd actually). However from our tests, when the device is has undergone lots of usage, it initializes _very_slowly_ when the system is powered on. So slow that the system is already done booting but the device init is not yet. Of course this is in fw. From the driver side, we employ mechanism to hold off system's attempts to read the device during block layer add_disk() when the module is installed IF the device is not yet done initializing. Once the device is ready, the driver allows those pending reads to proceed, and that completes the block driver module installation. On normal cases when the device is not yet too used up, that driver delaying tactic works during bootup - device finishes its installation and system boots nicely and smoothly. But when device is too used up, driver still installs itself after the very slow device init completes, but by that time the system just keeps cycling around some USB drivers and can't get to login screen. Some systems already invoke their emergency mode because of too much lag on device side. Observed in RHEL 7 distro. My question is: is there a way for my block driver to tell or message the system to wait for it (the driver) so the system bootup will still boot normally? Like it's i'm busy, please wait for me... Yes, the FW must have the root cause but let's assume at this point changing it will be very costly and very risky. So far I've tried blk_stop_queue() and blk_start_queue() in an attempt to hold off those read requests during add_disk, but results are still same. blk_requeue_request was also tried but with same results. Those functions are more on internal management of the request_queue, and it seems they have nothing to do with communicating my intention to the system. I know I'm asking for a plug fix and not the cleanest solution but I want your thoughts if this is possible. Thanks!

1 0

shared memory via /dev/shm?
by Nicholas Murphy Aug. 1, 2015

Aug. 1, 2015

Apologies if this has been asked before: Yes, I’ve read all the disclaimers against accessing files in the kernel, but I want to set up a shared memory segment between a kernel module and one or more user processes, and /dev/shm seems like a good way to do that. Given that, what’s the preferred way to access files within the kernel (specifically within a kernel module)? At the moment, I’m using filp_open() on module load to open the file (which seems to work), then: filp_close() to close the file * kern_path() to get the entry for the /dev/shm file vfs_unlink() to delete the /dev/shm file dput() to free the dentry path_put() to free the path …on module unload, and it hangs. Any suggestions what I’m doing wrong? Thanks, Nick

2 3