- kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

How to contribute to the linux kernel
by Qianqiang Liu Sept. 24, 2024

Sept. 24, 2024

Hi all, I am an embedded software engineer. I use Linux every day, and I appreciate its neatness and simplicity. One day, I watched a video from Greg: https://youtu.be/LLBrBBImJt4, and I started wondering if maybe I could contribute to the Linux kernel. So, I sent a very simple (and maybe stupid) patch to the community: > On Fri, Aug 30, 2024 at 04:54:38PM +0800, Qianqiang Liu wrote: > There is no need to add parentheses around 'devcode != 0x0000' and > 'devcode != 0x9320' > > Signed-off-by: Qianqiang Liu <qianqiang.liu(a)163.com> > --- > drivers/staging/fbtft/fb_ili9320.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/fbtft/fb_ili9320.c b/drivers/staging/fbtft/fb_ili9320.c > index 0be7c2d51548..409b54cc562e 100644 > --- a/drivers/staging/fbtft/fb_ili9320.c > +++ b/drivers/staging/fbtft/fb_ili9320.c > @@ -37,7 +37,7 @@ static int init_display(struct fbtft_par *par) > devcode = read_devicecode(par); > fbtft_par_dbg(DEBUG_INIT_DISPLAY, par, "Device code: 0x%04X\n", > devcode); > - if ((devcode != 0x0000) && (devcode != 0x9320)) > + if (devcode != 0x0000 && devcode != 0x9320) > dev_warn(par->info->device, > "Unrecognized Device code: 0x%04X (expected 0x9320)\n", > devcode); > -- > 2.39.2 It turns out that the patch was rejected. So, my question is: how can I start contributing to the Linux kernel? Maybe I could start by fixing some small bugs? Thanks, Qianqiang Liu

5 10

ACK packets being rejected in SYNPROXY, unless there was a valid TCP connection before it
by Yadunandan Pillai Sept. 16, 2024

Sept. 16, 2024

Hi, I have written an XDP program that intercepts ACK handshake packets, and rewrites the acknowledgement number with a randomly generated syncookie (bpf_tcp_raw_gen_syncookie_ipv4). The idea is to eventually create a custom SYNPROXY. I've got a TCP socket server that logs whenever "accept" finishes (connection was established). Initially, my ACK packets kept getting rejected with RST packets. However, I found that once I unlink the XDP program, complete a normal TCP handshake, and then link the XDP program again, the ACK packets are accepted. I figured there's some issue with hanging socket states so I tried killing all TIME_WAIT, and other sockets in various close states with `ss`, but the same behavior continued. "xdp_synproxy_kern.c" is the only relevant example I can find in the kernel source, and it does the same thing I do with ACK packets. Only difference is, the sample code generates a SYNACK directly in the XDP program, while I let the kernel do it for me and just modify the ACK. I looked through the kernel source, and I didn't see any context being added to the listening port with SYNCOOKIES enabled until the ACK packet is received (as should be the behavior, otherwise you defeat the purpose of SYNCOOKIES). What am I missing here?

1 0

Bug across major branches, advice for bisecting and contributing
by james young Sept. 14, 2024

Sept. 14, 2024

I've hit an odd CIFS corruption issue, in certain contexts, on ARM, dependent on the Linux kernel version. I have a repeatable test. It looks like:  * Debian 11, bullseye, kernel 6.1: ok  * Debian 12, bookworm, kernel 6.6: impacted  * v6.10, that I compiled: ok I think I need to be *far* more specific before I go to the main kernel mailing list or report a regression. I'm planning to test the mainline kernel, though I haven't noted significant differences from what Debian distributed. What's most useful here? * bisecting what broke between 6.1 and 6.6 - about 88k commits  * bisecting the fix between 6.6 and 6.10 - about 66k commits  * survey the major branches - 6.1, 6.2, ... 6.10 - my current WIP Each iteration can take hours, and these aren't fully unattended, so, I can't be too extensive, here. Any thoughts or suggestions? -James

2 1

data relocation to !ENDBR
by jim.cromie＠gmail.com Sept. 13, 2024

Sept. 13, 2024

anybody familiar with this error, or how to fix it ? It doesnt seem to break anything (boots,runs fine), but thats not much of a test. [jimc@frodo b0-dd]$ make GEN Makefile CALL ../scripts/checksyscalls.sh DESCEND objtool INSTALL libsubcmd_headers LD vmlinux.o vmlinux.o: warning: objtool: .export_symbol+0x2c1d8: data relocation to !ENDBR: stpcpy+0x0 OBJCOPY modules.builtin.modinfo ... make finishes [jimc@frodo b0-dd]$ nm vmlinux.a | grep s7tpcpy 0000000000000050 r __export_symbol_stpcpy 0000000000000110 T stpcpy 00000000000000b0 d __UNIQUE_ID___addressable_stpcpy9 is it improper to EXPORT_SYMBOL a struct in a __section ?

1 1

How to find all PCI/ USB/ drivers installed on my Ubuntu?
by S Sept. 12, 2024

Sept. 12, 2024

Like lsusb will tell me all USB devices. But now let's say I have modules that are loading USB drivers or high level USB drivers. How to find that list. Same question for PCI

2 1

TIP
by Constantine Shulyupin Sept. 10, 2024

Sept. 10, 2024

What does "TIP" stand for in the repository https://git.kernel.org/pub/scm/linux/kernel/git/tip/? Thanks

5 4

Question regarding appropriate mailing list
by Patryk Sept. 3, 2024

Sept. 3, 2024

Hi, What would be the most appropriate mailing list to ask about pmbus drivers and power management devices like ltc29**. I'm trying to bring-up some LTC devices using existing drivers and I've encountered some problems while reading e.g. temp1_max_alarm attribute (NACK returned from the target device). I've found what exact line of code introduced in 5.15.x kernel causes this problem but I'm not sure whether or not that line was added according to the pmbus specification expectations therefore the code is fine, but it may that it's the device that responds incorrectly and it's behaviour does not adhere to the pmbus specification. BR Patryk

2 1

Query Regarding Stack-Out-of-Bounds Error
by Muni Sekhar Aug. 31, 2024

Aug. 31, 2024

Dear Linux Kernel Community, I am writing to seek clarification on a potential stack-out-of-bounds issue observed during the calls to for_each_set_bit function or find_first_bit function, specifically in the following code snippet: static struct cmd_info *find_cmd_entry_any_ring(struct intel_gvt *gvt, unsigned int opcode, int rings) { struct cmd_info *info = NULL; unsigned int ring; ... for_each_set_bit(ring, (unsigned long *)&rings, I915_NUM_ENGINES) { In the above code, a 32-bit integer pointer (rings) is being cast to a 64-bit unsigned long pointer, which leads to an extra 4 bytes being accessed. This raises a concern regarding a stack-out-of-bounds bug. My specific query is: While it is logically understandable that a write operation involving these extra 4 bytes could cause a kernel crash, in this case, it is a read operation that is occurring. Would such a read operation still be capable of crashing the kernel or resulting in unpredictable system behaviour? If so, could you please explain how that would happen? I appreciate your insights and look forward to your guidance on this issue. -- Thanks, Sekhar

2 3

Reproducing syzbot
by Kenneth Adam Miller Aug. 31, 2024

Aug. 31, 2024

Is there any way to obtain a downloadable version of something executable from syzbot that demonstrates the errors encountered?

2 1

Separating driver and documentation changes
by Patryk Biel Aug. 22, 2024

Aug. 22, 2024

Hi I'm going to send a patch that extends existing driver with support for a new variant of the existing device. The changes in the drivr code are rather small, around 100 lines of code. Apart from the driver changes I would like to also update Documentation/devicetree/bindings for this driver to add the information about the new supported variant. Should I split the changes and send them separately? If so, how can I make sure that the documentation changes won't be merged to kernel source tree until the drive's modifications are merged? (if ofc maintainer decides to integrate them). Best regards Patryk

2 1