So here we are, one week late, and 5.19 is tagged and pushed out.
The full shortlog (just from rc8, obviously not all of 5.19) is below,
but I can happily report that there is nothing really interesting in
there. A lot of random small stuff.
In the diffstat, the loongarch updates stand out, as does another
batch of the networking sysctl READ_ONCE() annotations to make some of
the data race checker code happy.
Other than that it's really just a mixed bag of various odds and ends.
On a personal note, the most interesting part here is that I did the
release (and am writing this) on an arm64 laptop. It's something I've
been waiting for for a _loong_ time, and it's finally reality, thanks
to the Asahi team. We've had arm64 hardware around running Linux for a
long time, but none of it has really been usable as a development
platform until now.
It's the third time I'm using Apple hardware for Linux development - I
did it many years ago for powerpc development on a ppc970 machine.
And then a decade+ ago when the Macbook Air was the only real
thin-and-lite around. And now as an arm64 platform.
Not that I've used it for any real work, I literally have only been
doing test builds and boots and now the actual release tagging. But
I'm trying to make sure that the next time I travel, I can travel with
this as a laptop and finally dogfooding the arm64 side too.
Anyway, regardless of all that, this obviously means that the merge
window (*) will open tomorrow. But please give this a good test run
before you get all excited about a new development kernel.
Linus
(*) I'll likely call it 6.0 since I'm starting to worry about getting
confused by big numbers again.
---
Abhishek Pandit-Subedi (1):
Bluetooth: Always set event mask on suspend
Alejandro Lucero (1):
sfc: disable softirqs for ptp TX
Alistair Popple (1):
nouveau/svm: Fix to migrate all requested pages
Andrei Vagin (1):
fs: sendfile handles O_NONBLOCK of out_fd
Anirudh Venkataramanan (1):
ice: Fix VSIs unable to share unicast MAC
Arnaldo Carvalho de Melo (1):
tools headers cpufeatures: Sync with the kernel sources
Baolin Wang (1):
mailmap: update Baolin Wang's email
Bart Van Assche (1):
scsi: ufs: core: Fix a race condition related to device management
Benjamin Poirier (1):
bridge: Do not send empty IFLA_AF_SPEC attribute
Bibo Mao (2):
LoongArch: Remove clock setting during cpu hotplug stage
LoongArch: Remove unused variables
Borislav Petkov (1):
Revert "x86/sev: Expose sev_es_ghcb_hv_call() for use by HyperV"
ChenXiaoSong (1):
ntfs: fix use-after-free in ntfs_ucsncmp()
Christophe JAILLET (1):
caif: Fix bitmap data type in "struct caifsock"
Dan Carpenter (2):
Bluetooth: mgmt: Fix double free on error path
stmmac: dwmac-mediatek: fix resource leak in probe
David Howells (1):
watch_queue: Fix missing rcu annotation
David Jeffery (1):
scsi: mpt3sas: Stop fw fault watchdog work item during system shutdown
Dimitris Michailidis (1):
net/funeth: Fix fun_xdp_tx() and XDP packet reclaim
Duoming Zhou (1):
sctp: fix sleep in atomic context bug in timer handlers
Eiichi Tsukata (1):
docs/kernel-parameters: Update descriptions for "mitigations="
param with retbleed
Emil Renner Berthing (1):
riscv: compat: vdso: Fix vdso_install target
Eric Dumazet (1):
tcp: md5: fix IPv4-mapped support
Florian Fainelli (2):
tools: Fixed MIPS builds due to struct flock re-definition
ARM: 9216/1: Fix MAX_DMA_ADDRESS overflow
Florian Westphal (3):
netfilter: nf_queue: do not allow packet truncation below
transport header offset
netfilter: nf_tables: add rescheduling points during loop detection walks
netfilter: nft_queue: only allow supported familes and hooks
Gao Xiang (1):
mailmap: update Gao Xiang's email addresses
Harald Freudenberger (1):
s390/archrandom: prevent CPACF trng invocations in interrupt context
Huacai Chen (2):
LoongArch: Disable executable stack by default
LoongArch: Fix shared cache size calculation
Ian Rogers (1):
perf bpf: Remove undefined behavior from bpf_perf_object__next()
Jaewon Kim (1):
page_alloc: fix invalid watermark check on a negative value
Jason Wang (1):
virtio-net: fix the race between refill work and close
Jason Yan (1):
scsi: core: Fix warning in scsi_alloc_sgtables()
Jernej Skrabec (1):
clk: sunxi-ng: Fix H6 RTC clock definition
Jianglei Nie (1):
net: macsec: fix potential resource leak in macsec_add_rxsa()
and macsec_add_txsa()
Jonathan Lemon (1):
ptp: ocp: Select CRC16 in the Kconfig.
Josef Bacik (1):
mm: fix page leak with multiple threads mapping the same page
Jun Yi (1):
LoongArch: Remove useless header compiler.h
Junxiao Bi (1):
Revert "ocfs2: mount shared volume without ha stack"
Kuniyuki Iwashima (23):
tcp: Fix data-races around sysctl_tcp_dsack.
tcp: Fix a data-race around sysctl_tcp_app_win.
tcp: Fix a data-race around sysctl_tcp_adv_win_scale.
tcp: Fix a data-race around sysctl_tcp_frto.
tcp: Fix a data-race around sysctl_tcp_nometrics_save.
tcp: Fix data-races around sysctl_tcp_no_ssthresh_metrics_save.
tcp: Fix data-races around sysctl_tcp_moderate_rcvbuf.
tcp: Fix data-races around sysctl_tcp_workaround_signed_windows.
tcp: Fix a data-race around sysctl_tcp_limit_output_bytes.
tcp: Fix a data-race around sysctl_tcp_challenge_ack_limit.
tcp: Fix a data-race around sysctl_tcp_min_tso_segs.
tcp: Fix a data-race around sysctl_tcp_tso_rtt_log.
tcp: Fix a data-race around sysctl_tcp_min_rtt_wlen.
tcp: Fix a data-race around sysctl_tcp_autocorking.
tcp: Fix a data-race around sysctl_tcp_invalid_ratelimit.
tcp: Fix data-races around sk_pacing_rate.
net: Fix data-races around sysctl_[rw]mem(_offset)?.
tcp: Fix a data-race around sysctl_tcp_comp_sack_delay_ns.
tcp: Fix a data-race around sysctl_tcp_comp_sack_slack_ns.
tcp: Fix a data-race around sysctl_tcp_comp_sack_nr.
tcp: Fix data-races around sysctl_tcp_reflect_tos.
ipv4: Fix data-races around sysctl_fib_notify_on_flag_change.
net: ping6: Fix memleak in ipv6_renew_options().
Lai Jiangshan (1):
workqueue: Avoid a false warning in unbind_workers()
Leo Yan (3):
perf scripts python: Let script to be python2 compliant
perf symbol: Correct address for bss symbols
perf symbol: Skip symbols if SHF_ALLOC flag is not set
Liang He (2):
net: sungem_phy: Add of_node_put() for reference returned by
of_get_parent()
scsi: ufs: host: Hold reference returned by of_parse_phandle()
Linus Torvalds (2):
watch_queue: Fix missing locking in add_watch_to_object()
Linux 5.19
Linus Walleij (1):
ARM: pxa2xx: Fix GPIO descriptor tables
Luiz Augusto von Dentz (1):
Bluetooth: L2CAP: Fix use-after-free caused by l2cap_chan_put
Lukas Bulwahn (2):
asm-generic: remove a broken and needless ifdef conditional
x86/configs: Update configs in x86_debug.config
Maciej Fijalkowski (2):
ice: check (DD | EOF) bits on Rx descriptor rather than (EOP | RS)
ice: do not setup vlan for loopback VSI
Mat Martineau (1):
mptcp: Do not return EINPROGRESS when subflow creation succeeds
Maxim Mikityanskiy (1):
net/tls: Remove the context from the list in tls_device_down
Miaohe Lin (1):
hugetlb: fix memoryleak in hugetlb_mcopy_atomic_pte
Michael Ellerman (2):
powerpc/64s: Disable stack variable initialisation for prom_init
drm/amdgpu: Re-enable DCN for 64-bit powerpc
Michael Walle (1):
ARM: dts: lan966x: fix sys_clk frequency
Michal Maloszewski (1):
i40e: Fix interface init with MSI interrupts (no MSI-X)
Mike Rapoport (1):
secretmem: fix unhandled fault in truncate
Muchun Song (1):
mm: fix missing wake-up event for FSDAX pages
Nadav Amit (1):
userfaultfd: provide properly masked address for huge-pages
Naoya Horiguchi (1):
mm/hugetlb: separate path for hwpoison entry in copy_hugetlb_page_range()
Nathan Chancellor (1):
drm/simpledrm: Fix return type of
simpledrm_simple_display_pipe_mode_valid()
Przemyslaw Patynowski (2):
ice: Fix max VLANs available for VF
ice: Fix tunnel checksum offload with fragmented traffic
Qi Hu (1):
LoongArch: Fix missing fcsr in ptrace's fpr_set
Qi Zheng (1):
mm: fix NULL pointer dereference in wp_page_reuse()
Ralph Campbell (1):
mm/hmm: fault non-owner device private entries
Rob Herring (2):
dt-bindings: net: ethernet-controller: Rework 'fixed-link' schema
dt-bindings: net: fsl,fec: Add missing types to phy-reset-* properties
Russell King (Oracle) (1):
ARM: findbit: fix overflowing offset
Sabrina Dubroca (4):
macsec: fix NULL deref in macsec_add_rxsa
macsec: fix error message in macsec_add_rxsa and _txsa
macsec: limit replay window size with XPN
macsec: always read MACSEC_SA_ATTR_PN as a u64
Seth Forshee (1):
mailmap: update Seth Forshee's email address
Sherry Sun (2):
EDAC/synopsys: Use the correct register to disable the error
interrupt on v3 hw
EDAC/synopsys: Re-enable the error interrupts on v3 hw
Slark Xiao (3):
nfp: bpf: Fix typo 'the the' in comment
net: ipa: Fix typo 'the the' in comment
s390/qeth: Fix typo 'the the' in comment
Subbaraya Sundeep (1):
octeontx2-pf: Fix UDP/TCP src and dst port tc filters
Sunil Goutham (1):
octeontx2-pf: cn10k: Fix egress ratelimit configuration
Taehee Yoo (1):
net: mld: fix reference count leak in mld_{query | report}_work()
Tetsuo Handa (1):
wifi: mac80211: do not abuse fq.lock in ieee80211_do_stop()
Thadeu Lima de Souza Cascardo (1):
x86/bugs: Do not enable IBPB at firmware entry when IBPB is not available
Tiezhu Yang (1):
LoongArch: Fix wrong "ROM Size" of boardinfo
Tobias Gruetzmacher (1):
nvme-pci: Crucial P2 has bogus namespace ids
Toshi Kani (1):
EDAC/ghes: Set the DIMM label unconditionally
Umesh Nerlige Ramappa (1):
drm/i915/reset: Add additional steps for Wa_22011802037 for
execlist backend
Vladimir Oltean (2):
net: pcs: xpcs: propagate xpcs_read error to xpcs_get_state_c37_sgmii
net: dsa: fix reference counting for LAG FDBs
WANG Xuerui (8):
LoongArch: Use ABI names of registers where appropriate
LoongArch: Use the "jr" pseudo-instruction where applicable
LoongArch: Use the "move" pseudo-instruction where applicable
LoongArch: Simplify "BEQ/BNE foo, zero" with BEQZ/BNEZ
LoongArch: Simplify "BLT foo, zero" with BLTZ
LoongArch: Simplify "BGT foo, zero" with BGTZ
LoongArch: Re-tab the assembly files
LoongArch: Remove several syntactic sugar macros for branches
Waiman Long (2):
intel_idle: Fix false positive RCU splats due to incorrect hardirqs state
locking/rwsem: Allow slowpath writer to ignore handoff bit if
not set by first waiter
Wei Wang (1):
Revert "tcp: change pingpong threshold to 3"
Xin Long (2):
Documentation: fix sctp_wmem in ip-sysctl.rst
sctp: leave the err path free in sctp_stream_init to sctp_stream_free
Yee Lee (1):
mm: kfence: apply kmemleak_ignore_phys on early allocated pool
ZhaoLong Wang (1):
tmpfs: fix the issue that the mount and remount results are inconsistent.
Ziyang Xuan (1):
ipv6/addrconf: fix a null-ptr-deref bug for ip6_ptr
Below is the list of build error/warning regressions/improvements in
v5.19[1] compared to v5.18[2].
Summarized:
- build errors: +8/-4
- build warnings: +11/-11
JFYI, when comparing v5.19[1] to v5.19-rc8[3], the summaries are:
- build errors: +5/-0
- build warnings: +0/-0
Note that there may be false regressions, as some logs are incomplete.
Still, they're build errors/warnings.
Happy fixing! ;-)
Thanks to the linux-next team for providing the build service.
[1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/3d7cb6b04c3f3115719235cc6866b10326de34cd/ (all 135 configs)
[2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/4b0986a3613c92f4ec1bdc7f60ec66fea135991f/ (131 out of 135 configs)
[3] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/e0dccc3b76fb35bb257b4118367a883073d7390e/ (all 135 configs)
*** ERRORS ***
8 error regressions:
+ /kisskb/src/include/ufs/ufshci.h: error: initializer element is not constant: => 245:36
+ error: relocation truncated to fit: R_SPARC_WDISP22 against `.init.text': => (.head.text+0x5040), (.head.text+0x5100)
+ error: relocation truncated to fit: R_SPARC_WDISP22 against symbol `leon_smp_cpu_startup' defined in .text section in arch/sparc/kernel/trampoline_32.o: => (.init.text+0xa4)
+ {standard input}: Error: displacement to undefined symbol .L271 overflows 12-bit field: => 1625
+ {standard input}: Error: displacement to undefined symbol .L271 overflows 8-bit field : => 1634
+ {standard input}: Error: displacement to undefined symbol .L318 overflows 8-bit field : => 1693, 1711, 1665, 1681
+ {standard input}: Error: pcrel too far: => 1644, 1672, 1676, 1685, 1635, 1657, 1609, 1618, 1629, 1670, 1632, 1686, 1673, 1667, 1702, 1695, 1698, 1660, 1705, 1655, 1649, 1656, 1700, 1684
+ {standard input}: Error: unknown opcode: => 1713
4 error improvements:
- /kisskb/src/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c: error: case label does not reduce to an integer constant: 4917:4 =>
- /kisskb/src/drivers/scsi/aacraid/commsup.c: error: case label does not reduce to an integer constant: 1983:2 =>
- error: arch/sparc/kernel/head_32.o: relocation truncated to fit: R_SPARC_WDISP22 against `.init.text': (.head.text+0x5040), (.head.text+0x5100) =>
- error: arch/sparc/kernel/head_32.o: relocation truncated to fit: R_SPARC_WDISP22 against symbol `leon_smp_cpu_startup' defined in .text section in arch/sparc/kernel/trampoline_32.o: (.init.text+0xa4) =>
*** WARNINGS ***
11 warning regressions:
+ .config: warning: override: ARCH_RV32I changes choice state: => 3864
+ arch/m68k/configs/multi_defconfig: warning: symbol value 'm' invalid for ZPOOL: => 61
+ arch/m68k/configs/sun3_defconfig: warning: symbol value 'm' invalid for ZPOOL: => 37
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x47b0): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x47c8): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x47e0): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x47f8): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4810): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4828): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: => N/A
+ modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4840): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: => N/A
+ modpost: WARNING: modpost: vmlinux.o(.text.unlikely+0x52bc): Section mismatch in reference from the function __trace_event_discard_commit() to the variable .init.data:initcall_level_names: => N/A
11 warning improvements:
- .config: warning: override: reassigning to symbol GCC_PLUGIN_RANDSTRUCT: 12475, 12253 =>
- /kisskb/src/drivers/scsi/mpt3sas/mpt3sas_base.c: warning: array subscript 'Mpi2SasIOUnitPage1_t {aka struct _MPI2_CONFIG_PAGE_SASIOUNIT_1}[0]' is partly outside array bounds of 'unsigned char[20]' [-Warray-bounds]: 5400:40, 5403:43, 5396:40 =>
- /kisskb/src/drivers/tty/serial/sh-sci.c: warning: unused variable 'sport' [-Wunused-variable]: 2651:26 =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4790): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x47a8): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x47c0): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x47d8): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x47f0): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4808): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4820): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A =>
- modpost: WARNING: modpost: vmlinux.o(.text.unlikely+0x45d4): Section mismatch in reference from the function __trace_event_discard_commit() to the variable .init.data:initcall_level_names: N/A =>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Sun, Jul 31, 2022 at 02:43:03PM -0700, Linus Torvalds wrote:
> (*) I'll likely call it 6.0 since I'm starting to worry about getting
> confused by big numbers again.
Are you confused by gradually smaller "big numbers"? Last major release
update went:
v4.19 v4.20 v5.0
-Tony
On Mon, Aug 1, 2022 at 9:52 AM Tony Luck <[email protected]> wrote:
>
> On Sun, Jul 31, 2022 at 02:43:03PM -0700, Linus Torvalds wrote:
> > (*) I'll likely call it 6.0 since I'm starting to worry about getting
> > confused by big numbers again.
>
> Are you confused by gradually smaller "big numbers"? Last major release
> update went:
>
> v4.19 v4.20 v5.0
You are only proving my point. The 4.0 transition was v3.19 .. v4.0.
"Confusion" isn't some sudden-onset "hit-by-a-freight-train" thing.
It slowly creeps up on you, like a ninja sloth on the hunt.
Linus
On Mon, 1 Aug 2022, Geert Uytterhoeven wrote:
> JFYI, when comparing v5.19[1] to v5.19-rc8[3], the summaries are:
> - build errors: +5/-0
+ {standard input}: Error: displacement to undefined symbol .L271 overflows 12-bit field: => 1625
+ {standard input}: Error: displacement to undefined symbol .L271 overflows 8-bit field : => 1634
+ {standard input}: Error: displacement to undefined symbol .L318 overflows 8-bit field : => 1665, 1681, 1693, 1711
sh4-gcc11/sh-allyesconfig (seen before)
+ {standard input}: Error: pcrel too far: => 1629, 1686, 1635, 1655, 1702, 1618, 1660, 1676, 1672, 1684, 1685, 1698, 1695, 1656, 1649, 1670, 1667, 1657, 1644, 1673, 1705, 1609, 1632, 1700
+ {standard input}: Error: unknown opcode: => 1713
sh4-gcc11/sh-all{mod,yes}config (seen before)
The root cause is probably a compiler bug:
sh4-linux-gcc: internal compiler error: Segmentation fault signal terminated program cc1
> [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/3d7cb6b04c3f3115719235cc6866b10326de34cd/ (all 135 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/e0dccc3b76fb35bb257b4118367a883073d7390e/ (all 135 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi,
On 2022/8/1 05:43, Linus Torvalds wrote:
> (*) I'll likely call it 6.0 since I'm starting to worry about getting
> confused by big numbers again.
Could you please consider use 5.20 as next version number instead of
6.0? "5.20" is a wordplay number in Chinese, which means "I love you".
Thus "Linux 5.20" can be read as "I love Linux" in Chinese. So I think
it's good thing to release something like "Linux 5.20 I love linux
edition", just like "Linux For Workgroups 3.11" in the past.
Best Regards,
Zhang Boyang
From: Zhang Boyang
> Sent: 05 August 2022 18:00
>
> On 2022/8/1 05:43, Linus Torvalds wrote:
> > (*) I'll likely call it 6.0 since I'm starting to worry about getting
> > confused by big numbers again.
>
> Could you please consider use 5.20 as next version number instead of
> 6.0? "5.20" is a wordplay number in Chinese, which means "I love you".
> Thus "Linux 5.20" can be read as "I love Linux" in Chinese. So I think
> it's good thing to release something like "Linux 5.20 I love linux
> edition", just like "Linux For Workgroups 3.11" in the past.
I was thinking he should do 5.20, 5.21 and 5.22 before 6.0.
Just to stop anyone thinking it always changed after .19.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Hi,
On 2022/8/1 05:43, Linus Torvalds wrote:
> (*) I'll likely call it 6.0 since I'm starting to worry about getting
> confused by big numbers again.
Could you please consider name the next Linux release (5.20 or 6.0) "I
love linux" ? The number "5.20" is a wordplay in Chinese, which means "I
love you" [1], thus "Linux 5.20" can be read as "I love Linux" in Chinese.
Even if next kernel version is 6.0, I think it's probably a good idea
for both Chinese-speakers and non-Chinese speakers to express our love
to Linux Kernel.
The name of Linux kernel release has a long history of play-on-words
[2]. For example, 5.15 is named "Trick or Treat" and 5.17 is named
"Superb Owl".
[1] https://en.wikipedia.org/wiki/Chinese_Internet_slang
[2] https://en.wikipedia.org/wiki/Linux_kernel_version_history
Thanks and regards,
Zhang Boyang
Hi Boyang,
On 08/11/22 at 10:02pm, Zhang Boyang wrote:
> Hi,
>
> On 2022/8/1 05:43, Linus Torvalds wrote:
> > (*) I'll likely call it 6.0 since I'm starting to worry about getting
> > confused by big numbers again.
>
> Could you please consider name the next Linux release (5.20 or 6.0) "I love
> linux" ? The number "5.20" is a wordplay in Chinese, which means "I love
> you" [1], thus "Linux 5.20" can be read as "I love Linux" in Chinese.
>
> Even if next kernel version is 6.0, I think it's probably a good idea for
> both Chinese-speakers and non-Chinese speakers to express our love to Linux
> Kernel.
Interesting idea, LOL.
Yes, 520 means 'I love you' in chinese since it has the similar pronunciation
with '我爱你'. I even don't remember since when May 20th becomes another
holiday similar to Valentine's day in China. While I have complicated feeling
about 520. It means on each May 20th, I also need prepare gift for my wife. I
am not a romantic person, preparing gift to lover is always a torture to me.
So almost each May 20th day, Valentine's day, double seventh festival which is
a traditional Valentine's day, I will become nervous, and it ends up
with a satisfactory gift, or a bunch of flower and a digital red envelope with
520￥ and then complainment and blame in next two weeks.
So, for naming next release as '5.20', I will vote for it w/o hesitance. No need
to prepare gift, and can express our love to Linux kernel, it sounds
awesome.
Meanwhile, I would remind people to take it easy. Whether the suggestion
is accepted or not, it doesn't impact the fact that linux may have
become part of our life, not just our work, considering many kernel developers
are workoing form home. But if you have boasted to your girlfriend
or wife, and want to take this as a gift to her, you should try harder to
convince Linus.
Thanks
Baoquan
>
> The name of Linux kernel release has a long history of play-on-words [2].
> For example, 5.15 is named "Trick or Treat" and 5.17 is named "Superb Owl".
>
> [1] https://en.wikipedia.org/wiki/Chinese_Internet_slang
>
> [2] https://en.wikipedia.org/wiki/Linux_kernel_version_history
>
> Thanks and regards,
> Zhang Boyang
>
Hi, all,
On Fri, Aug 12, 2022 at 10:40 AM Baoquan He <[email protected]> wrote:
>
> Hi Boyang,
>
> On 08/11/22 at 10:02pm, Zhang Boyang wrote:
> > Hi,
> >
> > On 2022/8/1 05:43, Linus Torvalds wrote:
> > > (*) I'll likely call it 6.0 since I'm starting to worry about getting
> > > confused by big numbers again.
> >
> > Could you please consider name the next Linux release (5.20 or 6.0) "I love
> > linux" ? The number "5.20" is a wordplay in Chinese, which means "I love
> > you" [1], thus "Linux 5.20" can be read as "I love Linux" in Chinese.
> >
> > Even if next kernel version is 6.0, I think it's probably a good idea for
> > both Chinese-speakers and non-Chinese speakers to express our love to Linux
> > Kernel.
>
> Interesting idea, LOL.
>
> Yes, 520 means 'I love you' in chinese since it has the similar pronunciation
> with '我爱你'. I even don't remember since when May 20th becomes another
> holiday similar to Valentine's day in China. While I have complicated feeling
> about 520. It means on each May 20th, I also need prepare gift for my wife. I
> am not a romantic person, preparing gift to lover is always a torture to me.
> So almost each May 20th day, Valentine's day, double seventh festival which is
> a traditional Valentine's day, I will become nervous, and it ends up
> with a satisfactory gift, or a bunch of flower and a digital red envelope with
> 520￥ and then complainment and blame in next two weeks.
>
> So, for naming next release as '5.20', I will vote for it w/o hesitance. No need
> to prepare gift, and can express our love to Linux kernel, it sounds
> awesome.
>
> Meanwhile, I would remind people to take it easy. Whether the suggestion
> is accepted or not, it doesn't impact the fact that linux may have
> become part of our life, not just our work, considering many kernel developers
> are workoing form home. But if you have boasted to your girlfriend
> or wife, and want to take this as a gift to her, you should try harder to
> convince Linus.
>
> Thanks
> Baoquan
Frankly, I agree with Boyang and Baoquan. :)
Huacai
>
> >
> > The name of Linux kernel release has a long history of play-on-words [2].
> > For example, 5.15 is named "Trick or Treat" and 5.17 is named "Superb Owl".
> >
> > [1] https://en.wikipedia.org/wiki/Chinese_Internet_slang
> >
> > [2] https://en.wikipedia.org/wiki/Linux_kernel_version_history
> >
> > Thanks and regards,
> > Zhang Boyang
> >
>
On Fri, Aug 12, 2022 at 11:28:12AM +0800, Huacai Chen wrote:
> Hi, all,
>
> On Fri, Aug 12, 2022 at 10:40 AM Baoquan He <[email protected]> wrote:
> >
> > Hi Boyang,
> >
> > On 08/11/22 at 10:02pm, Zhang Boyang wrote:
> > > Hi,
> > >
> > > On 2022/8/1 05:43, Linus Torvalds wrote:
> > > > (*) I'll likely call it 6.0 since I'm starting to worry about getting
> > > > confused by big numbers again.
> > >
> > > Could you please consider name the next Linux release (5.20 or 6.0) "I love
> > > linux" ? The number "5.20" is a wordplay in Chinese, which means "I love
> > > you" [1], thus "Linux 5.20" can be read as "I love Linux" in Chinese.
> > >
> > > Even if next kernel version is 6.0, I think it's probably a good idea for
> > > both Chinese-speakers and non-Chinese speakers to express our love to Linux
> > > Kernel.
> >
> > Interesting idea, LOL.
> >
> > Yes, 520 means 'I love you' in chinese since it has the similar pronunciation
> > with '我爱你'. I even don't remember since when May 20th becomes another
> > holiday similar to Valentine's day in China. While I have complicated feeling
> > about 520. It means on each May 20th, I also need prepare gift for my wife. I
> > am not a romantic person, preparing gift to lover is always a torture to me.
> > So almost each May 20th day, Valentine's day, double seventh festival which is
> > a traditional Valentine's day, I will become nervous, and it ends up
> > with a satisfactory gift, or a bunch of flower and a digital red envelope with
> > 520￥ and then complainment and blame in next two weeks.
> >
> > So, for naming next release as '5.20', I will vote for it w/o hesitance. No need
> > to prepare gift, and can express our love to Linux kernel, it sounds
> > awesome.
> >
> > Meanwhile, I would remind people to take it easy. Whether the suggestion
> > is accepted or not, it doesn't impact the fact that linux may have
> > become part of our life, not just our work, considering many kernel developers
> > are workoing form home. But if you have boasted to your girlfriend
> > or wife, and want to take this as a gift to her, you should try harder to
> > convince Linus.
> >
> > Thanks
> > Baoquan
> Frankly, I agree with Boyang and Baoquan. :)
+1, I'm fine with either approach. If there is a 5.20 version, that is
fine.
The traditional Valentine's day of China is `Qixi Festival` which is the seventh
day of the seventh lunisolar month on the Chinese lunisolar calendar [1].
There are also other somewhat special days in China such as `Programmer day`
(Oct, 24 each year), yet I'm not sure if anyone out of China heard of it.
Personally I think 521 (yi vs ni) sounds more similar to "我爱你" in Mandarin
Chinese and who knows how many special days for couples -- since I'm single. ;)
[1] https://en.wikipedia.org/wiki/Qixi_Festival
Thanks,
Gao Xiang
>
> Huacai
> >
> > >
> > > The name of Linux kernel release has a long history of play-on-words [2].
> > > For example, 5.15 is named "Trick or Treat" and 5.17 is named "Superb Owl".
> > >
> > > [1] https://en.wikipedia.org/wiki/Chinese_Internet_slang
> > >
> > > [2] https://en.wikipedia.org/wiki/Linux_kernel_version_history
> > >
> > > Thanks and regards,
> > > Zhang Boyang
> > >
> >
在 2022/8/12 14:31, Gao Xiang 写道:
> On Fri, Aug 12, 2022 at 11:28:12AM +0800, Huacai Chen wrote:
>> Hi, all,
>>
>> On Fri, Aug 12, 2022 at 10:40 AM Baoquan He <[email protected]> wrote:
>>> Hi Boyang,
>>>
>>> On 08/11/22 at 10:02pm, Zhang Boyang wrote:
>>>> Hi,
>>>>
>>>> On 2022/8/1 05:43, Linus Torvalds wrote:
>>>>> (*) I'll likely call it 6.0 since I'm starting to worry about getting
>>>>> confused by big numbers again.
>>>> Could you please consider name the next Linux release (5.20 or 6.0) "I love
>>>> linux" ? The number "5.20" is a wordplay in Chinese, which means "I love
>>>> you" [1], thus "Linux 5.20" can be read as "I love Linux" in Chinese.
>>>>
>>>> Even if next kernel version is 6.0, I think it's probably a good idea for
>>>> both Chinese-speakers and non-Chinese speakers to express our love to Linux
>>>> Kernel.
>>> Interesting idea, LOL.
>>>
>>> Yes, 520 means 'I love you' in chinese since it has the similar pronunciation
>>> with '我爱你'. I even don't remember since when May 20th becomes another
>>> holiday similar to Valentine's day in China. While I have complicated feeling
>>> about 520. It means on each May 20th, I also need prepare gift for my wife. I
>>> am not a romantic person, preparing gift to lover is always a torture to me.
>>> So almost each May 20th day, Valentine's day, double seventh festival which is
>>> a traditional Valentine's day, I will become nervous, and it ends up
>>> with a satisfactory gift, or a bunch of flower and a digital red envelope with
>>> 520￥ and then complainment and blame in next two weeks.
>>>
>>> So, for naming next release as '5.20', I will vote for it w/o hesitance. No need
>>> to prepare gift, and can express our love to Linux kernel, it sounds
>>> awesome.
>>>
>>> Meanwhile, I would remind people to take it easy. Whether the suggestion
>>> is accepted or not, it doesn't impact the fact that linux may have
>>> become part of our life, not just our work, considering many kernel developers
>>> are workoing form home. But if you have boasted to your girlfriend
>>> or wife, and want to take this as a gift to her, you should try harder to
>>> convince Linus.
>>>
>>> Thanks
>>> Baoquan
>> Frankly, I agree with Boyang and Baoquan. :)
> +1, I'm fine with either approach. If there is a 5.20 version, that is
> fine.
>
> The traditional Valentine's day of China is `Qixi Festival` which is the seventh
> day of the seventh lunisolar month on the Chinese lunisolar calendar [1].
>
> There are also other somewhat special days in China such as `Programmer day`
> (Oct, 24 each year), yet I'm not sure if anyone out of China heard of it.
>
> Personally I think 521 (yi vs ni) sounds more similar to "我爱你" in Mandarin
> Chinese and who knows how many special days for couples -- since I'm single. ;)
>
> [1] https://en.wikipedia.org/wiki/Qixi_Festival
How romantic! I agree to all the abrove.
Thanks,
Yanteng
>
> Thanks,
> Gao Xiang
>
>> Huacai
>>>> The name of Linux kernel release has a long history of play-on-words [2].
>>>> For example, 5.15 is named "Trick or Treat" and 5.17 is named "Superb Owl".
>>>>
>>>> [1] https://en.wikipedia.org/wiki/Chinese_Internet_slang
>>>>
>>>> [2] https://en.wikipedia.org/wiki/Linux_kernel_version_history
>>>>
>>>> Thanks and regards,
>>>> Zhang Boyang
>>>>
On 2022/8/12 10:39, Baoquan He wrote:
> Hi Boyang,
>
> On 08/11/22 at 10:02pm, Zhang Boyang wrote:
>> Hi,
>>
>> On 2022/8/1 05:43, Linus Torvalds wrote:
>>> (*) I'll likely call it 6.0 since I'm starting to worry about getting
>>> confused by big numbers again.
>>
>> Could you please consider name the next Linux release (5.20 or 6.0) "I love
>> linux" ? The number "5.20" is a wordplay in Chinese, which means "I love
>> you" [1], thus "Linux 5.20" can be read as "I love Linux" in Chinese.
>>
>> Even if next kernel version is 6.0, I think it's probably a good idea for
>> both Chinese-speakers and non-Chinese speakers to express our love to Linux
>> Kernel.
>
> Interesting idea, LOL.
>
> Yes, 520 means 'I love you' in chinese since it has the similar pronunciation
> with '我爱你'. I even don't remember since when May 20th becomes another
> holiday similar to Valentine's day in China. While I have complicated feeling
> about 520. It means on each May 20th, I also need prepare gift for my wife. I
> am not a romantic person, preparing gift to lover is always a torture to me.
> So almost each May 20th day, Valentine's day, double seventh festival which is
> a traditional Valentine's day, I will become nervous, and it ends up
> with a satisfactory gift, or a bunch of flower and a digital red envelope with
> 520￥ and then complainment and blame in next two weeks.
>
> So, for naming next release as '5.20', I will vote for it w/o hesitance. No need
> to prepare gift, and can express our love to Linux kernel, it sounds
> awesome.
>
> Meanwhile, I would remind people to take it easy. Whether the suggestion
> is accepted or not, it doesn't impact the fact that linux may have
> become part of our life, not just our work, considering many kernel developers
> are workoing form home. But if you have boasted to your girlfriend
> or wife, and want to take this as a gift to her, you should try harder to
> convince Linus.
>
Yes, I think so. Linus may be too busy to respond, so let's take it easy
and let him focus on his work. :)
> Thanks
> Baoquan
>
>>
>> The name of Linux kernel release has a long history of play-on-words [2].
>> For example, 5.15 is named "Trick or Treat" and 5.17 is named "Superb Owl".
>>
>> [1] https://en.wikipedia.org/wiki/Chinese_Internet_slang
>>
>> [2] https://en.wikipedia.org/wiki/Linux_kernel_version_history
>>
>> Thanks and regards,
>> Zhang Boyang
>>
>
On 8/12/22 10:39, Baoquan He wrote:
> Hi Boyang,
>
> On 08/11/22 at 10:02pm, Zhang Boyang wrote:
>> Hi,
>>
>> On 2022/8/1 05:43, Linus Torvalds wrote:
>>> (*) I'll likely call it 6.0 since I'm starting to worry about getting
>>> confused by big numbers again.
>> Could you please consider name the next Linux release (5.20 or 6.0) "I love
>> linux" ? The number "5.20" is a wordplay in Chinese, which means "I love
>> you" [1], thus "Linux 5.20" can be read as "I love Linux" in Chinese.
>>
>> Even if next kernel version is 6.0, I think it's probably a good idea for
>> both Chinese-speakers and non-Chinese speakers to express our love to Linux
>> Kernel.
> Interesting idea, LOL.
>
> Yes, 520 means 'I love you' in chinese since it has the similar pronunciation
> with '我爱你'. I even don't remember since when May 20th becomes another
> holiday similar to Valentine's day in China. While I have complicated feeling
> about 520. It means on each May 20th, I also need prepare gift for my wife. I
> am not a romantic person, preparing gift to lover is always a torture to me.
> So almost each May 20th day, Valentine's day, double seventh festival which is
> a traditional Valentine's day, I will become nervous, and it ends up
> with a satisfactory gift, or a bunch of flower and a digital red envelope with
> 520￥ and then complainment and blame in next two weeks.
>
> So, for naming next release as '5.20', I will vote for it w/o hesitance. No need
> to prepare gift, and can express our love to Linux kernel, it sounds
> awesome.
>
> Meanwhile, I would remind people to take it easy. Whether the suggestion
> is accepted or not, it doesn't impact the fact that linux may have
> become part of our life, not just our work, considering many kernel developers
> are workoing form home. But if you have boasted to your girlfriend
> or wife, and want to take this as a gift to her, you should try harder to
> convince Linus.
Woah. This is some of the larger-scale "cultural export" I've ever seen,
and probably the first time on LKML. I'd remember the few dry laughs
when I tried to explain the "Superb Owl" meme to my teammates,
unfamiliar with (US) English memes in general, so I could even
sympathize with those of you not knowing Chinese Internet memes...
One thing is for sure, if the next Linux version is to be kept 5.20 and
codenamed "Linux I love you" or something like that, it would certainly
make headlines on Chinese tech news sites for a while, more specifically
both after rc1 and the final release; but anyway, as Baoquan already
pointed out, our collective love for Linux and the open-source ideals
behind the whole thing is not going anywhere, no matter what the
Makefile says. (You may find it useful to make your partner happy using
the 520/521 meme too, if applicable; but from my own experience, better
not bring up Linux if your partner is not interested in that topic!)
(And, pun semi-intended for that "bringing up". ;-)
--
WANG "xen0n" Xuerui
Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/