Closed fatalhalt closed 3 years ago
Hello,
fatalhalt:
Will there be aufs patchset released for Linux 5.8 anytime soon? Thanks.
Unfortunately, the situation is unchanged from https://www.mail-archive.com/aufs-users@lists.sourceforge.net/msg05822.html
J. R. Okajima
I wish J.R.O @sfjro a speedy resolution of his problems and a return to his greatly appreciated work for the community. in the meantime.... This is very very unofficial and only to be used at your own risk..... but you can find an amended aufs5-base.patch at: https://u.pcloud.link/publink/show?code=XZI5x7XZH0G8B1h38uRzXngfAhAqChaW2XoV which does allow 5.8 to be built with aufs-5.x-rcN The resulting 5.8 built for Puppy Linux seems to work fine in that environment - but only that environment has been "tested"....
@peabee thanks for the patch! It is working fine on my custom gentoo distro with 5.8.11 kernel . 🙂
5.9 is likely to be the next LTS kernel .... so probably more "important" than 5.8. Looking to the future, I decided it would be interesting to see if 5.9-rc6 with aufs would build. Further changes to the aufs patches were required - in both aufs5-base.patch and aufs5-mmap.patch Then the patched kernel failed to compile throwing an error in fs/aufs/hfsnotify.c Having made a change to hsnotify.c (described below) kernel 5.9-rc6 did build. A Puppy Linux system with the new kernel booted successfully (screenshot below) ..... large programs such as chromium and libreoffice could be installed and run from sfs (squashfs) files.... HOWEVER the filemanager PcManFM would not run (but didn't throw any errors either). (the other file filemanager RoxFiler did run OK)
I've probably got the fix for the hsnotify.c compile error completely wrong but due to lack of knowledge I do not know what the correct fix should be.
The compile error indicated that at line 205 of hsnotify.c there were [-Werror=incompatible-pointer-types]
205 | .handle_event = au_hfsn_handle_event,
and in particular the order of the components were slightly different so as "au_hfsn_handle_event" was declared at line 162, I changed the position of "struct inode *inode," to match ".handle_event" so that it read:
static int au_hfsn_handle_event(struct fsnotify_group group, u32 mask, const void data, int data_type, struct inode inode, const struct qstr file_name, u32 cookie, struct fsnotify_iter_info *iter_info)
Anybody (with more knowledge) able to suggest what the correct fix might be? Thanks!
5.9 has been released but is not yet identified as an LTS kernel.... https://www.kernel.org/
OK - have built 5.9 with the changes previously tried on 5.9-RC6 and this time they seem to have worked successfully..... pcmanfm now works as expected. I've uploaded the 3 aufs files that had to be changed: https://u.pcloud.link/publink/show?code=XZvhPFXZG6bEshssryQQO150kW2kPYwrBWQk ...
5.10 assistance required........ https://www.zdnet.com/article/linux-5-10-finally-ditches-decades-old-tool-that-caused-security-bugs/ : "Torvalds drew attention to the removal of an addressing tool, called set_fs()" this causes problems in https://github.com/sfjro/aufs5-standalone/blob/aufs5.7/fs/aufs/xino.c e.g. "fs/aufs/xino.c:894:2: error: implicit declaration of function ‘set_fs’; did you mean ‘sget_fc’?"
Is there a simple replacement for set_fs and get_fs in xino.c ??
Hi PB,
PB:
5.10 assistance required........=0D ::: Is there a simple replacement for set_fs and get_fs in xino.c ??=0D
I will return to aufs development as soon as possible and dive into this issue. For a while, will you try these options?
According to the commit 3c57fa13f6bf 2020-10-04 asm-generic: make the set_fs implementation optional Enabling CONFIG_SET_FS looks hopeful. Did you already try it?
fs/read_write.c also uses set_fs(). How does it handle this? Can we simply follow the same say? $ git diff v5.8 v5.10-rc4 read_write.c :::
J. R. Okajima
Hi J. R. Okajima
I will return to aufs development as soon as possible and dive into this
Great news! And many thanks for all your great work during the years.
I agree with fredx181, good news and also thank you for the excellent work.
Hello @sfjro Great to hear from you and for your advice - many thanks. I have tried putting CONFIG_SET_FS=y into the kernel config but this doesn't seem to be sufficient as the compile time errors still occur .... the key include referring to CONFIG_SET_FS seems to be linux-5.10.0/include/asm-generic/uaccess.h but I don't know if xino.c will be including this. Your Option 2 seems to require a major rewrite of xino.c (there are 8 occurrences of set_fs and 4 occurrences of get_fs) which I fear is beyond my capabilities! Thanks again peebee
Notes: As well as xino.c cpup.c vfsub.c also use set_fs & get_fs and need to be updated. cpup.c seems to be different to the other 2 and does not relate to the read_write.c model. seq_file.c in the kernel also uses init_sync_kiocb(&kiocb, file);
"J. R. Okajima":
I will return to aufs development as soon as possible and dive into this issue. For a while, will you try these options?
Here is a patch for linux-v5.10-rc5. It passed the subset of my local tests. Why subset? Because my full test may take much longer time and I don't have enough time for that.
Please try
J. R. Okajima
Hi @sfjro Many thanks but....
I don't think you included the patch?????
PB:
I don't thinkyou included the patch?????
I did attached, but I cannot see it on github.com either. Hmm, github doesn't accept xz compressed attachment, or no attachement at all? Now I try attaching bz2 compressed patch.
J. R. Okajima
@sfjro - still invisible - maybe try renaming with -false.gz ??
Now a.patch.gz.
Then a.patch.gz again, but in different mail format.
J. R. Okajima
PB:
@sfjro - still invisible - maybe try renaming with -false.gz ??
Hmm, something is wrong. Really wrong. Am I? Now a.patch.gz.
Patch sent to me by email - many thanks.
Splendid news with great thanks due to J.R.Okajima ( @sfjro ) for finding the time to produce the quite complicated changes needed to integrate aufs5 with kernel 5.10-rc5. I have been able to build a working aufs-enabled kernel 5.10-rc5 with the patches sent to me by email. I have uploaded to: https://sourceforge.net/projects/lxpup/files/Other/huge-kernels/kernel-5.10-aufs-changes/aufs-5.10-changed-files.tar.xz/download .... three amended aufs patches of the kernel sources - aufs5-base.patch aufs5-mmap.patch aufs5-standalone.patch - to substitute the patches downloaded from Github aufs5.x-rcN .... plus, based on the @sfjro supplied new patch, - a new k510.patch - which has to be applied to the kernel sources (including aufs) after aufs has been added to the stock kernel. As kernel 5.10 has been confirmed at the next Long Term Supported LTS kernel release, this is indeed good news. Cheers PeeBee
PB:
Splendid news with great thanks due to J.R.Okajima ( @sfjro ) for finding the time to produce the quite complicated changes needed to integrate aufs5 with kernel 5.10-rc5. I have been able to build a working aufs-enabled kernel 5.10-rc5 with the patches sent to me by email.
Thank you for testing and publishing. When I fully come back to aufs development, I will start from aufs-5.8. So reaching aufs-5.10 may take some time. Please be patience.
J. R. Okajima
Kernel 5.10 has been released. aufs-enabled version builds apparently successfully with the above patches.
Loopback patch needs update, too. This hunk:
--- drivers/block/loop.c~ 2020-12-15 14:31:38.000000000 +0100
+++ drivers/block/loop.c 2020-12-15 14:36:32.548939602 +0100
@@ -1189,6 +1189,7 @@ static int loop_configure(struct loop_de
lo->use_dio = lo->lo_flags & LO_FLAGS_DIRECT_IO;
lo->lo_device = bdev;
lo->lo_backing_file = file;
+ lo->lo_backing_virt_file = virt_file;
lo->old_gfp_mask = mapping_gfp_mask(mapping);
mapping_set_gfp_mask(mapping, lo->old_gfp_mask & ~(__GFP_IO|__GFP_FS));
Hi @arekm Is the above patch for 5.8 5.9 or 5.10 ? What problems do you see without this patch? Thanks
Original loopback patch no longer applies to 5.10. And above hunk is a fixed version. With this 5.10 builds fine for me (+ patches from this issue).
Thanks - we don't apply the loopback patch so didn't detect the need for this further change - see next comment.
Original loopback patch no longer applies to 5.10. And above hunk is a fixed version. With this 5.10 builds fine for me (+ patches from this issue).
Hi @arekm Are you saying that the loopback.patch in aufs-5.x-rcN should be deleted and that the only content of loopback.patch for 5.10 should be the single patch that you have posted above?
There are many other files patched in the aufs-5.x-rcN loopback.patch other than drivers/block/loop.c .......
No. If you try to apply loopback patch then one hunk will fail. That one hunk needs to be replaced with above.
Hi @arekm Can you email me the complete amended loopback.patch that works with 5.10 please?
I have updated the 5.10 changes download with the loopback.patch sent to me by @arekm (with thanks). However I haven't been able to check the amended patch fully. I did note however that it still contains patches for a function 'static int loop_set_fd' which isn't present in the 5.10 drivers/block/loop.c however this doesn't seem to raise any errors.
PB:
I have updated the 5.10 changes download with the loopback.patch sent to me by @arekm (with thanks). However I haven't been able to check the amended patch fully. I did note however that it still contains patches for a function 'static int loop_set_fd' which isn't present in the 5.10 drivers/block/loop.c however this doesn't seem to raise any errors.
It might be v5.8 instead of v5.10. By the commit in v5.8-rc1, 3448914e8cc55 2020-05-21 loop: Add LOOP_CONFIGURE ioctl aufs5-loopback.patch looks need to be updated. And I think Arkadiusz's patch is correct, but I haven't test it by myself.
FYI, I attach my local untested aufs5-loopback.patch. Arkadiusz, is this perfectly match with yours?
Oh, wait. Github looks discarding my mail attachment. I will append the patch as a text after my signature.
J. R. Okajima
SPDX-License-Identifier: GPL-2.0 aufs5.x-rcN loopback patch
diff --git a/drivers/block/loop.c b/drivers/block/loop.c index 8d77e68aa52b9..655f2252187a8 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -648,6 +648,15 @@ static inline void loop_update_dio(struct loop_device *lo) lo->use_dio); }
+static struct file loop_real_file(struct file file) +{
static void loop_reread_partitions(struct loop_device lo, struct block_device bdev) { @@ -703,6 +712,7 @@ static int loop_change_fd(struct loop_device lo, struct block_device bdev, unsigned int arg) { struct file file = NULL, old_file;
@@ -722,12 +732,19 @@ static int loop_change_fd(struct loop_device lo, struct block_device bdev, file = fget(arg); if (!file) goto out_err;
}
error = loop_validate_file(file, bdev); if (error) goto out_err;
old_file = lo->lo_backing_file;
old_virt_file = lo->lo_backing_virt_file;
error = -EINVAL;
@@ -739,6 +756,7 @@ static int loop_change_fd(struct loop_device lo, struct block_device bdev, blk_mq_freeze_queue(lo->lo_queue); mapping_set_gfp_mask(old_file->f_mapping, lo->old_gfp_mask); lo->lo_backing_file = file;
@@ -1085,7 +1107,7 @@ static int loop_configure(struct loop_device lo, fmode_t mode, struct block_device bdev, const struct loop_config *config) {
}
/*
@@ -1208,6 +1237,8 @@ static int loop_configure(struct loop_device *lo, fmode_t mode, bd_abort_claiming(bdev, claimed_bdev, loop_configure); out_putf: fput(file);
struct file virt_filp = lo->lo_backing_virt_file; gfp_t gfp = lo->old_gfp_mask; struct block_device bdev = lo->lo_device; int err = 0; @@ -1240,6 +1272,7 @@ static int __loop_clr_fd(struct loop_device *lo, bool release)
spin_lock_irq(&lo->lo_lock); lo->lo_backing_file = NULL;
lo->lo_backing_virt_file = NULL; spin_unlock_irq(&lo->lo_lock);
loop_release_xfer(lo); @@ -1323,6 +1356,8 @@ static int __loop_clr_fd(struct loop_device lo, bool release) / if (filp) fput(filp);
diff --git a/drivers/block/loop.h b/drivers/block/loop.h index af75a5ee40944..1d847cb194ff6 100644 --- a/drivers/block/loop.h +++ b/drivers/block/loop.h @@ -46,7 +46,7 @@ struct loop_device { int (ioctl)(struct loop_device , int cmd, unsigned long arg);
diff --git a/fs/aufs/f_op.c b/fs/aufs/f_op.c index 6fb4a4ed8cc7f..ba9a959f2db27 100644 --- a/fs/aufs/f_op.c +++ b/fs/aufs/f_op.c @@ -359,7 +359,7 @@ static ssize_t aufs_read_iter(struct kiocb kio, struct iov_iter iov_iter) if (IS_ERR(h_file)) goto out;
+/ ---------------------------------------------------------------------- /
+/ support the loopback block device insude aufs /
+struct file aufs_real_loop(struct file file) +{
return f; +} diff --git a/fs/aufs/loop.h b/fs/aufs/loop.h index 94f4f80ae33bf..ca1194354aff4 100644 --- a/fs/aufs/loop.h +++ b/fs/aufs/loop.h @@ -26,6 +26,8 @@ void au_warn_loopback(struct super_block *h_sb);
int au_loopback_init(void); void au_loopback_fin(void);
+struct file aufs_real_loop(struct file file);
AuStub(struct file , loop_backing_file, return NULL, struct super_block sb)
@@ -36,6 +38,8 @@ AuStubVoid(au_warn_loopback, struct super_block *h_sb)
AuStubInt0(au_loopback_init, void) AuStubVoid(au_loopback_fin, void) + +AuStub(struct file , aufs_real_loop, return NULL, struct file file)
diff --git a/fs/aufs/super.c b/fs/aufs/super.c index 589dd01220201..801e0a7faec59 100644 --- a/fs/aufs/super.c +++ b/fs/aufs/super.c @@ -844,7 +844,10 @@ static const struct super_operations aufs_sop = { .statfs = aufs_statfs, .put_super = aufs_put_super, .sync_fs = aufs_sync_fs,
.real_loop = aufs_real_loop +#endif };
/ ---------------------------------------------------------------------- / diff --git a/include/linux/fs.h b/include/linux/fs.h index 0b008da5678d2..e9f71ef720edb 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -1985,6 +1985,10 @@ struct super_operations { struct shrink_control ); long (free_cached_objects)(struct super_block , struct shrink_control ); +#if IS_ENABLED(CONFIG_BLK_DEV_LOOP) || IS_ENABLED(CONFIG_BLK_DEV_LOOP_MODULE)
struct file (real_loop)(struct file *); +#endif };
/*
Congrats & well done @sfjro ...........
@fatalhalt this issue can be closed ............
Subject aufs5 GIT release (v5.{8,9,10}) From J. R. Okajima To aufs-users@lists.sourceforge.net Date Today 16:21 I'm back. Thanks for your patience and sorry for you inconvenient. I hope I can keep my development pace as I had.
o news
J. R. Okajima
Hello,
Will there be aufs patchset released for Linux 5.8 anytime soon? Thanks.