Linux 5.19

Linux 5.19

[Linus Torvalds]

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

Build regressions/improvements in v5.19

[Geert Uytterhoeven]

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 -- geert@linux-m68k.org

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

Re: Linux 5.19

[Tony Luck]

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

Re: Linux 5.19

[Linus Torvalds]

On Mon, Aug 1, 2022 at 9:52 AM Tony Luck <tony.luck@intel.com> 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

Re: Build regressions/improvements in v5.19

[Geert Uytterhoeven]

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 -- geert@linux-m68k.org

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

Please consider Linux 5.20 because it means "I love Linux" in Chinese (Re: Linux 5.19)

[Zhang Boyang]

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

RE: Please consider Linux 5.20 because it means "I love Linux" in Chinese (Re: Linux 5.19)

[David Laight]

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)

ext2/zram issue [was: Linux 5.19]

[Jiri Slaby]

Hi,

On 31. 07. 22, 23:43, Linus Torvalds wrote:
> 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.

Note: I originally reported this downstream for tracking at:
https://bugzilla.suse.com/show_bug.cgi?id=1202203

5.19 behaves pretty weird in openSUSE's openQA (opposing to 5.18, or 
5.18.15). It's all qemu-kvm "HW"¹⁾:
https://openqa.opensuse.org/tests/2502148
loop2: detected capacity change from 0 to 72264
EXT4-fs warning (device zram0): ext4_end_bio:343: I/O error 10 writing 
to inode 57375 starting block 137216)
Buffer I/O error on device zram0, logical block 137216
Buffer I/O error on device zram0, logical block 137217
...
SQUASHFS error: xz decompression failed, data probably corrupt
SQUASHFS error: Failed to read block 0x2e41680: -5
SQUASHFS error: xz decompression failed, data probably corrupt
SQUASHFS error: Failed to read block 0x2e41680: -5
Bus error



https://openqa.opensuse.org/tests/2502145
FS-Cache: Loaded
begin 644 ldconfig.core.pid_2094.sig_7.time_1659859442



https://openqa.opensuse.org/tests/2502146
FS-Cache: Loaded
begin 644 Xorg.bin.core.pid_3733.sig_6.time_1659858784



https://openqa.opensuse.org/tests/2502148
EXT4-fs warning (device zram0): ext4_end_bio:343: I/O error 10 writing 
to inode 57375 starting block 137216)
Buffer I/O error on device zram0, logical block 137216
Buffer I/O error on device zram0, logical block 137217



https://openqa.opensuse.org/tests/2502154
[   13.158090][  T634] FS-Cache: Loaded
...
[  525.627024][    C0] sysrq: Show State



Those are various failures -- crashes of ldconfig, Xorg; I/O failures on 
zram; the last one is a lockup likely, something invoked sysrq after 
500s stall.

Interestingly, I've also hit this twice locally:
 > init[1]: segfault at 18 ip 00007fb6154b4c81 sp 00007ffc243ed600 error 
6 in libc.so.6[7fb61543f000+185000]
 > Code: 41 5f c3 66 0f 1f 44 00 00 42 f6 44 10 08 01 0f 84 04 01 00 00 
48 83 e1 fe 48 89 48 08 49 8b 47 70 49 89 5f 70 66 48 0f 6e c0 <48> 89 
58 18 0f 16 44 24 08 48 81 fd ff 03 00 00 76 08 66 0f ef c9
 > ***  signal 11 ***
 > malloc(): unsorted double linked list corrupted
 > traps: init[1] general protection fault ip:7fb61543f8b9 
sp:7ffc243ebf40 error:0 in libc.so.6[7fb61543f000+185000]
 > Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
 > CPU: 0 PID: 1 Comm: init Not tainted 5.19.0-1-default #1 openSUSE 
Tumbleweed e1df13166a33f423514290c702e43cfbb2b5b575

KASAN is not helpful either, so it's unlikely a memory corruption 
(unless it is "HW" related; should I try to turn on IOMMU in qemu?):
> kasan: KernelAddressSanitizer initialized
> ...
> zram: module verification failed: signature and/or required key missing - tainting kernel
> zram: Added device: zram0
> zram0: detected capacity change from 0 to 2097152
> EXT4-fs (zram0): mounting ext2 file system using the ext4 subsystem
> EXT4-fs (zram0): mounted filesystem without journal. Quota mode: none.
> EXT4-fs warning (device zram0): ext4_end_bio:343: I/O error 10 writing to inode 16386 starting block 159744)
> Buffer I/O error on device zram0, logical block 159744
> Buffer I/O error on device zram0, logical block 159745



They all occur to me like a zram failure. The installer apparently 
creates an ext2 FS and after it mounts it using ext4 module, the issue 
starts occurring.

Any tests I/you could run on 5.19 to exercise zram and ext2? Otherwise I 
am unable to reproduce easily, except using the openSUSE installer :/.

Any other ideas? Or is this known already?

¹⁾ main are uefi boot and virtio-blk (it likely happens with virtio-scsi 
too). The cmdline _I_ use: qemu-kvm -device intel-hda -device hda-duplex 
-drive file=/tmp/pokus.qcow2,if=none,id=hd -device 
virtio-blk-pci,drive=hd -drive 
if=pflash,format=raw,unit=0,readonly=on,file=/usr/share/qemu/ovmf-x86_64-opensuse-code.bin 
-drive if=pflash,format=raw,unit=1,file=/tmp/vars.bin -cdrom 
/tmp/cd1.iso  -m 1G -smp 1 -net user -net nic,model=virtio -serial pty 
-device virtio-rng-pci -device qemu-xhci,p2=4,p3=4 -usbdevice tablet


thanks,
-- 
js
suse labs

Re: ext2/zram issue [was: Linux 5.19]

[Jiri Slaby]

On 09. 08. 22, 8:03, Jiri Slaby wrote:
> Hi,
> 
> On 31. 07. 22, 23:43, Linus Torvalds wrote:
>> 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.
> 
> Note: I originally reported this downstream for tracking at:
> https://bugzilla.suse.com/show_bug.cgi?id=1202203
> 
> 5.19 behaves pretty weird in openSUSE's openQA (opposing to 5.18, or 
> 5.18.15). It's all qemu-kvm "HW"¹⁾:
> https://openqa.opensuse.org/tests/2502148
> loop2: detected capacity change from 0 to 72264
> EXT4-fs warning (device zram0): ext4_end_bio:343: I/O error 10 writing 
> to inode 57375 starting block 137216)
> Buffer I/O error on device zram0, logical block 137216
> Buffer I/O error on device zram0, logical block 137217
> ...
> SQUASHFS error: xz decompression failed, data probably corrupt
> SQUASHFS error: Failed to read block 0x2e41680: -5
> SQUASHFS error: xz decompression failed, data probably corrupt
> SQUASHFS error: Failed to read block 0x2e41680: -5
> Bus error
> 
> 
> 
> https://openqa.opensuse.org/tests/2502145
> FS-Cache: Loaded
> begin 644 ldconfig.core.pid_2094.sig_7.time_1659859442
> 
> 
> 
> https://openqa.opensuse.org/tests/2502146
> FS-Cache: Loaded
> begin 644 Xorg.bin.core.pid_3733.sig_6.time_1659858784
> 
> 
> 
> https://openqa.opensuse.org/tests/2502148
> EXT4-fs warning (device zram0): ext4_end_bio:343: I/O error 10 writing 
> to inode 57375 starting block 137216)
> Buffer I/O error on device zram0, logical block 137216
> Buffer I/O error on device zram0, logical block 137217
> 
> 
> 
> https://openqa.opensuse.org/tests/2502154
> [   13.158090][  T634] FS-Cache: Loaded
> ...
> [  525.627024][    C0] sysrq: Show State
> 
> 
> 
> Those are various failures -- crashes of ldconfig, Xorg; I/O failures on 
> zram; the last one is a lockup likely, something invoked sysrq after 
> 500s stall.
> 
> Interestingly, I've also hit this twice locally:
>  > init[1]: segfault at 18 ip 00007fb6154b4c81 sp 00007ffc243ed600 error 
> 6 in libc.so.6[7fb61543f000+185000]
>  > Code: 41 5f c3 66 0f 1f 44 00 00 42 f6 44 10 08 01 0f 84 04 01 00 00 
> 48 83 e1 fe 48 89 48 08 49 8b 47 70 49 89 5f 70 66 48 0f 6e c0 <48> 89 
> 58 18 0f 16 44 24 08 48 81 fd ff 03 00 00 76 08 66 0f ef c9
>  > ***  signal 11 ***
>  > malloc(): unsorted double linked list corrupted
>  > traps: init[1] general protection fault ip:7fb61543f8b9 
> sp:7ffc243ebf40 error:0 in libc.so.6[7fb61543f000+185000]
>  > Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>  > CPU: 0 PID: 1 Comm: init Not tainted 5.19.0-1-default #1 openSUSE 
> Tumbleweed e1df13166a33f423514290c702e43cfbb2b5b575
> 
> KASAN is not helpful either, so it's unlikely a memory corruption 
> (unless it is "HW" related; should I try to turn on IOMMU in qemu?):
>> kasan: KernelAddressSanitizer initialized
>> ...
>> zram: module verification failed: signature and/or required key 
>> missing - tainting kernel
>> zram: Added device: zram0
>> zram0: detected capacity change from 0 to 2097152
>> EXT4-fs (zram0): mounting ext2 file system using the ext4 subsystem
>> EXT4-fs (zram0): mounted filesystem without journal. Quota mode: none.
>> EXT4-fs warning (device zram0): ext4_end_bio:343: I/O error 10 writing 
>> to inode 16386 starting block 159744)
>> Buffer I/O error on device zram0, logical block 159744
>> Buffer I/O error on device zram0, logical block 159745
> 
> 
> 
> They all occur to me like a zram failure. The installer apparently 
> creates an ext2 FS and after it mounts it using ext4 module, the issue 
> starts occurring.
> 
> Any tests I/you could run on 5.19 to exercise zram and ext2? Otherwise I 
> am unable to reproduce easily, except using the openSUSE installer :/.

Ah, now I can. It's easy when one lowers memory available to qemu. -m 
800M in this case:
echo $((1000*1024*1024)) > /sys/block/zram0/disksize
mkfs.ext2 /dev/zram0
mount /dev/zram0 /mnt/a/
dd if=/dev/urandom of=/mnt/a/stuff
[  200.334277][    T8] EXT4-fs warning (device zram0): ext4_end_bio:343: 
I/O error 10 writing to inode 12 starting block 8192)
[  200.340198][    T8] Buffer I/O error on device zram0, logical block 8192


So currently, I blame:
commit e7be8d1dd983156bbdd22c0319b71119a8fbb697
Author: Alexey Romanov <avromanov@sberdevices.ru>
Date:   Thu May 12 20:23:07 2022 -0700

     zram: remove double compression logic


/me needs to confirm.

> Any other ideas? Or is this known already?
> 
> ¹⁾ main are uefi boot and virtio-blk (it likely happens with virtio-scsi 
> too). The cmdline _I_ use: qemu-kvm -device intel-hda -device hda-duplex 
> -drive file=/tmp/pokus.qcow2,if=none,id=hd -device 
> virtio-blk-pci,drive=hd -drive 
> if=pflash,format=raw,unit=0,readonly=on,file=/usr/share/qemu/ovmf-x86_64-opensuse-code.bin -drive if=pflash,format=raw,unit=1,file=/tmp/vars.bin -cdrom /tmp/cd1.iso  -m 1G -smp 1 -net user -net nic,model=virtio -serial pty -device virtio-rng-pci -device qemu-xhci,p2=4,p3=4 -usbdevice tablet
> 
> 
> thanks,

-- 
js
suse labs

Re: ext2/zram issue [was: Linux 5.19]

[Jiri Slaby]

On 09. 08. 22, 9:59, Jiri Slaby wrote:
> Ah, now I can. It's easy when one lowers memory available to qemu. -m 
> 800M in this case:
> echo $((1000*1024*1024)) > /sys/block/zram0/disksize
> mkfs.ext2 /dev/zram0
> mount /dev/zram0 /mnt/a/
> dd if=/dev/urandom of=/mnt/a/stuff
> [  200.334277][    T8] EXT4-fs warning (device zram0): ext4_end_bio:343: 
> I/O error 10 writing to inode 12 starting block 8192)
> [  200.340198][    T8] Buffer I/O error on device zram0, logical block 8192
> 
> 
> So currently, I blame:
> commit e7be8d1dd983156bbdd22c0319b71119a8fbb697
> Author: Alexey Romanov <avromanov@sberdevices.ru>
> Date:   Thu May 12 20:23:07 2022 -0700
> 
>      zram: remove double compression logic
> 
> 
> /me needs to confirm.

With that commit reverted, I see no more I/O errors, only oom-killer 
messages (which is OK IMO, provided I write 1G of urandom on a machine 
w/ 800M of RAM):
[   30.424603][  T728] dd invoked oom-killer: 
gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=0

Now let me submit it to openQA too...

thanks,
-- 
js
suse labs

Re: ext2/zram issue [was: Linux 5.19]

[Sergey Senozhatsky]

On (22/08/09 10:12), Jiri Slaby wrote:
> > So currently, I blame:
> > commit e7be8d1dd983156bbdd22c0319b71119a8fbb697
> > Author: Alexey Romanov <avromanov@sberdevices.ru>
> > Date:   Thu May 12 20:23:07 2022 -0700
> > 
> >      zram: remove double compression logic
> > 
> > 
> > /me needs to confirm.
> 
> With that commit reverted, I see no more I/O errors, only oom-killer
> messages (which is OK IMO, provided I write 1G of urandom on a machine w/
> 800M of RAM):

Hmm... So handle allocation always succeeds in the slow path? (when we
try to allocate it second time)

Re: ext2/zram issue [was: Linux 5.19]

[Sergey Senozhatsky]

On (22/08/09 17:43), Sergey Senozhatsky wrote:
> On (22/08/09 10:12), Jiri Slaby wrote:
> > > So currently, I blame:
> > > commit e7be8d1dd983156bbdd22c0319b71119a8fbb697
> > > Author: Alexey Romanov <avromanov@sberdevices.ru>
> > > Date:   Thu May 12 20:23:07 2022 -0700
> > > 
> > >      zram: remove double compression logic
> > > 
> > > 
> > > /me needs to confirm.
> > 
> > With that commit reverted, I see no more I/O errors, only oom-killer
> > messages (which is OK IMO, provided I write 1G of urandom on a machine w/
> > 800M of RAM):
> 
> Hmm... So handle allocation always succeeds in the slow path? (when we
> try to allocate it second time)

Yeah I can see how handle re-allocation with direct reclaim can make it more
successful, but in exchange it oom-kills some user-space process, I suppose.
Is oom-kill really a good alternative though?

Re: ext2/zram issue [was: Linux 5.19]

[Lukas Czerner]

On Tue, Aug 09, 2022 at 08:03:11AM +0200, Jiri Slaby wrote:
> Hi,
> 
> On 31. 07. 22, 23:43, Linus Torvalds wrote:
> > 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.
> 
> Note: I originally reported this downstream for tracking at:
> https://bugzilla.suse.com/show_bug.cgi?id=1202203
> 
> 5.19 behaves pretty weird in openSUSE's openQA (opposing to 5.18, or
> 5.18.15). It's all qemu-kvm "HW"¹⁾:
> https://openqa.opensuse.org/tests/2502148
> loop2: detected capacity change from 0 to 72264
> EXT4-fs warning (device zram0): ext4_end_bio:343: I/O error 10 writing to
> inode 57375 starting block 137216)
> Buffer I/O error on device zram0, logical block 137216
> Buffer I/O error on device zram0, logical block 137217
> ...
> SQUASHFS error: xz decompression failed, data probably corrupt
> SQUASHFS error: Failed to read block 0x2e41680: -5
> SQUASHFS error: xz decompression failed, data probably corrupt
> SQUASHFS error: Failed to read block 0x2e41680: -5
> Bus error
> 
> 
> 
> https://openqa.opensuse.org/tests/2502145
> FS-Cache: Loaded
> begin 644 ldconfig.core.pid_2094.sig_7.time_1659859442
> 
> 
> 
> https://openqa.opensuse.org/tests/2502146
> FS-Cache: Loaded
> begin 644 Xorg.bin.core.pid_3733.sig_6.time_1659858784
> 
> 
> 
> https://openqa.opensuse.org/tests/2502148
> EXT4-fs warning (device zram0): ext4_end_bio:343: I/O error 10 writing to
> inode 57375 starting block 137216)
> Buffer I/O error on device zram0, logical block 137216
> Buffer I/O error on device zram0, logical block 137217
> 
> 
> 
> https://openqa.opensuse.org/tests/2502154
> [   13.158090][  T634] FS-Cache: Loaded
> ...
> [  525.627024][    C0] sysrq: Show State
> 
> 
> 
> Those are various failures -- crashes of ldconfig, Xorg; I/O failures on
> zram; the last one is a lockup likely, something invoked sysrq after 500s
> stall.
> 
> Interestingly, I've also hit this twice locally:
> > init[1]: segfault at 18 ip 00007fb6154b4c81 sp 00007ffc243ed600 error 6 in
> libc.so.6[7fb61543f000+185000]
> > Code: 41 5f c3 66 0f 1f 44 00 00 42 f6 44 10 08 01 0f 84 04 01 00 00 48 83
> e1 fe 48 89 48 08 49 8b 47 70 49 89 5f 70 66 48 0f 6e c0 <48> 89 58 18 0f 16
> 44 24 08 48 81 fd ff 03 00 00 76 08 66 0f ef c9
> > ***  signal 11 ***
> > malloc(): unsorted double linked list corrupted
> > traps: init[1] general protection fault ip:7fb61543f8b9 sp:7ffc243ebf40
> error:0 in libc.so.6[7fb61543f000+185000]
> > Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> > CPU: 0 PID: 1 Comm: init Not tainted 5.19.0-1-default #1 openSUSE
> Tumbleweed e1df13166a33f423514290c702e43cfbb2b5b575
> 
> KASAN is not helpful either, so it's unlikely a memory corruption (unless it
> is "HW" related; should I try to turn on IOMMU in qemu?):
> > kasan: KernelAddressSanitizer initialized
> > ...
> > zram: module verification failed: signature and/or required key missing - tainting kernel
> > zram: Added device: zram0
> > zram0: detected capacity change from 0 to 2097152
> > EXT4-fs (zram0): mounting ext2 file system using the ext4 subsystem
> > EXT4-fs (zram0): mounted filesystem without journal. Quota mode: none.
> > EXT4-fs warning (device zram0): ext4_end_bio:343: I/O error 10 writing to inode 16386 starting block 159744)
> > Buffer I/O error on device zram0, logical block 159744
> > Buffer I/O error on device zram0, logical block 159745
> 
> 
> 
> They all occur to me like a zram failure. The installer apparently creates
> an ext2 FS and after it mounts it using ext4 module, the issue starts
> occurring.
> 
> Any tests I/you could run on 5.19 to exercise zram and ext2? Otherwise I am
> unable to reproduce easily, except using the openSUSE installer :/.

Hi Jiri,

I've tried a quick xfstests run on ext2 on zram and I can't see any
issues like this so far. I will run a full test and report back in case
there is anything obvious.

-Lukas

> 
> Any other ideas? Or is this known already?
> 
> ¹⁾ main are uefi boot and virtio-blk (it likely happens with virtio-scsi
> too). The cmdline _I_ use: qemu-kvm -device intel-hda -device hda-duplex
> -drive file=/tmp/pokus.qcow2,if=none,id=hd -device virtio-blk-pci,drive=hd
> -drive if=pflash,format=raw,unit=0,readonly=on,file=/usr/share/qemu/ovmf-x86_64-opensuse-code.bin
> -drive if=pflash,format=raw,unit=1,file=/tmp/vars.bin -cdrom /tmp/cd1.iso
> -m 1G -smp 1 -net user -net nic,model=virtio -serial pty -device
> virtio-rng-pci -device qemu-xhci,p2=4,p3=4 -usbdevice tablet
> 
> 
> thanks,
> -- 
> js
> suse labs
> 

Re: ext2/zram issue [was: Linux 5.19]

[Sergey Senozhatsky]

On (22/08/09 11:12), Lukas Czerner wrote:
> Hi Jiri,
> 
> I've tried a quick xfstests run on ext2 on zram and I can't see any
> issues like this so far. I will run a full test and report back in case
> there is anything obvious.

AFAICT this should be visible only when we are under memory pressure,
so that direct reclaim from zs_malloc handle allocation call makes a
difference.

Re: ext2/zram issue [was: Linux 5.19]

[Sergey Senozhatsky]

On (22/08/09 18:11), Sergey Senozhatsky wrote:
> > > > /me needs to confirm.
> > > 
> > > With that commit reverted, I see no more I/O errors, only oom-killer
> > > messages (which is OK IMO, provided I write 1G of urandom on a machine w/
> > > 800M of RAM):
> > 
> > Hmm... So handle allocation always succeeds in the slow path? (when we
> > try to allocate it second time)
> 
> Yeah I can see how handle re-allocation with direct reclaim can make it more
> successful, but in exchange it oom-kills some user-space process, I suppose.
> Is oom-kill really a good alternative though?

We likely will need to revert e7be8d1dd983 given that it has some
user visible changes. But, honestly, failing zram write vs oom-kill
a user-space is a tough choice.

Re: ext2/zram issue [was: Linux 5.19]

[Lukas Czerner]

On Tue, Aug 09, 2022 at 06:15:37PM +0900, Sergey Senozhatsky wrote:
> On (22/08/09 11:12), Lukas Czerner wrote:
> > Hi Jiri,
> > 
> > I've tried a quick xfstests run on ext2 on zram and I can't see any
> > issues like this so far. I will run a full test and report back in case
> > there is anything obvious.
> 
> AFAICT this should be visible only when we are under memory pressure,
> so that direct reclaim from zs_malloc handle allocation call makes a
> difference.
> 

True, I haven't seen the other email from Jiri, sorry about that. I can
confirm that under memory pressure it is in fact reproducible with
xfstests and also I can confirm that reverting
e7be8d1dd983156bbdd22c0319b71119a8fbb697 makes it go away.
But Jiri has a better repro already anyway.

Thanks!
-Lukas

Re: ext2/zram issue [was: Linux 5.19]

[Dmitry Rokosov]

Hello Sergey,

On Tue, Aug 09, 2022 at 06:20:04PM +0900, Sergey Senozhatsky wrote:
> On (22/08/09 18:11), Sergey Senozhatsky wrote:
> > > > > /me needs to confirm.
> > > > 
> > > > With that commit reverted, I see no more I/O errors, only oom-killer
> > > > messages (which is OK IMO, provided I write 1G of urandom on a machine w/
> > > > 800M of RAM):
> > > 
> > > Hmm... So handle allocation always succeeds in the slow path? (when we
> > > try to allocate it second time)
> > 
> > Yeah I can see how handle re-allocation with direct reclaim can make it more
> > successful, but in exchange it oom-kills some user-space process, I suppose.
> > Is oom-kill really a good alternative though?
> 
> We likely will need to revert e7be8d1dd983 given that it has some
> user visible changes. But, honestly, failing zram write vs oom-kill
> a user-space is a tough choice.

I think oom-kill is an inevitable escape from low memory situation if we
don't solve original problem with high memory consumption in the user
setup. Reclaim-based zram slow path just delays oom if memory eating
root cause is not resolved.

I totally agree with you that all patches which have visible user
degradations should be reverted, but maybe this is more user setup
problem, what do you think?

If you make the decision to revert slow path removal patch, I would
prefer to review the original patch with unneeded code removal again
if you don't mind:
https://lore.kernel.org/linux-block/20220422115959.3313-1-avromanov@sberdevices.ru/

-- 
Thank you,
Dmitry

Re: ext2/zram issue [was: Linux 5.19]

[Sergey Senozhatsky]

Hi,

On (22/08/09 10:20), Dmitry Rokosov wrote:
> I think oom-kill is an inevitable escape from low memory situation if we
> don't solve original problem with high memory consumption in the user
> setup. Reclaim-based zram slow path just delays oom if memory eating
> root cause is not resolved.
> 
> I totally agree with you that all patches which have visible user
> degradations should be reverted, but maybe this is more user setup
> problem, what do you think?

I'd go with the revert.
Jiri, are you going to send the revert patch or shall I handle it?

> If you make the decision to revert slow path removal patch, I would
> prefer to review the original patch with unneeded code removal again
> if you don't mind:
> https://lore.kernel.org/linux-block/20220422115959.3313-1-avromanov@sberdevices.ru/

Sure, we can return to it after the merge window.

Re: ext2/zram issue [was: Linux 5.19]

[Jiri Slaby]

On 09. 08. 22, 11:20, Sergey Senozhatsky wrote:
> On (22/08/09 18:11), Sergey Senozhatsky wrote:
>>>>> /me needs to confirm.
>>>>
>>>> With that commit reverted, I see no more I/O errors, only oom-killer
>>>> messages (which is OK IMO, provided I write 1G of urandom on a machine w/
>>>> 800M of RAM):
>>>
>>> Hmm... So handle allocation always succeeds in the slow path? (when we
>>> try to allocate it second time)
>>
>> Yeah I can see how handle re-allocation with direct reclaim can make it more
>> successful, but in exchange it oom-kills some user-space process, I suppose.
>> Is oom-kill really a good alternative though?
> 
> We likely will need to revert e7be8d1dd983 given that it has some
> user visible changes. But, honestly, failing zram write vs oom-kill
> a user-space is a tough choice.

Note that it OOMs only in my use case -- it's obviously too large zram 
on too low memory machine.

But the installer is different. It just creates memory pressure, yet, 
reclaim works well and is able to find memory and go on. I would say 
atomic vs non-atomic retry in the original (pre-5.19) approach makes the 
difference.

And yes, we should likely increase the memory in openQA to avoid too 
many reclaims...

PS the kernel finished building, now images are built, hence the new 
openQA run hasn't started yet. I will send the revert when it's complete 
and all green.

thanks,
-- 
js
suse labs

Re: ext2/zram issue [was: Linux 5.19]

[Jiri Slaby]

On 09. 08. 22, 14:35, Jiri Slaby wrote:
> But the installer is different. It just creates memory pressure, yet, 
> reclaim works well and is able to find memory and go on. I would say 
> atomic vs non-atomic retry in the original (pre-5.19) approach makes the 
> difference.

Sorry, I meant no-direct-reclaim (5.19) vs direct-reclaim (pre-5.19).

-- 
js
suse labs

Re: ext2/zram issue [was: Linux 5.19]

[Sergey Senozhatsky]

On (22/08/09 14:45), Jiri Slaby wrote:
> On 09. 08. 22, 14:35, Jiri Slaby wrote:
> > But the installer is different. It just creates memory pressure, yet,
> > reclaim works well and is able to find memory and go on. I would say
> > atomic vs non-atomic retry in the original (pre-5.19) approach makes the
> > difference.
> 
> Sorry, I meant no-direct-reclaim (5.19) vs direct-reclaim (pre-5.19).

Sure, I understood.

This somehow makes me scratch my head and ask if we really want to
continue using per-CPU steams. We previously (many years ago) had
a list of idle compression streams, which would do compression in
preemptible context and we would have only one zs_malloc handle
allocation path, which would do direct reclaim (when needed)

Re: ext2/zram issue [was: Linux 5.19]

[Sergey Senozhatsky]

On (22/08/09 21:57), Sergey Senozhatsky wrote:
> This somehow makes me scratch my head and ask if we really want to
> continue using per-CPU steams. We previously (many years ago) had
> a list of idle compression streams, which would do compression in
> preemptible context and we would have only one zs_malloc handle
> allocation path, which would do direct reclaim (when needed)

Scratch that, I take it back. Sorry for the noise.

Re: ext2/zram issue [was: Linux 5.19]

[Aleksey Romanov]

Hi Sergey,

On Tue, Aug 09, 2022 at 08:53:36PM +0900, Sergey Senozhatsky wrote:
> > If you make the decision to revert slow path removal patch, I would
> > prefer to review the original patch with unneeded code removal again
> > if you don't mind:
> > https://lore.kernel.org/linux-block/20220422115959.3313-1-avromanov@sberdevices.ru/
> 
> Sure, we can return to it after the merge window.

In that case, do I need to send my original patch again? 

-- 
Thank you,
Alexey

Re: ext2/zram issue [was: Linux 5.19]

[Sergey Senozhatsky]

On (22/08/09 13:15), Aleksey Romanov wrote:
> On Tue, Aug 09, 2022 at 08:53:36PM +0900, Sergey Senozhatsky wrote:
> > > If you make the decision to revert slow path removal patch, I would
> > > prefer to review the original patch with unneeded code removal again
> > > if you don't mind:
> > > https://lore.kernel.org/linux-block/20220422115959.3313-1-avromanov@sberdevices.ru/
> > 
> > Sure, we can return to it after the merge window.
> 
> In that case, do I need to send my original patch again? 

Would be nice, since the patch needs rebasing (due to zsmalloc PTR_ERR changes)

[PATCH] Revert "zram: remove double compression logic"

[Jiri Slaby]

This reverts commit e7be8d1dd983156bbdd22c0319b71119a8fbb697 as it
causes zram failures. It does not revert cleanly, PTR_ERR handling was
introduced in the meantime. This is handled by appropriate IS_ERR.

When under memory pressure, zs_malloc() can fail. Before the above
commit, the allocation was retried with direct reclaim enabled
(GFP_NOIO). After the commit, it is not -- only __GFP_KSWAPD_RECLAIM is
tried.

So when the failure occurs under memory pressure, the overlaying
filesystem such as ext2 (mounted by ext4 module in this case) can emit
failures, making the (file)system unusable:
  EXT4-fs warning (device zram0): ext4_end_bio:343: I/O error 10 writing to inode 16386 starting block 159744)
  Buffer I/O error on device zram0, logical block 159744

With direct reclaim, memory is really reclaimed and allocation succeeds,
eventually. In the worst case, the oom killer is invoked, which is
proper outcome if user sets up zram too large (in comparison to
available RAM).

This very diff doesn't apply to 5.19 (stable) cleanly (see PTR_ERR note
above). Use revert of e7be8d1dd983 directly.

Link: https://bugzilla.suse.com/show_bug.cgi?id=1202203
Fixes: e7be8d1dd983 ("zram: remove double compression logic")
Cc: stable@vger.kernel.org # 5.19
Cc: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: Alexey Romanov <avromanov@sberdevices.ru>
Cc: Dmitry Rokosov <ddrokosov@sberdevices.ru>
Cc: Lukas Czerner <lczerner@redhat.com>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 drivers/block/zram/zram_drv.c | 42 ++++++++++++++++++++++++++---------
 drivers/block/zram/zram_drv.h |  1 +
 2 files changed, 33 insertions(+), 10 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 92cb929a45b7..226ea76cc819 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -1146,14 +1146,15 @@ static ssize_t bd_stat_show(struct device *dev,
 static ssize_t debug_stat_show(struct device *dev,
 		struct device_attribute *attr, char *buf)
 {
-	int version = 2;
+	int version = 1;
 	struct zram *zram = dev_to_zram(dev);
 	ssize_t ret;
 
 	down_read(&zram->init_lock);
 	ret = scnprintf(buf, PAGE_SIZE,
-			"version: %d\n%8llu\n",
+			"version: %d\n%8llu %8llu\n",
 			version,
+			(u64)atomic64_read(&zram->stats.writestall),
 			(u64)atomic64_read(&zram->stats.miss_free));
 	up_read(&zram->init_lock);
 
@@ -1351,7 +1352,7 @@ static int __zram_bvec_write(struct zram *zram, struct bio_vec *bvec,
 {
 	int ret = 0;
 	unsigned long alloced_pages;
-	unsigned long handle = 0;
+	unsigned long handle = -ENOMEM;
 	unsigned int comp_len = 0;
 	void *src, *dst, *mem;
 	struct zcomp_strm *zstrm;
@@ -1369,6 +1370,7 @@ static int __zram_bvec_write(struct zram *zram, struct bio_vec *bvec,
 	}
 	kunmap_atomic(mem);
 
+compress_again:
 	zstrm = zcomp_stream_get(zram->comp);
 	src = kmap_atomic(page);
 	ret = zcomp_compress(zstrm, src, &comp_len);
@@ -1377,20 +1379,39 @@ static int __zram_bvec_write(struct zram *zram, struct bio_vec *bvec,
 	if (unlikely(ret)) {
 		zcomp_stream_put(zram->comp);
 		pr_err("Compression failed! err=%d\n", ret);
+		zs_free(zram->mem_pool, handle);
 		return ret;
 	}
 
 	if (comp_len >= huge_class_size)
 		comp_len = PAGE_SIZE;
-
-	handle = zs_malloc(zram->mem_pool, comp_len,
-			__GFP_KSWAPD_RECLAIM |
-			__GFP_NOWARN |
-			__GFP_HIGHMEM |
-			__GFP_MOVABLE);
-
+	/*
+	 * handle allocation has 2 paths:
+	 * a) fast path is executed with preemption disabled (for
+	 *  per-cpu streams) and has __GFP_DIRECT_RECLAIM bit clear,
+	 *  since we can't sleep;
+	 * b) slow path enables preemption and attempts to allocate
+	 *  the page with __GFP_DIRECT_RECLAIM bit set. we have to
+	 *  put per-cpu compression stream and, thus, to re-do
+	 *  the compression once handle is allocated.
+	 *
+	 * if we have a 'non-null' handle here then we are coming
+	 * from the slow path and handle has already been allocated.
+	 */
+	if (IS_ERR((void *)handle))
+		handle = zs_malloc(zram->mem_pool, comp_len,
+				__GFP_KSWAPD_RECLAIM |
+				__GFP_NOWARN |
+				__GFP_HIGHMEM |
+				__GFP_MOVABLE);
 	if (IS_ERR((void *)handle)) {
 		zcomp_stream_put(zram->comp);
+		atomic64_inc(&zram->stats.writestall);
+		handle = zs_malloc(zram->mem_pool, comp_len,
+				GFP_NOIO | __GFP_HIGHMEM |
+				__GFP_MOVABLE);
+		if (!IS_ERR((void *)handle))
+			goto compress_again;
 		return PTR_ERR((void *)handle);
 	}
 
@@ -1948,6 +1969,7 @@ static int zram_add(void)
 	if (ZRAM_LOGICAL_BLOCK_SIZE == PAGE_SIZE)
 		blk_queue_max_write_zeroes_sectors(zram->disk->queue, UINT_MAX);
 
+	blk_queue_flag_set(QUEUE_FLAG_STABLE_WRITES, zram->disk->queue);
 	ret = device_add_disk(NULL, zram->disk, zram_disk_groups);
 	if (ret)
 		goto out_cleanup_disk;
diff --git a/drivers/block/zram/zram_drv.h b/drivers/block/zram/zram_drv.h
index 158c91e54850..80c3b43b4828 100644
--- a/drivers/block/zram/zram_drv.h
+++ b/drivers/block/zram/zram_drv.h
@@ -81,6 +81,7 @@ struct zram_stats {
 	atomic64_t huge_pages_since;	/* no. of huge pages since zram set up */
 	atomic64_t pages_stored;	/* no. of pages currently stored */
 	atomic_long_t max_used_pages;	/* no. of maximum pages stored */
+	atomic64_t writestall;		/* no. of write slow paths */
 	atomic64_t miss_free;		/* no. of missed free */
 #ifdef	CONFIG_ZRAM_WRITEBACK
 	atomic64_t bd_count;		/* no. of pages in backing device */
-- 
2.37.1

Re: [PATCH] Revert "zram: remove double compression logic"

[Sergey Senozhatsky]

On (22/08/10 09:06), Jiri Slaby wrote:
> This reverts commit e7be8d1dd983156bbdd22c0319b71119a8fbb697 as it
> causes zram failures. It does not revert cleanly, PTR_ERR handling was
> introduced in the meantime. This is handled by appropriate IS_ERR.
> 
> When under memory pressure, zs_malloc() can fail. Before the above
> commit, the allocation was retried with direct reclaim enabled
> (GFP_NOIO). After the commit, it is not -- only __GFP_KSWAPD_RECLAIM is
> tried.
> 
> So when the failure occurs under memory pressure, the overlaying
> filesystem such as ext2 (mounted by ext4 module in this case) can emit
> failures, making the (file)system unusable:
>   EXT4-fs warning (device zram0): ext4_end_bio:343: I/O error 10 writing to inode 16386 starting block 159744)
>   Buffer I/O error on device zram0, logical block 159744
> 
> With direct reclaim, memory is really reclaimed and allocation succeeds,
> eventually. In the worst case, the oom killer is invoked, which is
> proper outcome if user sets up zram too large (in comparison to
> available RAM).
> 
> This very diff doesn't apply to 5.19 (stable) cleanly (see PTR_ERR note
> above). Use revert of e7be8d1dd983 directly.
> 
> Link: https://bugzilla.suse.com/show_bug.cgi?id=1202203
> Fixes: e7be8d1dd983 ("zram: remove double compression logic")
> Cc: stable@vger.kernel.org # 5.19
> Cc: Minchan Kim <minchan@kernel.org>
> Cc: Nitin Gupta <ngupta@vflare.org>
> Cc: Sergey Senozhatsky <senozhatsky@chromium.org>
> Cc: Alexey Romanov <avromanov@sberdevices.ru>
> Cc: Dmitry Rokosov <ddrokosov@sberdevices.ru>
> Cc: Lukas Czerner <lczerner@redhat.com>
> Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
> Signed-off-by: Jiri Slaby <jslaby@suse.cz>

Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>

[RESEND] Please consider name next Linux release "I love Linux" (Re: Linux 5.19)

[Zhang Boyang]

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

Re: [RESEND] Please consider name next Linux release "I love Linux" (Re: Linux 5.19)

[Baoquan He]

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
> 

Re: [RESEND] Please consider name next Linux release "I love Linux" (Re: Linux 5.19)

[Huacai Chen]

Hi, all,

On Fri, Aug 12, 2022 at 10:40 AM Baoquan He <bhe@redhat.com> 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
> >
>

Re: [RESEND] Please consider name next Linux release "I love Linux" (Re: Linux 5.19)

[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 <bhe@redhat.com> 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
> > >
> >

Re: [RESEND] Please consider name next Linux release "I love Linux" (Re: Linux 5.19)

[YanTeng Si]

在 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 <bhe@redhat.com> 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
>>>>

Re: [RESEND] Please consider name next Linux release "I love Linux" (Re: Linux 5.19)

[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
>>
> 

Re: [RESEND] Please consider name next Linux release "I love Linux" (Re: Linux 5.19)

[WANG Xuerui]

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/

Re: ext2/zram issue [was: Linux 5.19]

[Jiri Slaby]

On 30. 08. 22, 23:46, charlie39@cock.li wrote:
> Hi, I think i bumped on  the same issue on version 5.19.2 with ext4 on zram mounted on /tmp

Only 5.19.6 contains the fix.

> ```
> # sudo dmesg -T | grep ext4
> 
> [Tue Aug 30 21:41:45 2022] EXT4-fs error (device zram1): ext4_check_bdev_write_error:218: comm kworker/u8:3: Error while
> [Tue Aug 30 21:41:45 2022] EXT4-fs warning (device zram1): ext4_end_bio:347: I/O error 10 writing to inode 76 starting b
> [Tue Aug 30 21:41:45 2022] EXT4-fs warning (device zram1): ext4_end_bio:347: I/O error 10 writing to inode 76 starting b
> [Tue Aug 30 21:41:45 2022] EXT4-fs warning (device zram1): ext4_end_bio:347: I/O error 10 writing to inode 66 starting b
> [Tue Aug 30 22:07:02 2022] EXT4-fs error (device zram1): ext4_journal_check_start:83: comm ThreadPoolForeg: Detected abo
> [Tue Aug 30 22:07:02 2022] EXT4-fs (zram1): Remounting filesystem read-only
> 
> ```
> Not sure what caused it, i was just updating my arch system.
> 

-- 
js