All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitriy Monakhov <dmonakhov@sw.ru>
To: Nick Piggin <npiggin@suse.de>
Cc: Dmitriy Monakhov <dmonakhov@sw.ru>,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	devel@openvz.org
Subject: Re: [PATCH 1/2] mm: move common segment checks to separate helper function (v6)
Date: Mon, 12 Mar 2007 21:32:28 +0300	[thread overview]
Message-ID: <874poq1fer.fsf@sw.ru> (raw)
In-Reply-To: <20070312083110.GB28546@wotan.suse.de> (Nick Piggin's message of "Mon, 12 Mar 2007 09:31:10 +0100")

Nick Piggin <npiggin@suse.de> writes:

> On Mon, Mar 12, 2007 at 10:57:53AM +0300, Dmitriy Monakhov wrote:
>> I realy don't want to be annoying by sending this patcheset over and over
>> again. If anyone think this patch is realy cappy, please comment what 
>> exectly is bad. Thank you.
>
> Doesn't seem like a bad idea.
>
>> 
>> Changes:
>>   - patch was split in two patches.

>> +/*
>> + * Performs necessary checks before doing a write
>> + *
>> + * Adjust number of segments and amount of bytes to write.
>> + * Returns appropriate error code that caller should return or
>> + * zero in case that write should be allowed.
>> + */
>> +inline int generic_segment_checks(const struct iovec *iov,
>> +			unsigned long *nr_segs, size_t *count,
>> +			unsigned long access_flags)
>
> Make it static and not inline, and the compiler will work it out.
Wow i've just carefully checked and found more functions with duplicating code:
fs/xfs/linux-2.6/xfs_lrw.c:655 xfs_write()
fs/ntfs/file.c:2339 ntfs_file_aio_write_nolock()
So i think nobody will object against exporting generic_segment_checks()
and removing doplicating code.
>
> This function name doesn't really imply that it returns you the
> nr_segs and count, but that's not a big deal I guess.
>
> You also don't say that nr_segs should be initialised to the amount
> you which to write, while count must be initialised to zero.
>
>> +{
>> +	unsigned long   seg;
>> +	for (seg = 0; seg < *nr_segs; seg++) {
>> +		const struct iovec *iv = &iov[seg];
>> +
>> +		/*
>> +		 * If any segment has a negative length, or the cumulative
>> +		 * length ever wraps negative then return -EINVAL.
>> +		 */
>> +		*count += iv->iov_len;
>> +		if (unlikely((ssize_t)(*count|iv->iov_len) < 0))
>> +			return -EINVAL;
>> +		if (access_ok(access_flags, iv->iov_base, iv->iov_len))
>> +			continue;
>
> Why now insert the above test, and put the below statements inside the
> branch? OTOH, that makes it less obviously c&p from the others. Maybe
> a subsequent patch.
>
>> +		if (seg == 0)
>> +			return -EFAULT;
>> +		*nr_segs = seg;
>> +		*count -= iv->iov_len;	/* This segment is no good */
>> +		break;
>> +	}
>
>
> You could assign to *count here, once, and remove the requirement
> that the caller initialised it to zero?
>
>> +	return 0;
>> +}
>> +
>>  /**
>>   * generic_file_aio_read - generic filesystem read routine
>>   * @iocb:	kernel I/O control block
>> @@ -1180,24 +1213,9 @@ generic_file_aio_read(struct kiocb *iocb, const struct iovec *iov,
>>  	loff_t *ppos = &iocb->ki_pos;
>>  
>>  	count = 0;
>> -	for (seg = 0; seg < nr_segs; seg++) {
>> -		const struct iovec *iv = &iov[seg];
>> -
>> -		/*
>> -		 * If any segment has a negative length, or the cumulative
>> -		 * length ever wraps negative then return -EINVAL.
>> -		 */
>> -		count += iv->iov_len;
>> -		if (unlikely((ssize_t)(count|iv->iov_len) < 0))
>> -			return -EINVAL;
>> -		if (access_ok(VERIFY_WRITE, iv->iov_base, iv->iov_len))
>> -			continue;
>> -		if (seg == 0)
>> -			return -EFAULT;
>> -		nr_segs = seg;
>> -		count -= iv->iov_len;	/* This segment is no good */
>> -		break;
>> -	}
>> +	retval = generic_segment_checks(iov, &nr_segs, &count, VERIFY_WRITE);
>> +	if (retval)
>> +		return retval;
>>  
>>  	/* coalesce the iovecs and go direct-to-BIO for O_DIRECT */
>>  	if (filp->f_flags & O_DIRECT) {
>> @@ -2094,30 +2112,14 @@ __generic_file_aio_write_nolock(struct kiocb *iocb, const struct iovec *iov,
>>  	size_t ocount;		/* original count */
>>  	size_t count;		/* after file limit checks */
>>  	struct inode 	*inode = mapping->host;
>> -	unsigned long	seg;
>>  	loff_t		pos;
>>  	ssize_t		written;
>>  	ssize_t		err;
>>  
>>  	ocount = 0;
>> -	for (seg = 0; seg < nr_segs; seg++) {
>> -		const struct iovec *iv = &iov[seg];
>> -
>> -		/*
>> -		 * If any segment has a negative length, or the cumulative
>> -		 * length ever wraps negative then return -EINVAL.
>> -		 */
>> -		ocount += iv->iov_len;
>> -		if (unlikely((ssize_t)(ocount|iv->iov_len) < 0))
>> -			return -EINVAL;
>> -		if (access_ok(VERIFY_READ, iv->iov_base, iv->iov_len))
>> -			continue;
>> -		if (seg == 0)
>> -			return -EFAULT;
>> -		nr_segs = seg;
>> -		ocount -= iv->iov_len;	/* This segment is no good */
>> -		break;
>> -	}
>> +	err = generic_segment_checks(iov, &nr_segs, &ocount, VERIFY_READ);
>> +	if (err)
>> +		return err;
>>  
>>  	count = ocount;
>>  	pos = *ppos;
>> -- 
>> 1.5.0.1
>> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


  reply	other threads:[~2007-03-12 18:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-12  7:57 [PATCH 1/2] mm: move common segment checks to separate helper function (v6) Dmitriy Monakhov
2007-03-12  8:27 ` Christoph Hellwig
2007-03-12  8:31 ` Nick Piggin
2007-03-12 18:32   ` Dmitriy Monakhov [this message]
2007-03-15 21:52 ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874poq1fer.fsf@sw.ru \
    --to=dmonakhov@sw.ru \
    --cc=akpm@linux-foundation.org \
    --cc=devel@openvz.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=npiggin@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.