linux-kernel - Re: [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 19 May 2011 13:08:38 +0900
From:	Hitoshi Mitake <h.mitake@...il.com>
To:	"Moore, Eric" <Eric.Moore@....com>
Cc:	Milton Miller <miltonm@....com>, Sam Ravnborg <sam@...nborg.org>,
	Ingo Molnar <mingo@...e.hu>, Ingo Molnar <mingo@...hat.com>,
	"Desai, Kashyap" <Kashyap.Desai@....com>,
	"Prakash, Sathya" <Sathya.Prakash@....com>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	Matthew Wilcox <matthew@....cx>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	linux scsi dev <linux-scsi@...r.kernel.org>,
	"paulus@...ba.org" <paulus@...ba.org>,
	linux powerpc dev <linuxppc-dev@...ts.ozlabs.org>,
	linux pci <linux-pci@...r.kernel.org>,
	linux kernel <linux-kernel@...r.kernel.org>,
	linux-arch <linux-arch@...r.kernel.org>
Subject: Re: [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is
 not atomic

On Thu, May 19, 2011 at 04:11, Moore, Eric <Eric.Moore@....com> wrote:
> On Wednesday, May 18, 2011 12:31 PM Milton Miller wrote:
>> Ingo I would propose the following commits added in 2.6.29 be reverted.
>> I think the current concensus is drivers must know if the writeq is
>> not atomic so they can provide their own locking or other workaround.
>>
>
>
> Exactly.
>

The original motivation of preparing common readq/writeq is that
letting each driver
have their own readq/writeq is bad for maintenance of source code.

But if you really dislike them, there might be two solutions:

1. changing the name of readq/writeq to readq_nonatomic/writeq_nonatomic
2. adding new C file to somewhere and defining spinlock for them.
    With spin_lock_irqsave() and spin_unlock_irqrestore() on the spinlock,
    readq/writeq can be atomic.

How do you think about them? If you cannot agree with the above two solutions,
I'll agree with reverting them.

-- 
Hitoshi Mitake
h.mitake@...il.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/