linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Pete Zaitcev <zaitcev@redhat.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: akpm@linux-foundation.org, oliver.pntr@gmail.com,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org, jmorris@namei.org,
	linux-usb@vger.kernel.org, zaitcev@redhat.com
Subject: Re: [2.6.24 REGRESSION] BUG: Soft lockup - with VFS
Date: Mon, 11 Feb 2008 18:12:54 -0800	[thread overview]
Message-ID: <20080211181254.5029b8b4.zaitcev@redhat.com> (raw)
In-Reply-To: <20080212104612S.fujita.tomonori@lab.ntt.co.jp>

On Tue, 12 Feb 2008 10:46:12 +0900, FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:

> On a serious note, it seems that two scatter lists per request leaded
> to this bug. Can the scatter list in struct ub_request be removed?

Good question. It's an eyesore to be sure. The duplication exists
for the sake of retries combined with the separation of requests
from commands.

Please bear with me, if you're curious: commands can be launched
without requests (at probe time, for instance, or when sense is
requested). So, they need an s/g table. But then, the lifetime of
a request is greater than than of a command, in case of a retry
especially. Therefore a request needs the s/g table too.

So, one way to kill this duplication is to mandate that a
request existed for every command. It seemed like way more code
than just one memcpy() when I wrote it.

Another way would be to make commands flexible, e.g. sometimes with
just a virtual address and size, sometimes with an s/g table.
If you guys make struct scatterlist illegal to copy with memcpy
one day, this is probably what I'll do.

-- Pete

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      reply	other threads:[~2008-02-12  2:12 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-28  8:31 [2.6.24 REGRESSION] BUG: Soft lockup - with VFS Oliver Pinter (Pintér Olivér)
2008-01-28 16:25 ` Oliver Pinter (Pintér Olivér)
2008-01-28 16:27   ` Oliver Pinter (Pintér Olivér)
2008-02-05  5:39 ` Andrew Morton
2008-02-05 10:02   ` James Morris
2008-02-05 13:46   ` Stephen Smalley
2008-02-05 18:40     ` Andrew Morton
     [not found]       ` <6101e8c40802051115v12d3c02br24873ef1014dbea9@mail.gmail.com>
     [not found]         ` <6101e8c40802051321l13268239m913fd90f56891054@mail.gmail.com>
2008-02-05 21:48           ` Oliver Pinter
2008-02-05 22:05             ` Andrew Morton
2008-02-05 22:19               ` Pete Zaitcev
2008-02-05 22:29                 ` Oliver Pinter
2008-02-05 22:35                   ` Oliver Pinter
2008-02-09  7:46               ` Pete Zaitcev
2008-02-12  1:46                 ` FUJITA Tomonori
2008-02-12  2:12                   ` Pete Zaitcev [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080211181254.5029b8b4.zaitcev@redhat.com \
    --to=zaitcev@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=jmorris@namei.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=oliver.pntr@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).