| 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
| ||
|
Message-ID: <YY5BRrE8bLyvd3PB@smile.fi.intel.com>
Date: Fri, 12 Nov 2021 12:26:14 +0200
From: "andriy.shevchenko" <andriy.shevchenko@...ux.intel.com>
To: 黄碧波 <huangbibo@...ontech.com>
Cc: Jarkko Nikula <jarkko.nikula@...ux.intel.com>,
linux-i2c <linux-i2c@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
"mika.westerberg" <mika.westerberg@...ux.intel.com>,
"p.zabel" <p.zabel@...gutronix.de>
Subject: Re: [PATCH] i2c: designware: I2C unexpected interrupt handling will
cause kernel panic
On Fri, Nov 12, 2021 at 03:35:07AM +0000, 黄碧波 wrote:
> Hi Andy,
First of all, please fix your email client (it mangled the message
in a bad way) and do not top post!
> This patch is to make the kernel more stable & stronger,
> Even if there is an unexpected I2C interrupt, kernel will not crash
As far as I can see this is, as Jarkko said, the change to hide the real issue.
> Let me elaborate on this issue:
> The BIOS support EFI RTC feature and add the I2C bus descr in the ACPI table (RTC chip is connected to I2C bus), The OS matches and registers the I2C bus driver.
>
> When OS get RTC time by BIOS interface (Runtime Server), crash occurs.
> The BIOS interface direct acces registers to sends and receives data, which conflicts with the I2C driver
>
> This is a BIOS error and the root cause of this issue. The final solution is to delete the I2C device node in the ACPI table
Oh, yeah, yet another brain damaged design. If somebody wants to have driver of
the I²C peripheral in the ASL, it's not gonna work in Linux (in 99.99% cases).
What you should do is go and fix BIOS that it won't do two things together, i.e.
ASL based driver and exposure of I²C host controller in ACPI.
On the constructive way, you need to use DMI quirks and somehow make EFI and
I²C code to be communicating nicely in the kernel.
The patch makes no sense to me, the problem is obviously somewhere else.
NAK.
>
>
> ------------------ Original ------------------
> From: "Jarkko Nikula"<jarkko.nikula@...ux.intel.com>;
> Date: Thu, Nov 11, 2021 02:06 PM
> To: "huangbibo"<huangbibo@...ontech.com>; "linux-i2c"<linux-i2c@...r.kernel.org>;
> Cc: "linux-kernel"<linux-kernel@...r.kernel.org>; "mika.westerberg"<mika.westerberg@...ux.intel.com>; "andriy.shevchenko"<andriy.shevchenko@...ux.intel.com>; "p.zabel"<p.zabel@...gutronix.de>;
> Subject: Re: [PATCH] i2c: designware: I2C unexpected interrupt handling will cause kernel panic
>
>
>
> Hi
>
> On 11/11/21 8:57 AM, huangbibo wrote:
> > I2C interrupts may be triggered unexpectedly,
> > such as programs that directly access I2C registers,
> > bus conflicts caused by hardware design defects, etc.
> > These can cause null pointer reference errors and kernel panic.
> >
> > kernel log:
> > [ 52.676442] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
> > ...
> > [ 52.816536] Workqueue: efi_rts_wq efi_call_rts
> > [ 52.820968] pstate: 60000085 (nZCv daIf -PAN -UAO)
> > [ 52.825753] pc : i2c_dw_isr+0x36c/0x5e0 [i2c_designware_core]
> > [ 52.831487] lr : i2c_dw_isr+0x88/0x5e0 [i2c_designware_core]
> > [ 52.837134] sp : ffff8020fff17650
> > [ 52.924451] Call trace:
> > [ 52.926888] i2c_dw_isr+0x36c/0x5e0 [i2c_designware_core]
> > ...
> > [ 52.957394] gic_handle_irq+0x7c/0x178
> > [ 52.961130] el1_irq+0xb0/0x140
> > [ 52.964259] 0x21291d30
> > [ 52.983729] 0x21160938
> > [ 52.986164] __efi_rt_asm_wrapper+0x28/0x44
> > [ 52.990335] efi_call_rts+0x78/0x448
> > [ 53.019021] Kernel panic - not syncing: Fatal exception in interrupt
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists