On Mon, Nov 01, 2010 at 04:08:55PM +0100, Jiri Slaby wrote:
Stanse found that pSMBFile in cifs_ioctl and file-f_path.dentry in
cifs_user_write are dereferenced prior their test to NULL.
file-f_path.dentry is never NULL for an opened file, neither is
file-f_path.dentry-d_inode (which cannot
On Thu, Jan 20, 2011 at 10:31:34AM +0530, Suresh Jayaraman wrote:
Sorry it was not a VFS fix but a fix from Al Viro that fixed this
problem. IIUC, the commit has made it to cifs-2.6.git but not upstream.
commit 1c929cfe6d8f2087a337a868fbf6c38d56bb4889
Author: Al Viro v...@zeniv.linux.org.uk
On Mon, Mar 07, 2011 at 08:00:09PM -0800, Vinay Sawal wrote:
Removed a compile time warning by initializing an uninitialized variable.
- int rc;
+ int rc = -EFAULT;
Why is that the right thing to do? Other than it made the compiler to
STFU, therefore it is Good(tm), please.
--
To
On Fri, Jun 17, 2011 at 04:54:21AM +0100, Al Viro wrote:
See #untested in vfs-2.6.git; I *hope* I've got all the leaks in current
mainline plugged and all sget() races ought to be taken care of. And
yes, the branch name matches the reality - this sucker is completely
untested. Have fun
On Mon, Jun 20, 2011 at 11:13:22AM -0500, Steve French wrote:
Would the plan be for Al to merge these out of his tree?
Can do, if cifs folks are OK with it... Note that it's a regression since
the last merge window, so it probably ought to go to Linus before 3.0-final.
--
To unsubscribe from
On Mon, Jul 18, 2011 at 05:45:02PM +0100, Al Viro wrote:
lookup-by-hand code in there. Or with calculating hash - also done
by lookup_one_len(), TYVM... If anything, I'd start with this as the first
approximation and probably looked into simplifying the loop a bit more -
lookup_one_len
On Mon, Jul 18, 2011 at 01:49:42PM -0400, Jeff Layton wrote:
Thanks, Al...
Looks good to me. I also gave it some basic smoke testing and it seems
to do the right thing.
Reviewed-by: Jeff Layton jlay...@redhat.com
OK, it's in #for-linus2
--
To unsubscribe from this list: send the line
On Fri, Aug 05, 2011 at 09:02:40AM -0400, Jeff Layton wrote:
The loop around lookup_one_len doesn't handle the case where it might
return a negative dentry, which can cause an oops on the next pass
through the loop. Check for that and break out of the loop with an
error of -ENOENT if there is
On Fri, Aug 05, 2011 at 10:01:47AM -0500, Steve French wrote:
On Fri, Aug 5, 2011 at 9:54 AM, Al Viro v...@zeniv.linux.org.uk wrote:
On Fri, Aug 05, 2011 at 09:02:40AM -0400, Jeff Layton wrote:
The loop around lookup_one_len doesn't handle the case where it might
return a negative dentry
On Tue, Aug 09, 2011 at 09:41:33AM +0400, Pavel Shilovsky wrote:
? ? ? ? ? ? ? ?mutex_unlock(dir-i_mutex);
? ? ? ? ? ? ? ?dput(dentry);
? ? ? ? ? ? ? ?dentry = child;
+ ? ? ? ? ? ? ? if (!dentry-d_inode) {
dentry can be NULL here (returned from lookup_one_len) and it can
cause a null
On Fri, Jun 08, 2012 at 03:25:50PM -0700, Andrew Morton wrote:
A neater implementation might be to add a kmem_cache* argument to
unregister_filesystem(). If that is non-NULL, unregister_filesystem()
does the rcu_barrier() and destroys the cache. That way we get to
delete (rather than add) a
On Tue, Oct 30, 2012 at 04:14:39PM -0400, Jeff Moyer wrote:
This patch passes a data pointer along to the alloc_inode
super_operations function. The value will initially be used by
bdev_alloc_inode to allocate the bdev_inode on the same numa
node as the device to which it is tied.
Yecchhh...
On Tue, Oct 30, 2012 at 08:51:42PM +, Al Viro wrote:
On Tue, Oct 30, 2012 at 04:14:39PM -0400, Jeff Moyer wrote:
This patch passes a data pointer along to the alloc_inode
super_operations function. The value will initially be used by
bdev_alloc_inode to allocate the bdev_inode
On Thu, Nov 29, 2012 at 05:39:27PM +0100, Stef Bon wrote:
And yes there is no such thing as a killer app, but in my opinion it's
the user experience.
Ah, yes... UX - the killer argument. Doing that would make qi flow better
and any objections are waved away, since the person objecting has no
On Thu, Nov 29, 2012 at 09:31:05PM +0100, Stef Bon wrote:
2012/11/29 Al Viro v...@zeniv.linux.org.uk:
On Thu, Nov 29, 2012 at 05:39:27PM +0100, Stef Bon wrote:
And yes there is no such thing as a killer app, but in my opinion it's
the user experience.
Ah, yes... UX - the killer
@@ -635,22 +640,14 @@ struct dentry *dget_parent(struct dentry *dentry)
{
struct dentry *ret;
-repeat:
- /*
- * Don't need rcu_dereference because we re-check it was correct under
- * the lock.
- */
rcu_read_lock();
- ret = dentry-d_parent;
-
On Sat, Apr 06, 2013 at 12:04:52PM +0200, Marco Stornelli wrote:
In every place where sb_start_write was called now we must manage
the error code and return -EINTR.
Now go and look for callers of mnt_want_write() ;-/ The really
painful one is in do_last(), but kern_path_create() is not much
On Sun, Apr 13, 2014 at 08:46:22PM +0200, Geert Uytterhoeven wrote:
mm/shmem.c: In function ‘shmem_file_aio_read’:
mm/shmem.c:1414: warning: ‘error’ may be used uninitialized in this function
If the loop is aborted during the first iteration by one of the two first
break statements, error
.
This way, the error code is returned by the function.
Acked-by: Al Viro v...@zeniv.linux.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-cifs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Mar 16, 2015 at 04:33:48AM -0700, Omar Sandoval wrote:
Hi,
Al, here's some cleanup that you mentioned back in December that I got
around to (https://lkml.org/lkml/2014/12/15/28).
In summary, the rw parameter to a_ops-direct_IO() is redundant with
.type in struct iov_iter.
On Mon, Mar 16, 2015 at 04:33:49AM -0700, Omar Sandoval wrote:
Get either READ or WRITE out of iter-type.
Umm...
+ * Get one of READ or WRITE out of iter-type without any other flags OR'd in
+ * with it.
+ */
+static inline int iov_iter_rw(const struct iov_iter *i)
+{
+ return
On Tue, Mar 17, 2015 at 10:31:51AM +0100, David Sterba wrote:
Agreed, but the proposed define is rather cryptic and I was not able to
understand the meaning on the first glance.
#define iov_iter_rw(i) ((0 ? (struct iov_iter *)0 : (i))-type RW_MASK)
This worked for me, does not compile
On Mon, Mar 16, 2015 at 04:33:48AM -0700, Omar Sandoval wrote:
Hi,
Al, here's some cleanup that you mentioned back in December that I got
around to (https://lkml.org/lkml/2014/12/15/28).
Applied. See #for-next
--
To unsubscribe from this list: send the line unsubscribe linux-cifs in
the
On Tue, Dec 08, 2015 at 03:54:53PM +0100, Christoph Hellwig wrote:
> On Tue, Dec 08, 2015 at 04:05:04AM +0000, Al Viro wrote:
> > Where the hell would truncate(2) get struct file, anyway? IOW, the inode
> > argument is _not_ pointless; re-added.
>
> Oh, right. Intere
On Thu, Dec 03, 2015 at 12:59:49PM +0100, Christoph Hellwig wrote:
> Pass a loff_t end for the last byte instead of the 32-bit count
> parameter to allow full file clones even on 32-bit architectures.
> While we're at it also drop the pointless inode argument and simplify
> the read/write
25 matches
Mail list logo
