linux-kernel - Re: [PATCH 1/1] driver core: Fix unbalance probe_count in really

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <65b25d4b-39ad-e5be-ecfd-39bdc7ae9458@gmail.com>
Date:   Wed, 3 Jun 2020 15:35:07 +0800
From:   "Ji-Ze Hong (Peter Hong)" <hpeter@...il.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>, peter_hong@...tek.com.tw,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Ji-Ze Hong (Peter Hong)" <hpeter+linux_kernel@...il.com>
Subject: Re: [PATCH 1/1] driver core: Fix unbalance probe_count in
 really_probe()

Hi Geert,

Geert Uytterhoeven 於 2020/6/3 下午 03:13 寫道:
> Hi Ji-Ze,
> 
> If devres_head is not empty, you have a serious problem on your system,
> as those resources may be in an unknown state (e.g. freed but still in
> use).  While I had missed the probe_count imbalance when implementing
> the original change, it may actually be safer to not decrease
> probe_count, to prevent further probes from happening.  But I guess it
> doesn't matter: if you get here, your system is in a bad state anyway.

We want to fix the shutdown/reboot freeze issue and bisect to this
patch and found if the probe_count != 0, the PC will stuck with
wait_for_device_probe() with shutdown/reboot forever. So we just
change the increment after return -EBUSY.

In this case, it maybe 8250_PNP & serial 8250 platform driver resources
conflict. I'll try to dump more message to debug.

IMO, the shutdown/reboot operation should not block.


>> with serial8250 platform driver. e.g. AOPEN DE6200. The conflict boot
>> dmesg below:
>>
>>          Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
>>          00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 921600) is a 16550A
>>          00:04: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 921600) is a 16550A
>>          00:05: ttyS2 at I/O 0x3e8 (irq = 5, base_baud = 921600) is a 16550A
>>          serial8250: ttyS3 at I/O 0x2e8 (irq = 3, base_baud = 921600) is a 16550A
>>
>> Reboot/Shutdown will freeze in wait_for_device_probe(), message as
>> following:
>>          INFQ: task systemd-shutdown: 1 blocked for more than 120 seconds.
> 
> Now, how did you get to this state, i.e. which driver triggered the
> "Resources present before probing" message? Because that is the root
> issue that must be fixed, and the probe_count imbalance is IMHO just a
> red herring.
> 

Sorry for lost important dmesg:

Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 921600) is a 16550A
00:04: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 921600) is a 16550A
00:05: ttyS2 at I/O 0x3e8 (irq = 5, base_baud = 921600) is a 16550A
serial8250: ttyS3 at I/O 0x2e8 (irq = 3, base_baud = 921600) is a 16550A
platform serial8250: Resources present before probing
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

-- 
With Best Regards,
Peter Hong