Skip to contentSkip to conversation

reiser4: port for Linux-4.5

PATCH In review Edward Shishkin 2 participants 7 messages Mar 30, 2016 – Apr 6, 2016

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 reiser4: port for Linux-4.5

. Adjust for the new ->get_link() of vfs's inode_operations: we don't
support RCU mode;
. check returned value of __copy_from_user() to make gcc happy
(the path is never invoked) in create_item_node40().

fs/reiser4/plugin/inode_ops.c +22 -9
diff -u -r linux-4.4/fs/reiser4/plugin/inode_ops.c linux-4.5/fs/reiser4/plugin/inode_ops.c
@@ -394,23 +394,25 @@
  */
 
 /**
- * reiser4_follow_link_common - follow_link of inode operations
+ * reiser4_get_link_common: ->get_link() of inode_operations
  * @dentry: dentry of symlink
- * @data:
  *
- * This is common implementation of vfs's followlink method of struct
- * inode_operations.
  * Assumes that inode's i_private points to the content of symbolic link.
  */
-const char *reiser4_follow_link_common(struct dentry *dentry, void **cookie)
+const char *reiser4_get_link_common(struct dentry *dentry,
+				    struct inode *inode,
+				    struct delayed_call *done)
 {
+	if (!dentry)
+		return ERR_PTR(-ECHILD);
+
 	assert("vs-851", S_ISLNK(dentry->d_inode->i_mode));
 
-	if (!dentry->d_inode->i_private
-	    || !reiser4_inode_get_flag(dentry->d_inode,
-				       REISER4_GENERIC_PTR_USED))
+	if (!dentry->d_inode->i_private ||
+	    !reiser4_inode_get_flag(dentry->d_inode, REISER4_GENERIC_PTR_USED))
 		return ERR_PTR(RETERR(-EINVAL));
-	return *cookie = dentry->d_inode->i_private;
+
+	return dentry->d_inode->i_private;
 }
 
 /**
@@ -877,3 +879,14 @@
 	dir->i_ctime = dir->i_mtime = CURRENT_TIME;
 	return reiser4_update_sd(dir);
 }
+
+/*
+  Local variables:
+  c-indentation-style: "K&R"
+  mode-name: "LC"
+  c-basic-offset: 8
+  tab-width: 8
+  fill-column: 80
+  scroll-step: 1
+  End:
+*/
fs/reiser4/plugin/node/node40.c +4 -3
diff -u -r linux-4.4/fs/reiser4/plugin/node/node40.c linux-4.5/fs/reiser4/plugin/node/node40.c
@@ -876,9 +876,10 @@
 			   without this check? */
 			assert("nikita-3038", reiser4_schedulable());
 			/* copy data from user space */
-			__copy_from_user(zdata(target->node) + offset,
-					 (const char __user *)data->data,
-					 (unsigned)data->length);
+			if (__copy_from_user(zdata(target->node) + offset,
+					     (const char __user *)data->data,
+					     (unsigned)data->length))
+				return RETERR(-EFAULT);
 		} else
 			/* copy from kernel space */
 			memcpy(zdata(target->node) + offset, data->data,
fs/reiser4/plugin/object.c +1 -1
diff -u -r linux-4.4/fs/reiser4/plugin/object.c linux-4.5/fs/reiser4/plugin/object.c
@@ -156,7 +156,7 @@
 /* VFS methods for symlink files */
 static struct inode_operations symlink_file_i_ops = {
 	.readlink = generic_readlink,
-	.follow_link = reiser4_follow_link_common,
+	.get_link = reiser4_get_link_common,
 	.permission = reiser4_permission_common,
 	.setattr = reiser4_setattr_common,
 	.getattr = reiser4_getattr_common
fs/reiser4/plugin/object.h +2 -1
diff -u -r linux-4.4/fs/reiser4/plugin/object.h linux-4.5/fs/reiser4/plugin/object.h
@@ -24,7 +24,8 @@
 		 umode_t mode, dev_t rdev);
 int reiser4_rename_common(struct inode *old_dir, struct dentry *old_name,
 			  struct inode *new_dir, struct dentry *new_name);
-const char *reiser4_follow_link_common(struct dentry *, void **cookie);
+const char *reiser4_get_link_common(struct dentry *, struct inode *inode,
+				    struct delayed_call *done);
 int reiser4_permission_common(struct inode *, int mask);
 int reiser4_setattr_common(struct dentry *, struct iattr *);
 int reiser4_getattr_common(struct vfsmount *mnt, struct dentry *,
#1 lore raw
Quoted 6 lines · Edward Shishkin

. Adjust for the new ->get_link() of vfs's inode_operations: we don't support RCU mode;
. check returned value of __copy_from_user() to make gcc happy (the path is never invoked) in create_item_node40().

Hi Edward,

could you please send a separate patch with adjustments for 4.4?

Thanks,

Signature · 1 line
Ivan Shapovalov / intelfx /
#2 lore raw

Which "adjustments" do you mean?

Quoted 12 lines · Ivan Shapovalov
Quoted 6 lines · Edward Shishkin

. Adjust for the new ->get_link() of vfs's inode_operations: we don't

    support RCU mode;

. check returned value of __copy_from_user() to make gcc happy
(the path is never invoked) in create_item_node40().

Hi Edward,

could you please send a separate patch with adjustments for 4.4?

Thanks,

#3 lore raw
Quoted 19 lines · Edward Shishkin

Which "adjustments" do you mean?

Quoted 15 lines · Ivan Shapovalov
Quoted 8 lines · Edward Shishkin

. Adjust for the new ->get_link() of vfs's inode_operations: we don't
    support RCU mode;
. check returned value of __copy_from_user() to make gcc happy (the path is never invoked) in create_item_node40().

Hi Edward,

could you please send a separate patch with adjustments for 4.4?

Thanks,

I meant usual forward-porting changes. But now I see that there were none :) Sorry for the noise.

Signature · 1 line
Ivan Shapovalov / intelfx /
#4 lore raw
In reply to Edward Shishkin
Quoted 6 lines · Edward Shishkin

. Adjust for the new ->get_link() of vfs's inode_operations: we don't support RCU mode;
. check returned value of __copy_from_user() to make gcc happy (the path is never invoked) in create_item_node40().

By the way: I've noticed many times that the resulting squashed patch which you put on sourceforge is _different_ from what can be composed using incremental patches you send on the ML.

Maybe you could finally consider having a git repo somewhere (e. g. on github)? It would be much easier to work with the code (and, for me in particular, to learn how it works) this way.

Thanks.

Signature · 1 line
Ivan Shapovalov / intelfx /
#5 lore raw
Quoted 10 lines · Ivan Shapovalov
Quoted 6 lines · Edward Shishkin

. Adjust for the new ->get_link() of vfs's inode_operations: we don't

    support RCU mode;

. check returned value of __copy_from_user() to make gcc happy
(the path is never invoked) in create_item_node40().

By the way: I've noticed many times that the resulting squashed patch which you put on sourceforge is _different_ from what can be composed using incremental patches you send on the ML.

I never announced any peculiar properties of the patches that I send to the mailing list. This is mostly for me (to look at the mail archive and to refresh memory.

Quoted 4 lines

Maybe you could finally consider having a git repo somewhere (e. g. on github)? It would be much easier to work with the code (and, for me in particular, to learn how it works) this way.

I'll consider it sooner or later, since all Namesys archives are git-based, but it seems that probably "later", because currently I am very busy..

Edward.

#6 lore raw
Quoted 9 lines · Edward Shishkin
Quoted 7 lines · Ivan Shapovalov

[...]
By the way: I've noticed many times that the resulting squashed patch
which you put on sourceforge is _different_ from what can be composed
using incremental patches you send on the ML.

Quoted 3 lines

I never announced any peculiar properties of the patches that I send to the mailing list. This is mostly for me (to look at the mail archive and to refresh memory.

OK. Life could've been easier...

Quoted 9 lines
Quoted 5 lines

Maybe you could finally consider having a git repo somewhere (e. g. on
github)? It would be much easier to work with the code (and, for me in
particular, to learn how it works) this way.

I'll consider it sooner or later, since all Namesys archives are git-based, but it seems that probably "later", because currently I am very busy..

ditto.

Thanks anyway,

Signature · 1 line
Ivan Shapovalov / intelfx /