linux-kernel - Re: [GIT PULL] two more s390 bug fixes for 4.17

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]

Message-Id: <alpine.LFD.2.21.1805301425580.1717@schleppi>
Date:   Wed, 30 May 2018 14:59:58 +0200 (CEST)
From:   Sebastian Ott <sebott@...ux.ibm.com>
To:     Christoph Hellwig <hch@...radead.org>
cc:     Martin Schwidefsky <schwidefsky@...ibm.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-s390 <linux-s390@...r.kernel.org>,
        Heiko Carstens <heiko.carstens@...ibm.com>
Subject: Re: [GIT PULL] two more s390 bug fixes for 4.17

On Wed, 30 May 2018, Christoph Hellwig wrote:

> > -	req->completion_data = cqr;
> > +	*((struct dasd_ccw_req **) blk_mq_rq_to_pdu(req)) = cqr;
> > +
> 
> Please don't play such tricks.  In general your driver structure
> should have struct request embedded.  If for some reason
> struct dasd_ccw_req has a different life time please create a new
> structure instead of these hacks.

Would you agree that this is an improvement over using completion_data
(at least now we don't mess with the block layers internal data)?

I already looked into what needs to be done to put struct dasd_ccw_req
behind the request and let it be managed by the block layer.

My concerns are lifetime and memory constraints (some of our HW interfaces
still use 31 bit pointers) but I think both of these are manageable with
the blk-mq interfaces.

But this would not be a small change and nothing for rc7. Would you be
OK with doing the small fix now and I'll work on the mentioned
improvement?

Regards,
Sebastian