LKML Archive on lore.kernel.org
 help / color / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
						download: 
* Re: kernel BUG at mm/huge_memory.c:1798!
  @ 2012-12-27 16:08 82%     ` Alex Xu
  0 siblings, 0 replies; 42+ results
From: Alex Xu @ 2012-12-27 16:08 UTC (permalink / raw)
  To: Hillf Danton
  Cc: Zhouping Liu, linux-mm, linux-kernel, Ingo Molnar,
	Johannes Weiner, mgorman, hughd, Andrea Arcangeli

On 25/12/12 07:05 AM, Hillf Danton wrote:
> On Tue, Dec 25, 2012 at 12:38 PM, Zhouping Liu <zliu@redhat.com> wrote:
>> Hello all,
>>
>> I found the below kernel bug using latest mainline(637704cbc95),
>> my hardware has 2 numa nodes, and it's easy to reproduce the issue
>> using LTP test case: "# ./mmap10 -a -s -c 200":
> 
> Can you test with 5a505085f0 and 4fc3f1d66b1 reverted?
> 
> Hillf
>

(for people from mailing lists, please cc me when replying)

Same thing?

mapcount 0 page_mapcount 1
------------[ cut here ]------------
kernel BUG at mm/huge_memory.c:1798!
invalid opcode: 0000 [#1] SMP
Modules linked in: usb_storage wacom
CPU 3
Pid: 1287, comm: thunderbird Not tainted 3.8.0-rc1+ #5 HP-Pavilion
AU992AA-ABL e9262f/Indio
RIP: 0010:[<ffffffff810c12c0>]  [<ffffffff810c12c0>] 0xffffffff810c12c0
RSP: 0018:ffff880216887c58  EFLAGS: 00010297
RAX: 0000000000000001 RBX: ffffea00065d0000 RCX: 0000000000000038
RDX: 000000000000002c RSI: 0000000000000046 RDI: ffffffff818e9e34
RBP: ffff880216887cd8 R08: 000000000000000a R09: 0000000000000000
R10: 0000000000000272 R11: 0000000000000271 R12: ffff880203fbad10
R13: 00007f1160e00000 R14: 0000000000000000 R15: ffffea00065d0000
FS:  00007f1180fca740(0000) GS:ffff88022fd80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fca86e18000 CR3: 00000002168e3000 CR4: 00000000000007e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process thunderbird (pid: 1287, threadinfo ffff880216886000, task
ffff8802259c4380)
Stack:
 ffff880216887c68 ffffffff8145f284 ffff880216887cb8 ffff8801f9c24ac0
 00000000065d0000 ffff8801f9c24af0 0000000000000000 ffff880216887cf8
 0000000000000000 00000007f1160e00 0000000000000000 ffffea00065d0000
Call Trace:
 [<ffffffff8145f284>] ? 0xffffffff8145f284
 [<ffffffff810c2310>] 0xffffffff810c2310
 [<ffffffff810a69ea>] 0xffffffff810a69ea
 [<ffffffff8106bbd8>] ? 0xffffffff8106bbd8
 [<ffffffff810a7710>] 0xffffffff810a7710
 [<ffffffff810a4a1d>] 0xffffffff810a4a1d
 [<ffffffff8106e062>] ? 0xffffffff8106e062
 [<ffffffff810adf84>] ? 0xffffffff810adf84
 [<ffffffff81460952>] 0xffffffff81460952
Code: 6d 81 31 c0 8b 75 c4 83 c2 01 e8 c4 94 39 00 e9 83 fb ff ff 0f 0b
0f 0b 0f 0b f3 90 48 8b 03 a9 00 00 80 00 75 f4 e9 b6 fb ff ff <0f> 0b
0f 0b 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 49 89 d1 48
RIP  [<ffffffff810c12c0>] 0xffffffff810c12c0
 RSP <ffff880216887c58>
---[ end trace 0d442da0022ecdd1 ]---

I don't have KALLSYMS, so after running through ksymoops:

>>RIP; ffffffff810c12c0 <split_huge_page+600/610>   <=====

>>RBX; ffffea00065d0000 <phys_startup_64+ffffea00055d0000/ffffffff80000000>
>>RDI; ffffffff818e9e34 <logbuf_lock+0/4>
>>RBP; ffff880216887cd8 <phys_startup_64+ffff880215887cd8/ffffffff80000000>
>>R12; ffff880203fbad10 <phys_startup_64+ffff880202fbad10/ffffffff80000000>
>>R13; 00007f1160e00000 <phys_startup_64+7f115fe00000/ffffffff80000000>
>>R15; ffffea00065d0000 <phys_startup_64+ffffea00055d0000/ffffffff80000000>

Trace; ffffffff8145f284 <schedule+24/70>
Trace; ffffffff810c2310 <__split_huge_page_pmd+b0/1b0>
Trace; ffffffff810a69ea <unmap_single_vma+25a/700>
Trace; ffffffff8106bbd8 <futex_wake+108/130>
Trace; ffffffff810a7710 <zap_page_range+90/d0>
Trace; ffffffff810a4a1d <sys_madvise+25d/690>
Trace; ffffffff8106e062 <sys_futex+142/1a0>
Trace; ffffffff810adf84 <vm_munmap+54/70>
Trace; ffffffff81460952 <system_call_fastpath+16/1b>

Code;  ffffffff810c1295 <split_huge_page+5d5/610>
0000000000000000 <_RIP>:
Code;  ffffffff810c1295 <split_huge_page+5d5/610>
   0:   6d                        insl   (%dx),%es:(%rdi)
Code;  ffffffff810c1296 <split_huge_page+5d6/610>
   1:   81 31 c0 8b 75 c4         xorl   $0xc4758bc0,(%rcx)
Code;  ffffffff810c129c <split_huge_page+5dc/610>
   7:   83 c2 01                  add    $0x1,%edx
Code;  ffffffff810c129f <split_huge_page+5df/610>
   a:   e8 c4 94 39 00            callq  3994d3 <_RIP+0x3994d3>
Code;  ffffffff810c12a4 <split_huge_page+5e4/610>
   f:   e9 83 fb ff ff            jmpq   fffffffffffffb97
<_RIP+0xfffffffffffffb97>
Code;  ffffffff810c12a9 <split_huge_page+5e9/610>
  14:   0f 0b                     ud2
Code;  ffffffff810c12ab <split_huge_page+5eb/610>
  16:   0f 0b                     ud2
Code;  ffffffff810c12ad <split_huge_page+5ed/610>
  18:   0f 0b                     ud2
Code;  ffffffff810c12af <split_huge_page+5ef/610>
  1a:   f3 90                     pause
Code;  ffffffff810c12b1 <split_huge_page+5f1/610>
  1c:   48 8b 03                  mov    (%rbx),%rax
Code;  ffffffff810c12b4 <split_huge_page+5f4/610>
  1f:   a9 00 00 80 00            test   $0x800000,%eax
Code;  ffffffff810c12b9 <split_huge_page+5f9/610>
  24:   75 f4                     jne    1a <_RIP+0x1a>
Code;  ffffffff810c12bb <split_huge_page+5fb/610>
  26:   e9 b6 fb ff ff            jmpq   fffffffffffffbe1
<_RIP+0xfffffffffffffbe1>
Code;  ffffffff810c12c0 <split_huge_page+600/610>   <=====
  2b:   0f 0b                     ud2       <=====
Code;  ffffffff810c12c2 <split_huge_page+602/610>
  2d:   0f 0b                     ud2
Code;  ffffffff810c12c4 <split_huge_page+604/610>
  2f:   66 66 66 2e 0f 1f 84      data32 data32 nopw %cs:0x0(%rax,%rax,1)
Code;  ffffffff810c12cb <split_huge_page+60b/610>
  36:   00 00 00 00 00
Code;  ffffffff810c12d0 <do_huge_pmd_wp_page+0/840>
  3b:   55                        push   %rbp
Code;  ffffffff810c12d1 <do_huge_pmd_wp_page+1/840>
  3c:   49 89 d1                  mov    %rdx,%r9
Code;  ffffffff810c12d4 <do_huge_pmd_wp_page+4/840>
  3f:   48                        rex.W

^ permalink raw reply	[relevance 82%]

* bfq/ext4 disk IO hangs forever on resume
@ 2017-06-26  3:07 86% Alex Xu
    0 siblings, 1 reply; 42+ results
From: Alex Xu @ 2017-06-26  3:07 UTC (permalink / raw)
  To: linux-kernel, linux-ext4

Hi,

I get hangs when resuming when using bfq-mq with ext4 on 4.12-rc6+
(currently a4fd8b3accf43d407472e34403d4b0a4df5c0e71).

Steps to reproduce:
1. boot computer
2. systemctl suspend
3. wait few seconds
4. press power button
5. type "ls" into console or SSH or do anything that does disk IO

Expected results:
Command is executed.

Actual results:
Command hangs.

lockdep has no comments, but sysrq-d shows that i_mutex_dir_key and
jbd2_handle are held by multiple processes, leading me to suspect that
ext4 is at least partially involved. [0]

sysrq-w lists many blocked processes [1]

This happens consistently, every time I resume the system from
suspend-to-RAM using this configuration. Switching to noop IO scheduler
makes it stop happening. I haven't tried switching filesystems yet.

I can do more debugging (enable KASAN or whatever), but usually when I
bother doing that I find someone has already sent a patch for the issue.

Please CC me on replies.

Cheers,
Alex.

[0]

4 locks held by systemd/384:                                                                                                                                                                                                                 
 #0:  (sb_writers#3){.+.+.+}, at: [<ffffffff811b0e5f>] mnt_want_write+0x1f/0x50
 #1:  (&type->i_mutex_dir_key/1){+.+.+.}, at: [<ffffffff8119b7ce>] do_rmdir+0x15e/0x1e0
 #2:  (&type->i_mutex_dir_key){++++++}, at: [<ffffffff81195ee0>] vfs_rmdir+0x50/0x130
 #3:  (jbd2_handle){++++..}, at: [<ffffffff8124f17f>] start_this_handle+0xff/0x430
4 locks held by syncthing/279: 
 #0:  (&f->f_pos_lock){+.+.+.}, at: [<ffffffff811ade1e>] __fdget_pos+0x3e/0x50
 #1:  (sb_writers#3){.+.+.+}, at: [<ffffffff8118b04c>] vfs_write+0x17c/0x1d0
 #2:  (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<ffffffff81217977>] ext4_file_write_iter+0x57/0x350
 #3:  (jbd2_handle){++++..}, at: [<ffffffff8124f17f>] start_this_handle+0xff/0x430
2 locks held by zsh/238:
 #0:  (&tty->ldisc_sem){++++.+}, at: [<ffffffff816fbeaf>] ldsem_down_read+0x1f/0x30
 #1:  (&ldata->atomic_read_lock){+.+...}, at: [<ffffffff8134fbb0>] n_tty_read+0xb0/0x8b0
2 locks held by sddm-greeter/267:
 #0:  (sb_writers#3){.+.+.+}, at: [<ffffffff811b0e5f>] mnt_want_write+0x1f/0x50
 #1:  (&type->i_mutex_dir_key){++++++}, at: [<ffffffff8119a698>] path_openat+0x2d8/0xa10
2 locks held by kworker/u16:28/330:
 #0:  ("events_unbound"){.+.+.+}, at: [<ffffffff810a1ef3>] process_one_work+0x1c3/0x420
 #1:  ((&entry->work)){+.+.+.}, at: [<ffffffff810a1ef3>] process_one_work+0x1c3/0x420
1 lock held by zsh/382:
 #0:  (&sig->cred_guard_mutex){+.+.+.}, at: [<ffffffff81192570>] prepare_bprm_creds+0x30/0x70

[1]

  task                        PC stack   pid father
systemd         D    0   384      0 0x00000000   
Call Trace:
 __schedule+0x295/0x7c0
 ? bit_wait+0x50/0x50
 ? bit_wait+0x50/0x50
 schedule+0x31/0x80
 io_schedule+0x11/0x40
 bit_wait_io+0xc/0x50
 __wait_on_bit+0x53/0x80
 ? bit_wait+0x50/0x50
 out_of_line_wait_on_bit+0x6e/0x80
 ? autoremove_wake_function+0x30/0x30
 do_get_write_access+0x20b/0x420
 jbd2_journal_get_write_access+0x2c/0x60
 __ext4_journal_get_write_access+0x55/0xa0
 ext4_delete_entry+0x8c/0x140
 ? __ext4_journal_start_sb+0x4e/0xa0
 ext4_rmdir+0x114/0x250
 vfs_rmdir+0x6e/0x130
 do_rmdir+0x1a3/0x1e0
 SyS_unlinkat+0x1d/0x30
 entry_SYSCALL_64_fastpath+0x18/0xad
jbd2/sda1-8     D    0    81      2 0x00000000   
Call Trace:
 __schedule+0x295/0x7c0
 ? bit_wait+0x50/0x50
 schedule+0x31/0x80
 io_schedule+0x11/0x40
 bit_wait_io+0xc/0x50
 __wait_on_bit+0x53/0x80
 ? bit_wait+0x50/0x50
 out_of_line_wait_on_bit+0x6e/0x80
 ? autoremove_wake_function+0x30/0x30
 __wait_on_buffer+0x2d/0x30
 jbd2_journal_commit_transaction+0xe6a/0x1700
 kjournald2+0xc8/0x270
 ? kjournald2+0xc8/0x270
 ? wake_atomic_t_function+0x50/0x50
 kthread+0xfe/0x130
 ? commit_timeout+0x10/0x10
 ? kthread_create_on_node+0x40/0x40
 ret_from_fork+0x27/0x40
[ more processes follow, some different tracebacks ]

^ permalink raw reply	[relevance 86%]

* Re: bfq/ext4 disk IO hangs forever on resume
  @ 2017-08-18 20:29 99%   ` Alex Xu
  0 siblings, 0 replies; 42+ results
From: Alex Xu @ 2017-08-18 20:29 UTC (permalink / raw)
  To: Ming Lei, Jens Axboe
  Cc: Linux Kernel Mailing List, open list:EXT4 FILE SYSTEM

On Tue, 25 Jul 2017 20:18:07 +0800
Ming Lei <tom.leiming@gmail.com> wrote as excerpted:

> On Mon, Jun 26, 2017 at 11:07 AM, Alex Xu <alex_y_xu@yahoo.ca> wrote:
> > Hi,
> >
> > I get hangs when resuming when using bfq-mq with ext4 on 4.12-rc6+
> > (currently a4fd8b3accf43d407472e34403d4b0a4df5c0e71).  
> 
> Please test the following patch to see if it can help your issue:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/commit/?h=for-linus&id=765e40b675a9566459ddcb8358ad16f3b8344bbe
> 

I tried 4.13-rc3+ (including that commit) and still have (seemingly)
the same issue.

^ permalink raw reply	[relevance 99%]

* [PATCH] mm: fix z3fold warnings on CONFIG_SMP=n
@ 2018-09-27 20:27 99% Alex Xu (Hello71)
    0 siblings, 1 reply; 42+ results
From: Alex Xu (Hello71) @ 2018-09-27 20:27 UTC (permalink / raw)
  To: linux-mm, linux-kernel; +Cc: ddstreet

Spinlocks are always lockable on UP systems, even if they were just
locked.

Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
 mm/z3fold.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/mm/z3fold.c b/mm/z3fold.c
index 4b366d181..4e6ad2de4 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -202,6 +202,13 @@ static inline void z3fold_page_lock(struct z3fold_header *zhdr)
 	spin_lock(&zhdr->page_lock);
 }
 
+static inline void z3fold_page_ensure_locked(struct z3fold_header *zhdr)
+{
+#ifdef CONFIG_SMP
+	WARN_ON(z3fold_page_trylock(zhdr));
+#endif
+}
+
 /* Try to lock a z3fold page */
 static inline int z3fold_page_trylock(struct z3fold_header *zhdr)
 {
@@ -277,7 +284,7 @@ static void release_z3fold_page_locked(struct kref *ref)
 {
 	struct z3fold_header *zhdr = container_of(ref, struct z3fold_header,
 						refcount);
-	WARN_ON(z3fold_page_trylock(zhdr));
+	z3fold_page_ensure_locked(zhdr);
 	__release_z3fold_page(zhdr, true);
 }
 
@@ -289,7 +296,7 @@ static void release_z3fold_page_locked_list(struct kref *ref)
 	list_del_init(&zhdr->buddy);
 	spin_unlock(&zhdr->pool->lock);
 
-	WARN_ON(z3fold_page_trylock(zhdr));
+	z3fold_page_ensure_locked(zhdr);
 	__release_z3fold_page(zhdr, true);
 }
 
@@ -403,7 +410,7 @@ static void do_compact_page(struct z3fold_header *zhdr, bool locked)
 
 	page = virt_to_page(zhdr);
 	if (locked)
-		WARN_ON(z3fold_page_trylock(zhdr));
+		z3fold_page_ensure_locked(zhdr);
 	else
 		z3fold_page_lock(zhdr);
 	if (WARN_ON(!test_and_clear_bit(NEEDS_COMPACTING, &page->private))) {
-- 
2.19.0


^ permalink raw reply	[relevance 99%]

* Re: [PATCH] mm: fix z3fold warnings on CONFIG_SMP=n
  @ 2018-09-27 21:12 99%   ` Alex Xu
  2018-09-27 21:15 99%     ` [PATCH v2] " Alex Xu (Hello71)
  0 siblings, 1 reply; 42+ results
From: Alex Xu @ 2018-09-27 21:12 UTC (permalink / raw)
  To: Dan Streetman; +Cc: Linux-MM, linux-kernel

Quoting Dan Streetman (2018-09-27 20:41:21)
> On Thu, Sep 27, 2018 at 4:27 PM Alex Xu (Hello71) <alex_y_xu@yahoo.ca> wrote:
> >
> > Spinlocks are always lockable on UP systems, even if they were just
> > locked.
> 
> i think it would be much better to just use either
> assert_spin_locked() or just spin_is_locked(), instead of an #ifdef.
> 

I wrote a longer response and then learned about the WARN_ON_SMP macro,
so I'll just use that instead.

Original response below:

I thought about using assert_spin_locked, but I wanted to keep the
existing behavior, and it seems to make sense to try to lock the page if
we forgot to lock it earlier? Maybe not though; I don't understand this
code completely. I did write a version of z3fold_page_ensure_locked with
"if (assert_spin_locked(...))" but not only did that look even worse, it
doesn't even work, because assert_spin_locked is a statement on UP
systems, not an expression. It might be worth adding a
ensure_spin_locked function that does that though...

spin_is_locked currently still always returns 0 "on CONFIG_SMP=n builds
with CONFIG_DEBUG_SPINLOCK=n", so that would just return us to the same
problem of checking CONFIG_SMP.

^ permalink raw reply	[relevance 99%]

* [PATCH v2] mm: fix z3fold warnings on CONFIG_SMP=n
  2018-09-27 21:12 99%   ` Alex Xu
@ 2018-09-27 21:15 99%     ` Alex Xu (Hello71)
  0 siblings, 0 replies; 42+ results
From: Alex Xu (Hello71) @ 2018-09-27 21:15 UTC (permalink / raw)
  To: Dan Streetman, linux-mm; +Cc: linux-kernel

Spinlocks are always lockable on UP systems, even if they were just
locked.

Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
 mm/z3fold.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/mm/z3fold.c b/mm/z3fold.c
index 4b366d181..2e8d268ac 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -277,7 +277,7 @@ static void release_z3fold_page_locked(struct kref *ref)
 {
 	struct z3fold_header *zhdr = container_of(ref, struct z3fold_header,
 						refcount);
-	WARN_ON(z3fold_page_trylock(zhdr));
+	WARN_ON_SMP(z3fold_page_trylock(zhdr));
 	__release_z3fold_page(zhdr, true);
 }
 
@@ -289,7 +289,7 @@ static void release_z3fold_page_locked_list(struct kref *ref)
 	list_del_init(&zhdr->buddy);
 	spin_unlock(&zhdr->pool->lock);
 
-	WARN_ON(z3fold_page_trylock(zhdr));
+	WARN_ON_SMP(z3fold_page_trylock(zhdr));
 	__release_z3fold_page(zhdr, true);
 }
 
@@ -403,7 +403,7 @@ static void do_compact_page(struct z3fold_header *zhdr, bool locked)
 
 	page = virt_to_page(zhdr);
 	if (locked)
-		WARN_ON(z3fold_page_trylock(zhdr));
+		WARN_ON_SMP(z3fold_page_trylock(zhdr));
 	else
 		z3fold_page_lock(zhdr);
 	if (WARN_ON(!test_and_clear_bit(NEEDS_COMPACTING, &page->private))) {
-- 
2.19.0


^ permalink raw reply	[relevance 99%]

* [PATCH net] r8169: always autoneg on resume
@ 2018-09-30  1:18 99% Alex Xu (Hello71)
  0 siblings, 0 replies; 42+ results
From: Alex Xu (Hello71) @ 2018-09-30  1:18 UTC (permalink / raw)
  To: linux-netdev; +Cc: hkallweit1, nic_swsd, davem, linux-kernel

This affects at least versions 25 and 33, so assume all cards are broken
and just renegotiate by default.

Fixes: a2965f12fde6 ("r8169: remove rtl8169_set_speed_xmii")
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
 drivers/net/ethernet/realtek/r8169.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index ab30aaeac6d3..db2f347c1463 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4072,13 +4072,12 @@ static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private *tp)
 
 	genphy_soft_reset(dev->phydev);
 
-	/* It was reported that chip version 33 ends up with 10MBit/Half on a
+	/* It was reported that several chips end up with 10MBit/Half on a
 	 * 1GBit link after resuming from S3. For whatever reason the PHY on
-	 * this chip doesn't properly start a renegotiation when soft-reset.
+	 * these chips doesn't properly start a renegotiation when soft-reset.
 	 * Explicitly requesting a renegotiation fixes this.
 	 */
-	if (tp->mac_version == RTL_GIGA_MAC_VER_33 &&
-	    dev->phydev->autoneg == AUTONEG_ENABLE)
+	if (dev->phydev->autoneg == AUTONEG_ENABLE)
 		phy_restart_aneg(dev->phydev);
 }
 
-- 
2.19.0

^ permalink raw reply	[relevance 99%]

* [PATCH net v2] r8169: always autoneg on resume
@ 2018-09-30 15:06 99% Alex Xu (Hello71)
    0 siblings, 1 reply; 42+ results
From: Alex Xu (Hello71) @ 2018-09-30 15:06 UTC (permalink / raw)
  To: netdev; +Cc: hkallweit1, nic_swsd, davem, linux-kernel

This affects at least versions 25 and 33, so assume all cards are broken
and just renegotiate by default.

Fixes: 10bc6a6042c9 ("r8169: fix autoneg issue on resume with RTL8168E")
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
 drivers/net/ethernet/realtek/r8169.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index ab30aaeac6d3..db2f347c1463 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4072,13 +4072,12 @@ static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private *tp)
 
 	genphy_soft_reset(dev->phydev);
 
-	/* It was reported that chip version 33 ends up with 10MBit/Half on a
+	/* It was reported that several chips end up with 10MBit/Half on a
 	 * 1GBit link after resuming from S3. For whatever reason the PHY on
-	 * this chip doesn't properly start a renegotiation when soft-reset.
+	 * these chips doesn't properly start a renegotiation when soft-reset.
 	 * Explicitly requesting a renegotiation fixes this.
 	 */
-	if (tp->mac_version == RTL_GIGA_MAC_VER_33 &&
-	    dev->phydev->autoneg == AUTONEG_ENABLE)
+	if (dev->phydev->autoneg == AUTONEG_ENABLE)
 		phy_restart_aneg(dev->phydev);
 }
 
-- 
2.19.0

^ permalink raw reply	[relevance 99%]

* Re: [PATCH net v2] r8169: always autoneg on resume
  @ 2018-09-30 22:30 99%   ` Alex Xu
    0 siblings, 1 reply; 42+ results
From: Alex Xu @ 2018-09-30 22:30 UTC (permalink / raw)
  To: Daan Wendelen; +Cc: netdev, hkallweit1, nic_swsd, davem, linux-kernel

Quoting Daan Wendelen (2018-09-30 22:17:51)
> Hi Alex,
> 
> I randomly opened your patch even though I have absolutely no idea what this patch is about, but I
> found a mistake in one of the comments:
> 
> On Sun, Sep 30, 2018 at 11:06:39AM -0400, Alex Xu (Hello71) wrote:
> > This affects at least versions 25 and 33, so assume all cards are broken
>                      ...
> >        * 1GBit link after resuming from S3. For whatever reason the PHY on
> > -      * this chip doesn't properly start a renegotiation when soft-reset.
> > +      * these chips doesn't properly start a renegotiation when soft-reset.
>                        ~~~~~~~ 
> I believe it should be "these chips don't"
> 
> With kind regards,
> Daan

The grammar is correct as is. The subject of the sentence is "the PHY",
which is singular. However, I think it should be "the PHYs" instead,
assuming that they are different.

^ permalink raw reply	[relevance 99%]

* Re: [PATCH net v2] r8169: always autoneg on resume
  @ 2018-10-01  3:31 99%       ` Alex Xu
  0 siblings, 0 replies; 42+ results
From: Alex Xu @ 2018-10-01  3:31 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Daan Wendelen, netdev, hkallweit1, nic_swsd, davem, linux-kernel

Quoting Andrew Lunn (2018-10-01 02:39:47)
> I keep reading the patch wrong, so here is the end state:
> 
>         /* It was reported that several chips end up with 10MBit/Half on a
>          * 1GBit link after resuming from S3. For whatever reason the PHY on
>          * these chips doesn't properly start a renegotiation when soft-reset.
>          * Explicitly requesting a renegotiation fixes this.
>          */
> 
> I would also say 'don't'. For me the subject is 'PHY on these chips',
> which is plural.
> 
> However:
> 
> For whatever reason the PHY, on these chips, doesn't properly start a
> renegotiation when soft-reset.
> 
> Now just 'the PHY' is the subject, so singular.
> 
> But i'm just a native speaker who never actually learnt the rules of
> grammar, it just sounds right or wrong, and i have no idea why.

No. Ending in a plural noun doesn't make a noun phrase plural.

Example 1: The boy with the books is walking.
Example 2: The women on the roof are waving.

In these cases, "with" and "on" introduce prepositional phrases
which are subordinate to the noun phrase. The subjects are "boy" and
"women" respectively; the books are not walking, and the roof is not
waving.

In fact, this can be clearly seen by drawing a parse tree, which should
hopefully be a familiar tool to all programmers.

Furthermore, the addition of commas in these cases is not correct (hey,
another example!); the phrases are essential, so commas may not be used.

Regardless, this is highly off-topic, so I think further replies can go
off-list.

^ permalink raw reply	[relevance 99%]

* r8169 only works in promisc mode
@ 2019-03-09  2:16 99% Alex Xu (Hello71)
    2019-03-23  1:26 91% ` Alex Xu
  0 siblings, 2 replies; 42+ results
From: Alex Xu (Hello71) @ 2019-03-09  2:16 UTC (permalink / raw)
  To: netdev, linux-kernel

After suspending, my r8169 (not actually 8169, just that driver) only 
receives packets when in promiscuous mode. I have tried disabling all 
offload features except highdma [fixed], and it doesn't fix the issue.

I am using torvalds/linux, compiled about two days ago (not sure which 
commit). I think this happened after a recent upgrade (some time in the 
past week). Given the long testing cycle, I don't really want to bisect; 
I am hoping someone has some idea of where the issue could be.

Please CC me on replies.

Thanks,
Alex.

^ permalink raw reply	[relevance 99%]

* Re: r8169 only works in promisc mode
  @ 2019-03-09 16:53 99%   ` Alex Xu
  0 siblings, 0 replies; 42+ results
From: Alex Xu @ 2019-03-09 16:53 UTC (permalink / raw)
  To: Heiner Kallweit, linux-kernel, netdev

Quoting Heiner Kallweit (2019-03-09 09:33:40)
> On 09.03.2019 03:16, Alex Xu (Hello71) wrote:
> > After suspending, my r8169 (not actually 8169, just that driver) only 
> > receives packets when in promiscuous mode. I have tried disabling all 
> > offload features except highdma [fixed], and it doesn't fix the issue.
> > 
> > I am using torvalds/linux, compiled about two days ago (not sure which 
> > commit). I think this happened after a recent upgrade (some time in the 
> > past week). Given the long testing cycle, I don't really want to bisect; 
> > I am hoping someone has some idea of where the issue could be.
> > 
> The provided information isn't enough to say anything. Please create a
> bug ticket in bugzilla. Needed information:
> - Last working and first failing kernel version (as reported by uname -a)
> - Is 5.0 ok?
> - Full dmesg log
> - lspci -vv output for the network card
> - If the issue happens only after resume from suspend, diff of the
>   chip registers (ethtool -d) before and after suspend.
> - Does removing / reloading the r8169 module fix the issue?
> 
> > Please CC me on replies.
> > 
> > Thanks,
> > Alex.
> > 
> Heiner

I filed bug 202851 with some of the requested information.

Alex.

^ permalink raw reply	[relevance 99%]

* Re: r8169 only works in promisc mode
  2019-03-09  2:16 99% r8169 only works in promisc mode Alex Xu (Hello71)
  @ 2019-03-23  1:26 91% ` Alex Xu
  1 sibling, 0 replies; 42+ results
From: Alex Xu @ 2019-03-23  1:26 UTC (permalink / raw)
  To: linux-kernel, netdev; +Cc: gnomes

I have done some more investigation, some of which I posted on the
Bugzilla bug.

I believe the promisc issue is due to the MAC address receive filter
being silently reset to the invalid burned-in address. I used wireshark
and determined that the outgoing MAC address after suspend is the
overridden value. Re-setting the overridden value with "ip link set eth0
address" appears to have no effect. Setting it to a different overridden
value works normally and resolves the packet loss issue. Removing the
module and re-inserting it also resolves the issue.

I also attempted to determine why the MAC address on boot is
8e:00:00:00:8e:8e. As far as I can tell, this value is burned into the
flash somewhere. I tried turning off the machine, unplugging the power,
pressing the power button several times, then plugging it back in and
immediately booting into Windows; the incorrect MAC address was shown.

This reminded me that I am experiencing another firmware-related issue,
namely that it appears that the machine is only able to reach S1 or
possibly S2 sleep mode, even when specifying S3, and even in Windows. I
think there may be some flash bitrot, but clearing the firmware
settings, by all of: in the interface, removing the battery, and setting
the jumper; had no effect. I also tried reinstalling the BIOS using the
vendor-provided Windows updater, which also had no effect.

In conclusion: I think my firmware is broken (even moreso than regular
PC firmware), but I believe there is in fact some bug with r8169 on
"RTL8211B" in 5.0-rc1.

I can try bisecting if someone more competent than me believes that
would be helpful.

Thanks,
Alex.

^ permalink raw reply	[relevance 91%]

* shmem_recalc_inode: unable to handle kernel NULL pointer dereference
@ 2019-03-24 15:30 99% Alex Xu (Hello71)
    0 siblings, 1 reply; 42+ results
From: Alex Xu (Hello71) @ 2019-03-24 15:30 UTC (permalink / raw)
  To: linux-mm, linux-kernel
  Cc: Vineeth Remanan Pillai, Kelley Nielsen, Huang Ying, Hugh Dickins,
	Rik van Riel, Andrew Morton

I get this BUG in 5.1-rc1 sometimes when powering off the machine. I 
suspect my setup erroneously executes two swapoff+cryptsetup close 
operations simultaneously, so a race condition is triggered.

I am using a single swap on a plain dm-crypt device on a MBR partition 
on a SATA drive.

I think the problem is probably related to 
b56a2d8af9147a4efe4011b60d93779c0461ca97, so CCing the related people.

Thanks,
Alex.

^ permalink raw reply	[relevance 99%]

* Re: shmem_recalc_inode: unable to handle kernel NULL pointer dereference
  @ 2019-03-31 16:15 99%   ` Alex Xu (Hello71)
  0 siblings, 0 replies; 42+ results
From: Alex Xu (Hello71) @ 2019-03-31 16:15 UTC (permalink / raw)
  To: Vineeth Pillai
  Cc: Andrew Morton, Hugh Dickins, Kelley Nielsen, linux-kernel,
	linux-mm, Rik van Riel, Huang Ying

Excerpts from Vineeth Pillai's message of March 25, 2019 6:08 pm:
> On Sun, Mar 24, 2019 at 11:30 AM Alex Xu (Hello71) <alex_y_xu@yahoo.ca> wrote:
>>
>> I get this BUG in 5.1-rc1 sometimes when powering off the machine. I
>> suspect my setup erroneously executes two swapoff+cryptsetup close
>> operations simultaneously, so a race condition is triggered.
>>
>> I am using a single swap on a plain dm-crypt device on a MBR partition
>> on a SATA drive.
>>
>> I think the problem is probably related to
>> b56a2d8af9147a4efe4011b60d93779c0461ca97, so CCing the related people.
>>
> Could you please provide more information on this - stack trace, dmesg etc?
> Is it easily reproducible? If yes, please detail the steps so that I
> can try it inhouse.
> 
> Thanks,
> Vineeth
> 

Some info from the BUG entry (I didn't bother to type it all, 
low-quality image available upon request):

BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
#PF error: [normal kernel read fault]
PGD 0 P4D 0
Oops: 0000 [#1] SMP
CPU: 0 Comm: swapoff Not tainted 5.1.0-rc1+ #2
RIP: 0010:shmem_recalc_inode+0x41/0x90

Call Trace:
? shmem_undo_range
? rb_erase_cached
? set_next_entity
? __inode_wait_for_writeback
? shmem_truncate_range
? shmem_evict_inode
? evict
? shmem_unuse
? try_to_unuse
? swapcache_free_entries
? _cond_resched
? __se_sys_swapoff
? do_syscall_64
? entry_SYSCALL_64_after_hwframe

As I said, it only occurs occasionally on shutdown. I think it is a safe 
guess that it can only occur when the swap is not empty, but possibly 
other conditions are necessary, so I will test further.

^ permalink raw reply	[relevance 99%]

* [PATCH] treewide: fix awk regexp over-escaping
@ 2019-04-30  2:17 84% Alex Xu (Hello71)
  0 siblings, 0 replies; 42+ results
From: Alex Xu (Hello71) @ 2019-04-30  2:17 UTC (permalink / raw)
  To: linux-kernel
  Cc: x86, jpoimboe, peterz, hpa, masami.hiramatsu.pt, ben-linux,
	adrian.hunter, Alex Xu (Hello71)

Fix "warning: regexp escape sequence is not a known regexp operator" on
gawk 5.0.0.

Results found by:

- grepping '\\[^\[\\^$.|?*+()a-z]' on *.awk
- grepping 'awk.*\\[^\[\\^$.|?*+()a-z]'
- running awk --lint -f </dev/null >/dev/null on *.awk

Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
 Documentation/arm/Samsung/clksrc-change-registers.awk  | 2 +-
 arch/x86/tools/gen-insn-attr-x86.awk                   | 4 ++--
 lib/raid6/unroll.awk                                   | 2 +-
 tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk     | 4 ++--
 tools/perf/arch/x86/tests/gen-insn-x86-dat.awk         | 2 +-
 tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk | 4 ++--
 6 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/Documentation/arm/Samsung/clksrc-change-registers.awk b/Documentation/arm/Samsung/clksrc-change-registers.awk
index 7be1b8aa7cd9..d853f750c861 100755
--- a/Documentation/arm/Samsung/clksrc-change-registers.awk
+++ b/Documentation/arm/Samsung/clksrc-change-registers.awk
@@ -67,7 +67,7 @@ BEGIN {
 # to replace and create an associative array of values
 
     while (getline line < ARGV[1] > 0) {
-	if (line ~ /\#define.*_MASK/ &&
+	if (line ~ /#define.*_MASK/ &&
 	    !(line ~ /USB_SIG_MASK/)) {
 	    splitdefine(line, fields)
 	    name = fields[0]
diff --git a/arch/x86/tools/gen-insn-attr-x86.awk b/arch/x86/tools/gen-insn-attr-x86.awk
index b02a36b2c14f..a42015b305f4 100644
--- a/arch/x86/tools/gen-insn-attr-x86.awk
+++ b/arch/x86/tools/gen-insn-attr-x86.awk
@@ -69,7 +69,7 @@ BEGIN {
 
 	lprefix1_expr = "\\((66|!F3)\\)"
 	lprefix2_expr = "\\(F3\\)"
-	lprefix3_expr = "\\((F2|!F3|66\\&F2)\\)"
+	lprefix3_expr = "\\((F2|!F3|66&F2)\\)"
 	lprefix_expr = "\\((66|F2|F3)\\)"
 	max_lprefix = 4
 
@@ -257,7 +257,7 @@ function convert_operands(count,opnd,       i,j,imm,mod)
 	return add_flags(imm, mod)
 }
 
-/^[0-9a-f]+\:/ {
+/^[0-9a-f]+:/ {
 	if (NR == 1)
 		next
 	# get index
diff --git a/lib/raid6/unroll.awk b/lib/raid6/unroll.awk
index c6aa03631df8..0809805a7e23 100644
--- a/lib/raid6/unroll.awk
+++ b/lib/raid6/unroll.awk
@@ -13,7 +13,7 @@ BEGIN {
 	for (i = 0; i < rep; ++i) {
 		tmp = $0
 		gsub(/\$\$/, i, tmp)
-		gsub(/\$\#/, n, tmp)
+		gsub(/\$#/, n, tmp)
 		gsub(/\$\*/, "$", tmp)
 		print tmp
 	}
diff --git a/tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk b/tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk
index b02a36b2c14f..a42015b305f4 100644
--- a/tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk
+++ b/tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk
@@ -69,7 +69,7 @@ BEGIN {
 
 	lprefix1_expr = "\\((66|!F3)\\)"
 	lprefix2_expr = "\\(F3\\)"
-	lprefix3_expr = "\\((F2|!F3|66\\&F2)\\)"
+	lprefix3_expr = "\\((F2|!F3|66&F2)\\)"
 	lprefix_expr = "\\((66|F2|F3)\\)"
 	max_lprefix = 4
 
@@ -257,7 +257,7 @@ function convert_operands(count,opnd,       i,j,imm,mod)
 	return add_flags(imm, mod)
 }
 
-/^[0-9a-f]+\:/ {
+/^[0-9a-f]+:/ {
 	if (NR == 1)
 		next
 	# get index
diff --git a/tools/perf/arch/x86/tests/gen-insn-x86-dat.awk b/tools/perf/arch/x86/tests/gen-insn-x86-dat.awk
index a21454835cd4..27585d032ee6 100644
--- a/tools/perf/arch/x86/tests/gen-insn-x86-dat.awk
+++ b/tools/perf/arch/x86/tests/gen-insn-x86-dat.awk
@@ -31,7 +31,7 @@ BEGIN {
 	going = 0
 }
 
-/^\s*[0-9a-fA-F]+\:/ {
+/^\s*[0-9a-fA-F]+:/ {
 	if (going) {
 		colon_pos = index($0, ":")
 		useful_line = substr($0, colon_pos + 1)
diff --git a/tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk b/tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk
index ddd5c4c21129..606ccd154392 100644
--- a/tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk
+++ b/tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk
@@ -69,7 +69,7 @@ BEGIN {
 
 	lprefix1_expr = "\\((66|!F3)\\)"
 	lprefix2_expr = "\\(F3\\)"
-	lprefix3_expr = "\\((F2|!F3|66\\&F2)\\)"
+	lprefix3_expr = "\\((F2|!F3|66&F2)\\)"
 	lprefix_expr = "\\((66|F2|F3)\\)"
 	max_lprefix = 4
 
@@ -257,7 +257,7 @@ function convert_operands(count,opnd,       i,j,imm,mod)
 	return add_flags(imm, mod)
 }
 
-/^[0-9a-f]+\:/ {
+/^[0-9a-f]+:/ {
 	if (NR == 1)
 		next
 	# get index
-- 
2.21.0


^ permalink raw reply	[relevance 84%]

* [REGRESSION] ptrace broken from "cgroup: cgroup v2 freezer" (76f969e)
@ 2019-05-13  1:20 83% Alex Xu (Hello71)
  0 siblings, 0 replies; 42+ results
From: Alex Xu (Hello71) @ 2019-05-13  1:20 UTC (permalink / raw)
  To: linux-kernel, tj, guro; +Cc: oleg, kernel-team

Hi,

I was trying to use strace recently and found that it exhibited some 
strange behavior. I produced this minimal test case:

#include <unistd.h>

int main() {
    write(1, "a", 1);
    return 0;
}

which, when run using "gcc test.c && strace ./a.out" produces this 
strace output:

[ pre-main omitted ]
write(1, "a", 1)                        = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
write(1, "a", 1)                        = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
write(1, "a", 1)                        = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
write(1, "a", 1)                        = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
write(1, "a", 1)                        = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
write(1, "a", 1)                        = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
[ repeats forever ]

The correct result is of course:

[ pre-main omitted ]
write(1, "a", 1)                        = 1
exit_group(0)                           = ?
+++ exited with 0 +++

Strangely, this only occurs when outputting to a tty-like output. 
Running "strace ./a.out" from a native Linux x86 console or a terminal 
emulator causes the abnormal behavior. However, the following commands 
work correctly:

- strace ./a.out >/dev/null
- strace ./a.out >/tmp/a # /tmp is a standard tmpfs
- strace ./a.out >&- # causes -1 EBADF (Bad file descriptor)

"strace -o /tmp/a ./a.out" hangs and produces the above (infinite) 
output to /tmp/a.

I bisected this to 76f969e, "cgroup: cgroup v2 freezer". I reverted the 
entire patchset (reverting only that one caused a conflict), which 
resolved the issue. I skimmed the patch and came up with this 
workaround, which also resolves the issue. I am not at all clear on the 
technical workings of the patchset, but it seems to me like a process's 
frozen status is supposed to be "suspended" when a frozen process is 
ptraced, and "unsuspended" when ptracing ends. Therefore, it seems 
suspicious to always "enter frozen" whether or not the cgroup is 
actually frozen. It seems like the code should instead check if the 
cgroup is actually frozen, and if so, restore the frozen status.

I am using systemd but not any other cgroup features. I tried in an 
initramfs environment (no systemd, /init -> shell script) and reproduced 
the failing test case.

Please CC me on replies.

Thanks,
Alex.

---
 kernel/signal.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/signal.c b/kernel/signal.c
index 62f9aea4a15a..47145d9d89ca 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2110,7 +2110,7 @@ static void ptrace_stop(int exit_code, int why, int clear_code, kernel_siginfo_t
                preempt_disable();
                read_unlock(&tasklist_lock);
                preempt_enable_no_resched();
-               cgroup_enter_frozen();
+               //cgroup_enter_frozen();
                freezable_schedule();
        } else {
                /*
@@ -2289,7 +2289,7 @@ static bool do_signal_stop(int signr)
                }
 
                /* Now we don't run again until woken by SIGCONT or SIGKILL */
-               cgroup_enter_frozen();
+               //cgroup_enter_frozen();
                freezable_schedule();
                return true;
        } else {
-- 
2.21.0

^ permalink raw reply	[relevance 83%]

* Re: [bugreport] kernel 5.2 pblk bad header/extent: invalid extent entries
  @ 2019-05-18 18:59 99%   ` Alex Xu (Hello71)
  0 siblings, 0 replies; 42+ results
From: Alex Xu (Hello71) @ 2019-05-18 18:59 UTC (permalink / raw)
  To: linux-ext4, Linux List Kernel Mailing, Mikhail Gavrilov

Excerpts from Mikhail Gavrilov's message of May 18, 2019 7:07 am:
> On Sat, 18 May 2019 at 11:44, Mikhail Gavrilov
> <mikhail.v.gavrilov@gmail.com> wrote:
>> [28616.429757] EXT4-fs error (device nvme0n1p2): ext4_find_extent:908:
>> inode #8: comm jbd2/nvme0n1p2-: pblk 23101439 bad header/extent:
>> invalid extent entries - magic f30a, entries 8, max 340(340), depth
>> 0(0)


I had a similar problem today:

EXT4-fs error (device dm-0): ext4_find_extent:908: inode #8: comm jbd2/dm-0-8: pblk 117997567 bad header/extent: invalid extent entries - magic f30a, entries 8, max 340(340), depth 0(0)

I am using dm-crypt on SATA disk.

^ permalink raw reply	[relevance 99%]

* [PATCH] treewide: fix awk regexp over-escaping
@ 2019-05-18 19:53 84% Alex Xu (Hello71)
  0 siblings, 0 replies; 42+ results
From: Alex Xu (Hello71) @ 2019-05-18 19:53 UTC (permalink / raw)
  To: linux-kernel
  Cc: x86, jpoimboe, peterz, hpa, masami.hiramatsu.pt, ben-linux,
	adrian.hunter, Alex Xu (Hello71)

Fix "warning: regexp escape sequence is not a known regexp operator" on
gawk 5.0.0.

Results found by:

- grepping '\\[^\[\\^$.|?*+()a-z]' on *.awk
- grepping 'awk.*\\[^\[\\^$.|?*+()a-z]'
- running awk --lint -f </dev/null >/dev/null on *.awk

Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
 Documentation/arm/Samsung/clksrc-change-registers.awk  | 2 +-
 arch/x86/tools/gen-insn-attr-x86.awk                   | 4 ++--
 lib/raid6/unroll.awk                                   | 2 +-
 tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk     | 4 ++--
 tools/perf/arch/x86/tests/gen-insn-x86-dat.awk         | 2 +-
 tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk | 4 ++--
 6 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/Documentation/arm/Samsung/clksrc-change-registers.awk b/Documentation/arm/Samsung/clksrc-change-registers.awk
index 7be1b8aa7cd9..d853f750c861 100755
--- a/Documentation/arm/Samsung/clksrc-change-registers.awk
+++ b/Documentation/arm/Samsung/clksrc-change-registers.awk
@@ -67,7 +67,7 @@ BEGIN {
 # to replace and create an associative array of values
 
     while (getline line < ARGV[1] > 0) {
-	if (line ~ /\#define.*_MASK/ &&
+	if (line ~ /#define.*_MASK/ &&
 	    !(line ~ /USB_SIG_MASK/)) {
 	    splitdefine(line, fields)
 	    name = fields[0]
diff --git a/arch/x86/tools/gen-insn-attr-x86.awk b/arch/x86/tools/gen-insn-attr-x86.awk
index b02a36b2c14f..a42015b305f4 100644
--- a/arch/x86/tools/gen-insn-attr-x86.awk
+++ b/arch/x86/tools/gen-insn-attr-x86.awk
@@ -69,7 +69,7 @@ BEGIN {
 
 	lprefix1_expr = "\\((66|!F3)\\)"
 	lprefix2_expr = "\\(F3\\)"
-	lprefix3_expr = "\\((F2|!F3|66\\&F2)\\)"
+	lprefix3_expr = "\\((F2|!F3|66&F2)\\)"
 	lprefix_expr = "\\((66|F2|F3)\\)"
 	max_lprefix = 4
 
@@ -257,7 +257,7 @@ function convert_operands(count,opnd,       i,j,imm,mod)
 	return add_flags(imm, mod)
 }
 
-/^[0-9a-f]+\:/ {
+/^[0-9a-f]+:/ {
 	if (NR == 1)
 		next
 	# get index
diff --git a/lib/raid6/unroll.awk b/lib/raid6/unroll.awk
index c6aa03631df8..0809805a7e23 100644
--- a/lib/raid6/unroll.awk
+++ b/lib/raid6/unroll.awk
@@ -13,7 +13,7 @@ BEGIN {
 	for (i = 0; i < rep; ++i) {
 		tmp = $0
 		gsub(/\$\$/, i, tmp)
-		gsub(/\$\#/, n, tmp)
+		gsub(/\$#/, n, tmp)
 		gsub(/\$\*/, "$", tmp)
 		print tmp
 	}
diff --git a/tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk b/tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk
index b02a36b2c14f..a42015b305f4 100644
--- a/tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk
+++ b/tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk
@@ -69,7 +69,7 @@ BEGIN {
 
 	lprefix1_expr = "\\((66|!F3)\\)"
 	lprefix2_expr = "\\(F3\\)"
-	lprefix3_expr = "\\((F2|!F3|66\\&F2)\\)"
+	lprefix3_expr = "\\((F2|!F3|66&F2)\\)"
 	lprefix_expr = "\\((66|F2|F3)\\)"
 	max_lprefix = 4
 
@@ -257,7 +257,7 @@ function convert_operands(count,opnd,       i,j,imm,mod)
 	return add_flags(imm, mod)
 }
 
-/^[0-9a-f]+\:/ {
+/^[0-9a-f]+:/ {
 	if (NR == 1)
 		next
 	# get index
diff --git a/tools/perf/arch/x86/tests/gen-insn-x86-dat.awk b/tools/perf/arch/x86/tests/gen-insn-x86-dat.awk
index a21454835cd4..27585d032ee6 100644
--- a/tools/perf/arch/x86/tests/gen-insn-x86-dat.awk
+++ b/tools/perf/arch/x86/tests/gen-insn-x86-dat.awk
@@ -31,7 +31,7 @@ BEGIN {
 	going = 0
 }
 
-/^\s*[0-9a-fA-F]+\:/ {
+/^\s*[0-9a-fA-F]+:/ {
 	if (going) {
 		colon_pos = index($0, ":")
 		useful_line = substr($0, colon_pos + 1)
diff --git a/tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk b/tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk
index ddd5c4c21129..606ccd154392 100644
--- a/tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk
+++ b/tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk
@@ -69,7 +69,7 @@ BEGIN {
 
 	lprefix1_expr = "\\((66|!F3)\\)"
 	lprefix2_expr = "\\(F3\\)"
-	lprefix3_expr = "\\((F2|!F3|66\\&F2)\\)"
+	lprefix3_expr = "\\((F2|!F3|66&F2)\\)"
 	lprefix_expr = "\\((66|F2|F3)\\)"
 	max_lprefix = 4
 
@@ -257,7 +257,7 @@ function convert_operands(count,opnd,       i,j,imm,mod)
 	return add_flags(imm, mod)
 }
 
-/^[0-9a-f]+\:/ {
+/^[0-9a-f]+:/ {
 	if (NR == 1)
 		next
 	# get index
-- 
2.21.0


^ permalink raw reply	[relevance 84%]

* [PATCH] crypto: ux500 - fix license comment syntax error
@ 2019-06-01 14:49 99% Alex Xu (Hello71)
    0 siblings, 1 reply; 42+ results
From: Alex Xu (Hello71) @ 2019-06-01 14:49 UTC (permalink / raw)
  To: linux-kernel, linux-crypto, tglx
  Cc: allison, alexios.zavras, swinslow, rfontana, gregkh, linux-spdx,
	torvalds, Alex Xu (Hello71)

Causes error: drivers/crypto/ux500/cryp/Makefile:5: *** missing
separator.  Stop.

Fixes: af873fcecef5 ("treewide: Replace GPLv2 boilerplate/reference with
SPDX - rule 194")

Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
 drivers/crypto/ux500/cryp/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/ux500/cryp/Makefile b/drivers/crypto/ux500/cryp/Makefile
index a90b50597e5c..3e67531f484c 100644
--- a/drivers/crypto/ux500/cryp/Makefile
+++ b/drivers/crypto/ux500/cryp/Makefile
@@ -2,7 +2,7 @@
 #/*
 # * Copyright (C) ST-Ericsson SA 2010
 # * Author: shujuan.chen@stericsson.com for ST-Ericsson.
- */
+# */
 
 ccflags-$(CONFIG_CRYPTO_DEV_UX500_DEBUG) += -DDEBUG
 
-- 
2.21.0


^ permalink raw reply	[relevance 99%]

* Re: [PATCH] crypto: ux500 - fix license comment syntax error
  @ 2019-06-01 19:41 99%   ` Alex Xu
  0 siblings, 0 replies; 42+ results
From: Alex Xu @ 2019-06-01 19:41 UTC (permalink / raw)
  To: Greg KH
  Cc: linux-kernel, linux-crypto, tglx, allison, alexios.zavras,
	swinslow, rfontana, linux-spdx, torvalds

Quoting Greg KH (2019-06-01 16:29:07)
> On Sat, Jun 01, 2019 at 10:49:43AM -0400, Alex Xu (Hello71) wrote:
> > Causes error: drivers/crypto/ux500/cryp/Makefile:5: *** missing
> > separator.  Stop.
> > 
> > Fixes: af873fcecef5 ("treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 194")
> > Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
> > ---
> >  drivers/crypto/ux500/cryp/Makefile | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Also, how did 0-day not catch this?  Is this an odd configuration that
> it can not build?

I had to run "make clean" to get the error.

^ permalink raw reply	[relevance 99%]

* [PATCH] random: print a message when waiting for random
@ 2019-07-24 22:33 94% Alex Xu (Hello71)
  0 siblings, 0 replies; 42+ results
From: Alex Xu (Hello71) @ 2019-07-24 22:33 UTC (permalink / raw)
  To: linux-kernel, tytso; +Cc: arnd, gregkh, Alex Xu (Hello71)

- many programs now use getrandom on startup, including for cases which
  may not be security-sensitive (e.g. hash tables)
- boot times are faster than ever with the widespread use of high-speed
  SSD storage
- no major distributions currently use RNDADDENTROPY ioctl when
  restoring the random seed, including systemd and OpenRC. systemd may
  add this functionality soon
  (https://github.com/systemd/systemd/pull/13137) but it seems to have
  some special requirements (systemd-boot) and/or require special
  opt-in.
- despite the availability of virtio-rng, many hosts do not offer it,
  and many/most distributions do not configure rngd by default

in combination, many programs (e.g. sshd, gdm) now block on startup,
sometimes for many minutes. in the kernel, we can't fix this easily, but
we should at least notify users why their program is stuck.

Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
 drivers/char/random.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 5d5ea4ce1442..e4490c6c9c84 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -511,6 +511,8 @@ static struct ratelimit_state unseeded_warning =
 	RATELIMIT_STATE_INIT("warn_unseeded_randomness", HZ, 3);
 static struct ratelimit_state urandom_warning =
 	RATELIMIT_STATE_INIT("warn_urandom_randomness", HZ, 3);
+static struct ratelimit_state wait_for_random_warning =
+	RATELIMIT_STATE_INIT("warn_wait_for_random", HZ, 3);
 
 static int ratelimit_disable __read_mostly;
 
@@ -1745,6 +1747,9 @@ int wait_for_random_bytes(void)
 {
 	if (likely(crng_ready()))
 		return 0;
+	if (__ratelimit(&wait_for_random_warning))
+		pr_info("random: %s: waiting for randomness\n",
+		       current->comm);
 	return wait_event_interruptible(crng_init_wait, crng_ready());
 }
 EXPORT_SYMBOL(wait_for_random_bytes);
@@ -1901,6 +1906,7 @@ int __init rand_initialize(void)
 	if (ratelimit_disable) {
 		urandom_warning.interval = 0;
 		unseeded_warning.interval = 0;
+		wait_for_random_warning.interval = 0;
 	}
 	return 0;
 }
-- 
2.22.0


^ permalink raw reply	[relevance 94%]

* [PATCH] kbuild: move -pipe to global KBUILD_CFLAGS
       [not found]     <20200222003820.220854-1-alex_y_xu.ref@yahoo.ca>
@ 2020-02-22  0:38 62% ` Alex Xu (Hello71)
    0 siblings, 1 reply; 42+ results
From: Alex Xu (Hello71) @ 2020-02-22  0:38 UTC (permalink / raw)
  To: linux-kbuild, michal.lkml, masahiroy
  Cc: linux-kernel, Russell King, Alex Xu (Hello71)

-pipe reduces unnecessary disk wear for systems where /tmp is not a
tmpfs, slightly increases compilation speed, and avoids leaving behind
files when gcc crashes.

According to the gcc manual, "this fails to work on some systems where
the assembler is unable to read from a pipe; but the GNU assembler has
no trouble". We already require GNU ld on all platforms, so this is not
an additional dependency. LLVM as also supports pipes.

-pipe has always been used for most architectures, this change
standardizes it globally. Most notably, arm, arm64, riscv, and x86 are
affected.

Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
 Makefile               | 2 +-
 arch/alpha/Makefile    | 2 +-
 arch/arc/Makefile      | 2 +-
 arch/arm/Makefile      | 1 -
 arch/csky/Makefile     | 1 -
 arch/ia64/Makefile     | 2 +-
 arch/m68k/Makefile     | 2 +-
 arch/mips/Makefile     | 2 +-
 arch/nios2/Makefile    | 2 +-
 arch/openrisc/Makefile | 2 +-
 arch/parisc/Makefile   | 2 +-
 arch/powerpc/Makefile  | 2 +-
 arch/s390/Makefile     | 2 +-
 arch/sh/Makefile       | 2 +-
 arch/sparc/Makefile    | 4 ++--
 arch/xtensa/Makefile   | 2 +-
 16 files changed, 15 insertions(+), 17 deletions(-)

diff --git a/Makefile b/Makefile
index aab38cb02b24..782c12267151 100644
--- a/Makefile
+++ b/Makefile
@@ -459,7 +459,7 @@ KBUILD_CFLAGS   := -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs \
 		   -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE \
 		   -Werror=implicit-function-declaration -Werror=implicit-int \
 		   -Wno-format-security \
-		   -std=gnu89
+		   -std=gnu89 -pipe
 KBUILD_CPPFLAGS := -D__KERNEL__
 KBUILD_AFLAGS_KERNEL :=
 KBUILD_CFLAGS_KERNEL :=
diff --git a/arch/alpha/Makefile b/arch/alpha/Makefile
index 12dee59b011c..b40a9be72d9b 100644
--- a/arch/alpha/Makefile
+++ b/arch/alpha/Makefile
@@ -12,7 +12,7 @@ NM := $(NM) -B
 
 LDFLAGS_vmlinux	:= -static -N #-relax
 CHECKFLAGS	+= -D__alpha__
-cflags-y	:= -pipe -mno-fp-regs -ffixed-8
+cflags-y	:= -mno-fp-regs -ffixed-8
 cflags-y	+= $(call cc-option, -fno-jump-tables)
 
 cpuflags-$(CONFIG_ALPHA_EV4)		:= -mcpu=ev4
diff --git a/arch/arc/Makefile b/arch/arc/Makefile
index 20e9ab6cc521..b6a2f553771c 100644
--- a/arch/arc/Makefile
+++ b/arch/arc/Makefile
@@ -9,7 +9,7 @@ ifeq ($(CROSS_COMPILE),)
 CROSS_COMPILE := $(call cc-cross-prefix, arc-linux- arceb-linux-)
 endif
 
-cflags-y	+= -fno-common -pipe -fno-builtin -mmedium-calls -D__linux__
+cflags-y	+= -fno-common -fno-builtin -mmedium-calls -D__linux__
 cflags-$(CONFIG_ISA_ARCOMPACT)	+= -mA7
 cflags-$(CONFIG_ISA_ARCV2)	+= -mcpu=hs38
 
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index db857d07114f..7711467e0797 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -21,7 +21,6 @@ KBUILD_LDS_MODULE	+= $(srctree)/arch/arm/kernel/module.lds
 endif
 
 GZFLAGS		:=-9
-#KBUILD_CFLAGS	+=-pipe
 
 # Never generate .eh_frame
 KBUILD_CFLAGS	+= $(call cc-option,-fno-dwarf2-cfi-asm)
diff --git a/arch/csky/Makefile b/arch/csky/Makefile
index fb1bbbd91954..3ba8d936122c 100644
--- a/arch/csky/Makefile
+++ b/arch/csky/Makefile
@@ -42,7 +42,6 @@ KBUILD_CFLAGS += -msoft-float -mdiv
 KBUILD_CFLAGS += -fno-tree-vectorize
 endif
 
-KBUILD_CFLAGS += -pipe
 ifeq ($(CSKYABI),abiv2)
 KBUILD_CFLAGS += -mno-stack-size
 endif
diff --git a/arch/ia64/Makefile b/arch/ia64/Makefile
index 32240000dc0c..554dc20873d8 100644
--- a/arch/ia64/Makefile
+++ b/arch/ia64/Makefile
@@ -24,7 +24,7 @@ KBUILD_LDS_MODULE += $(srctree)/arch/ia64/module.lds
 KBUILD_AFLAGS_KERNEL := -mconstant-gp
 EXTRA		:=
 
-cflags-y	:= -pipe $(EXTRA) -ffixed-r13 -mfixed-range=f12-f15,f32-f127 \
+cflags-y	:= $(EXTRA) -ffixed-r13 -mfixed-range=f12-f15,f32-f127 \
 		   -falign-functions=32 -frename-registers -fno-optimize-sibling-calls
 KBUILD_CFLAGS_KERNEL := -mconstant-gp
 
diff --git a/arch/m68k/Makefile b/arch/m68k/Makefile
index 5d9288384096..99a226bbd06c 100644
--- a/arch/m68k/Makefile
+++ b/arch/m68k/Makefile
@@ -60,7 +60,7 @@ cpuflags-$(CONFIG_M5206)	:= $(call cc-option,-mcpu=5206,-m5200)
 KBUILD_AFLAGS += $(cpuflags-y)
 KBUILD_CFLAGS += $(cpuflags-y)
 
-KBUILD_CFLAGS += -pipe -ffreestanding
+KBUILD_CFLAGS += -ffreestanding
 
 ifdef CONFIG_MMU
 # without -fno-strength-reduce the 53c7xx.c driver fails ;-(
diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index e1c44aed8156..05eb77328a13 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -95,7 +95,7 @@ all-$(CONFIG_SYS_SUPPORTS_ZBOOT)+= vmlinuz
 # machines may also.  Since BFD is incredibly buggy with respect to
 # crossformat linking we rely on the elf2ecoff tool for format conversion.
 #
-cflags-y			+= -G 0 -mno-abicalls -fno-pic -pipe
+cflags-y			+= -G 0 -mno-abicalls -fno-pic
 cflags-y			+= -msoft-float
 LDFLAGS_vmlinux			+= -G 0 -static -n -nostdlib
 KBUILD_AFLAGS_MODULE		+= -mlong-calls
diff --git a/arch/nios2/Makefile b/arch/nios2/Makefile
index 52c03e60b114..3205cb5fd143 100644
--- a/arch/nios2/Makefile
+++ b/arch/nios2/Makefile
@@ -24,7 +24,7 @@ LIBGCC         := $(shell $(CC) $(KBUILD_CFLAGS) $(KCFLAGS) -print-libgcc-file-n
 
 KBUILD_AFLAGS += -march=r$(CONFIG_NIOS2_ARCH_REVISION)
 
-KBUILD_CFLAGS += -pipe -D__linux__ -D__ELF__
+KBUILD_CFLAGS += -D__linux__ -D__ELF__
 KBUILD_CFLAGS += -march=r$(CONFIG_NIOS2_ARCH_REVISION)
 KBUILD_CFLAGS += $(if $(CONFIG_NIOS2_HW_MUL_SUPPORT),-mhw-mul,-mno-hw-mul)
 KBUILD_CFLAGS += $(if $(CONFIG_NIOS2_HW_MULX_SUPPORT),-mhw-mulx,-mno-hw-mulx)
diff --git a/arch/openrisc/Makefile b/arch/openrisc/Makefile
index bf10141c7426..86075fc673d9 100644
--- a/arch/openrisc/Makefile
+++ b/arch/openrisc/Makefile
@@ -22,7 +22,7 @@ KBUILD_DEFCONFIG := or1ksim_defconfig
 OBJCOPYFLAGS    := -O binary -R .note -R .comment -S
 LIBGCC 		:= $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
 
-KBUILD_CFLAGS	+= -pipe -ffixed-r10 -D__linux__
+KBUILD_CFLAGS	+= -ffixed-r10 -D__linux__
 
 ifeq ($(CONFIG_OPENRISC_HAVE_INST_MUL),y)
 	KBUILD_CFLAGS += $(call cc-option,-mhard-mul)
diff --git a/arch/parisc/Makefile b/arch/parisc/Makefile
index dca8f2de8cf5..88bee828400d 100644
--- a/arch/parisc/Makefile
+++ b/arch/parisc/Makefile
@@ -64,7 +64,7 @@ endif
 
 OBJCOPY_FLAGS =-O binary -R .note -R .comment -S
 
-cflags-y	:= -pipe
+cflags-y	:=
 
 # These flags should be implied by an hppa-linux configuration, but they
 # are not in gcc 3.2.
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index f35730548e42..0550b976157c 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -215,7 +215,7 @@ asinstr := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1)
 KBUILD_CPPFLAGS	+= -I $(srctree)/arch/$(ARCH) $(asinstr)
 KBUILD_AFLAGS	+= $(AFLAGS-y)
 KBUILD_CFLAGS	+= $(call cc-option,-msoft-float)
-KBUILD_CFLAGS	+= -pipe $(CFLAGS-y)
+KBUILD_CFLAGS	+= $(CFLAGS-y)
 CPP		= $(CC) -E $(KBUILD_CFLAGS)
 
 CHECKFLAGS	+= -m$(BITS) -D__powerpc__ -D__powerpc$(BITS)__
diff --git a/arch/s390/Makefile b/arch/s390/Makefile
index e0e3a465bbfd..3ca3e3a29864 100644
--- a/arch/s390/Makefile
+++ b/arch/s390/Makefile
@@ -118,7 +118,7 @@ endif
 cfi := $(call as-instr,.cfi_startproc\n.cfi_val_offset 15$(comma)-160\n.cfi_endproc,-DCONFIG_AS_CFI_VAL_OFFSET=1)
 
 KBUILD_CFLAGS	+= -mbackchain -msoft-float $(cflags-y)
-KBUILD_CFLAGS	+= -pipe -Wno-sign-compare
+KBUILD_CFLAGS	+= -Wno-sign-compare
 KBUILD_CFLAGS	+= -fno-asynchronous-unwind-tables $(cfi)
 KBUILD_AFLAGS	+= $(aflags-y) $(cfi)
 export KBUILD_AFLAGS_DECOMPRESSOR
diff --git a/arch/sh/Makefile b/arch/sh/Makefile
index b4a86f27e048..2e224b2a436b 100644
--- a/arch/sh/Makefile
+++ b/arch/sh/Makefile
@@ -194,7 +194,7 @@ drivers-$(CONFIG_OPROFILE)	+= arch/sh/oprofile/
 cflags-y	+= $(foreach d, $(cpuincdir-y), -I $(srctree)/arch/sh/include/$(d)) \
 		   $(foreach d, $(machdir-y), -I $(srctree)/arch/sh/include/$(d))
 
-KBUILD_CFLAGS		+= -pipe $(cflags-y)
+KBUILD_CFLAGS		+= $(cflags-y)
 KBUILD_CPPFLAGS		+= $(cflags-y)
 KBUILD_AFLAGS		+= $(cflags-y)
 
diff --git a/arch/sparc/Makefile b/arch/sparc/Makefile
index 4a0919581697..ad30e7e668e0 100644
--- a/arch/sparc/Makefile
+++ b/arch/sparc/Makefile
@@ -29,7 +29,7 @@ UTS_MACHINE    := sparc
 # versions of gcc.  Some gcc versions won't pass -Av8 to binutils when you
 # give -mcpu=v8.  This silently worked with older bintutils versions but
 # does not any more.
-KBUILD_CFLAGS  += -m32 -mcpu=v8 -pipe -mno-fpu -fcall-used-g5 -fcall-used-g7
+KBUILD_CFLAGS  += -m32 -mcpu=v8 -mno-fpu -fcall-used-g5 -fcall-used-g7
 KBUILD_CFLAGS  += -Wa,-Av8
 
 KBUILD_AFLAGS  += -m32 -Wa,-Av8
@@ -44,7 +44,7 @@ KBUILD_LDFLAGS := -m elf64_sparc
 export BITS   := 64
 UTS_MACHINE   := sparc64
 
-KBUILD_CFLAGS += -m64 -pipe -mno-fpu -mcpu=ultrasparc -mcmodel=medlow
+KBUILD_CFLAGS += -m64 -mno-fpu -mcpu=ultrasparc -mcmodel=medlow
 KBUILD_CFLAGS += -ffixed-g4 -ffixed-g5 -fcall-used-g7 -Wno-sign-compare
 KBUILD_CFLAGS += -Wa,--undeclared-regs
 KBUILD_CFLAGS += $(call cc-option,-mtune=ultrasparc3)
diff --git a/arch/xtensa/Makefile b/arch/xtensa/Makefile
index 67a7d151d1e7..fdaa588c504c 100644
--- a/arch/xtensa/Makefile
+++ b/arch/xtensa/Makefile
@@ -42,7 +42,7 @@ export PLATFORM
 
 # temporarily until string.h is fixed
 KBUILD_CFLAGS += -ffreestanding -D__linux__
-KBUILD_CFLAGS += -pipe -mlongcalls -mtext-section-literals
+KBUILD_CFLAGS += -mlongcalls -mtext-section-literals
 KBUILD_CFLAGS += $(call cc-option,-mforce-no-pic,)
 KBUILD_CFLAGS += $(call cc-option,-mno-serialize-volatile,)
 
-- 
2.25.1


^ permalink raw reply	[relevance 62%]

* Re: [PATCH] kbuild: move -pipe to global KBUILD_CFLAGS
  @ 2020-02-22  4:01 79%     ` Alex Xu (Hello71)
    0 siblings, 1 reply; 42+ results
From: Alex Xu (Hello71) @ 2020-02-22  4:01 UTC (permalink / raw)
  To: Nathan Chancellor
  Cc: Russell King, linux-kbuild, linux-kernel, masahiroy, michal.lkml

Excerpts from Nathan Chancellor's message of February 21, 2020 9:16 pm:
> Hi Alex,
> 
> On Fri, Feb 21, 2020 at 07:38:20PM -0500, Alex Xu (Hello71) wrote:
>> -pipe reduces unnecessary disk wear for systems where /tmp is not a
>> tmpfs, slightly increases compilation speed, and avoids leaving behind
>> files when gcc crashes.
>> 
>> According to the gcc manual, "this fails to work on some systems where
>> the assembler is unable to read from a pipe; but the GNU assembler has
>> no trouble". We already require GNU ld on all platforms, so this is not
>> an additional dependency. LLVM as also supports pipes.
>> 
>> -pipe has always been used for most architectures, this change
>> standardizes it globally. Most notably, arm, arm64, riscv, and x86 are
>> affected.
>> 
>> Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
> 
> Do you have any numbers to show this is actually beneficial from a
> compilation time perspective? I ask because I saw an improvement in
> compilation time when removing -pipe from x86's KBUILD_CFLAGS in
> commit 437e88ab8f9e ("x86/build: Remove -pipe from KBUILD_CFLAGS").
> 
> For what it's worth, clang ignores -pipe so this does not actually
> matter for its integrated assembler.
> 
> That type of change could have been a fluke but I guarantee people
> will care more about any change in compilation time than any of the
> other things that you mention so it might be wise to check on major
> architectures to make sure that it doesn't hurt.
> 
> Cheers,
> Nathan
> 

Sorry, I should've checked the performance first. I have now run:

cd /tmp/linux # previously: make O=/tmp/linux
export MAKEFLAGS=12 # Ryzen 1600, 6 cores, 12 threads
make allnoconfig
for i in {1..10}; do
    make clean >/dev/null
    time make XPIPE=-pipe >/dev/null
    make clean >/dev/null
    time make >/dev/null
done

after patching -pipe to $(XPIPE) in Makefile.

Results (without ld warnings):

make > /dev/null  130.54s user 10.41s system 969% cpu 14.537 total
make XPIPE=-pipe > /dev/null  129.83s user 9.95s system 977% cpu 14.296 total
make > /dev/null  129.73s user 10.28s system 966% cpu 14.493 total
make XPIPE=-pipe > /dev/null  130.04s user 10.63s system 986% cpu 14.252 total
make > /dev/null  129.53s user 10.28s system 972% cpu 14.379 total
make XPIPE=-pipe > /dev/null  130.29s user 10.17s system 983% cpu 14.288 total
make > /dev/null  130.19s user 10.52s system 968% cpu 14.530 total
make XPIPE=-pipe > /dev/null  129.90s user 10.47s system 978% cpu 14.343 total
make > /dev/null  129.50s user 10.81s system 959% cpu 14.620 total
make XPIPE=-pipe > /dev/null  130.37s user 10.60s system 975% cpu 14.446 total
make > /dev/null  129.63s user 10.18s system 972% cpu 14.374 total
make XPIPE=-pipe > /dev/null  131.29s user 9.92s system 1016% cpu 13.899 total
make > /dev/null  129.96s user 10.39s system 961% cpu 14.596 total
make XPIPE=-pipe > /dev/null  131.63s user 10.16s system 1011% cpu 14.015 total
make > /dev/null  129.33s user 10.54s system 970% cpu 14.405 total
make XPIPE=-pipe > /dev/null  129.70s user 10.40s system 976% cpu 14.349 total
make > /dev/null  129.53s user 10.25s system 964% cpu 14.494 total
make XPIPE=-pipe > /dev/null  130.38s user 10.62s system 973% cpu 14.479 total
make > /dev/null  130.73s user 10.08s system 957% cpu 14.704 total
make XPIPE=-pipe > /dev/null  130.43s user 10.62s system 985% cpu 14.309 total
make > /dev/null  130.54s user 10.41s system 969% cpu 14.537 total

There is a fair bit of variance, probably due to cpufreq, schedutil, CPU 
temperature, CPU scheduler, motherboard power delivery, etc. But, I 
think it can be clearly seen that -pipe is, on average, about 0.1 to 0.2 
seconds faster.

I also tried "make defconfig":

make > /dev/null  1238.26s user 102.39s system 1095% cpu 2:02.33 total
make XPIPE=-pipe > /dev/null  1231.33s user 102.52s system 1081% cpu 2:03.29 total
make > /dev/null  1232.92s user 102.07s system 1096% cpu 2:01.71 total
make XPIPE=-pipe > /dev/null  1239.59s user 102.30s system 1096% cpu 2:02.39 total
make > /dev/null  1229.81s user 101.72s system 1093% cpu 2:01.74 total
make XPIPE=-pipe > /dev/null  1234.64s user 101.30s system 1098% cpu 2:01.64 total
make > /dev/null  1228.50s user 104.39s system 1093% cpu 2:01.91 total
make XPIPE=-pipe > /dev/null  1238.78s user 102.57s system 1099% cpu 2:01.99 total
make > /dev/null  1238.26s user 102.39s system 1095% cpu 2:02.33 total

I stopped after this because I needed to use the machine for other 
tasks. The results are less clear, but I think there's not a big 
difference one way or another, at least on my machine.

CPU: Ryzen 1600, overclocked to ~3.8 GHz
RAM: Corsair Vengeance, overclocked to ~3300 MHz, forgot timings
Motherboard: ASRock B450 Pro4

I would speculate that the recent pipe changes have caused a change in 
the relative speed compared to 2018. I am using 5.6.0-rc2 with -O3 
-march=native patches.

Regards,
Alex.

^ permalink raw reply	[relevance 79%]

* Re: [PATCH] kbuild: move -pipe to global KBUILD_CFLAGS
  @ 2020-02-22 14:24 99%         ` Alex Xu (Hello71)
  0 siblings, 0 replies; 42+ results
From: Alex Xu (Hello71) @ 2020-02-22 14:24 UTC (permalink / raw)
  To: Nathan Chancellor
  Cc: Russell King, linux-kbuild, linux-kernel, masahiroy, michal.lkml

Excerpts from Nathan Chancellor's message of February 22, 2020 3:01 am:
> I used hyperfine [1] to run a quick benchmark with a freshly built
> GCC 9.2.0 for x86 and aarch64 and here are the results:
> 
> In both cases it seems like performance regresses (by 1% but still) but
> maybe it is my machine, even though this benchmark was done on a
> different machine than the one from my commit back in 2018.
> 
> I am not sure I would write off these results, since I did the benchmark
> 25 times on each one back to back, eliminating most of the variance that
> you described.
> 
> [1]: https://github.com/sharkdp/hyperfine
> 
> Cheers,
> Nathan
> 

What kernel version are you running? Do you have the 5.6 pipe reworks?

^ permalink raw reply	[relevance 99%]

* Bad rss-counter state from drm/ttm, drm/vmwgfx: Support huge TTM pagefaults
       [not found]     <1586138158.v5u7myprlp.none.ref@localhost>
@ 2020-04-06 19:51 99% ` Alex Xu (Hello71)
    0 siblings, 1 reply; 42+ results
From: Alex Xu (Hello71) @ 2020-04-06 19:51 UTC (permalink / raw)
  To: linux-mm, dri-devel, linux-kernel, thomas_os
  Cc: pv-drivers, linux-graphics-maintainer, Andrew Morton,
	Michal Hocko, Matthew Wilcox (Oracle),
	Kirill A. Shutemov, Ralph Campbell, Jérôme Glisse,
	Christian König, Dan Williams, Roland Scheidegger

Using 314b658 with amdgpu, starting sway and firefox causes "BUG: Bad 
rss-counter state" and "BUG: non-zero pgtables_bytes on freeing mm" to 
start filling dmesg, and then closing programs causes more BUGs and 
hangs, and then everything grinds to a halt (can't start more programs, 
can't even reboot through systemd).

Using master and reverting that branch up to that point fixes the 
problem.

I'm using a Ryzen 1600 and AMD Radeon RX 480 on an ASRock B450 Pro4 
board with IOMMU enabled.

^ permalink raw reply	[relevance 99%]

* Re: Bad rss-counter state from drm/ttm, drm/vmwgfx: Support huge TTM pagefaults
  @ 2020-04-07  0:38 99%     ` Alex Xu (Hello71)
    0 siblings, 1 reply; 42+ results
From: Alex Xu (Hello71) @ 2020-04-07  0:38 UTC (permalink / raw)
  To: dri-devel, linux-kernel, linux-mm, Thomas Hellström (VMware)
  Cc: Andrew Morton, Christian König, Dan Williams,
	Jérôme Glisse, Kirill A. Shutemov,
	linux-graphics-maintainer, Michal Hocko, pv-drivers,
	Ralph Campbell, Roland Scheidegger, Matthew Wilcox (Oracle)

Excerpts from Thomas Hellström (VMware)'s message of April 6, 2020 5:04 pm:
> Hi,
> 
> On 4/6/20 9:51 PM, Alex Xu (Hello71) wrote:
>> Using 314b658 with amdgpu, starting sway and firefox causes "BUG: Bad
>> rss-counter state" and "BUG: non-zero pgtables_bytes on freeing mm" to
>> start filling dmesg, and then closing programs causes more BUGs and
>> hangs, and then everything grinds to a halt (can't start more programs,
>> can't even reboot through systemd).
>>
>> Using master and reverting that branch up to that point fixes the
>> problem.
>>
>> I'm using a Ryzen 1600 and AMD Radeon RX 480 on an ASRock B450 Pro4
>> board with IOMMU enabled.
> 
> If you could try the attached patch, that'd be great!
> 
> Thanks,
> 
> Thomas
> 

Yeah, that works too. Kernel config sent off-list.

Regards,
Alex.

^ permalink raw reply	[relevance 99%]

* Re: Bad rss-counter state from drm/ttm, drm/vmwgfx: Support huge TTM pagefaults
  @ 2020-04-07 15:36 99%         ` Alex Xu (Hello71)
  0 siblings, 0 replies; 42+ results
From: Alex Xu (Hello71) @ 2020-04-07 15:36 UTC (permalink / raw)
  To: dri-devel, linux-kernel, linux-mm, Thomas Hellström (VMware)
  Cc: Andrew Morton, Christian König, Dan Williams,
	Jérôme Glisse, Kirill A. Shutemov,
	linux-graphics-maintainer, Michal Hocko, pv-drivers,
	Ralph Campbell, Roland Scheidegger, Matthew Wilcox (Oracle)

Excerpts from Thomas Hellström (VMware)'s message of April 7, 2020 7:26 am:
> On 4/7/20 2:38 AM, Alex Xu (Hello71) wrote:
>> Excerpts from Thomas Hellström (VMware)'s message of April 6, 2020 5:04 pm:
>>> Hi,
>>>
>>> On 4/6/20 9:51 PM, Alex Xu (Hello71) wrote:
>>>> Using 314b658 with amdgpu, starting sway and firefox causes "BUG: Bad
>>>> rss-counter state" and "BUG: non-zero pgtables_bytes on freeing mm" to
>>>> start filling dmesg, and then closing programs causes more BUGs and
>>>> hangs, and then everything grinds to a halt (can't start more programs,
>>>> can't even reboot through systemd).
>>>>
>>>> Using master and reverting that branch up to that point fixes the
>>>> problem.
>>>>
>>>> I'm using a Ryzen 1600 and AMD Radeon RX 480 on an ASRock B450 Pro4
>>>> board with IOMMU enabled.
>>> If you could try the attached patch, that'd be great!
>>>
>>> Thanks,
>>>
>>> Thomas
>>>
>> Yeah, that works too. Kernel config sent off-list.
>>
>> Regards,
>> Alex.
> 
> Thanks. Do you want me to add your
> 
> Reported-by: and Tested-by: To this patch?
> 
> /Thomas
> 
> 

Sure. Shouldn't we fix it properly though?

^ permalink raw reply	[relevance 99%]

* Unrecoverable AER error when resuming from RAM (hda regression in 5.7-rc2)
       [not found]     <1587494585.7pihgq0z3i.none.ref@localhost>
@ 2020-04-21 19:08 90% ` Alex Xu (Hello71)
  0 siblings, 0 replies; 42+ results
From: Alex Xu (Hello71) @ 2020-04-21 19:08 UTC (permalink / raw)
  To: alsa-devel, Takashi Iwai; +Cc: Roy Spliet, linux-kernel, linux-pci

With 5.7-rc2, after resuming from suspend to RAM, I get:

[   55.679382] pcieport 0000:00:03.1: AER: Multiple Uncorrected (Non-Fatal) error received: 0000:00:00.0
[   55.679405] pcieport 0000:00:03.1: AER: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID)
[   55.679410] pcieport 0000:00:03.1: AER:   device [1022:1453] error status/mask=00100000/04400000
[   55.679414] pcieport 0000:00:03.1: AER:    [20] UnsupReq               (First)
[   55.679417] pcieport 0000:00:03.1: AER:   TLP Header: 40000004 0a0000ff fffc0e80 00000000
[   55.679423] amdgpu 0000:0a:00.0: AER: can't recover (no error_detected callback)
[   55.679425] snd_hda_intel 0000:0a:00.1: AER: can't recover (no error_detected callback)
[   55.679455] pcieport 0000:00:03.1: AER: device recovery failed

Then the display freezes and the system basically falls apart (can't 
even sudo reboot -f, need to use magic sysrq).

I bisected this to "ALSA: hda: Skip controller resume if not needed". 
Setting snd_hda_intel.power_save=0 resolves the issue.

I am using an ASRock B450 Pro4 with Realtek HDA codec:

[    1.009400] snd_hda_intel 0000:0a:00.1: enabling device (0000 -> 0002)
[    1.009425] snd_hda_intel 0000:0a:00.1: Force to non-snoop mode
[    1.009653] snd_hda_intel 0000:0c:00.3: enabling device (0000 -> 0002)
[    1.021452] snd_hda_codec_generic hdaudioC0D0: ignore pin 0x7, too many assigned pins
[    1.021461] snd_hda_codec_generic hdaudioC0D0: ignore pin 0x9, too many assigned pins
[    1.021471] snd_hda_codec_generic hdaudioC0D0: ignore pin 0xb, too many assigned pins
[    1.021480] snd_hda_codec_generic hdaudioC0D0: ignore pin 0xd, too many assigned pins
[    1.021482] snd_hda_codec_generic hdaudioC0D0: autoconfig for Generic: line_outs=0 (0x0/0x0/0x0/0x0/0x0) type:line
[    1.021482] snd_hda_codec_generic hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[    1.021483] snd_hda_codec_generic hdaudioC0D0:    hp_outs=0 (0x0/0x0/0x0/0x0/0x0)
[    1.021484] snd_hda_codec_generic hdaudioC0D0:    mono: mono_out=0x0
[    1.021484] snd_hda_codec_generic hdaudioC0D0:    dig-out=0x3/0x5
[    1.021485] snd_hda_codec_generic hdaudioC0D0:    inputs:
[    1.046053] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC892: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line
[    1.046054] snd_hda_codec_realtek hdaudioC1D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[    1.046055] snd_hda_codec_realtek hdaudioC1D0:    hp_outs=1 (0x1b/0x0/0x0/0x0/0x0)
[    1.046055] snd_hda_codec_realtek hdaudioC1D0:    mono: mono_out=0x0
[    1.046056] snd_hda_codec_realtek hdaudioC1D0:    inputs:
[    1.046057] snd_hda_codec_realtek hdaudioC1D0:      Front Mic=0x19
[    1.046058] snd_hda_codec_realtek hdaudioC1D0:      Rear Mic=0x18
[    1.046058] snd_hda_codec_realtek hdaudioC1D0:      Line=0x1a

I also have an ASUS RX 480 graphics card with HDMI audio output.

^ permalink raw reply	[relevance 90%]

* Re: next-0519 on thinkpad x60: sound related? window manager crash
  @ 2020-06-07 15:58 85% ` Alex Xu (Hello71)
      0 siblings, 2 replies; 42+ results
From: Alex Xu (Hello71) @ 2020-06-07 15:58 UTC (permalink / raw)
  To: alsa-devel, bp, hpa, linux-kernel, mingo, Pavel Machek, perex,
	tglx, tiwai, x86, rientjes, hch, hch

I have a similar issue, caused between aaa2faab4ed8 and b170290c2836.

[   20.263098] BUG: unable to handle page fault for address: ffffb2b582cc2000
[   20.263104] #PF: supervisor write access in kernel mode
[   20.263105] #PF: error_code(0x000b) - reserved bit violation
[   20.263107] PGD 3fd03b067 P4D 3fd03b067 PUD 3fd03c067 PMD 3f8822067 PTE 8000273942ab2163
[   20.263113] Oops: 000b [#1] PREEMPT SMP
[   20.263117] CPU: 3 PID: 691 Comm: mpv Not tainted 5.7.0-11262-gb170290c2836 #1
[   20.263119] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B450 Pro4, BIOS P4.10 03/05/2020
[   20.263125] RIP: 0010:__memset+0x24/0x30
[   20.263128] Code: cc cc cc cc cc cc 0f 1f 44 00 00 49 89 f9 48 89 d1 83 e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 <f3> 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 f3
[   20.263131] RSP: 0018:ffffb2b583d07e10 EFLAGS: 00010216
[   20.263133] RAX: 0000000000000000 RBX: ffff8b8000102c00 RCX: 0000000000004000
[   20.263134] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb2b582cc2000
[   20.263136] RBP: ffff8b8000101000 R08: 0000000000000000 R09: ffffb2b582cc2000
[   20.263137] R10: 0000000000005356 R11: ffff8b8000102c18 R12: 0000000000000000
[   20.263139] R13: 0000000000000000 R14: ffff8b8039944200 R15: ffffffff9794daa0
[   20.263141] FS:  00007f41aa4b4200(0000) GS:ffff8b803ecc0000(0000) knlGS:0000000000000000
[   20.263143] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   20.263144] CR2: ffffb2b582cc2000 CR3: 00000003b6731000 CR4: 00000000003406e0
[   20.263146] Call Trace:
[   20.263151]  ? snd_pcm_hw_params+0x3f3/0x47a
[   20.263154]  ? snd_pcm_common_ioctl+0xf2/0xf73
[   20.263158]  ? snd_pcm_ioctl+0x1e/0x29
[   20.263161]  ? ksys_ioctl+0x77/0x91
[   20.263163]  ? __x64_sys_ioctl+0x11/0x14
[   20.263166]  ? do_syscall_64+0x3d/0xf5
[   20.263170]  ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   20.263173] Modules linked in: uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videodev snd_usb_audio videobuf2_common snd_hwdep snd_usbmidi_lib input_leds snd_rawmidi led_class
[   20.263182] CR2: ffffb2b582cc2000
[   20.263184] ---[ end trace c6b47a774b91f0a0 ]---
[   20.263187] RIP: 0010:__memset+0x24/0x30
[   20.263190] Code: cc cc cc cc cc cc 0f 1f 44 00 00 49 89 f9 48 89 d1 83 e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 <f3> 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 f3
[   20.263192] RSP: 0018:ffffb2b583d07e10 EFLAGS: 00010216
[   20.263193] RAX: 0000000000000000 RBX: ffff8b8000102c00 RCX: 0000000000004000
[   20.263195] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb2b582cc2000
[   20.263196] RBP: ffff8b8000101000 R08: 0000000000000000 R09: ffffb2b582cc2000
[   20.263197] R10: 0000000000005356 R11: ffff8b8000102c18 R12: 0000000000000000
[   20.263199] R13: 0000000000000000 R14: ffff8b8039944200 R15: ffffffff9794daa0
[   20.263201] FS:  00007f41aa4b4200(0000) GS:ffff8b803ecc0000(0000) knlGS:0000000000000000
[   20.263202] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   20.263204] CR2: ffffb2b582cc2000 CR3: 00000003b6731000 CR4: 00000000003406e0

I bisected this to 82fef0ad811f "x86/mm: unencrypted non-blocking DMA 
allocations use coherent pools". Reverting 1ee18de92927 resolves the 
issue.

Looks like Thinkpad X60 doesn't have VT-d, but could still be DMA 
related.

^ permalink raw reply	[relevance 85%]

* Re: 82fef0ad811f "x86/mm: unencrypted non-blocking DMA allocations use coherent pools" was Re: next-0519 on thinkpad x60: sound related? window manager crash
  @ 2020-06-07 22:53 99%       ` Alex Xu (Hello71)
    0 siblings, 1 reply; 42+ results
From: Alex Xu (Hello71) @ 2020-06-07 22:53 UTC (permalink / raw)
  To: David Rientjes
  Cc: alsa-devel, bp, hch, hch, hpa, linux-kernel, mingo, perex, tglx,
	tiwai, x86, Pavel Machek

Excerpts from David Rientjes's message of June 7, 2020 3:41 pm:
> On Sun, 7 Jun 2020, Pavel Machek wrote:
> 
>> > I have a similar issue, caused between aaa2faab4ed8 and b170290c2836.
>> > 
>> > [   20.263098] BUG: unable to handle page fault for address: ffffb2b582cc2000
>> > [   20.263104] #PF: supervisor write access in kernel mode
>> > [   20.263105] #PF: error_code(0x000b) - reserved bit violation
>> > [   20.263107] PGD 3fd03b067 P4D 3fd03b067 PUD 3fd03c067 PMD 3f8822067 PTE 8000273942ab2163
>> > [   20.263113] Oops: 000b [#1] PREEMPT SMP
>> > [   20.263117] CPU: 3 PID: 691 Comm: mpv Not tainted 5.7.0-11262-gb170290c2836 #1
>> > [   20.263119] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B450 Pro4, BIOS P4.10 03/05/2020
>> > [   20.263125] RIP: 0010:__memset+0x24/0x30
>> > [   20.263128] Code: cc cc cc cc cc cc 0f 1f 44 00 00 49 89 f9 48 89 d1 83 e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 <f3> 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 f3
>> > [   20.263131] RSP: 0018:ffffb2b583d07e10 EFLAGS: 00010216
>> > [   20.263133] RAX: 0000000000000000 RBX: ffff8b8000102c00 RCX: 0000000000004000
>> > [   20.263134] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb2b582cc2000
>> > [   20.263136] RBP: ffff8b8000101000 R08: 0000000000000000 R09: ffffb2b582cc2000
>> > [   20.263137] R10: 0000000000005356 R11: ffff8b8000102c18 R12: 0000000000000000
>> > [   20.263139] R13: 0000000000000000 R14: ffff8b8039944200 R15: ffffffff9794daa0
>> > [   20.263141] FS:  00007f41aa4b4200(0000) GS:ffff8b803ecc0000(0000) knlGS:0000000000000000
>> > [   20.263143] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> > [   20.263144] CR2: ffffb2b582cc2000 CR3: 00000003b6731000 CR4: 00000000003406e0
>> > [   20.263146] Call Trace:
>> > [   20.263151]  ? snd_pcm_hw_params+0x3f3/0x47a
>> > [   20.263154]  ? snd_pcm_common_ioctl+0xf2/0xf73
>> > [   20.263158]  ? snd_pcm_ioctl+0x1e/0x29
>> > [   20.263161]  ? ksys_ioctl+0x77/0x91
>> > [   20.263163]  ? __x64_sys_ioctl+0x11/0x14
>> > [   20.263166]  ? do_syscall_64+0x3d/0xf5
>> > [   20.263170]  ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
>> > [   20.263173] Modules linked in: uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videodev snd_usb_audio videobuf2_common snd_hwdep snd_usbmidi_lib input_leds snd_rawmidi led_class
>> > [   20.263182] CR2: ffffb2b582cc2000
>> > [   20.263184] ---[ end trace c6b47a774b91f0a0 ]---
>> > [   20.263187] RIP: 0010:__memset+0x24/0x30
>> > [   20.263190] Code: cc cc cc cc cc cc 0f 1f 44 00 00 49 89 f9 48 89 d1 83 e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 <f3> 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 f3
>> > [   20.263192] RSP: 0018:ffffb2b583d07e10 EFLAGS: 00010216
>> > [   20.263193] RAX: 0000000000000000 RBX: ffff8b8000102c00 RCX: 0000000000004000
>> > [   20.263195] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb2b582cc2000
>> > [   20.263196] RBP: ffff8b8000101000 R08: 0000000000000000 R09: ffffb2b582cc2000
>> > [   20.263197] R10: 0000000000005356 R11: ffff8b8000102c18 R12: 0000000000000000
>> > [   20.263199] R13: 0000000000000000 R14: ffff8b8039944200 R15: ffffffff9794daa0
>> > [   20.263201] FS:  00007f41aa4b4200(0000) GS:ffff8b803ecc0000(0000) knlGS:0000000000000000
>> > [   20.263202] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> > [   20.263204] CR2: ffffb2b582cc2000 CR3: 00000003b6731000 CR4: 00000000003406e0
>> > 
>> > I bisected this to 82fef0ad811f "x86/mm: unencrypted non-blocking DMA 
>> > allocations use coherent pools". Reverting 1ee18de92927 resolves the 
>> > issue.
>> > 
>> > Looks like Thinkpad X60 doesn't have VT-d, but could still be DMA 
>> > related.
>> 
>> Note that newer -next releases seem to behave okay for me. The commit
>> pointed out by siection is really simple:
>> 
>> AFAIK you could verify it is responsible by turning off
>> CONFIG_AMD_MEM_ENCRYPT on latest kernel...
>> 
>> Best regards,
>> 								Pavel
>> 
>> index 1d6104ea8af0..2bf2222819d3 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -1520,6 +1520,7 @@ config X86_CPA_STATISTICS
>>  config AMD_MEM_ENCRYPT
>>         bool "AMD Secure Memory Encryption (SME) support"
>>         depends on X86_64 && CPU_SUP_AMD
>> +       select DMA_COHERENT_POOL
>>         select DYNAMIC_PHYSICAL_MASK
>>         select ARCH_USE_MEMREMAP_PROT
>>         select ARCH_HAS_FORCE_DMA_UNENCRYPTED
> 
> Thanks for the report!
> 
> Besides CONFIG_AMD_MEM_ENCRYPT, do you have CONFIG_DMA_DIRECT_REMAP 
> enabled?  If so, it may be caused by the virtual address passed to the 
> set_memory_{decrypted,encrypted}() functions.
> 
> And I assume you are enabling SME by using mem_encrypt=on on the kernel 
> command line or CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT is enabled.
> 
> We likely need an atomic pool for devices that support DMA to addresses in 
> sme_me_mask as well.  I can test this tomorrow, but wanted to get it out 
> early to see if it helps?

This patch doesn't seem to help. I have the same problem (kernel page 
fault, __memset, snd_pcm_hw_params...).

I don't have CONFIG_DMA_DIRECT_REMAP enabled, and AFAICT it doesn't seem 
to be selectable currently on x86, unless there are some patches 
floating around for that.

^ permalink raw reply	[relevance 99%]

* Re: 82fef0ad811f "x86/mm: unencrypted non-blocking DMA allocations use coherent pools" was Re: next-0519 on thinkpad x60: sound related? window manager crash
  @ 2020-06-08  2:13 99%           ` Alex Xu (Hello71)
  0 siblings, 0 replies; 42+ results
From: Alex Xu (Hello71) @ 2020-06-08  2:13 UTC (permalink / raw)
  To: David Rientjes
  Cc: alsa-devel, bp, hch, hch, hpa, linux-kernel, mingo, Pavel Machek,
	perex, tglx, tiwai, x86

Excerpts from David Rientjes's message of June 7, 2020 8:57 pm:
> Thanks for trying it out, Alex.  Would you mind sending your .config and 
> command line?  I assume either mem_encrypt=on or 
> CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT is enabled.
> 
> Could you also give this a try?
> 
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -99,10 +99,11 @@ static inline bool dma_should_alloc_from_pool(struct device *dev, gfp_t gfp,
>  static inline bool dma_should_free_from_pool(struct device *dev,
>  					     unsigned long attrs)
>  {
> -	if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL))
> +	if (!IS_ENABLED(CONFIG_DMA_COHERENT_POOL))
> +		return false;
> +	if (force_dma_unencrypted(dev))
>  		return true;
> -	if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
> -	    !force_dma_unencrypted(dev))
> +	if (attrs & DMA_ATTR_NO_KERNEL_MAPPING)
>  		return false;
>  	if (IS_ENABLED(CONFIG_DMA_DIRECT_REMAP))
>  		return true;
> 

This patch doesn't work for me either. It has since occurred to me that 
while I do have CONFIG_AMD_MEM_ENCYRPT=y, I have 
CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT=n, because it was broken with 
amdgpu (unfortunately a downgrade from radeon in this respect). Tried it 
again just now and it looks like it's now able to enable KMS, but all it 
displays is serious-looking errors.

Sorry for not mentioning that earlier. I'll send you my .config and 
command line off-list.

Thanks,
Alex.

^ permalink raw reply	[relevance 99%]

* Re: next-0519 on thinkpad x60: sound related? window manager crash
  @ 2020-06-08 13:53 99%     ` Alex Xu (Hello71)
    0 siblings, 1 reply; 42+ results
From: Alex Xu (Hello71) @ 2020-06-08 13:53 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: alsa-devel, bp, hch, hpa, linux-kernel, mingo, Pavel Machek,
	perex, rientjes, tglx, tiwai, x86

Excerpts from Christoph Hellwig's message of June 8, 2020 2:19 am:
> Can you do a listing using gdb where this happens?
> 
> gdb vmlinux
> 
> l *(snd_pcm_hw_params+0x3f3)
> 
> ?
> 

(gdb) l *(snd_pcm_hw_params+0x3f3)
0xffffffff817efc85 is in snd_pcm_hw_params (.../linux/sound/core/pcm_native.c:749).
744             while (runtime->boundary * 2 <= LONG_MAX - runtime->buffer_size)
745                     runtime->boundary *= 2;
746
747             /* clear the buffer for avoiding possible kernel info leaks */
748             if (runtime->dma_area && !substream->ops->copy_user)
749                     memset(runtime->dma_area, 0, runtime->dma_bytes);
750
751             snd_pcm_timer_resolution_change(substream);
752             snd_pcm_set_state(substream, SNDRV_PCM_STATE_SETUP);
753

^ permalink raw reply	[relevance 99%]

* Re: next-0519 on thinkpad x60: sound related? window manager crash
    @ 2020-06-11 14:51 99%         ` Alex Xu (Hello71)
  1 sibling, 0 replies; 42+ results
From: Alex Xu (Hello71) @ 2020-06-11 14:51 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: alsa-devel, bp, hch, hpa, linux-kernel, mingo, Pavel Machek,
	perex, rientjes, tglx, tiwai, x86

Excerpts from Christoph Hellwig's message of June 9, 2020 7:47 am:
> Alex, can you try this patch?
> 
> diff --git a/sound/core/Kconfig b/sound/core/Kconfig
> index d4554f376160a9..10b06e575a7fc5 100644
> --- a/sound/core/Kconfig
> +++ b/sound/core/Kconfig
> @@ -192,6 +192,6 @@ config SND_VMASTER
>  
>  config SND_DMA_SGBUF
>  	def_bool y
> -	depends on X86
> +	depends on BROKEN
>  
>  source "sound/core/seq/Kconfig"
> 

Sorry, this patch doesn't work for me with SME off using abfbb29297c2. 
David's newest submitted patch works for me, which I already replied to 
separately.

Thanks,
Alex.

^ permalink raw reply	[relevance 99%]

* Re: [patch for-5.8] dma-pool: decouple DMA_REMAP from DMA_COHERENT_POOL
  @ 2020-06-11 14:49 99% ` Alex Xu (Hello71)
  0 siblings, 0 replies; 42+ results
From: Alex Xu (Hello71) @ 2020-06-11 14:49 UTC (permalink / raw)
  To: Christoph Hellwig, David Rientjes
  Cc: alsa-devel, bp, hch, hpa, linux-kernel, mingo, Pavel Machek,
	perex, tglx, tiwai, x86

Excerpts from David Rientjes's message of June 11, 2020 3:25 am:
> DMA_REMAP is an unnecessary requirement for AMD SEV, which requires 
> DMA_COHERENT_POOL, so avoid selecting it when it is otherwise unnecessary.  
> 
> The only other requirement for DMA coherent pools is DMA_DIRECT_REMAP, so 
> ensure that properly selects the config option when needed.
> 
> Fixes: 82fef0ad811f ("x86/mm: unencrypted non-blocking DMA allocations use 
> coherent pools")
> Suggested-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: David Rientjes <rientjes@google.com>
> ---
>  kernel/dma/Kconfig | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 

Works for me with SME on or off with af7b480103, and with SME off in 
abfbb29297. There is some regression with amdgpu and SME between those 
two points, I need to check that out too. I haven't tested either before 
or after with SEV (which I'm not even sure my system supports). 
Regardless, this is a definite improvement.

Tested-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>

Thanks,
Alex.

^ permalink raw reply	[relevance 99%]

* Re: next-0519 on thinkpad x60: sound related? window manager crash
       [not found]               ` <<s5hr1uogtna.wl-tiwai@suse.de>
@ 2020-06-11 14:51 99%             ` Alex Xu (Hello71)
  0 siblings, 0 replies; 42+ results
From: Alex Xu (Hello71) @ 2020-06-11 14:51 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: alsa-devel, bp, hch, Christoph Hellwig, hpa, linux-kernel, mingo,
	Pavel Machek, perex, rientjes, tglx, tiwai, x86

Excerpts from Takashi Iwai's message of June 9, 2020 11:12 am:
> On Tue, 09 Jun 2020 13:47:33 +0200,
> Christoph Hellwig wrote:
>> 
>> Alex, can you try this patch?
> 
> Also could you check whether just papering over the memset() call
> alone avoids the crash like below?  For PulseAudio and dmix/dsnoop,
> it's the only code path that accesses the vmapped buffer, I believe.
> 
> If this works more or less, I'll cook a more comprehensive fix.
> 
> 
> thanks,
> 
> Takashi
> 
> --- a/sound/core/pcm_native.c
> +++ b/sound/core/pcm_native.c
> @@ -754,9 +754,11 @@ static int snd_pcm_hw_params(struct snd_pcm_substream *substream,
>  	while (runtime->boundary * 2 <= LONG_MAX - runtime->buffer_size)
>  		runtime->boundary *= 2;
>  
> +#if 0
>  	/* clear the buffer for avoiding possible kernel info leaks */
>  	if (runtime->dma_area && !substream->ops->copy_user)
>  		memset(runtime->dma_area, 0, runtime->dma_bytes);
> +#endif
>  
>  	snd_pcm_timer_resolution_change(substream);
>  	snd_pcm_set_state(substream, SNDRV_PCM_STATE_SETUP);
> 

Sorry, this patch doesn't work for me with SME off using abfbb29297c2. 
David's newest submitted patch works for me, which I already replied to 
separately.

Thanks,
Alex.

^ permalink raw reply	[relevance 99%]

* AMD IOMMU + SME + amdgpu regression
       [not found]     <1591915710.rakbpzst8h.none.ref@localhost>
@ 2020-06-11 23:05 86% ` Alex Xu (Hello71)
    0 siblings, 1 reply; 42+ results
From: Alex Xu (Hello71) @ 2020-06-11 23:05 UTC (permalink / raw)
  To: Joerg Roedel, linux-kernel, David Rientjes, Christoph Hellwig
  Cc: Will Deacon, Robin Murphy, Marek Szyprowski, Kukjin Kim,
	Krzysztof Kozlowski, David Woodhouse, Lu Baolu, Andy Gross,
	Bjorn Andersson, Matthias Brugger, Rob Clark, Heiko Stuebner,
	Gerald Schaefer, Thierry Reding, Jonathan Hunter,
	Jean-Philippe Brucker, Daniel Drake, jonathan.derrick,
	linux-samsung-soc, linux-arm-msm, linux-mediatek, linux-rockchip,
	linux-s390, linux-tegra, virtualization, Joerg Roedel

Hi,

amdgpu + IOMMU + SME is now working for me on 5.7, yay! But, it is 
broken on torvalds master, boo. On boot, depending on which exact commit 
I test, it either hangs immediately (with built-in driver, before 
starting initramfs), displays some errors then hangs, or spams the 
screen with many amdgpu errors.

I bisected the black screen hang to:

commit dce8d6964ebdb333383bacf5e7ab8c27df151218
Author: Joerg Roedel <jroedel@suse.de>
Date:   Wed Apr 29 15:36:53 2020 +0200

    iommu/amd: Convert to probe/release_device() call-backs

    Convert the AMD IOMMU Driver to use the probe_device() and
    release_device() call-backs of iommu_ops, so that the iommu core code
    does the group and sysfs setup.

    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Link: https://lore.kernel.org/r/20200429133712.31431-16-joro@8bytes.org
    Signed-off-by: Joerg Roedel <jroedel@suse.de>

Testing torvalds master (623f6dc593) with the containing merge 
(98bdc74b36) plus the DMA mapping merge (4e94d08734) reverted allows 
amdgpu + IOMMU + SME to once again work.

I think that nobody is really working on amdgpu + SME, but it would be a 
shame if it was supported and then incidentally broken by a small 
change.

I am using an ASRock B450 Pro4 with Ryzen 1600 and ASUS RX 480. I don't 
understand this code at all, but let me know what I can do to 
troubleshoot.

Thanks,
Alex.

^ permalink raw reply	[relevance 86%]

* Re: next-0519 on thinkpad x60: sound related? window manager crash
  @ 2020-06-13 16:25 99%             ` Alex Xu (Hello71)
    0 siblings, 1 reply; 42+ results
From: Alex Xu (Hello71) @ 2020-06-13 16:25 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: alsa-devel, bp, hch, Christoph Hellwig, hpa, linux-kernel, mingo,
	Pavel Machek, perex, rientjes, tglx, tiwai, x86

Excerpts from Takashi Iwai's message of June 11, 2020 1:11 pm:
> Thanks, so something still missing in the mmap handling, I guess.
> 
> I've worked on two different branches for potential fixes of your
> problems.  Could you test topic/dma-fix and topic/dma-fix2 branches?
>   git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
> Just pull one of them onto Linus' git HEAD.
> 
> I guess we'll go with David's new patch, but still it's interesting
> whether my changes do anything good actually.
> 
> 
> Takashi
> 

On torvalds 623f6dc593, topic/dma-fix causes sound to be output as 
alternating half-second bursts of noise and a few seconds of silence. 
topic/dma-fix2 appears to work properly.

Thanks,
Alex.

^ permalink raw reply	[relevance 99%]

* Re: next-0519 on thinkpad x60: sound related? window manager crash
  @ 2020-06-14 12:07 99%                 ` Alex Xu (Hello71)
  0 siblings, 0 replies; 42+ results
From: Alex Xu (Hello71) @ 2020-06-14 12:07 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: alsa-devel, bp, hch, Christoph Hellwig, hpa, linux-kernel, mingo,
	Pavel Machek, perex, rientjes, tglx, tiwai, x86

Excerpts from Takashi Iwai's message of June 14, 2020 5:54 am:
> On Sat, 13 Jun 2020 18:25:22 +0200,
> Alex Xu (Hello71) wrote:
>> 
>> Excerpts from Takashi Iwai's message of June 11, 2020 1:11 pm:
>> > Thanks, so something still missing in the mmap handling, I guess.
>> > 
>> > I've worked on two different branches for potential fixes of your
>> > problems.  Could you test topic/dma-fix and topic/dma-fix2 branches?
>> >   git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
>> > Just pull one of them onto Linus' git HEAD.
>> > 
>> > I guess we'll go with David's new patch, but still it's interesting
>> > whether my changes do anything good actually.
>> > 
>> > 
>> > Takashi
>> > 
>> 
>> On torvalds 623f6dc593, topic/dma-fix causes sound to be output as 
>> alternating half-second bursts of noise and a few seconds of silence. 
>> topic/dma-fix2 appears to work properly.
> 
> OK, thanks for the feedback!  Just to make sure, you're using
> PulseAudio, right?
> If so, it was still something wrong about mmap, and the secondary
> method (the fallback to the continuous page) looks like a safer
> approach in the end.
> 
> I suppose that David's fix will be merged sooner or later.  Meanwhile
> I'll work on the change in the sound driver side to make things a bit
> more robust.  They don't conflict and both good applicable.
> 
> 
> thanks,
> 
> Takashi
> 

Ah, no, I think that wasn't clear. I use ALSA directly with mostly 
default configuration, except an asym sets separate default playback and 
record devices.

asound.conf:

defaults.pcm.card 1
defaults.ctl.card 1

pcm.!default {
    type asym
    playback.pcm
    {
        type plug
        slave.pcm "dmix"
    }
    capture.pcm
    {
        type plug
        slave.pcm {
            type dsnoop
            ipc_key 6793
            slave.pcm "hw:U0x46d0x81d"
        }
    }
}

I think I wasn't able to set defaults.pcm.dmix.card and 
defaults.pcm.dsnoop.card for some reason, not sure why. I can try that, 
but I don't think it will affect this mmap issue.

Thanks,
Alex.

^ permalink raw reply	[relevance 99%]

* Re: AMD IOMMU + SME + amdgpu regression
  @ 2020-06-22 15:30 98%     ` Alex Xu (Hello71)
  0 siblings, 0 replies; 42+ results
From: Alex Xu (Hello71) @ 2020-06-22 15:30 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Andy Gross, Lu Baolu, Bjorn Andersson, Daniel Drake,
	David Woodhouse, Gerald Schaefer, Christoph Hellwig,
	Heiko Stuebner, Jean-Philippe Brucker, jonathan.derrick,
	Jonathan Hunter, Joerg Roedel, Kukjin Kim, Krzysztof Kozlowski,
	linux-arm-msm, linux-kernel, linux-mediatek, linux-rockchip,
	linux-s390, linux-samsung-soc, linux-tegra, Matthias Brugger,
	Marek Szyprowski, David Rientjes, Rob Clark, Robin Murphy,
	Thierry Reding, virtualization, Will Deacon

Excerpts from Joerg Roedel's message of June 22, 2020 6:02 am:
> Hi Alex,
> 
> On Thu, Jun 11, 2020 at 07:05:21PM -0400, Alex Xu (Hello71) wrote:
>> I am using an ASRock B450 Pro4 with Ryzen 1600 and ASUS RX 480. I don't 
>> understand this code at all, but let me know what I can do to 
>> troubleshoot.
> 
> Does it boot without SME enabled?
> 
> 
> Regards,
> 
> 	Joerg
> 

Yes, it works with SME off with dbed452a078 ("dma-pool: decouple 
DMA_REMAP from DMA_COHERENT_POOL") applied.

^ permalink raw reply	[relevance 98%]

* Kernel compression benchmarks
       [not found]     <1588791882.08g1378g67.none.ref@localhost>
@ 2020-07-01 14:35 74% ` Alex Xu (Hello71)
  0 siblings, 0 replies; 42+ results
From: Alex Xu (Hello71) @ 2020-07-01 14:35 UTC (permalink / raw)
  To: linux-kernel, Nick Terrell, Nick Terrell, Norbert Lange
  Cc: Chris Mason, linux-kbuild, x86, gregkh, Petr Malat, Kees Cook,
	Kernel Team, Adam Borowski, Patrick Williams, rmikey, mingo,
	Patrick Williams, Sedat Dilek


[-- Attachment #1: Type: text/plain, Size: 3687 bytes --]

Hi all,

ZSTD compression patches have been sent in a number of times over the 
past few years. Every time, someone asks for benchmarks. Every time, 
someone is concerned about compression time. Sometimes, someone provides 
benchmarks.

But, as far as I can tell, nobody considered the compression parameters, 
which have a significant impact on compression time and ratio.

So, I did some benchmarks myself, including all the compression levels 
for each compressor.

Results:

The results are attached as SVG graphs and CSV data.

Summary:

- compression level, predictably, has a huge impact on compression time.
- compression level has virtually no impact on decompression time for 
  lz4, zstd, and some effect on others. interestingly, xz decompresses 
  slightly faster at higher compression levels (perhaps cache-related).
- gzip compresses slightly faster than zstd at medium compression levels.
- bzip2 sucks: slow compression, very slow decompression, poor ratio.
- lzma decompresses slightly faster than xz, but is also slightly larger.
- xz is smallest but with very slow compression and decompression.
- lz4 decompresses fastest.
- zstd is a good balanced default.
- 7z is much faster than xz, even with wine overhead.

Files:

For the kernel, I did "make allmodconfig; sed -i -e '/=m$/d' .config" 
with a 5.6 kernel and gcc 9.3.0 on x86_64, then concatenated vmlinux.bin 
and vmlinux.relocs. For the initramfs, I used the Arch Linux fallback 
initramfs with default hooks.

Versions:

gzip 1.10
bzip2, a block-sorting file compressor.  Version 1.0.8, 13-Jul-2019.
xz (XZ Utils) 5.2.5
*** LZ4 command line interface 64-bits v1.9.2, by Yann Collet ***
lzop 1.04
LZO library 2.10
*** zstd command line interface 64-bits v1.4.4, by Yann Collet ***
7-Zip 19.00 (x64) : Copyright (c) 1999-2018 Igor Pavlov : 2019-02-21

Notes:

I used the userspace versions of the decompressors, not the kernel 
version. This is particularly relevant for xz, as the kernel xzminidec 
is significantly slower than xz.

pigz is faster than gzip, but I used gzip as a common baseline.

7-Zip was run through wine with a persistent wineserver.

I ran the benchmark on a Ryzen 1600, with turbo boost turned off. Each 
test was run only once, on the basis that any noise wouldn't disrupt the 
overall curve, and also I don't want to spend hours waiting for the 
results.

The current compression level defaults are:

- gzip -9
- bzip2 -9
- lzma -9
- xz --check=crc32 --x86 --lzma2=,dict=32MiB # except on ppc
- lzop -9
- lz4 -l -1

My conclusions:

- zstd is an improvement on almost all metrics.
- bzip2 and lzma should be removed post-haste.
- lzo should be removed once zstd is merged.
- compression level is important to consider for compression speed: the 
  default lz4 -1 compresses very fast but has a very poor compression 
  ratio. zstd -19 compresses barely better than zstd -18, but takes 
  significantly longer to compress.
- compression level should be configurable: lz4 -1 is useful, but so is 
  lz4 -9. zstd -1 is useful, but so is zstd -19. zstd -1 is useful for 
  developers who want kernel builds as fast as possible, zstd -19 for 
  everybody else.
- gzip is by far not the fastest compressor (even excluding cat)
- modern compressors (xz, lz4, zstd) decompress about as fast for each 
  compression level, only requiring more memory
- 7-Zip is much faster than xz, needs more research
- 7-Zip BCJ2 is slightly better than xz/BCJ. probably better filters for 
  all archs would be a good area of research, as apparently BCJ/BCJ2 are 
  intended only for 32-bit x86.

Thanks,
Alex.

[-- Attachment #2: kernel-compression-benchmarks.tar.gz --]
[-- Type: application/x-compressed-tar, Size: 56733 bytes --]

^ permalink raw reply	[relevance 74%]

* Re: Kernel compression benchmarks
  @ 2020-07-01 17:32 99%   ` Alex Xu (Hello71)
  0 siblings, 0 replies; 42+ results
From: Alex Xu (Hello71) @ 2020-07-01 17:32 UTC (permalink / raw)
  To: Gao Xiang
  Cc: Chris Mason, gregkh, Kees Cook, Kernel Team, Adam Borowski,
	linux-kbuild, linux-kernel, mingo, Nick Terrell, Norbert Lange,
	Petr Malat, Patrick Williams, Patrick Williams, rmikey,
	Sedat Dilek, Nick Terrell, x86

Excerpts from Gao Xiang's message of July 1, 2020 11:50 am:
>  Anyway, I think LZMA (xz) is still useful and which is more
>  friendly to fixed-sized output compression than Zstd yet (But
>  yeah, I'm not familar with all ZSTD internals. I will dig
>  into that if I've more extra time).

Yes, I agree. If you look at the graphs, LZMA2 (xz/7zip) still produces 
smaller results, even compared to zstd maximum settings, so definitely 
LZMA2 should be kept, at least for now. I am only suggesting removing 
LZMA, since it has no benefits over xz and zstd combination (bigger than 
xz, slower than zstd).

>> - modern compressors (xz, lz4, zstd) decompress about as fast for each 
>>   compression level, only requiring more memory
> 
>  lz4 has fixed sliding window (dictionary, 64k), so it won't
>  require more memory among different compression level when
>  decompressing.

Yes, this is true. I tried to simplify among all compressors, but I 
think I simplified too much. Thanks for clarifying.

Cheers,
Alex.

^ permalink raw reply	[relevance 99%]

Results 1-42 of 42 | reverse results
     [not found]     <1621091901.34838094.1356409676820.JavaMail.root@redhat.com>
2012-12-25  4:38     ` kernel BUG at mm/huge_memory.c:1798! Zhouping Liu
2012-12-25 12:05       ` Hillf Danton
2012-12-27 16:08 82%     ` Alex Xu
2017-06-26  3:07 86% bfq/ext4 disk IO hangs forever on resume Alex Xu
2017-07-25 12:18     ` Ming Lei
2017-08-18 20:29 99%   ` Alex Xu
2018-09-27 20:27 99% [PATCH] mm: fix z3fold warnings on CONFIG_SMP=n Alex Xu (Hello71)
2018-09-27 20:41     ` Dan Streetman
2018-09-27 21:12 99%   ` Alex Xu
2018-09-27 21:15 99%     ` [PATCH v2] " Alex Xu (Hello71)
2018-09-30  1:18 99% [PATCH net] r8169: always autoneg on resume Alex Xu (Hello71)
2018-09-30 15:06 99% [PATCH net v2] " Alex Xu (Hello71)
2018-09-30 22:17     ` Daan Wendelen
2018-09-30 22:30 99%   ` Alex Xu
2018-10-01  2:39         ` Andrew Lunn
2018-10-01  3:31 99%       ` Alex Xu
2019-03-09  2:16 99% r8169 only works in promisc mode Alex Xu (Hello71)
2019-03-09  9:33     ` Heiner Kallweit
2019-03-09 16:53 99%   ` Alex Xu
2019-03-23  1:26 91% ` Alex Xu
2019-03-24 15:30 99% shmem_recalc_inode: unable to handle kernel NULL pointer dereference Alex Xu (Hello71)
2019-03-25 22:08     ` Vineeth Pillai
2019-03-31 16:15 99%   ` Alex Xu (Hello71)
2019-04-30  2:17 84% [PATCH] treewide: fix awk regexp over-escaping Alex Xu (Hello71)
2019-05-13  1:20 83% [REGRESSION] ptrace broken from "cgroup: cgroup v2 freezer" (76f969e) Alex Xu (Hello71)
2019-05-18  6:44     [bugreport] kernel 5.2 pblk bad header/extent: invalid extent entries Mikhail Gavrilov
2019-05-18 11:07     ` Mikhail Gavrilov
2019-05-18 18:59 99%   ` Alex Xu (Hello71)
2019-05-18 19:53 84% [PATCH] treewide: fix awk regexp over-escaping Alex Xu (Hello71)
2019-06-01 14:49 99% [PATCH] crypto: ux500 - fix license comment syntax error Alex Xu (Hello71)
2019-06-01 16:29     ` Greg KH
2019-06-01 19:41 99%   ` Alex Xu
2019-07-24 22:33 94% [PATCH] random: print a message when waiting for random Alex Xu (Hello71)
     [not found]     <20200222003820.220854-1-alex_y_xu.ref@yahoo.ca>
2020-02-22  0:38 62% ` [PATCH] kbuild: move -pipe to global KBUILD_CFLAGS Alex Xu (Hello71)
2020-02-22  2:16       ` Nathan Chancellor
2020-02-22  4:01 79%     ` Alex Xu (Hello71)
2020-02-22  8:01           ` Nathan Chancellor
2020-02-22 14:24 99%         ` Alex Xu (Hello71)
     [not found]     <1586138158.v5u7myprlp.none.ref@localhost>
2020-04-06 19:51 99% ` Bad rss-counter state from drm/ttm, drm/vmwgfx: Support huge TTM pagefaults Alex Xu (Hello71)
2020-04-06 21:04       ` Thomas Hellström (VMware)
2020-04-07  0:38 99%     ` Alex Xu (Hello71)
2020-04-07 11:26           ` Thomas Hellström (VMware)
2020-04-07 15:36 99%         ` Alex Xu (Hello71)
     [not found]     <1587494585.7pihgq0z3i.none.ref@localhost>
2020-04-21 19:08 90% ` Unrecoverable AER error when resuming from RAM (hda regression in 5.7-rc2) Alex Xu (Hello71)
2020-05-20 11:11     next-0519 on thinkpad x60: sound related? window manager crash Pavel Machek
2020-06-07 15:58 85% ` Alex Xu (Hello71)
2020-06-07 16:38       ` 82fef0ad811f "x86/mm: unencrypted non-blocking DMA allocations use coherent pools" was " Pavel Machek
2020-06-07 19:41         ` David Rientjes
2020-06-07 22:53 99%       ` Alex Xu (Hello71)
2020-06-08  0:57             ` David Rientjes
2020-06-08  2:13 99%           ` Alex Xu (Hello71)
2020-06-08  6:19       ` Christoph Hellwig
2020-06-08 13:53 99%     ` Alex Xu (Hello71)
2020-06-09 11:47           ` Christoph Hellwig
2020-06-09 15:12             ` Takashi Iwai
     [not found]               ` <<s5hr1uogtna.wl-tiwai@suse.de>
2020-06-11 14:51 99%             ` Alex Xu (Hello71)
2020-06-11 17:11               ` Takashi Iwai
2020-06-13 16:25 99%             ` Alex Xu (Hello71)
2020-06-14  9:54                   ` Takashi Iwai
2020-06-14 12:07 99%                 ` Alex Xu (Hello71)
2020-06-11 14:51 99%         ` Alex Xu (Hello71)
2020-06-11  7:25     [patch for-5.8] dma-pool: decouple DMA_REMAP from DMA_COHERENT_POOL David Rientjes
2020-06-11 14:49 99% ` Alex Xu (Hello71)
     [not found]     <1591915710.rakbpzst8h.none.ref@localhost>
2020-06-11 23:05 86% ` AMD IOMMU + SME + amdgpu regression Alex Xu (Hello71)
2020-06-22 10:02       ` Joerg Roedel
2020-06-22 15:30 98%     ` Alex Xu (Hello71)
     [not found]     <1588791882.08g1378g67.none.ref@localhost>
2020-07-01 14:35 74% ` Kernel compression benchmarks Alex Xu (Hello71)
     [not found]     <20200701153028.GA30962.ref@hsiangkao-HP-ZHAN-66-Pro-G1>
2020-07-01 15:50     ` Gao Xiang
2020-07-01 17:32 99%   ` Alex Xu (Hello71)


LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git