Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757946Ab0GVBYS (ORCPT ); Wed, 21 Jul 2010 21:24:18 -0400 Received: from fgwmail7.fujitsu.co.jp ([192.51.44.37]:37533 "EHLO fgwmail7.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755013Ab0GVBYQ (ORCPT ); Wed, 21 Jul 2010 21:24:16 -0400 X-SecurityPolicyCheck-FJ: OK by FujitsuOutboundMailChecker v1.3.1 Message-ID: <4C479D7F.2070204@jp.fujitsu.com> Date: Thu, 22 Jul 2010 10:23:11 +0900 From: Hidetoshi Seto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "H. Peter Anvin" CC: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org, James Smart , Thomas Gleixner , Ingo Molnar , x86@kernel.org, Brian Gerst Subject: Re: [PATCH] BISECTED x86: avoid qword access in memcpy_*io References: <4C464BA0.20609@jp.fujitsu.com> <4C465FF0.1030407@zytor.com> In-Reply-To: <4C465FF0.1030407@zytor.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2401 Lines: 60 (2010/07/21 11:48), H. Peter Anvin wrote: > On 07/20/2010 06:21 PM, Hidetoshi Seto wrote: >> With v2.6.35-rc5, my x86-64 server doesn't boot but reports a >> Completer Abort on lpfc card. >> >> The result of git-bisect is: >> 6175ddf06b6172046a329e3abfd9c901a43efd2e is the first bad commit >> commit 6175ddf06b6172046a329e3abfd9c901a43efd2e >> Author: Brian Gerst >> Date: Fri Feb 5 09:37:07 2010 -0500 >> x86: Clean up mem*io functions. >> >> What I found are: >> - memcpy for 64bit uses movq if count >= 64 (arch/x86/lib/memcpy_64.S) >> - memcpy_toio and memcpy_fromio have changed to use this memcpy by >> the above commit. >> - my debug shows that lpfc calls memcpy_toio with not-qword-aligned >> addresses and count >= 64, e.g.: >> memcpy_toio(0xffffc900118de004, 0xffff88047293d614, 124); >> and it seems that it comes from: >> [drivers/scsi/lpfc/lpfc_sli.c] >> 4929 /* First copy mbox command data to HBA SLIM, skip past first >> 4930 word */ >> 4931 to_slim = phba->MBslimaddr + sizeof (uint32_t); >> 4932 lpfc_memcpy_to_slim(to_slim, &mb->un.varWords[0], >> 4933 MAILBOX_CMD_SIZE - sizeof (uint32_t)); >> >> Still I'm not sure what is wrong in software or hardware, however >> I suppose that qword access to iomem is not always safe, so it will >> be OK to back to use __inline_memcpy which uses movsl. >> >> I confirmed that my server (w/ lpfc) boots with 35-rc5 + this patch. >> >> Signed-off-by: Hidetoshi Seto > > A driver should not use the memcpy-like instructions if it isn't set up > to act as memory (meaning it can handle arbitrary byte enables.) So then is this a problem of lpfc driver? James, could you agree on that? > The function it should be using is called, fairly counterintuitively, > __iowrite32_copy(). It really should be called memcpy_toio32() or > something similar. > > -hpa It seems that lpfc already implemented lpfc_memcpy_{to,from}_slim() as such memcpy_*io32, but limited use of it to on big endian platforms only. Now lpfc can move to use it always, right? Thanks, H.Seto -- 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/