From patchwork Tue Jun 23 14:34:17 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Catalin Marinas X-Patchwork-Id: 29059 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by bilbo.ozlabs.org (Postfix) with ESMTP id 0C770B70B4 for ; Wed, 24 Jun 2009 00:35:38 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757189AbZFWOfJ (ORCPT ); Tue, 23 Jun 2009 10:35:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755095AbZFWOfI (ORCPT ); Tue, 23 Jun 2009 10:35:08 -0400 Received: from cam-admin0.cambridge.arm.com ([193.131.176.58]:32931 "EHLO cam-admin0.cambridge.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754544AbZFWOfH (ORCPT ); Tue, 23 Jun 2009 10:35:07 -0400 Received: from cam-owa1.Emea.Arm.com (cam-owa1.emea.arm.com [10.1.255.62]) by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id n5NEVaZm015889; Tue, 23 Jun 2009 15:31:36 +0100 (BST) Received: from [10.1.68.81] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 23 Jun 2009 15:34:18 +0100 Subject: Re: Rootfs in eMMC: Kernel panic ...Attempted to kill init! From: Catalin Marinas To: Russell King - ARM Linux Cc: Sudeep K N , linux-arm-kernel@lists.arm.linux.org.uk, drzeus-mmc@drzeus.cx, linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org In-Reply-To: <20090622164604.GG29188@n2100.arm.linux.org.uk> References: <20090622164604.GG29188@n2100.arm.linux.org.uk> Organization: ARM Ltd Date: Tue, 23 Jun 2009 15:34:17 +0100 Message-Id: <1245767657.16488.38.camel@pc1117.cambridge.arm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-OriginalArrivalTime: 23 Jun 2009 14:34:18.0593 (UTC) FILETIME=[B0E00D10:01C9F40F] Sender: linux-ide-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ide@vger.kernel.org On Mon, 2009-06-22 at 17:46 +0100, Russell King - ARM Linux wrote: > On Mon, Jun 22, 2009 at 05:13:16PM +0100, Catalin Marinas wrote: > > In my case (ext2 over pata_platform), there is no flush_dcache_page() > > call after the page was written with data from the CompactFlash (neither > > the driver nor the VFS layer do this and we used hardware tracing to > > double-check). When the page is mapped into user space, > > update_mmu_cache() is called but the page hasn't been marked as dirty > > and no D-cache flushing occurs. Calling flush_dcache_page() in > > mpage_end_io_read() works around this issue. > > As already covered, there's no chance of adding such a call to the > generic kernel. It's the responsibility of the drivers to ensure that > data they read in hits the underlying page - in the same way that DMA > does. The patch below appears to solve the problem with CompactFlash using pata_platform (I cc'ed linux-ide since the patch changes their code). The patch only handles the read case but similarly it may need to handle the write case if D-cache aliasing between user and kernel mappings exists. For the USB mass storage, I haven't yet figured out the best place to call flush_dcache_page(). Call flush_dcache_page after PIO data transfer in libata-aff.c From: Catalin Marinas When reading data from an ATA device using PIO, the kernel dirties the D-cache but there is no flush_dcache_page() call in ata_pio_sector(). Since neither the VFS layer calls this function, a subsequent update_mmu_cache() is not aware of the dirty page which may lead to cache incoherency in user space. Signed-off-by: Catalin Marinas --- drivers/ata/libata-sff.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c index bbbb1fa..2ae15c3 100644 --- a/drivers/ata/libata-sff.c +++ b/drivers/ata/libata-sff.c @@ -893,6 +893,9 @@ static void ata_pio_sector(struct ata_queued_cmd *qc) do_write); } + if (!do_write) + flush_dcache_page(page); + qc->curbytes += qc->sect_size; qc->cursg_ofs += qc->sect_size;