Commit graph

6 commits

Author SHA1 Message Date
James Bottomley
e12f0a3dec [SCSI] sr: partial revert of 24669f75a3
The patch

[SCSI] SCSI core kmalloc2kzalloc

Has an incorrect piece in sr_ioctl.c; it changes buffer from kmalloc
to kzalloc, but then removes the clearing of the stack variable struct
packet_command.  This, in turn leaves rubbish in the sense pointer
which the sr_do_ioctl() command then happily writes to ... oops.

Thanks to Mike Christie <michaelc@cs.wisc.edu> for spotting this.

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-03-07 14:53:40 -06:00
Jes Sorensen
24669f75a3 [SCSI] SCSI core kmalloc2kzalloc
Change the core SCSI code to use kzalloc rather than kmalloc+memset
where possible.

Signed-off-by: Jes Sorensen <jes@sgi.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-02-27 22:55:02 -06:00
Christoph Hellwig
a09c631121 [SCSI] sr: split sr_audio_ioctl into specific helpers
split each ioctl handled in sr_audio_ioctl into a function of it's own.
This cleans the code up nicely, and allows various places in sr_ioctl
to call these helpers directly instead of going through the multiplexer.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jens Axboe <axboe@suse.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-01-14 10:54:46 -06:00
James Bottomley
820732b501 [SCSI] convert sr to scsi_execute_req
This follows almost the identical model to sd, except that there's one
ioctl which returns raw sense data, so it had to use scsi_execute()
instead.

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-08-28 11:34:07 -05:00
Nate Dailey
3a73e8c771 [SCSI] drivers/scsi/sr_ioctl.c: check for failed allocation
I noticed a case in sr_ioctl.c's sr_get_mcn where a buffer is
allocated, but the pointer isn't checked for null.

Signed-off-by: Nate Dailey <nate.dailey@stratus.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-04-21 16:14:05 -04:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00