Krzysztof Kozlowski
Posts
191Following
31Followers
191🇵🇱 🇪🇺 🇰🇷 🇮🇱 🇺🇦 🇨ðŸ‡
IRC: krzk
Kernel work related account. Other accounts of mine: @krzk@mastodon.social
Krzysztof Kozlowski
krzk
Edited 1 year ago
For a year I have been keeping a branch on top of linux-next with all the cleanups and fixes for Qualcomm SoCs Devicetree sources. Goal is to pass DT schema validation someday (just like Samsung does). I update and rebase the branch frequently. I also add new patches to fix existing warnings. Unfortunately, the branch actually never gets smaller: I always have around 120-200 patches on top of linux-next. Always. Now, after rebasing on next-20230913 it is ~150 patches. Still 150 patches just cannot get applied...
If anyone tells you "Linux kernel development goes too fast", he is wrong. It's too slow. For one year I was able to create fixes much faster than people were applying then.
Branch is here if anyone wants to avoid duplicating work/effort:
https://github.com/krzk/linux/tree/pending/dt-bindings-qcom-new-and-fixes-for-warnings-linux-next
If anyone tells you "Linux kernel development goes too fast", he is wrong. It's too slow. For one year I was able to create fixes much faster than people were applying then.
Branch is here if anyone wants to avoid duplicating work/effort:
https://github.com/krzk/linux/tree/pending/dt-bindings-qcom-new-and-fixes-for-warnings-linux-next
0
0
3
Krzysztof Kozlowski
krzk
Syzkaller now creates nice monthly reports reminding what could be fixed. Anyone bored enough or having enough of spare time to fix these NFC issues (having repro!)?
https://lore.kernel.org/all/0000000000008253550604ac4d36@google.com/
https://lore.kernel.org/all/0000000000008253550604ac4d36@google.com/
0
1
2
Krzysztof Kozlowski
krzk
Trimmed diffstat of v6.6-rc1 pull request ARM SoC changes from @arnd - the most active platforms for v6.6:
18.9% arch/arm64/boot/dts/qcom/
0.6% arch/arm/boot/dts/qcom/
1.0% drivers/soc/qcom/
...
9.6% arch/arm64/boot/dts/freescale/
3.6% arch/arm/boot/dts/nxp/imx/
0.7% arch/arm/boot/dts/nxp/ls/
0.9% arch/arm/boot/dts/nxp/mxs/
...
8.1% arch/arm/boot/dts/aspeed/
...
8.2% arch/arm64/boot/dts/ti/
0.5% arch/arm/boot/dts/ti/
...
6.6% arch/arm64/boot/dts/nvidia/
...
6.3% arch/arm64/boot/dts/rockchip/
Way to go Qualcomm SoC community!
Source: https://lore.kernel.org/all/4f60d13e-f060-491a-88c7-6f25323a48f8@app.fastmail.com/
18.9% arch/arm64/boot/dts/qcom/
0.6% arch/arm/boot/dts/qcom/
1.0% drivers/soc/qcom/
...
9.6% arch/arm64/boot/dts/freescale/
3.6% arch/arm/boot/dts/nxp/imx/
0.7% arch/arm/boot/dts/nxp/ls/
0.9% arch/arm/boot/dts/nxp/mxs/
...
8.1% arch/arm/boot/dts/aspeed/
...
8.2% arch/arm64/boot/dts/ti/
0.5% arch/arm/boot/dts/ti/
...
6.6% arch/arm64/boot/dts/nvidia/
...
6.3% arch/arm64/boot/dts/rockchip/
Way to go Qualcomm SoC community!
Source: https://lore.kernel.org/all/4f60d13e-f060-491a-88c7-6f25323a48f8@app.fastmail.com/
0
3
5
Krzysztof Kozlowski
krzk
Edited 1 year ago
Corporate rules going mad: After replying to Nuvoton patches, I received now automated Out-of-office reply with "confidentiality" clause: "The privileged confidential information contained in this email is intended for use only". This is Out-of-office auto-reply, not confidential message. Get your silly systems together people...
0
0
1
@linuxplumbersconf Thanks. Good to know, although better would be to have in the Mastodon profile. It would avoid any misunderstandings.
0
0
0
Krzysztof Kozlowski
krzk
@linuxplumbersconf Hey Linux Plumbers! What is the point of the your mastodon account if you do not interact and do not respond here to any questions?
2
0
2
@siddhesh_p @gregkh @sj You did not really cover the case. Either this customer had outdated kernel, thus the group should not even start creating CVE, or this kernel did not have basic fix which was fixed 7 years ago. In the latter case it would be enough just to backport the fix, not go through ridiculous CVE assignment.
Anyway, it is not really professional and what RedHat is doing with CVEs is awesome example how useless CVEs are.
Anyway, it is not really professional and what RedHat is doing with CVEs is awesome example how useless CVEs are.
1
0
2
@siddhesh_p @gregkh @sj Independently? Something fixed 7 years ago? How can you trigger such bug?
I can barely believe that any customer discovered now a bug which was fixed 7 years ago. Even if this is possible, I can hardly believe any sane person on distro side would request for CVE for such bug, instead of replying: "dude, you forgot to update your system for the last 7 years".
So no, much more likely is that RedHat was actually shipping some crazy old kernel to some people without that fix and needed CVE to justify touching this old stuff...
I can barely believe that any customer discovered now a bug which was fixed 7 years ago. Even if this is possible, I can hardly believe any sane person on distro side would request for CVE for such bug, instead of replying: "dude, you forgot to update your system for the last 7 years".
So no, much more likely is that RedHat was actually shipping some crazy old kernel to some people without that fix and needed CVE to justify touching this old stuff...
1
0
0
@siddhesh_p @gregkh @sj Yeah, maybe they do not require CVE for every backport anymore... but then:
"Heh, apparently Red Hat recently assigned a CVE for a random kernel fix I did 7 years ago"
so not really.
https://mastodon.social/@vegard/110933167051678536
"Heh, apparently Red Hat recently assigned a CVE for a random kernel fix I did 7 years ago"
so not really.
https://mastodon.social/@vegard/110933167051678536
1
0
1
@sj Just in case - I was not offended and I just discuss the idea of measuring anything against CVEs.
I believe that in open-source work we should not be participating in this ridiculous CVE dance, unless of course it's our profession or job. Then... well, life. :) It was my job once too.
I understand why CVEs were invented and why they are still used, even though they were effectively made pointless in last few years. However, just because some corporations believe in them ("believe" is a key word here, because their decision about CVE was based on feelings not facts), does not mean we should be endorsing this or participating in this.
I believe that in open-source work we should not be participating in this ridiculous CVE dance, unless of course it's our profession or job. Then... well, life. :) It was my job once too.
I understand why CVEs were invented and why they are still used, even though they were effectively made pointless in last few years. However, just because some corporations believe in them ("believe" is a key word here, because their decision about CVE was based on feelings not facts), does not mean we should be endorsing this or participating in this.
1
0
1
@sj Since CVEs are basically useless, any percentage here or calling it "worst case time" is pointless. It's like measuring number of celebrities and mapping it to Linux kernel commits... Worse, it suggests that some bugs are not addressed (not fixed) or addressed slowly. This is in fact misleading.
1
0
1
@linuxplumbersconf Deadline for LPC 2023 refereed track and Kernel Summit passed two weeks ago. Any plans for sharing the schedule/program so people can do some planning?
0
0
0
Krzysztof Kozlowski
krzk
When review happens too fast:
"You replied within the same minute of me posting that patch, which is the fastest review I've had to date on an upstream kernel list. Before we continue, please verify:
[ ] I am not a robot"
From Brian Masney: https://lore.kernel.org/all/ZN5KIlI+RDu92jsi@brian-x1/
"You replied within the same minute of me posting that patch, which is the fastest review I've had to date on an upstream kernel list. Before we continue, please verify:
[ ] I am not a robot"
From Brian Masney: https://lore.kernel.org/all/ZN5KIlI+RDu92jsi@brian-x1/
0
1
9