Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754701AbbDUOkA (ORCPT ); Tue, 21 Apr 2015 10:40:00 -0400 Received: from www.linutronix.de ([62.245.132.108]:58511 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750937AbbDUOj6 (ORCPT ); Tue, 21 Apr 2015 10:39:58 -0400 Date: Tue, 21 Apr 2015 16:40:16 +0200 (CEST) From: Thomas Gleixner To: Semen Protsenko cc: linux-kernel@vger.kernel.org, Grygorii Strashko , Linus Walleij Subject: Re: [PATCH] genirq: check irq_ack callback in handle_edge_irq() before calling In-Reply-To: <1429621752-19082-1-git-send-email-semen.protsenko@globallogic.com> Message-ID: References: <1429621752-19082-1-git-send-email-semen.protsenko@globallogic.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1399 Lines: 35 On Tue, 21 Apr 2015, Semen Protsenko wrote: > Direct calling of .irq_ack callback (from struct irq_chip) leads to NULL > pointer dereference in some cases. E.g. this was observed for MAX732X > driver on hibernation: > > Unable to handle kernel NULL pointer dereference at virtual address 0 > Backtrace: > (handle_edge_irq) from (resend_irqs) > (resend_irqs) from (tasklet_action) > (tasklet_action) from (__do_softirq) > (__do_softirq) from (run_ksoftirqd) > (run_ksoftirqd) from (smpboot_thread_fn) > (smpboot_thread_fn) from (kthread) > (kthread) from (ret_from_fork) > > This patch checks if .irq_ack was set, so in case it wasn't (i.e. it's > NULL) we wouldn't have NULL pointer dereference. This check seems to > be pretty common in kernel/irq/chip.c, but it was missed for > handle_edge_irq() function. No, it's not missing by chance. It's missing on purpose. The edge handler is designed to deal with edge type interrupt chips and those have an ACK by definition. You are fixing the wrong place. That GPIO expander is using the wrong flow handler. It should not use the edge handler at all. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/