- kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

git send-email and gmail smtp
by jim.cromie＠gmail.com April 17, 2024

April 17, 2024

so I tried to submit a patchset via sendemail, and ran aground on authorization. its been a while since I sent from this computer, laptop power cord is cut :-( but failure wording is ambiguous 5.7.8 Username and Password not accepted. For more information, go to 5.7.8 https://support.google.com/mail/?p=BadCredentials j15-20020a0566022ccf00b007d6905cc017sm3758492iow.4 - gsmtp Essentially, google is changing policy, and 2FA is coming (or just arrived) is there a well-travelled path to work around this issue? something like ssh-key-agent ?

4 3

uboot and kernel entry point, load address for booting kernel from FIT image
by Lev Olshvang April 12, 2024

April 12, 2024

2 1

Seeking help addressing maintainer objections
by Ian Pilcher April 3, 2024

April 3, 2024

I have been maintaining an out of tree module for several years, and I'd like to take (yet another) run at getting it accepted. In order to do so, however, I need some advice/help to meet the requirements of the relevant subsystem maintainer. The module in question is an LED trigger for block devices. It allows the system administrator to create relationships between LEDS and block devices, so that activity (reads, writes, etc.) on those devices will cause the LEDs to blink. You can see the latest version (for 6.8 kernels) here[1]. The trigger is very configurable. It supports many-to-many relationships between block devices and LEDS, so a block device can be associated with more than one LED (potentially for different types of activity) and an LED can be associated with one or more block devices. These many-to-many relationships are part of the problem. LED triggers are traditionally configured with sysfs, and sysfs attributes don't really work all that well for configuring a list of things (such as the block devices associated with an LED). In order to avoid a read/modify/write cycle when adding or removing a device/LED association, and adhere to the one value per file guideline, the trigger provides write-only attributes for adding and removing associations. (Existing associations are represented as symbolic links.) The sysfs interface is documented here[2]. The maintainer of the LEDs subsystem considers this interface to be "crazy", but he has not suggested any alternative.[3] (I have not been able to find any existing example of configuring many-to-many relationships via sysfs.) The second problem is the use of device file paths (including symbolic link resolution), rather than kernel names, when creating associations. This limitation exists because the block subsystem does not provide an API to open a block device by its kernel name; only device file paths and device numbers (major & minor) are supported. Adding such an API to the block subsystem has been proposed many times over the years, and it has been denied (often vehemently) on every occasion. I believe it's accurate to say that the maintainers of the block subsystem feel that device file paths (and to a lesser extent device numbers) are *the* correct way to refer to block devices, and they are not willing to add APIs that use kernel names. Does anyone have any suggestions on how I can move forward with this? Thanks! [1] https://github.com/ipilcher/ledtrig-blkdev/blob/pre-6.9/drivers/leds/trigge… [2] https://github.com/ipilcher/ledtrig-blkdev/blob/pre-6.9/Documentation/leds/… [3] https://lore.kernel.org/lkml/a7ff3338-3d5e-4402-aaba-16e740f4ed5b@gmail.com… -- ======================================================================== If your user interface is intuitive in retrospect ... it isn't intuitive ========================================================================

2 3

Compile error on Rasperry PI arm64 in arch/arm64/kvm/hyp/nvhe/gen-hyprel
by Philipp Hortmann April 1, 2024

April 1, 2024

Hi, I tried to compile the mainline kernel on a Rasperry PI 32-Bit OS. Here the commands for preparation: make ARCH=arm64 KERNEL=kernel8 CROSS_COMPILE=aarch64-linux-gnu- defconfig make ARCH=arm64 KERNEL=kernel8 CROSS_COMPILE=aarch64-linux-gnu- -j4 Image.gz modules dtbs kernel@raspberrypi:~/Documents/git/staging $ git status On branch staging-testing Your branch is up to date with 'origin/staging-testing'. nothing to commit, working tree clean kernel@raspberrypi:~/Documents/git/staging $ I think that the compillation should work no matther if it is 32Bit or 64Bit. See below: AS arch/arm64/kvm/hyp/nvhe/../../../lib/memcpy.nvhe.o AS arch/arm64/kvm/hyp/nvhe/../../../lib/memset.nvhe.o CC kernel/time/timer_list.o HOSTCC arch/arm64/kvm/hyp/nvhe/gen-hyprel arch/arm64/kvm/hyp/nvhe/gen-hyprel.c: In function ‘section_by_off’: arch/arm64/kvm/hyp/nvhe/gen-hyprel.c:163:33: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘Elf64_Off’ {aka ‘long long unsigned int’} [-Wformat=] 163 | fprintf(stderr, "error: %s: " fmt "\n", \ | ^~~~~~~~~~~~~ arch/arm64/kvm/hyp/nvhe/gen-hyprel.c:183:25: note: in expansion of macro ‘fatal_error’ 183 | fatal_error("assertion " #lhs " " #op " " #rhs \ | ^~~~~~~~~~~ arch/arm64/kvm/hyp/nvhe/gen-hyprel.c:190:41: note: in expansion of macro ‘assert_op’ 190 | #define assert_ne(lhs, rhs, fmt) assert_op(lhs, rhs, fmt, !=) | ^~~~~~~~~ arch/arm64/kvm/hyp/nvhe/gen-hyprel.c:230:9: note: in expansion of macro ‘assert_ne’ 230 | assert_ne(off, 0UL, "%lu"); | ^~~~~~~~~ arch/arm64/kvm/hyp/nvhe/gen-hyprel.c: In function ‘init_elf’: arch/arm64/kvm/hyp/nvhe/gen-hyprel.c:163:33: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘__off64_t’ {aka ‘long long int’} [-Wformat=] 163 | fprintf(stderr, "error: %s: " fmt "\n", \ | ^~~~~~~~~~~~~ arch/arm64/kvm/hyp/nvhe/gen-hyprel.c:183:25: note: in expansion of macro ‘fatal_error’ 183 | fatal_error("assertion " #lhs " " #op " " #rhs \ | ^~~~~~~~~~~ arch/arm64/kvm/hyp/nvhe/gen-hyprel.c:192:41: note: in expansion of macro ‘assert_op’ 192 | #define assert_ge(lhs, rhs, fmt) assert_op(lhs, rhs, fmt, >=) | ^~~~~~~~~ arch/arm64/kvm/hyp/nvhe/gen-hyprel.c:276:9: note: in expansion of macro ‘assert_ge’ 276 | assert_ge(stat.st_size, sizeof(*elf.ehdr), "%lu"); | ^~~~~~~~~ arch/arm64/kvm/hyp/nvhe/gen-hyprel.c:163:33: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘unsigned int’ [-Wformat=] 163 | fprintf(stderr, "error: %s: " fmt "\n", \ | ^~~~~~~~~~~~~ arch/arm64/kvm/hyp/nvhe/gen-hyprel.c:183:25: note: in expansion of macro ‘fatal_error’ 183 | fatal_error("assertion " #lhs " " #op " " #rhs \ | ^~~~~~~~~~~ arch/arm64/kvm/hyp/nvhe/gen-hyprel.c:192:41: note: in expansion of macro ‘assert_op’ 192 | #define assert_ge(lhs, rhs, fmt) assert_op(lhs, rhs, fmt, >=) | ^~~~~~~~~ arch/arm64/kvm/hyp/nvhe/gen-hyprel.c:276:9: note: in expansion of macro ‘assert_ge’ 276 | assert_ge(stat.st_size, sizeof(*elf.ehdr), "%lu"); | ^~~~~~~~~ arch/arm64/kvm/hyp/nvhe/gen-hyprel.c: In function ‘emit_rela_abs64’: arch/arm64/kvm/hyp/nvhe/gen-hyprel.c:340:26: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘size_t’ {aka ‘unsigned int’} [-Wformat=] 340 | printf(".reloc %lu, R_AARCH64_PREL32, %s%s + 0x%lx\n", | ~~^ | | | long unsigned int | %u 341 | reloc_offset, HYP_SECTION_SYMBOL_PREFIX, sh_orig_name, | ~~~~~~~~~~~~ | | | size_t {aka unsigned int} arch/arm64/kvm/hyp/nvhe/gen-hyprel.c:340:58: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘__uint64_t’ {aka ‘long long unsigned int’} [-Wformat=] 340 | printf(".reloc %lu, R_AARCH64_PREL32, %s%s + 0x%lx\n", | ~~^ | | | long unsigned int | %llx arch/arm64/kvm/hyp/nvhe/gen-hyprel.c: In function ‘emit_rela_section’: arch/arm64/kvm/hyp/nvhe/gen-hyprel.c:163:33: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘__uint64_t’ {aka ‘long long unsigned int’} [-Wformat=] 163 | fprintf(stderr, "error: %s: " fmt "\n", \ | ^~~~~~~~~~~~~ arch/arm64/kvm/hyp/nvhe/gen-hyprel.c:183:25: note: in expansion of macro ‘fatal_error’ 183 | fatal_error("assertion " #lhs " " #op " " #rhs \ | ^~~~~~~~~~~ arch/arm64/kvm/hyp/nvhe/gen-hyprel.c:191:41: note: in expansion of macro ‘assert_op’ 191 | #define assert_lt(lhs, rhs, fmt) assert_op(lhs, rhs, fmt, <) | ^~~~~~~~~ arch/arm64/kvm/hyp/nvhe/gen-hyprel.c:376:17: note: in expansion of macro ‘assert_lt’ 376 | assert_lt(elf64toh(rela->r_offset), elf64toh(sh_orig->sh_size), "0x%lx"); | ^~~~~~~~~ arch/arm64/kvm/hyp/nvhe/gen-hyprel.c:163:33: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘__uint64_t’ {aka ‘long long unsigned int’} [-Wformat=] 163 | fprintf(stderr, "error: %s: " fmt "\n", \ | ^~~~~~~~~~~~~ arch/arm64/kvm/hyp/nvhe/gen-hyprel.c:183:25: note: in expansion of macro ‘fatal_error’ 183 | fatal_error("assertion " #lhs " " #op " " #rhs \ | ^~~~~~~~~~~ arch/arm64/kvm/hyp/nvhe/gen-hyprel.c:191:41: note: in expansion of macro ‘assert_op’ 191 | #define assert_lt(lhs, rhs, fmt) assert_op(lhs, rhs, fmt, <) | ^~~~~~~~~ arch/arm64/kvm/hyp/nvhe/gen-hyprel.c:376:17: note: in expansion of macro ‘assert_lt’ 376 | assert_lt(elf64toh(rela->r_offset), elf64toh(sh_orig->sh_size), "0x%lx"); | ^~~~~~~~~ LD arch/arm64/kvm/hyp/nvhe/kvm_nvhe.tmp.o HYPREL arch/arm64/kvm/hyp/nvhe/hyp-reloc.S AS arch/arm64/kvm/hyp/nvhe/hyp-reloc.o LD arch/arm64/kvm/hyp/nvhe/kvm_nvhe.rel.o HYPCOPY arch/arm64/kvm/hyp/nvhe/kvm_nvhe.o Bye Philipp

1 0

Netlink protocol
by Abdulrasaq Lawani April 1, 2024

April 1, 2024

Please how can find detailed resource on netlink protocol and ynl?

1 0

Coding style when using atomic_dec_and_test
by Camila Alvarez Inostroza March 31, 2024

March 31, 2024

I understand that atomic_dec_and_test returns 1 when the result of the operation is 0, and 0 otherwise. I've seen two ways of handling the resulting operation, below are a couple of examples: (1) if (!atomic_dec_and_test(&rd->refcount)) return; call_rcu(&rd->rcu, free_rootdomain); (2) if (atomic64_dec_and_test(&map->refcnt)) { /* bpf_map_free_id() must be called first */ ... } Is it prefered to use one option over the other? Or is it just personal preference? Thanks in advance! Camila Alvarez

2 1

Controlling the same I2C device from user and kernel space
by Patryk March 26, 2024

March 26, 2024

Hi, I've got a question. I have an I2C device (FPGA) connected to my board. This device implements a hardware watchdog and GPIO expander. My question is - can I control this device from userspace (watchdog part) using spidev driver and still be able to develop a kernel driver that controls GPIO expander part without any additional locking mechanisms? Best regards Patryk

1 1

Fwd: Mail delivery failed: returning message to sender
by daniel watson March 24, 2024

March 24, 2024

my reply to the confirmation email for subscribing to this mailing list failed. my account was confirmed by visiting the url instead. it seems like the "just reply to this email" option is broken. hope this helps! Mail Delivery System <Mailer-Daemon(a)shelob.surriel.com> writes: > This message was created automatically by mail delivery software. > > A message that you sent could not be delivered to one or more of its > recipients. This is a permanent error. The following address(es) failed: > > kernelnewbies-confirm%2Bdad8ab63e98c6c9aaa9b98b31156bcabb0d3127f(a)kernelnewbies.org > > Reporting-MTA: dns; shelob.surriel.com > > Action: failed > Final-Recipient: rfc822;kernelnewbies-confirm+dad8ab63e98c6c9aaa9b98b31156bcabb0d3127f@kernelnewbies.org > Status: 5.0.0 > > From: daniel watson <ozzloy(a)each.do> > Subject: Re: Your confirmation is required to join the Kernelnewbies mailing > list > To: kernelnewbies-confirm%2Bdad8ab63e98c6c9aaa9b98b31156bcabb0d3127f(a)kernelnewbies.org > Date: Sun, 24 Mar 2024 07:11:56 -0700 (38 minutes, 20 seconds ago) > Flags: seen, personal > Maildir: / > > > confirm dad8ab63e98c6c9aaa9b98b31156bcabb0d3127f > > kernelnewbies-confirm%2Bdad8ab63e98c6c9aaa9b98b31156bcabb0d3127f(a)kernelnewbies.org writes: > >> Mailing list subscription confirmation notice for mailing list >> Kernelnewbies >> >> We have received a request from 67.160.243.62 for subscription of your >> email address, "ozzloy(a)each.do", to the >> kernelnewbies(a)kernelnewbies.org mailing list. To confirm that you >> want to be added to this mailing list, simply reply to this message, >> keeping the Subject: header intact. Or visit this web page: >> >> https://lists.kernelnewbies.org/mailman/confirm/kernelnewbies/dad8ab63e98c6… >> >> >> Or include the following line -- and only the following line -- in a >> message to kernelnewbies-request(a)kernelnewbies.org: >> >> confirm dad8ab63e98c6c9aaa9b98b31156bcabb0d3127f >> >> Note that simply sending a `reply' to this message should work from >> most mail readers, since that usually leaves the Subject: line in the >> right form (additional "Re:" text in the Subject: is okay). >> >> If you do not wish to be subscribed to this list, please simply >> disregard this message. If you think you are being maliciously >> subscribed to the list, or have any other questions, send them to >> kernelnewbies-owner(a)kernelnewbies.org. > > ----------

1 0

EFAULT for sending UDP from LKM
by Jaydeep Das March 23, 2024

March 23, 2024

Hey everyone, I am trying to develop a linux kernel module. One of the task that it has is to send a UDP packet to the broadcast address of a network interface. I have attached the dmesg logs below. For some reason it is able to bind to the address but it is not able to send the packet. It shows EFAULT. Please advise. Thank you in advance. 16 static struct socket *sd_listener_sock = NULL; 17 static struct sockaddr_in sd_listener_sin; 18 static struct socket *sd_brdcst_sock = NULL; 19 static struct sockaddr_in sd_brdcst_sin; ... 106 static int __init onekfs_sd_brdcst_init(void) 107 { 108 int sd_err = 0; 109 int enable_brodcast = 1; 110 sockptr_t enable_brdcst; 111 112 /* Get socket */ 113 114 sd_err = sock_create_kern(&init_net, AF_INET, SOCK_DGRAM, 0, &sd_brdcst_sock); 115 if (sd_err < 0) { 116 printk(KERN_ERR "onekfs: Failed to create broadcast socket: %d\n", sd_err); 117 goto errout; 118 } 119 120 /* Enable broadcast */ 121 enable_brdcst.is_kernel = 1; 122 enable_brdcst.kernel = &enable_brodcast; 123 sd_err = sock_setsockopt(sd_brdcst_sock, SOL_SOCKET, 124 SO_BROADCAST, enable_brdcst, 125 sizeof(enable_brdcst)); 126 if (sd_err < 0) { 127 printk(KERN_ERR "onekfs: Could not set up broadcast: %d\n", sd_err); 128 goto errout_with_socket; 129 } 130 131 /* Bind to port */ 132 memset(&sd_brdcst_sin, 0, sizeof(struct sockaddr_in)); 133 134 sd_brdcst_sin.sin_family = AF_INET; 135 sd_brdcst_sin.sin_port = htons(ONEKFS_PORT + 1); 136 sd_brdcst_sin.sin_addr.s_addr = htonl(onekfs_brdcst_addr); 137 // sd_brdcst_sin.sin_addr.s_addr = onekfs_brdcst_addr; 138 139 sd_err = sd_brdcst_sock->ops->bind(sd_brdcst_sock, 140 (struct sockaddr *)&sd_brdcst_sin, 141 sizeof(struct sockaddr_in)); 142 if (sd_err < 0) { 143 printk(KERN_ERR "onekfs: Failed to bind broadcast socket: %d\n", sd_err); 144 goto errout_with_socket; 145 } 146 147 /* We're live */ 148 printk(KERN_INFO "onekfs: Broadcast of UDP packets at port %d\n", 149 ONEKFS_PORT + 1); 150 151 return 0; 152 153 154 errout_with_socket: 155 sock_release(sd_listener_sock); 156 157 errout: 158 return sd_err; 159 } ... 183 int broadcast_msg(char *data, ssize_t data_len) 184 { 185 /* Generate Msg */ 186 struct msghdr* msg = kzalloc(sizeof (struct msghdr), GFP_KERNEL); 187 struct iovec* iov = kzalloc(sizeof (struct iovec), GFP_KERNEL); 188 int ret; 189 190 // memset(&msg, 0, sizeof(struct msghdr)); 191 // memset(&iov, 0, sizeof(struct kvec)); 192 193 char *pk_data = kzalloc(PROJECT_NAME_LEN + data_len, GFP_KERNEL); 194 if (!pk_data) { 195 printk(KERN_WARNING "onekfs:" 196 " Could not get memory for payload\n"); 197 return 1; 198 } 199 200 sprintf(pk_data, "onekfs%s", data); 201 202 iov->iov_base = pk_data; 203 iov->iov_len = PROJECT_NAME_LEN + data_len; 204 msg->msg_name = (void *)&sd_brdcst_sin; 205 msg->msg_namelen = sizeof(sd_brdcst_sin); 206 msg->msg_inq = PROJECT_NAME_LEN + data_len; 207 iov_iter_init(&msg->msg_iter, WRITE, iov, 1, iov->iov_len); 208 /* Broadcast */ 209 210 printk(KERN_INFO "onekfs: Broadcast Socket type: %d\n", sd_brdcst_sock->type); 211 __be32 temp = (sd_brdcst_sin.sin_addr.s_addr); ... 215 ret = sock_sendmsg(sd_brdcst_sock, msg); 217 */* TODO: -14 (Bad Address error) */* 218 if (ret < 0){ 219 printk(KERN_INFO "onekfs: UDP Packet Send failed: %d\n", ret); 220 sock_release(sd_brdcst_sock); 221 sock_release(sd_listener_sock); 222 kfree(msg); 223 kfree(iov); 224 } 225 226 kfree(pk_data); 227 228 return ret < 0; 229 } *Logs*: *[ 4952.707575] onekfs: Interface: enp0s3, Broadcast Address: x.x.x.x[ 4952.707626] onekfs: Broadcast of UDP packets at port 39530[ 4952.707639] onekfs: Broadcast Addr: x.x.x.x[ 4952.707665] onekfs: UDP Packet Send failed: -14[ 4952.707678] onekfs: Loaded*

1 0

Translation fault while using mmu-600 (only when dma alloc is done during application on the fly)
by 김찬 March 22, 2024

March 22, 2024

Hello all, These several days we are having a difficulty in our linux device driver development.  case A ) Here we allocate the dma buffer for our accelerator device during the device driver(a platform driver) initialization and we don't have problem. That is, we use kmalloc + dma_map_single during the driver initialization and after the boot is complete, we run the application which uses the driver. During the application, the driver just calls dma_sync_single_for_device function and our accelerator device actually access the dma buffer with no problem. (no translation fault).   case B) Here we allocate the dma buffer for our accelerator device while the application runs after the boot (the buffer is not allocated during the drive initialization). While the application runs, the driver does the kmalloc + dma_map_single + dma_sync_single_for_device and then when then device accesses the dma buffer, we see translation fault. By printing the SMMU event data, we know it's for data read access, and the class is 'b10 which is 'Input address caused fault'. and it is from the first stage (S2=0).   We know that the SMMU reads STE, CD and 3 entries of translation table. (we use 48bit address). Can we know in what stage of this 5 stages the fault arose? By the way the io virtual address starts with 0x7ffff~ (48bit) in both cases. Could anyone suggest us what information to look into now? Thank you, Best regards,Chan Kim

1 0