July 2021 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

[RFC PATCH 0/8] Add configurable block device LED triggers
by Ian Pilcher July 29, 2021

July 29, 2021

This patch series adds configurable (i.e. user-defined) block device LED triggers. * Triggers can be created, listed, and deleted via sysfs block class attributes (led_trigger_{new,list,del}). * Once created, block device LED triggers are associated with LEDs just like any other LED trigger (via /sys/class/leds/${LED}/trigger). * Each block device gains a new device attribute (led_trigger) that can be used to associate the device with a trigger or clear its association. * My expectation is that most configuration will be done via sysfs (driven by udev), but there also in-kernel APIs for creating, deleting, and (dis)associating triggers. * Multiple devices can be associated with one trigger, so this supports a single LED driven by multiple devices, multiple device-specific LEDs, or arbitrary combinations. Along with support for more than just ATA devices, this is the main difference between this function and the current disk activity trigger. It makes it suitable for use on systems like the Thecus N5550 NAS, which has a software-driven activity LEDs for each disk. * In addition to physical block devices, many types of virtual block devices can drive LEDs; device mapper, MD RAID, and loop devices work (but zram swap devices do not). * The led trigger is "blinked" (75 msec on, 25 msec off) when a request is successfully sent to the low-level driver. The intent is to provide a visual indication of device activity, not any sort of exact measurement. * Related to the previous bullet, if the blink function is unable to immediately acquire a lock on the device's LED trigger information it simply returns, so that I/O processing can continue. It's probably obvious that I'm basically a complete newbie at kernel development, so I welcome feedback. Thanks! Ian Pilcher (8): docs: Add block device LED trigger documentation block: Add block device LED trigger list block: Add kernel APIs to create & delete block device LED triggers block: Add block class attributes to manage LED trigger list block: Add block device LED trigger info to struct genhd block: Add kernel APIs to set & clear per-block device LED triggers block: Add block device attributes to set & clear LED triggers block: Blink device LED when request is sent to low-level driver Documentation/block/index.rst | 1 + Documentation/block/led-triggers.rst | 124 ++++++ block/Kconfig | 10 + block/Makefile | 1 + block/blk-ledtrig.c | 570 +++++++++++++++++++++++++++ block/blk-ledtrig.h | 51 +++ block/blk-mq.c | 2 + block/genhd.c | 14 + include/linux/blk-ledtrig.h | 24 ++ include/linux/genhd.h | 4 + 10 files changed, 801 insertions(+) create mode 100644 Documentation/block/led-triggers.rst create mode 100644 block/blk-ledtrig.c create mode 100644 block/blk-ledtrig.h create mode 100644 include/linux/blk-ledtrig.h -- 2.31.1

6 23

MTD: How to get actual image size from MTD partition
by Pintu Agarwal July 29, 2021

July 29, 2021

Hi, Our ARM32 Linux embedded system consists of these: * Linux Kernel: 4.14 * Processor: Qualcomm Arm32 Cortex-A7 * Storage: NAND 512MB * Platform: Simple busybox * Filesystem: UBIFS, Squashfs * Consists of nand raw partitions, squashfs ubi volumes. My requirement: To find the checksum of a real image in runtime which is flashed in an MTD partition. Problem: Currently, to find the checksum, we are using: $ md5sum /dev/mtd14 This returns the proper checksum of the entire partition. But we wanted to find the checksum only for the actual image data which will be used by our C utility to validate the image. Here, we don't know the actual image size. We only know the "partition-size" and "erasesize". So, is there a mechanism to somehow find the image size at runtime? Regards, Pintu

5 12

PCM prepare callback
by Muni Sekhar July 28, 2021

July 28, 2021

Hi all, Is there any document which explains the sequence of snd_pcm_ops callbacks called during playback and capture? What driver is supposed to return from the PCM prepare callback if the sound card is not ready for playback\capture? -- Thanks, Sekhar

1 0

Return value for "impossible" situations
by Ian Pilcher July 26, 2021

July 26, 2021

In user space, I use assertions to check (and document) the assumptions built in to my code - this value won't ever be negative, this int will only ever by one of these 3 values, etc. For kernel code, I can use pr_err, dump_stack, WARN_ON, etc. to report the issue in the log, but I often also need to return some sort of error code (negative errno value). Is there any sort of convention around what to return in the case of an error in the logic of the code itself, something that will make it as obvious as possible that the problem is a bug. TIA! -- ======================================================================== In Soviet Russia, Google searches you! ========================================================================

3 6

How can I convert user virtual address to kernel virtual address and then to physical address?
by ckim＠etri.re.kr July 26, 2021

July 26, 2021

Hi, all, I'm testing a simple character driver on qemu arm64 virtual machine. I have uint64_t args[32] array and I pass args to the ioctl data. By the way args[2] contains the address of test_val which is set to 77. I want to change this value to 78 in the driver using kernel virtual address. (ultimately I want to get the physical address of test_val and pass it to the qemu hardware model). I read I can change user virtual address to kernel land virtual address using get_user_pages function and then I can use virt_to_phys function to get the physical address from kernel land virtual address. (please correct me if I'm wrong) When I try to write 78 at the kernel virtual address for test_val, trap occurs. ## app.c ## uint64_t __attribute__(( aligned(64) )) args[32]; uint64_t test_val = 77; args[2] = (uint64_t) &test_val; // let's see it's changed to 78 printf("app : args[2] = %p, *args[2] = %lld\n", args[2], *(uint64_t *)args[2]); ioctl(fd, CallSetBareMetalMode, (uint64_t)args); ### driver.c ### static long my_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { switch(cmd) { case CallSetBareMetalMode: printk("driver:cmd = %x, arg = %lx\n", cmd, arg); copy_from_user(&args, (void __user *)arg, 8*3); printk("args[2] = %llx\n", args[2]); offs = args[2] % 4096; down_read(&current->mm->mmap_sem); res = get_user_pages( (unsigned long)args[2], 1, 1, &pages, NULL); printk("get_user_pages done! args[2] = %px\n", args[2]); if (res) { printk(KERN_INFO "Got mmaped.\n"); kvpaddr = kmap(pages); printk("kmap done!\n"); printk(KERN_INFO "kvpaddr = %px, ofs = %x\n", kvpaddr, offs); printk("xx = %llx\n", ((unsigned long long int)(kvpaddr)+offs)); *(uint64_t *)((unsigned long long int)(kvpaddr)+offs) = 78; printk(KERN_INFO "changed value : %lld\n",\ *(uint64_t *)((unsigned int)(kvpaddr)+offs)); put_page(pages); //page_cache_release(page); printk("put_page done!\n"); } else { printk("get_user_pages failed!\n"); } up_read(&current->mm->mmap_sem); ### run output ### args = 0x442f40 app : args[0] = 0x443040 app : args[2] = 0xffffd2e44d98, *args[2] = 77 [85194.544029] driver:cmd = 40086142, arg = 442f40 [85194.544822] args[2] = ffffd2e44d98 [85194.545613] get_user_pages done! args[2] = 0000ffffd2e44d98 [85194.546004] Got mmaped. [85194.546248] kmap done! [85194.546536] kvpaddr = ffff00001f7c0000, ofs = d98 [85194.546976] kvaddr = ffff00001f7c0d98 [85194.548645] Unable to handle kernel paging request at virtual address 000000001f7c0d98 [85194.549245] Mem abort info: [85194.549513] ESR = 0x96000006 [85194.549929] EC = 0x25: DABT (current EL), IL = 32 bits [85194.550364] SET = 0, FnV = 0 [85194.550719] EA = 0, S1PTW = 0 [85194.551008] Data abort info: [85194.551555] ISV = 0, ISS = 0x00000006 [85194.551938] CM = 0, WnR = 0 [85194.552609] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000568fb000 [85194.553441] [000000001f7c0d98] pgd=0000000056209003, pud=0000000047b97003, pmd=0000000000000000 [85194.555783] Internal error: Oops: 96000006 [#16] SMP [85194.556761] Modules linked in: chr_drv_ex1(OE) nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua qemu_fw_cfg sch_fq_codel ppdev lp parport drm ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq libcrc32c raid1 raid0 multipath linear crct10dif_ce ghash_ce sm4_ce sm4_generic sm3_ce sm3_generic sha3_ce sha3_generic sha512_ce sha512_arm64 sha2_ce sha256_arm64 sha1_ce virtio_net net_failover virtio_blk failover aes_neon_bs aes_neon_blk aes_ce_blk crypto_simd cryptd aes_ce_cipher [last unloaded: chr_drv_ex1] [85194.563741] CPU: 2 PID: 4258 Comm: test_axpu_app Tainted: G D W OE 5.4.0-77-generic #86-Ubuntu [85194.564638] Hardware name: QEMU QEMU Ab21q Virtual Machine, BIOS 0.0.0 02/06/2015 [85194.565687] pstate: 60400005 (nZCv daif +PAN -UAO) [85194.568143] pc : my_ioctl+0x310/0x370 [chr_drv_ex1] [85194.568854] lr : my_ioctl+0x300/0x370 [chr_drv_ex1] [85194.569473] sp : ffff80001372bd30 [85194.569838] x29: ffff80001372bd30 x28: ffff000009f7bc00 [85194.570354] x27: 0000000000000000 x26: 0000000000000000 [85194.570796] x25: 0000000056000000 x24: ffff00000d3c35e0 [85194.571308] x23: ffff000016875600 x22: 0000000000000d98 [85194.571870] x21: 000000001f7c0d98 x20: 0000000000442f40 [85194.572273] x19: ffff00001f7c0000 x18: 0000000000000010 [85194.572669] x17: 0000000000000000 x16: 0000000000000000 [85194.573126] x15: ffff000009f7c128 x14: ffffffffffffffff [85194.573632] x13: ffff80009372ba77 x12: ffff80001372ba7f [85194.574127] x11: ffff800011b9e000 x10: 0000000000000000 [85194.574578] x9 : ffff800011db4000 x8 : 00000000000005f2 [85194.575193] x7 : 0000000000000017 x6 : ffff800011db39d4 [85194.575700] x5 : 0000000000000000 x4 : ffff00001feb5250 [85194.576139] x3 : ffff00001fec56c8 x2 : 0000000000000000 [85194.576550] x1 : 0000000000000000 x0 : ffff80000924b220 [85194.577379] Call trace: [85194.577805] my_ioctl+0x310/0x370 [chr_drv_ex1] [85194.579423] do_vfs_ioctl+0xc64/0xe60 [85194.579846] ksys_ioctl+0x88/0xb8 [85194.580116] __arm64_sys_ioctl+0x2c/0x228 [85194.580479] el0_svc_common.constprop.0+0xe4/0x1f0 [85194.580929] el0_svc_handler+0x38/0xa8 [85194.581293] el0_svc+0x10/0x2c8 [85194.582065] Code: d28009c0 f8336ac0 b0000000 91088000 (f94002a1) [85194.583646] ---[ end trace bd1ac75ca265aec2 ]--- [85194.590696] Device File closed.. Segmentation fault (core dumped) I thought I changed the user virtual address to kernel virtual address, but writing to the kernel virtual address causes trap. Can anyone help me with finding what is wrong here? Thank you for reading. Chan Kim

2 1

seeking guidance on adding MOD_PARAM_BITMAP
by jim.cromie＠gmail.com July 23, 2021

July 23, 2021

hi folks, I would like to add something like the following: MOD_PARM_DYNDBG_BITMAP_DESC(__gvt_debug, "dyndbg bitmap desc", { "gvt: cmd: ", "command processing" }, { "gvt: core: ", "core help" }, { "gvt: dpy: ", "display help" }, { "gvt: el: ", "help" }, { "gvt: irq: ", "help" }, { "gvt: mm: ", "help" }, { "gvt: mmio: ", "help" }, { "gvt: render: ", "help" }, { "gvt: sched: " "help" }); the point is to declaratively define an interface, a lot like: /sys/module/drm/parameters/debug and $> modinfo drm ... parm: debug:Enable debug output, where each bit enables a debug category. Bit 0 (0x01) will enable CORE messages (drm core code) Bit 1 (0x02) will enable DRIVER messages (drm controller code) Bit 2 (0x04) will enable KMS messages (modesetting code) Bit 3 (0x08) will enable PRIME messages (prime code) Bit 4 (0x10) will enable ATOMIC messages (atomic code) Bit 5 (0x20) will enable VBL messages (vblank code) Bit 7 (0x80) will enable LEASE messages (leasing code) Bit 8 (0x100) will enable DP messages (displayport code) (int) is there anything close to this in the kernel that I can copy & modify ? failing that, what set of macros (names & files they should be implemented in ) would stand some chance of surviving review ?

1 0

RE: a question about dma_set_mask function
by ckim＠etri.re.kr July 22, 2021

July 22, 2021

Further reading down the document, I realized the returned DMA address (=bus address) is used for setting the dma descriptors or the device register so that the address value is used for actual DMA. But I'm still confused for cases of using iommu. When the iommu exists for the device, does the dma_alloc function allocates virtual address range (which can be physically dis-contiguous) instead of the (physically contiguous) bus address? I mean, will the handle value below be pointing to virtual address for {this process and the device} pair? (virtual to bus address translation being done by iommu). dma_alloc_coherent(struct device *dev, size_t size, dma_addr_t *handle, gfp_t gfp) Any help will be really appreciated. Thanks! Chan Kim From: ckim(a)etri.re.kr <ckim(a)etri.re.kr> Sent: Thursday, July 22, 2021 4:33 PM To: kernelnewbies(a)kernelnewbies.org Subject: a question about dma_set_mask function Hello, I have a question about DNA (I was reading DMA-API-HOWTO.txt <https://www.kernel.org/doc/Documentation/DMA-API-HOWTO.txt> ). You know regarding DMA, there is cpu virtual address, cpu physical address and bus address for the device. Bus address is converted to cpu physical address using bridge or bus controller to which the device is attached. And for platform device, bus address is equal to the cpu physical address. The DMA-API-HOWTO.txt <https://www.kernel.org/doc/Documentation/DMA-API-HOWTO.txt> says > When dma_set_mask() or dma_set_mask_and_coherent() is successful, and > returns zero, the kernel saves away this mask you have provided. The > kernel will use this information later when you make DMA mappings. So I guess when the driver later requests memory for dma using dma_map_..(ex. dma_map_single, or dma_map_sg) function, the kernel allocates memory and sets up page table and it sets the bus address in the ranges supported by the dma_mask. The virtual address is returned by the function, but where is this 'bus address' kept? I see a pointer to the struct page in the function argument, Is it kept in this struct array? Or is the bus address just the physical address(pfn) in the page table?(I guess so) And when the device has a separate iommu(like arm64's SMMU), I guess the DMA virtual address (assigned for dma by the kernel) for the device is first converted to the bus address by iommu and then the bus address is converted to physical address by bus bridge. Is my understanding correct? It's so confusing.. Any explanation or comment will be deeply appreciated. Thanks! Chan Kim

1 0

a question about dma_set_mask function
by ckim＠etri.re.kr July 22, 2021

July 22, 2021

Hello, I have a question about DNA (I was reading DMA-API-HOWTO.txt <https://www.kernel.org/doc/Documentation/DMA-API-HOWTO.txt> ). You know regarding DMA, there is cpu virtual address, cpu physical address and bus address for the device. Bus address is converted to cpu physical address using bridge or bus controller to which the device is attached. And for platform device, bus address is equal to the cpu physical address. The DMA-API-HOWTO.txt <https://www.kernel.org/doc/Documentation/DMA-API-HOWTO.txt> says > When dma_set_mask() or dma_set_mask_and_coherent() is successful, and > returns zero, the kernel saves away this mask you have provided. The > kernel will use this information later when you make DMA mappings. So I guess when the driver later requests memory for dma using dma_map_..(ex. dma_map_single, or dma_map_sg) function, the kernel allocates memory and sets up page table and it sets the bus address in the ranges supported by the dma_mask. The virtual address is returned by the function, but where is this 'bus address' kept? I see a pointer to the struct page in the function argument, Is it kept in this struct array? Or is the bus address just the physical address(pfn) in the page table?(I guess so) And when the device has a separate iommu(like arm64's SMMU), I guess the DMA virtual address (assigned for dma by the kernel) for the device is first converted to the bus address by iommu and then the bus address is converted to physical address by bus bridge. Is my understanding correct? It's so confusing.. Any explanation or comment will be deeply appreciated. Thanks! Chan Kim

1 0

Re: Interested in kernel development
by Amit Kumar July 22, 2021

July 22, 2021

Hi Athul, I think people find learning kernel development difficult due to the following reasons, I) Lack of understanding about the underlying hardware. II) In the Linux kernel, some features are used which is specific to the GCC toolchain. III) There is also a good amount of assembly is being used which in turn also needs the underlying hardware knowledge. III) Last but not less important, An operating system does all its tasks by itself. It runs in a freestanding environment. So we need the patience to learn every aspect of an operating system. My next article which completes the minimal C program is coming soon. Please, stay tuned. Regards, Amit Kumar https://twitter.com/freeark1 On Wed, Jul 21, 2021 at 10:27 PM Athul Joy <a.athuljoy(a)gmail.com> wrote: > > Hi Amit, > I am Athul Joy. I am a software developer. I have seen your mail on the Kernelnewbies mailing list. I have similar interests as you about learning more about the Linux kernel. I have tried to put some effort to learn more about the Linux kernel but didn't go well. I would like to follow along with you. I hope you could help me. > Sincerely, > Athul Joy

2 1

Re: Kernel 4.14: Using dm-verity with squashfs rootfs - mounting issue
by Pintu Agarwal July 21, 2021

July 21, 2021

On Tue, 20 Jul 2021 at 17:12, Mikulas Patocka <mpatocka(a)redhat.com> wrote: > > Hi > > Try to set up dm-verity with block size 512 bytes. > > I don't know what block size does squashfs use, but if the filesystem > block size is smaller than dm-verity block size, it doesn't work. > Okay thank you so much for this clue, It seems we are using 65536 as the squashfs block size: ==> mksquashfs [...] - comp xz -Xdict-size 32K -noI -Xbcj arm -b 65536 -processors 1 But for dm-verity we are giving block size of 4096 ==> [ 0.000000] Kernel command line:[..] verity="96160 12020 d7b8a7d0c01b9aec888930841313a81603a50a2a7be44631c4c813197a50d681 0 " rootfstype=squashfs root=/dev/mtdblock34 ubi.mtd=30,0,30 [...] root=/dev/dm-0 dm="system none ro,0 96160 verity 1 /dev/mtdblock34 /dev/mtdblock39 4096 4096 12020 8 sha256 d7b8a7d0c01b9aec888930841313a81603a50a2a7be44631c4c813197a50d681 aee087a5be3b982978c923f566a94613496b417f2af592639bc80d141e34dfe7" Now, we are checking by giving squashfs block size also as 4096 In case, if this does not work, what else could be the other option ? Can we try with initramfs approach ? Thanks, Pintu

2 1