Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: Juhyung Park <qkrwngud825@gmail.com>
Cc: Gao Xiang <xiang@kernel.org>,
	linux-erofs@lists.ozlabs.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-crypto@vger.kernel.org,
	Yann Collet <yann.collet.73@gmail.com>
Subject: Re: Weird EROFS data corruption
Date: Tue, 5 Dec 2023 15:32:06 +0800	[thread overview]
Message-ID: <d7c7ea8c-6e2f-e8d8-88c3-4952c506ed13@linux.alibaba.com> (raw)
In-Reply-To: <CAD14+f3zgwgUugjnB7UGCYh4j3iXYsvv_DJ3yvwduA1xf3xn=A@mail.gmail.com>

Hi Juhyung,

On 2023/12/4 11:41, Juhyung Park wrote:

...
> 
>>
>> - Could you share the full message about the output of `lscpu`?
> 
> Sure:
> 
> Architecture:            x86_64
>    CPU op-mode(s):        32-bit, 64-bit
>    Address sizes:         39 bits physical, 48 bits virtual
>    Byte Order:            Little Endian
> CPU(s):                  8
>    On-line CPU(s) list:   0-7
> Vendor ID:               GenuineIntel
>    BIOS Vendor ID:        Intel(R) Corporation
>    Model name:            11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz
>      BIOS Model name:     11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz None CPU
>                            @ 3.0GHz
>      BIOS CPU family:     198
>      CPU family:          6
>      Model:               140
>      Thread(s) per core:  2
>      Core(s) per socket:  4
>      Socket(s):           1
>      Stepping:            1
>      CPU(s) scaling MHz:  60%
>      CPU max MHz:         4800.0000
>      CPU min MHz:         400.0000
>      BogoMIPS:            5990.40
>      Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mc
>                           a cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss
>                           ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art
>                            arch_perfmon pebs bts rep_good nopl xtopology nonstop_
>                           tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes6
>                           4 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xt
>                           pr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_dead
>                           line_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowp
>                           refetch cpuid_fault epb cat_l2 cdp_l2 ssbd ibrs ibpb st
>                           ibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_
>                           ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid
>                            rdt_a avx512f avx512dq rdseed adx smap avx512ifma clfl
>                           ushopt clwb intel_pt avx512cd sha_ni avx512bw avx512vl
>                           xsaveopt xsavec xgetbv1 xsaves split_lock_detect dtherm
>                            ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
>                            hwp_pkg_req vnmi avx512vbmi umip pku ospke avx512_vbmi
>                           2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg tme av
>                           x512_vpopcntdq rdpid movdiri movdir64b fsrm avx512_vp2i

Sigh, I've been thinking.  Here FSRM is the most significant difference between
our environments, could you only try the following diff to see if there's any
difference anymore? (without the previous disable patch.)

diff --git a/arch/x86/lib/memmove_64.S b/arch/x86/lib/memmove_64.S
index 1b60ae81ecd8..1b52a913233c 100644
--- a/arch/x86/lib/memmove_64.S
+++ b/arch/x86/lib/memmove_64.S
@@ -41,9 +41,7 @@ SYM_FUNC_START(__memmove)
  #define CHECK_LEN	cmp $0x20, %rdx; jb 1f
  #define MEMMOVE_BYTES	movq %rdx, %rcx; rep movsb; RET
  .Lmemmove_begin_forward:
-	ALTERNATIVE_2 __stringify(CHECK_LEN), \
-		      __stringify(CHECK_LEN; MEMMOVE_BYTES), X86_FEATURE_ERMS, \
-		      __stringify(MEMMOVE_BYTES), X86_FEATURE_FSRM
+	CHECK_LEN
  
  	/*
  	 * movsq instruction have many startup latency

Thanks,
Gao Xiang

  reply	other threads:[~2023-12-05  7:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-03 16:22 Weird EROFS data corruption Juhyung Park
2023-12-03 16:52 ` Gao Xiang
2023-12-03 17:01   ` Juhyung Park
2023-12-03 17:21     ` Gao Xiang
2023-12-03 17:32       ` Juhyung Park
2023-12-04  3:28         ` Gao Xiang
2023-12-04  3:41           ` Juhyung Park
2023-12-05  7:32             ` Gao Xiang [this message]
2023-12-05 14:23               ` Juhyung Park
2023-12-05 14:34                 ` Gao Xiang
2023-12-05 14:43                   ` Juhyung Park
2023-12-06  3:11                     ` Gao Xiang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d7c7ea8c-6e2f-e8d8-88c3-4952c506ed13@linux.alibaba.com \
    --to=hsiangkao@linux.alibaba.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=qkrwngud825@gmail.com \
    --cc=xiang@kernel.org \
    --cc=yann.collet.73@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox