linux-kernel - Re: Access to struct file in scsi_request

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>] [day] [month] [year] [list]

Date:	Thu, 03 Apr 2008 22:20:34 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	"hectorlas@...oo.com" <hectorlas@...oo.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Access to struct file in scsi_request_fn()?

hectorlas@...oo.com wrote:
> Here's the short question:  Is there a way to access the struct file
> associated with a write() within the libATA code?
> 
> I've been documenting the semi-direct execution path from a file I/O
> open() call down to the ata_scsi_rw_xlat() call in libATA.  I'd like
> to modify my local libATA code to do something based on the file being
> operated on using a flag that I still need to store in struct file,
> perhaps through the private_data field (I haven't worked that out
> yet).  The scsi_request_fn() gets a struct request_queue argument that
> has a lot of contexts in it.  Could anyone help me with information on
> whether the struct file * is in it somewhere?  I know there's some
> kind of cohesion between submitting the scsi command and its
> completion function, but I'm not quite seeing it yet.
> 
> That was painful to write, I'm sure it was painful to read, sorry
> about that.  I'm learning more and more as I go, but the big picture
> is still escaping me.
> 
> Thanks.
> Hector

I think that this is likely not a good approach for whatever you're 
attempting to do (and you would likely get better responses if you 
described what exactly that is). By the time libata or even the SCSI 
layer gets a write request, that is pretty well removed from the 
original file operation. They may be quite highly separated in time due 
to write buffering for one thing.
--
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/