headers
Jianjun Kong | 1 Jan 2009 05:51

[PATCH] scsi: fix kernel-doc warning


scsi: fix kernel-doc warning

Fix kernel-doc parameter warning:
Warning(/media/sda1/Project/linux-2.6//drivers/scsi/scsi_sysfs.c:1049): Excess function
parameter 'dev'
description in 'scsi_sysfs_add_host'

Signed-off-by: Jianjun Kong <jianjun <at> zeuux.org>
---
 drivers/scsi/scsi_sysfs.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 93c28f3..eda8f1a 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
 <at>  <at>  -1043,7 +1043,6  <at>  <at>  EXPORT_SYMBOL(scsi_register_interface);
 /**
  * scsi_sysfs_add_host - add scsi host to subsystem
  *  <at> shost:     scsi host struct to add to subsystem
- *  <at> dev:       parent struct device pointer
  **/
 int scsi_sysfs_add_host(struct Scsi_Host *shost)
 {
--

-- 
1.5.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Boaz Harrosh | 1 Jan 2009 10:19
Favicon
Gravatar

Re: [PATCH] scsi: Add VPD helper

Matthew Wilcox wrote:
> Based on prior work by Martin Petersen and James Bottomley, this patch
> adds a generic helper for retrieving VPD pages from SCSI devices.
> 
> Signed-off-by: Matthew Wilcox <willy <at> linux.intel.com>
> ---
>  drivers/scsi/scsi.c        |  104 ++++++++++++++++++++++++++++++++++++++++++++
>  include/scsi/scsi_device.h |    1 +
>  2 files changed, 105 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
> index f8b79d4..46b7942 100644
> --- a/drivers/scsi/scsi.c
> +++ b/drivers/scsi/scsi.c
>  <at>  <at>  -971,6 +971,110  <at>  <at>  int scsi_track_queue_full(struct scsi_device *sdev, int depth)
>  EXPORT_SYMBOL(scsi_track_queue_full);
>  
>  /**
> + * scsi_vpd_inquiry - Request a device provide us with a VPD page
> + *  <at> sdev: The device to ask
> + *  <at> buffer: Where to put the result
> + *  <at> page: Which Vital Product Data to return
> + *  <at> len: The length of the buffer
> + *
> + * This is an internal helper function.  You probably want to use
> + * scsi_get_vpd_page instead.
> + *
> + * Returns 0 on success or a negative error number.
> + */
> +static int scsi_vpd_inquiry(struct scsi_device *sdev, unsigned char *buffer,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Benny Halevy | 1 Jan 2009 10:22
Favicon

Re: [osd-dev] [PATCH 7/9] exofs: mkexofs

On Dec. 31, 2008, 17:57 +0200, James Bottomley <James.Bottomley <at> HansenPartnership.com> wrote:
> On Wed, 2008-12-31 at 17:19 +0200, Boaz Harrosh wrote:
>> Andrew Morton wrote:
>>> On Tue, 16 Dec 2008 17:33:48 +0200
>>> Boaz Harrosh <bharrosh <at> panasas.com> wrote:
>>>
>>>> We need a mechanism to prepare the file system (mkfs).
>>>> I chose to implement that by means of a couple of
>>>> mount-options. Because there is no user-mode API for committing
>>>> OSD commands. And also, all this stuff is highly internal to
>>>> the file system itself.
>>>>
>>>> - Added two mount options mkfs=0/1,format=capacity_in_meg, so mkfs/format
>>>>   can be executed by kernel code just before mount. An mkexofs utility
>>>>   can now be implemented by means of a script that mounts and unmount the
>>>>   file system with proper options.
>>> Doing mkfs in-kernel is unusual.  I don't think the above description
>>> sufficiently helps the uninitiated understand why mkfs cannot be done
>>> in userspace as usual.  Please flesh it out a bit.
>> There are a few main reasons.
>> - There is no user-mode API for initiating OSD commands. Such a subsystem
>>   would be hundredfold bigger then the mkfs code submitted. I think it would be
>>   hard and stupid to maintain a complex user-mode API just for creating
>>   a couple of objects and writing a couple of on disk structures.
> 
> This is really a reflection of the whole problem with the OSD paradigm.
> 
> In theory, a filesystem on OSD is a thin layer of metadata mapping
> objects to files.  Get this right and the storage will manage things,
> like security and access and attributes (there's even a natural mapping
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Garzik | 1 Jan 2009 10:54
Favicon

Re: [osd-dev] [PATCH 7/9] exofs: mkexofs

Benny Halevy wrote:
> On Dec. 31, 2008, 17:57 +0200, James Bottomley <James.Bottomley <at> HansenPartnership.com> wrote:
>> On Wed, 2008-12-31 at 17:19 +0200, Boaz Harrosh wrote:
>>> Andrew Morton wrote:
>>>> On Tue, 16 Dec 2008 17:33:48 +0200
>>>> Boaz Harrosh <bharrosh <at> panasas.com> wrote:
>>>>
>>>>> We need a mechanism to prepare the file system (mkfs).
>>>>> I chose to implement that by means of a couple of
>>>>> mount-options. Because there is no user-mode API for committing
>>>>> OSD commands. And also, all this stuff is highly internal to
>>>>> the file system itself.
>>>>>
>>>>> - Added two mount options mkfs=0/1,format=capacity_in_meg, so mkfs/format
>>>>>   can be executed by kernel code just before mount. An mkexofs utility
>>>>>   can now be implemented by means of a script that mounts and unmount the
>>>>>   file system with proper options.
>>>> Doing mkfs in-kernel is unusual.  I don't think the above description
>>>> sufficiently helps the uninitiated understand why mkfs cannot be done
>>>> in userspace as usual.  Please flesh it out a bit.
>>> There are a few main reasons.
>>> - There is no user-mode API for initiating OSD commands. Such a subsystem
>>>   would be hundredfold bigger then the mkfs code submitted. I think it would be
>>>   hard and stupid to maintain a complex user-mode API just for creating
>>>   a couple of objects and writing a couple of on disk structures.
>> This is really a reflection of the whole problem with the OSD paradigm.
>>
>> In theory, a filesystem on OSD is a thin layer of metadata mapping
>> objects to files.  Get this right and the storage will manage things,
>> like security and access and attributes (there's even a natural mapping
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexey Zaytsev | 1 Jan 2009 12:08
Picon
Gravatar

Re: [PATCH] Fix sg_io_hdr.info corruption.

[resending in case you missed the one I sent with broken headers]

On Wed, Dec 31, 2008 at 12:08, FUJITA Tomonori <fujita.tomonori <at> lab.ntt.co.jp> wrote:
> On Tue, 30 Dec 2008 15:46:03 -0800
> Andrew Morton <akpm <at> linux-foundation.org> wrote:
[...]
>> the code has been like this for years and years.  Why hasn't anyone
>> noticed?
>
> The members from 'status' in struct sg_io_hdr to the last are used to
> transfer information from kernel to user space. The values that user
> space sets are just ignored.
>

Then probably there is no need to copy those fields, right?
There should be no data leak from the kernel, as sgio is
allocated on the userspace stack, and the appropriate ioctl
handler should set/zero all those fields anyway, as it expects
them to come directly from the user (did not check).
So, in the worst case the user gets his own garbage insted of
the values he left in the fields that the kernel was supposed
to set.

If so, please drop my previous patch and take this one.

From: Alexey Zaytsev <alexey.zaytsev <at> gmail.com>
Subject: [PATCH] Don't perform unneeded copy.

FUJITA Tomonori <fujita.tomonori <at> lab.ntt.co.jp> says:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Boaz Harrosh | 1 Jan 2009 14:33
Favicon
Gravatar

Re: [PATCH 7/9] exofs: mkexofs

Andrew Morton wrote:
>>> Boaz Harrosh <bharrosh <at> panasas.com> wrote:
>> When, if, all is fixed, through which tree/maintainer can exofs be submitted?
> 
> I can merge them.  Or you can run a git tree of your own, add it to
> linux-next and ask Linus to pull it at the appropriate time.
> 

Hi James

Andrew suggested that maybe I should push exofs file system directly to
Linus as it is pretty orthogonal to any other work. Sitting in linux-next
will quickly expose any advancements in VFS and will force me to keep
the tree uptodate.

If that is so, and is accepted by Linus, would you rather that also the
open-osd initiator library will be submitted through the same tree?
The conflicts with scsi are very very narrow. The only real dependency
is the ULD being a SCSI ULD. I will routinely ask your ACK on any scsi 
or ULD related patches. Which are very few. This way it will be easier
to manage the dependencies between the OSD work, the OSD pNFS-Objects
trees at pNFS project, and the pNFSD+EXOFS export. One less dependency.

[I already have such a public tree at git.open-osd.org for a while now]

Thanks
Boaz

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthew Wilcox | 1 Jan 2009 14:38

Re: [PATCH] scsi: Add VPD helper

On Thu, Jan 01, 2009 at 11:19:33AM +0200, Boaz Harrosh wrote:
> +	buffer[1] = -1;
> see below
> > +	/*
> > +	 * I'm not convinced we need to try quite this hard to get VPD, but
> > +	 * all the existing users tried this hard.
> > +	 */
> > +	result = scsi_execute_req(sdev, cmd, DMA_FROM_DEVICE, buffer,
> > +				  len + 4, NULL, 30 * HZ, 3, NULL);
> > +	if (result)
> > +		return result;
> > +
> > +	/* Sanity check that we got the page back that we asked for */
> > +	if (buffer[1] != page)
> > +		return -EIO;
> 
> Maybe it's just me but, if you are going to if() on a buffer byte, then you need
> to make sure its initial value. Or at least document the need for a -1 at
> buffer[1]

buffer[] is an array of unsigned char, so -1 is 255.  We could be asking
for page 0xff, so your initialisation doesn't help reject bogus data.

Your concern here, presumably, is that the device might transfer less than
two bytes, and not return an error.  I think this is quite unlikely --
and in any case, such a misbehaving device is really no different from a
device which transfers complete garbage.

I suppose we could pass a 'resid' to scsi_execute_req and check that at
least four bytes was transferred.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Benny Halevy | 1 Jan 2009 15:23
Favicon

Re: [osd-dev] [PATCH 7/9] exofs: mkexofs

On Jan. 01, 2009, 11:54 +0200, Jeff Garzik <jeff <at> garzik.org> wrote:
> Benny Halevy wrote:
>> On Dec. 31, 2008, 17:57 +0200, James Bottomley <James.Bottomley <at> HansenPartnership.com> wrote:
>>> On Wed, 2008-12-31 at 17:19 +0200, Boaz Harrosh wrote:
>>>> Andrew Morton wrote:
>>>>> On Tue, 16 Dec 2008 17:33:48 +0200
>>>>> Boaz Harrosh <bharrosh <at> panasas.com> wrote:
>>>>>
>>>>>> We need a mechanism to prepare the file system (mkfs).
>>>>>> I chose to implement that by means of a couple of
>>>>>> mount-options. Because there is no user-mode API for committing
>>>>>> OSD commands. And also, all this stuff is highly internal to
>>>>>> the file system itself.
>>>>>>
>>>>>> - Added two mount options mkfs=0/1,format=capacity_in_meg, so mkfs/format
>>>>>>   can be executed by kernel code just before mount. An mkexofs utility
>>>>>>   can now be implemented by means of a script that mounts and unmount the
>>>>>>   file system with proper options.
>>>>> Doing mkfs in-kernel is unusual.  I don't think the above description
>>>>> sufficiently helps the uninitiated understand why mkfs cannot be done
>>>>> in userspace as usual.  Please flesh it out a bit.
>>>> There are a few main reasons.
>>>> - There is no user-mode API for initiating OSD commands. Such a subsystem
>>>>   would be hundredfold bigger then the mkfs code submitted. I think it would be
>>>>   hard and stupid to maintain a complex user-mode API just for creating
>>>>   a couple of objects and writing a couple of on disk structures.
>>> This is really a reflection of the whole problem with the OSD paradigm.
>>>
>>> In theory, a filesystem on OSD is a thin layer of metadata mapping
>>> objects to files.  Get this right and the storage will manage things,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthew Wilcox | 1 Jan 2009 15:28

Re: [osd-dev] [PATCH 7/9] exofs: mkexofs

On Thu, Jan 01, 2009 at 04:23:00PM +0200, Benny Halevy wrote:
> Personally, I'm not sure if maintaining that intimate knowledge in a
> user space program is an ideal model with respect to keeping both
> in sync, avoiding code duplication, and dealing with upgrade issues
> (e.g. upgrading the kernel and not the user space utils)

The other 30-40 filesystems that Linux supports manage to do it this
way.  I'm not sure why osdfs is different in this regard.

You need to be careful with the filesystem layout anyway -- when you
upgrade the kernel, it still needs to be able to access all the files
contained in existing filesystems.  And it needs to create new files
which are still readable by older kernels (users have this pesky habit
of downgrading).

--

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Douglas Gilbert | 1 Jan 2009 15:54
Picon

Re: [PATCH] Fix sg_io_hdr.info corruption.

Alexey Zaytsev wrote:
> [resending in case you missed the one I sent with broken headers]
> 
> On Wed, Dec 31, 2008 at 12:08, FUJITA Tomonori <fujita.tomonori <at> lab.ntt.co.jp> wrote:
>> On Tue, 30 Dec 2008 15:46:03 -0800
>> Andrew Morton <akpm <at> linux-foundation.org> wrote:
> [...]
>>> the code has been like this for years and years.  Why hasn't anyone
>>> noticed?
>> The members from 'status' in struct sg_io_hdr to the last are used to
>> transfer information from kernel to user space. The values that user
>> space sets are just ignored.
>>
> 
> Then probably there is no need to copy those fields, right?

Correct.

Doug Gilbert

> There should be no data leak from the kernel, as sgio is
> allocated on the userspace stack, and the appropriate ioctl
> handler should set/zero all those fields anyway, as it expects
> them to come directly from the user (did not check).
> So, in the worst case the user gets his own garbage insted of
> the values he left in the fields that the kernel was supposed
> to set.
> 
> If so, please drop my previous patch and take this one.
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane