September 2020 - kernelnewbies@kernelnewbies.org

Can I reboot a USB device within a driver's probe function?
by Thierry Seegers Sept. 14, 2020

Sept. 14, 2020

Hi, I have a USB device that when plugged into a computer shows up as a generic USB device with product ID "0580". The only thing you're expected to do is to upload firmware to it and reboot it. It then disappears from the system and reappears as a USB video camera with product ID "058a". For example, here's a Python script (https://github.com/longjie/ps4eye/blob/master/script/ps4eye_init.py) that does just that. It uses Python usb.core and usb.util to upload a firmware file as control packets. When that is done, it sends a special control packet to reboot the device. After the device is rebooted, it no longer shows up (using "lsusb", for example) as the generic device but as a USB camera device and is taken in charge by the corresponding driver. Note that sending that last control packet, it will fail with an EPIPE error but that is expected since the interface we were talking to is actually gone. One can even have this script executed automatically through a ".rules" file. So far so good. My question is: can I write a driver that will perform the same thing? I started exploring the idea but I'm stuck. I have written such a driver that performs the firmware upload and sends that special control packet. It does all of this within the USB probe() function which is called on the driver to see if it wants to handle the device. My problem is that, after returning from the probe() function, the system does not realize that the interface is actually gone and that a new one has appeared. If I do "lsusb", the same "0580" device is still listed and the new USB camera device isn't discovered. No matter what I tried, I can't get the OS to "shake" this device which is gone. I've tried the following: - usb_driver_release_interface() - usb_reset_configuration() - interface->condition = USB_INTERFACE_UNBOUND; - interface->needs_binding = 1; - usb_put_intf(); - usb_put_dev(); - return -ENODEV - return -EBUSY I don't know what I'm supposed to do within (or outside) the probe function to signify to the OS that this interface is actually not existent anymore, that this driver doesn't want to deal with this device any further and that it (the OS) should be listening to new device connections. Note that after sending the reboot packet, you can't communicate with the device anymore, it would simply return EPIPE. Thanks for your help

2 4

Disable EISA and probes
by Jeffrey Walton Sept. 5, 2020

Sept. 5, 2020

Hi Everyone, I would like to disable EISA and its probes during boot. I found the docs at https://www.kernel.org/doc/html/latest/driver-api/eisa.html, but it does not discuss how to disable EISA or the probes. I also found https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1543919, where folks are wondering why EISA is enabled by default nowadays. And one person asks about a kernel option to disable it (like I am doing). I'd like to add a boot param like eisa=0 or eisa=off, but I suspect it's not that easy. Looking at the three documented kernel parameters, they all enable EISA and probes. How do I disable EISA and the probes? Thanks in advance.

3 7

How to acquire the occupancy time of CPUs within a certain duration, i.e. 10ms, 1ms, and etc?
by 孙世龙 sunshilong Sept. 5, 2020

Sept. 5, 2020

Hi, list How to acquire the occupancy time of CPUs within a certain duration, i.e. 10ms, 1ms, and etc? Could somebody please shed some light on this matter? I would be grateful to have some help with this question. Best Regards. Sunshilong

2 2

Please assess this patch: [PATCH] Docs: FIxed spelling errors in Documentation/devicetree/bindings/
by Marlon Rac Cambasis Sept. 4, 2020

Sept. 4, 2020

Hello, I would like to make my first contribution to the Linux kernel in the form of a (trivial) spelling fix. Does this patch (including the subject and the way my mail is being displayed), meet the requirements? Furthermore, I think the correct place to send it to would be devicetree(a)vger.kernel.org and also CCing it to trivial(a)kernel.org. Is this all okay? Should I send it to somewhere else, do I need to make any changes? Also I don't need to add a body to the patch when I send it do I? Here is my patch: Signed-off-by: Marlon Rac Cambasis <marlonrc08(a)gmail.com> --- Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt | 2 +- Documentation/devicetree/bindings/reset/nuvoton,npcm-reset.txt | 2 +- Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt index 70659c9..372f473 100644 --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt @@ -75,7 +75,7 @@ Required Properties: The child node should contain a list of pin(s) on which a particular pin function selection or pin configuration (or both) have to applied. This list of pins is specified using the property name "samsung,pins". There - should be atleast one pin specfied for this property and there is no upper + should be atleast one pin specified for this property and there is no upper limit on the count of pins that can be specified. The pins are specified using pin names which are derived from the hardware manual of the SoC. As an example, the pins in GPA0 bank of the pin controller can be represented diff --git a/Documentation/devicetree/bindings/reset/nuvoton,npcm-reset.txt b/Documentation/devicetree/bindings/reset/nuvoton,npcm-reset.txt index 6e80270..17b7a6a 100644 --- a/Documentation/devicetree/bindings/reset/nuvoton,npcm-reset.txt +++ b/Documentation/devicetree/bindings/reset/nuvoton,npcm-reset.txt @@ -9,7 +9,7 @@ Optional property: - nuvoton,sw-reset-number - Contains the software reset number to restart the SoC. NPCM7xx contain four software reset that represent numbers 1 to 4. - If 'nuvoton,sw-reset-number' is not specfied software reset is disabled. + If 'nuvoton,sw-reset-number' is not specified software reset is disabled. Example: rstc: rstc@f0801000 { diff --git a/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt b/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt index d78d4a8f..a819763 100644 --- a/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt @@ -20,7 +20,7 @@ Optional properties: This is useful in situations where another watchdog engine on chip is to perform the reset. - If 'aspeed,reset-type=' is not specfied the default is to enable system + If 'aspeed,reset-type=' is not specified the default is to enable system reset. Reset types: -- 2.9.0

4 3

Relationship between Rx/Tx ring and Skbuff.
by Vasu M Sept. 4, 2020

Sept. 4, 2020

Hi, I would like to understand the journey of the packet in Linux kernel. There are many resources that explain this differently but as I have understood it on a high level, when a packet is received in a NIC, DMA moves the packets from the NIC frame buffer into the RX ring buffer in the driver. A hardware interrupt is then raised and the top half moves the packet to the RX ring buffer. Is it right to understand that the bottom half tasklets then drain the buffer and move the packets to sk_buff data structure? Are the RX/TX buffers different from sk_buff in terms of memory regions or the sk_buff simply points to the physical address of the packets residing in the RX ring and then does the manipulation of the pointers to send it up in the kernel IP stack? I know this is a broad topic but I would like to seek clarification from the experts on my understanding of packet movement inside the kernel. Or can you point me to a resource which can be a close explanation about the implementation on how the kernel handles in > 4.x ? Thanks, Vasu

4 4

HOW DO I KNOW SOMEONE RECEIVED MY PATCH
by Ronald P Guilmet Sept. 4, 2020

Sept. 4, 2020

I'm sure this has been asked before. I couldn't find any searches that answer this for me. I did the following: I made a file checkpatch clean. I checked my patch with checkpatch clean I used get_maintainer script to get emails to use for patch I used git send-email. The results are OK My concern is that my sendmail may not be setup right? I use Mutt and I have the muttrc setup as the Kernel docs show. Sendmail: /usr/sbin/sendmail -i pmladek(a)suse.com andriy.shevchenko(a)linux.intel.com sergey.senozhatsky(a)gmail.com gregkh(a)linuxfoundation.org gustavoars(a)kernel.org linux-kernel(a)vger.kernel.org ronpguilmet(a)gmail.com From: Ron Guilmet <ronpguilmet(a)gmail.com> To: pmladek(a)suse.com Cc: andriy.shevchenko(a)linux.intel.com, sergey.senozhatsky(a)gmail.com, gregkh(a)linuxfoundation.org, gustavoars(a)kernel.org, linux-kernel(a)vger.kernel.org, Ron Guilmet <ronpguilmet(a)gmail.com> Subject: [PATCH] Drivers Accessibility Braille braille_console.c makes checkpatch clean Date: Thu, 3 Sep 2020 23:44:46 -0400 Message-Id: <20200904034446.1867-1-ronpguilmet(a)gmail.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Result: OK

3 2

Please give advise about my first patch attempt
by Thomas Schmitt Sept. 3, 2020

Sept. 3, 2020

Hi, i am preparing my first patch. May i ask for review and advise how to make it acceptable ? The patch shall fix an old regression of cdrom and sr drivers. Although drivers/cdrom has no mailing list entry in MAINTAINERS, i assume that such patches should go to linux-scsi(a)vger.kernel.org which is listed for drivers/scsi/sr*. Right ? So the change affects two different subsystems which have the same maintainer and have a very close relation. Do i need to split it into two, nevertheless ? The change is relative to git tag v5.8 of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git It is not locally committed yet, so i cannot run git format-patch for now. I plan to do if i get some approval here. I tested with three different optical drives at SATA and USB by dd if=/dev/sr0 bs=2048 count=1 of=/dev/null Unchanged yields ENOMEDIUM or EIO. Changed yields success. Please also tell me if my mailer (used with this mail) would cause problems. -------------------------------------------------------------------------- Affected files: drivers/cdrom/cdrom.c drivers/scsi/sr.c include/linux/cdrom.h Check passed: scripts/checkpatch.pl reports total: 0 errors, 0 warnings, 131 lines checked -------------------------------------------------------------------------- Intended commit message: -------------------------------------------------------------------------- Re-enable waiting for CD drive to complete medium decision after tray load If open("/dev/sr0", O_RDONLY); pulls in the tray of an optical drive, it immediately returns -1 with errno ENOMEDIUM or the first read(2) fails with EIO. Later, when the drive has stopped blinking, another open() yields success and read() works. This affects not only userland reading of the device file but also mounting the device. Commit 210ba1d1724f5c4ed87a2ab1a21ca861a915f734 of january 2008 switched sr_drive_status() away from indirectly using sr_do_ioctl() for sending TEST UNIT READY commands. sr_do_ioctl() has a wait-and-retry loop for the drive's intermediate sense reply: 2 04 01 Logical unit is in process of becoming ready Since then sr_drive_status() does not wait any more. By commit 96bcc722c47d07b6fd05c9d0cb3ab8ea5574c5b1 of july 2008 it now returns CDS_DRIVE_NOT_READY if above drive reply is received. But the function open_for_data() in drivers/cdrom/cdrom.c expects that its call of cdo->drive_status() waits until the drive has decided about the usability of the inserted medium. Any reply other than CDS_DISC_OK yields ENOMEDIUM. Even if the drive waits with its reply to START/STOP UNIT until it is ready (e.g. Pioneer BDR-S09), the first read(2) yields EIO, because the newly loaded medium gets not properly assessed by check_disk_change() before sr_block_open() returns. Fix the problem by a new function wait_for_medium_decision() which gets called by open_for_data() instead of directly calling cdo->drive_status(). Make sure that scsi/sr.c assesses the newly loaded medium without additional risk of deadlock. After loading the tray and due waiting for readiness, cdrom_open() now returns -EDEADLK to urge its caller to drop its mutex, to re-run check_disk_change(), and then to call cdrom_open() again. Only scsi/sr.c is for now aware of this. cdrom/gdrom.c, paride/pcd.c, and ide/ide-cd.c call cdrom_open() too, but i cannot test them. So their unchanged code will return -EDEADLK instead of retrying. Not worse or more deceiving than -ENOMEDIUM or -EIO. Signed-off-by: Thomas Schmitt <scdbackup(a)gmx.net> -------------------------------------------------------------------------- Code change: -------------------------------------------------------------------------- diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c index d82b3b7658bd..9e113b0dfc82 100644 --- a/drivers/cdrom/cdrom.c +++ b/drivers/cdrom/cdrom.c @@ -286,6 +286,18 @@ #include <scsi/scsi_common.h> #include <scsi/scsi_request.h> +/* + * For the wait-and-retry loop after possibly having loaded the drive tray. + * 10 retries in 20 seconds are hardcoded in sr_do_ioctl() which was used + * up to 2008. + * But time spans up to 25 seconds were measured by libburn on + * drives connected via SATA or USB-SATA bridges. + * So 20 retries * 2000 ms = 40 seconds seems more appropriate. + */ +#define CD_OPEN_MEDIUM_RETRY_MAX 20 +#define CD_OPEN_MEDIUM_RETRY_MSLEEP 2000 +#include <linux/delay.h> + /* used to tell the module to turn on full debugging messages */ static bool debug; /* default compatibility mode */ @@ -1040,10 +1052,38 @@ static void cdrom_count_tracks(struct cdrom_device_info *cdi, tracktype *tracks) tracks->cdi, tracks->xa); } +static +int wait_for_medium_decision(struct cdrom_device_info *cdi) +{ + int ret, retry = 0; + const struct cdrom_device_ops *cdo = cdi->ops; + + /* Wait until the intermediate drive status CDS_DRIVE_NOT_READY ends */ + while (1) { + ret = cdo->drive_status(cdi, CDSL_CURRENT); + if (ret == CDS_DRIVE_NOT_READY && + retry++ < CD_OPEN_MEDIUM_RETRY_MAX) + msleep(CD_OPEN_MEDIUM_RETRY_MSLEEP); + else + break; + } + if (ret != CDS_DISC_OK) + return ret; + /* + * It is hard to test whether very recent readiness can cause race + * conditions with media change events. So wait a while to never + * undercut the average delay between actual readiness and detection + * which was tested without this additional msleep(). + */ + msleep(CD_OPEN_MEDIUM_RETRY_MSLEEP / 2); + + return CDS_DISC_OK; +} + static int open_for_data(struct cdrom_device_info *cdi) { - int ret; + int ret, tray_was_moved = 0; const struct cdrom_device_ops *cdo = cdi->ops; tracktype tracks; cd_dbg(CD_OPEN, "entering open_for_data\n"); @@ -1069,13 +1109,17 @@ int open_for_data(struct cdrom_device_info *cdi) ret=-ENOMEDIUM; goto clean_up_and_return; } + tray_was_moved = 1; } else { cd_dbg(CD_OPEN, "bummer. this drive can't close the tray.\n"); ret=-ENOMEDIUM; goto clean_up_and_return; } - /* Ok, the door should be closed now.. Check again */ - ret = cdo->drive_status(cdi, CDSL_CURRENT); + /* + * The door should be closed now, or in the process of + * closing and assessing the medium. + */ + ret = wait_for_medium_decision(cdi); if ((ret == CDS_NO_DISC) || (ret==CDS_TRAY_OPEN)) { cd_dbg(CD_OPEN, "bummer. the tray is still not closed.\n"); cd_dbg(CD_OPEN, "tray might not contain a medium\n"); @@ -1090,6 +1134,14 @@ int open_for_data(struct cdrom_device_info *cdi) ret = -ENOMEDIUM; goto clean_up_and_return; } + if (tray_was_moved) { + /* + * Bail out now to let callers like sr_block_open() + * unlock their mutex and run check_disk_change() + */ + ret = -EDEADLK; + goto clean_up_and_return; + } } cdrom_count_tracks(cdi, &tracks); if (tracks.error == CDS_NO_DISC) { diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c index 0c4aa4665a2f..a26c33c44ab9 100644 --- a/drivers/scsi/sr.c +++ b/drivers/scsi/sr.c @@ -521,7 +521,7 @@ static int sr_block_open(struct block_device *bdev, fmode_t mode) { struct scsi_cd *cd; struct scsi_device *sdev; - int ret = -ENXIO; + int ret = -ENXIO, tried = 0; cd = scsi_cd_get(bdev->bd_disk); if (!cd) @@ -529,11 +529,16 @@ static int sr_block_open(struct block_device *bdev, fmode_t mode) sdev = cd->device; scsi_autopm_get_device(sdev); +retry: + tried++; check_disk_change(bdev); mutex_lock(&cd->lock); ret = cdrom_open(&cd->cdi, bdev, mode); mutex_unlock(&cd->lock); + if (ret == -EDEADLK && tried <= 1) + /* Tray was loaded. Assess medium by check_disk_change(). */ + goto retry; scsi_autopm_put_device(sdev); if (ret) diff --git a/include/linux/cdrom.h b/include/linux/cdrom.h index 8543fa59da72..68d8297e6208 100644 --- a/include/linux/cdrom.h +++ b/include/linux/cdrom.h @@ -100,8 +100,17 @@ int cdrom_read_tocentry(struct cdrom_device_info *cdi, struct cdrom_tocentry *entry); /* the general block_device operations structure: */ + +/* + * Peculiarity: + * cdrom_open() returns -EDEADLK after automatically loading the tray, because + * it expects to be called under various mutexes after the callers called + * check_disk_change() outside of these mutex acquirations. Callers which get + * -EDEADLK should for once re-run check_disk_change() and retry cdrom_open(). + */ extern int cdrom_open(struct cdrom_device_info *cdi, struct block_device *bdev, fmode_t mode); + extern void cdrom_release(struct cdrom_device_info *cdi, fmode_t mode); extern int cdrom_ioctl(struct cdrom_device_info *cdi, struct block_device *bdev, fmode_t mode, unsigned int cmd, unsigned long arg); -------------------------------------------------------------------------- Have a nice day :) Thomas

6 10

How and where are a processes's PTEs set when mmaping a file in a tmpfs?
by Bijan Tabatabai Sept. 1, 2020

Sept. 1, 2020

Hello, I am looking into what happens under the hood when a file on a tmpfs partition gets mmap'd. I am particularly interested in seeing how the PTEs for the new memory region are populated, but I can't seem to find exactly where that happens. I tried looking through the shmem_mmap and shmem_fault functions as well as other places in mm/shmem.c without much luck, though it is possible I just missed it. Can someone point me in the right direction? Thanks, Bijan

1 0

Userspace app crash causes system crash on do_exit probe
by César Augusto Marcelino dos Santos Sept. 1, 2020

Sept. 1, 2020

Dear community, I have created a kernel module that adds probes to do_execve() and do_exit() syscalls (code by the end of this email). It is running on a custom kernel-based system, version 3.18.31. The goal of this module is to see if I can capture several information from any process that is about to start, or that is about to leave userspace. I have tested the following scenarios: - app inits - app finishes its execution gracefully - app is killed - app crashes The first three cases I can retrieve information from the process, but on the last case, I am having an unexpected Kernel Oops. More specifically, I am having trouble on retrieving command-line arguments from a process, and seems to be due to some unusual race condition. To ease things, I have simplified the original source code and focused on the command-line part. It can be noticed that “getCommandLine()” function is not being shown here, and the reason is because is a copy of get_cmdline() method from mm/util.c (https://elixir.bootlin.com/linux/latest/source/mm/util.c#L855) This version of get_cmdline() is using synchronization mechanisms (in my case, I have implemented it with semaphores instead of spinlocks), which causes the Kernel to crash: ... BUG: scheduling while atomic: mysegfaultapp/6037/0x00000002 Modules linked in: ... CPU: 0 PID: 9313 Comm: mysegfaultapp Tainted: P W O 3.18.31 #2 [<c0014024>] (unwind_backtrace) from [<c00119f0>] (show_stack+0x10/0x14) [<c00119f0>] (show_stack) from [<c0039830>] (__schedule_bug+0x44/0x60) [<c0039830>] (__schedule_bug) from [<c0838040>] (__schedule+0x68/0x470) [<c0838040>] (__schedule) from [<c083a864>] (rwsem_down_read_failed+0x104/0x130) [<c083a864>] (rwsem_down_read_failed) from [<bf000918>] (getCommandLine.constprop.0+0x44/0x160 [mymodule]) [<bf000918>] (getCommandLine.constprop.0 [mymodule]) from [<bf000644>] (doExitHandler+0x1dc/0x25c [mymodule]) [<bf000644>] (doExitHandler [mymodule]) from [<c0021850>] (SyS_exit_group+0x0/0x10) [<c0021850>] (SyS_exit_group) from [<00000009>] (0x9) Unable to handle kernel paging request at virtual address fffffffe pgd = dbc20000 [fffffffe] *pgd=9f3f8821, *pte=00000000, *ppte=00000000 Internal error: Oops: 80000007 [#1] PREEMPT ARM ... But if I use an implementation without synchronization mechanisms (which is the one that matches my kernel version - https://elixir.bootlin.com/linux/v3.18.31/source/mm/util.c#L355) once a running app causes segmentation fault and crashes, I am not able to report its command-line, but system remains running (for reference, this app is a dummy app that causes a segfault on purpose, here called “mysegfaultapp”). Due to those situations, I have a few questions that I hope the community can give me some directions on where to look further and understand: 1) Is it possible to retrieve the command-line arguments from a userspace process that crashed? 2) How can I inspect the reason for this crash on rwsem_down_read_failed? 3) If I go for the v.3.18.31 version that doesn’t use synchronization structures (semaphores or spinlocks), what are the risks? Please let me know if you need further information, or if you have any questions. Thanks in advance, Cesar. ------------------------------------------------------------------------------------------------------------------------------------------- static struct kretprobe initProcess; static struct jprobe exitProcess; static void doExitHandler(long code) { char commandLine[200]; memset(commandLine, 0, sizeof(commandLine)); if (getCommandLine(current, commandLine, sizeof(commandLine)) <= 0) { strcpy(commandLine, "ERROR"); } printk(KERN_INFO "doExitHandler %s\n", commandLine); jprobe_return(); } static int doExecHandler(struct kretprobe_instance *pMetadata, struct pt_regs *pRegs) { char commandLine[200]; memset(commandLine, 0, sizeof(commandLine)); if (getCommandLine(current, commandLine, sizeof(commandLine)) <= 0) { strcpy(commandLine, "ERROR"); } printk(KERN_INFO "doExecHandler %s\n", commandLine); return 0; } static int myInit(void) { int retval; initProcess.kp.symbol_name = "do_execve"; initProcess.handler = doExecHandler; retval = register_kretprobe(&initProcess); exitProcess.kp.symbol_name = "do_exit"; exitProcess.entry = JPROBE_ENTRY(doExitHandler); retval = register_jprobe(&exitProcess); return retval; } static void myExit(void) { unregister_kretprobe(&initProcess); unregister_jprobe(&exitProcess); } module_init(myInit); module_exit(myExit);

2 1