From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Aug 2014 16:45:44 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1]:52504 "EHLO linux-mips.org" rhost-flags-OK-OK-OK-FAIL) by eddie.linux-mips.org with ESMTP id S6901534AbaHNOpipnMlR (ORCPT ); Thu, 14 Aug 2014 16:45:38 +0200 Received: from scotty.linux-mips.net (localhost.localdomain [127.0.0.1]) by scotty.linux-mips.net (8.14.8/8.14.8) with ESMTP id s7EEjaZr017357; Thu, 14 Aug 2014 16:45:36 +0200 Received: (from ralf@localhost) by scotty.linux-mips.net (8.14.8/8.14.8/Submit) id s7EEjZ00017356; Thu, 14 Aug 2014 16:45:35 +0200 Date: Thu, 14 Aug 2014 16:45:35 +0200 From: Ralf Baechle To: Sergey Ryazanov Cc: Linux MIPS Subject: Re: [PATCH 1/2] MIPS: MSP71xx: remove unused plat_irq_dispatch() argument Message-ID: <20140814144535.GG21008@linux-mips.org> References: <1407967776-7320-1-git-send-email-ryazanov.s.a@gmail.com> <1407967776-7320-2-git-send-email-ryazanov.s.a@gmail.com> <20140814124652.GE21008@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 42098 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips On Thu, Aug 14, 2014 at 06:39:17PM +0400, Sergey Ryazanov wrote: > >> Remove unused argument to make the plat_irq_dispatch() function > >> declaration similar to the realization of other platforms. > > > > The issue may be harmless but the regs argument of the false argument > > isn't even being passed in! > > > IMHO, this argument can't cause smth terrible, until nobody tries to > access it, but I can mistake. Correct. In this particular case it appears that the value passed for regs is whatever value there was in $a0 in the interrupted code. Dereferencing that kind of value would most likely be lethal and crash the kernel during bootup. Ralf