Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\)
On 02/16/2021 04:56 PM, Jose R Rodriguez wrote: On Mon, 2021-02-08 at 17:03 +0100, Edward Shishkin wrote: On 02/08/2021 01:54 PM, Metztli Information Technology wrote: On Wed, Dec 23, 2020 at 3:40 PM Edward Shishkin < edward.shish...@gmail.com> wrote: On 12/23/2020 05:01 PM, Metztli Information Technology wrote: Niltze [Ð—Ð´Ñ€Ð°Ð²Ñ Ñ‚Ð²ÑƒÐ¹Ñ‚Ðµ : Hello], Ed- I built Linux kernel 5.10.1-1 within the 'Debian way' -- as usual -- to generate a kernel component for my Debian-Installer (d-i). The patch I applied is reiser4-for-5.10-rc3.patch.gz from v5- unstable. Once I built the proper reiser4progs-2.0.4.tar.gz and generated one set of components for d-i I built the d-i image. Fact is, the installer throws an error in *both* bare metal and VirtualBox 6.1.16: ... Dec 22 20:19:56 main-menu[330]: INFO: Menu item 'bootstrap- base' selected Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap -- components=main --debian-installer --resolve-deps -- keyring=/usr/share/keyrings/archive.gpg buster /target http://deb.debian.org/debian/ Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap: line 1596: /target/test-exec: Invalid argument Dec 22 20:19:56 kernel: [ 1018.632648] kernel read not supported for file /test-exec (pid: 10077 comm: debootstrap) Dec 22 20:19:56 debootstrap: E: NOEXEC Dec 22 20:19:56 debootstrap: EF: Cannot install into target '/target' mounted with noexec or nodev Dec 22 20:20:12 base-installer: error: exiting on error base- installer/debootstrap-failed Dec 22 20:20:14 main-menu[330]: WARNING **: Configuring 'bootstrap-base' failed with error code 1 Dec 22 20:20:14 main-menu[330]: WARNING **: Menu item 'bootstrap-base' failed. Dec 22 20:20:15 main-menu[330]: INFO: Falling back to the package description for brltty-udeb [...] Apparently, d-i [Debian-installer] complains about being unable to set the test file executable and causes the error when 1 is returned. Notwithstanding, I manually verified that I am able to touch a file and set it +x executable. Furthermore, tricking the function return value to 0 I am able to make d-i continue with the latest SFRN5 installation (see [*trick*] below); yet, subsequently halts again with an apparently related error --can not proceed any further. Digging deeper with dmesg, we can see that apparently it is the kernel which cannot 'read' properly. Please find a partial dmesg log with relevant output from an attempt on my physical development machine. ... [ 508.614488] Loading Reiser4 (Software Framework Release: 5.1.3). See reiser4.wiki.kernel.org for a description of Reiser4. [ 508.661951] SGI XFS with ACLs, security attributes, realtime, quota, no debug enabled [ 509.326270] device-mapper: uevent: version 1.0.3 [ 509.326505] device-mapper: ioctl: 4.43.0-ioctl (2020-10-01) initialised: dm-de...@redhat.com [ 509.902828] sda: sda1 sda2 sda3 sda4 sda5 sda6 [ 509.915300] sdb: sdb1 sdb2 sdb3 [ 511.973360] sdb: sdb1 sdb2 sdb3 [ 627.525371] Adding 9765884k swap on /dev/sda3. Priority:-2 extents:1 across:9765884k FS [ 636.240812] reiser4[mount(9430)]: reiser4_register_subvol (fs/reiser4/init_volume.c:222)[edward-1932]: [ 636.240812] NOTICE: brick /dev/sda6 has been registered [ 636.243003] reiser4 (sda6): found disk format 5.1.3. [ 643.759971] reiser4 (/dev/sda6): using Hybrid Transaction Model. [ 643.759980] reiser4: brick /dev/sda6 activated [ 643.788537] EXT4-fs (sda1): mounting ext2 file system using the ext4 subsystem [ 643.813474] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null) [ 643.813488] ext2 filesystem being mounted at /target/boot supports timestamps until 2038 (0x7fff) [ 648.168730] kernel read not supported for file /test-exec (pid: 9876 comm: debootstrap) [*trick*] [ 898.761385] reiser4: brick /dev/sda6 deactivated [ 991.001332] reiser4 (sda6): found disk format 5.1.3. [ 999.093471] reiser4 (/dev/sda6): using Hybrid Transaction Model. [ 999.093480] reiser4: brick /dev/sda6 activated [ 1009.340117] EXT4-fs (sda1): mounting ext2 file system using the ext4 subsystem [ 1009.362722] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null) [ 1009.362737] ext2 filesystem being mounted at /target/boot supports timestamps until 2038 (0x7fff) [ 6373.748413] kernel read not supported for file /test-exec (pid: 10094 comm: debootstrap) [ 6413.169920] kernel read not supported for file /usr/bin/true (pid: 15960 comm: chroot) Hello. This is because of VFS changes in Linux-5.10.X. Specifically, because of the following patch: https://lkml.org/lkml/2020/8/17/174 In the upstream git repository it is commit 4d03e3cc59828c82ee89ea6e2 So, Christoph, what to do now for file systems which implement ->read() method of file operations? *deafening silence* it appears that -- in the best of cases -- Christoph engaged in an act of _iter masturbation [1]; and in the worst of cases, the gentleman was aiming straight at reiser4. ... It seems that chroot doesn't work for them. And people are
Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\)
On 02/08/2021 01:54 PM, Metztli Information Technology wrote: On Wed, Dec 23, 2020 at 3:40 PM Edward Shishkin wrote: On 12/23/2020 05:01 PM, Metztli Information Technology wrote: Niltze [Ð—Ð´Ñ€Ð°Ð²Ñ Ñ‚Ð²ÑƒÐ¹Ñ‚Ðµ : Hello], Ed- I built Linux kernel 5.10.1-1 within the 'Debian way' -- as usual -- to generate a kernel component for my Debian-Installer (d-i). The patch I applied is reiser4-for-5.10-rc3.patch.gz from v5-unstable. Once I built the proper reiser4progs-2.0.4.tar.gz and generated one set of components for d-i I built the d-i image. Fact is, the installer throws an error in *both* bare metal and VirtualBox 6.1.16: ... Dec 22 20:19:56 main-menu[330]: INFO: Menu item 'bootstrap-base' selected Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap --components=main --debian-installer --resolve-deps --keyring=/usr/share/keyrings/archive.gpg buster /target http://deb.debian.org/debian/ Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap: line 1596: /target/test-exec: Invalid argument Dec 22 20:19:56 kernel: [ 1018.632648] kernel read not supported for file /test-exec (pid: 10077 comm: debootstrap) Dec 22 20:19:56 debootstrap: E: NOEXEC Dec 22 20:19:56 debootstrap: EF: Cannot install into target '/target' mounted with noexec or nodev Dec 22 20:20:12 base-installer: error: exiting on error base-installer/debootstrap-failed Dec 22 20:20:14 main-menu[330]: WARNING **: Configuring 'bootstrap-base' failed with error code 1 Dec 22 20:20:14 main-menu[330]: WARNING **: Menu item 'bootstrap-base' failed. Dec 22 20:20:15 main-menu[330]: INFO: Falling back to the package description for brltty-udeb [...] Apparently, d-i [Debian-installer] complains about being unable to set the test file executable and causes the error when 1 is returned. Notwithstanding, I manually verified that I am able to touch a file and set it +x executable. Furthermore, tricking the function return value to 0 I am able to make d-i continue with the latest SFRN5 installation (see [*trick*] below); yet, subsequently halts again with an apparently related error --can not proceed any further. Digging deeper with dmesg, we can see that apparently it is the kernel which cannot 'read' properly. Please find a partial dmesg log with relevant output from an attempt on my physical development machine. ... [ 508.614488] Loading Reiser4 (Software Framework Release: 5.1.3). See reiser4.wiki.kernel.org for a description of Reiser4. [ 508.661951] SGI XFS with ACLs, security attributes, realtime, quota, no debug enabled [ 509.326270] device-mapper: uevent: version 1.0.3 [ 509.326505] device-mapper: ioctl: 4.43.0-ioctl (2020-10-01) initialised: dm-de...@redhat.com [ 509.902828] sda: sda1 sda2 sda3 sda4 sda5 sda6 [ 509.915300] sdb: sdb1 sdb2 sdb3 [ 511.973360] sdb: sdb1 sdb2 sdb3 [ 627.525371] Adding 9765884k swap on /dev/sda3. Priority:-2 extents:1 across:9765884k FS [ 636.240812] reiser4[mount(9430)]: reiser4_register_subvol (fs/reiser4/init_volume.c:222)[edward-1932]: [ 636.240812] NOTICE: brick /dev/sda6 has been registered [ 636.243003] reiser4 (sda6): found disk format 5.1.3. [ 643.759971] reiser4 (/dev/sda6): using Hybrid Transaction Model. [ 643.759980] reiser4: brick /dev/sda6 activated [ 643.788537] EXT4-fs (sda1): mounting ext2 file system using the ext4 subsystem [ 643.813474] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null) [ 643.813488] ext2 filesystem being mounted at /target/boot supports timestamps until 2038 (0x7fff) [ 648.168730] kernel read not supported for file /test-exec (pid: 9876 comm: debootstrap) [*trick*] [ 898.761385] reiser4: brick /dev/sda6 deactivated [ 991.001332] reiser4 (sda6): found disk format 5.1.3. [ 999.093471] reiser4 (/dev/sda6): using Hybrid Transaction Model. [ 999.093480] reiser4: brick /dev/sda6 activated [ 1009.340117] EXT4-fs (sda1): mounting ext2 file system using the ext4 subsystem [ 1009.362722] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null) [ 1009.362737] ext2 filesystem being mounted at /target/boot supports timestamps until 2038 (0x7fff) [ 6373.748413] kernel read not supported for file /test-exec (pid: 10094 comm: debootstrap) [ 6413.169920] kernel read not supported for file /usr/bin/true (pid: 15960 comm: chroot) Hello. This is because of VFS changes in Linux-5.10.X. Specifically, because of the following patch: https://lkml.org/lkml/2020/8/17/174 In the upstream git repository it is commit 4d03e3cc59828c82ee89ea6e2 So, Christoph, what to do now for file systems which implement ->read() method of file operations? *deafening silence* it appears that -- in the best of cases -- Christoph engaged in an act of _iter masturbation [1]; and in the worst of cases, the gentleman was aiming straight at reiser4. ... It seems that chroot doesn't work for them. And people are not able to release distros with upgraded kernels.. Not only 'chroot doesn't work' for us, but even after replacing the ker
Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\)
On 12/23/2020 05:01 PM, Metztli Information Technology wrote: Niltze [ЗдравÑтвуйте : Hello], Ed- I built Linux kernel 5.10.1-1 within the 'Debian way' -- as usual -- to generate a kernel component for my Debian-Installer (d-i). The patch I applied is reiser4-for-5.10-rc3.patch.gz from v5-unstable. Once I built the proper reiser4progs-2.0.4.tar.gz and generated one set of components for d-i I built the d-i image. Fact is, the installer throws an error in *both* bare metal and VirtualBox 6.1.16: ... Dec 22 20:19:56 main-menu[330]: INFO: Menu item 'bootstrap-base' selected Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap --components=main --debian-installer --resolve-deps --keyring=/usr/share/keyrings/archive.gpg buster /target http://deb.debian.org/debian/ Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap: line 1596: /target/test-exec: Invalid argument Dec 22 20:19:56 kernel: [ 1018.632648] kernel read not supported for file /test-exec (pid: 10077 comm: debootstrap) Dec 22 20:19:56 debootstrap: E: NOEXEC Dec 22 20:19:56 debootstrap: EF: Cannot install into target '/target' mounted with noexec or nodev Dec 22 20:20:12 base-installer: error: exiting on error base-installer/debootstrap-failed Dec 22 20:20:14 main-menu[330]: WARNING **: Configuring 'bootstrap-base' failed with error code 1 Dec 22 20:20:14 main-menu[330]: WARNING **: Menu item 'bootstrap-base' failed. Dec 22 20:20:15 main-menu[330]: INFO: Falling back to the package description for brltty-udeb [...] Apparently, d-i [Debian-installer] complains about being unable to set the test file executable and causes the error when 1 is returned. Notwithstanding, I manually verified that I am able to touch a file and set it +x executable. Furthermore, tricking the function return value to 0 I am able to make d-i continue with the latest SFRN5 installation (see [*trick*] below); yet, subsequently halts again with an apparently related error --can not proceed any further. Digging deeper with dmesg, we can see that apparently it is the kernel which cannot 'read' properly. Please find a partial dmesg log with relevant output from an attempt on my physical development machine. ... [ 508.614488] Loading Reiser4 (Software Framework Release: 5.1.3). See reiser4.wiki.kernel.org for a description of Reiser4. [ 508.661951] SGI XFS with ACLs, security attributes, realtime, quota, no debug enabled [ 509.326270] device-mapper: uevent: version 1.0.3 [ 509.326505] device-mapper: ioctl: 4.43.0-ioctl (2020-10-01) initialised: dm-de...@redhat.com [ 509.902828] sda: sda1 sda2 sda3 sda4 sda5 sda6 [ 509.915300] sdb: sdb1 sdb2 sdb3 [ 511.973360] sdb: sdb1 sdb2 sdb3 [ 627.525371] Adding 9765884k swap on /dev/sda3. Priority:-2 extents:1 across:9765884k FS [ 636.240812] reiser4[mount(9430)]: reiser4_register_subvol (fs/reiser4/init_volume.c:222)[edward-1932]: [ 636.240812] NOTICE: brick /dev/sda6 has been registered [ 636.243003] reiser4 (sda6): found disk format 5.1.3. [ 643.759971] reiser4 (/dev/sda6): using Hybrid Transaction Model. [ 643.759980] reiser4: brick /dev/sda6 activated [ 643.788537] EXT4-fs (sda1): mounting ext2 file system using the ext4 subsystem [ 643.813474] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null) [ 643.813488] ext2 filesystem being mounted at /target/boot supports timestamps until 2038 (0x7fff) [ 648.168730] kernel read not supported for file /test-exec (pid: 9876 comm: debootstrap) [*trick*] [ 898.761385] reiser4: brick /dev/sda6 deactivated [ 991.001332] reiser4 (sda6): found disk format 5.1.3. [ 999.093471] reiser4 (/dev/sda6): using Hybrid Transaction Model. [ 999.093480] reiser4: brick /dev/sda6 activated [ 1009.340117] EXT4-fs (sda1): mounting ext2 file system using the ext4 subsystem [ 1009.362722] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null) [ 1009.362737] ext2 filesystem being mounted at /target/boot supports timestamps until 2038 (0x7fff) [ 6373.748413] kernel read not supported for file /test-exec (pid: 10094 comm: debootstrap) [ 6413.169920] kernel read not supported for file /usr/bin/true (pid: 15960 comm: chroot) Hello. This is because of VFS changes in Linux-5.10.X. Specifically, because of the following patch: https://lkml.org/lkml/2020/8/17/174 In the upstream git repository it is commit 4d03e3cc59828c82ee89ea6e2 So, Christoph, what to do now for file systems which implement ->read() method of file operations? It seems that chroot doesn't work for them. And people are not able to release distros with upgraded kernels.. Thanks, Edward.
Reiser5 Logical Volume Management - Updates
Reiser5 Logical Volume Management - Updates I am happy to inform, that Logical Volumes stuff has become more stable. Also we introduce the following changes, which make logical volumes administration more flexible and simple: 1. No balancing by default Now all volume operations except brick removal don't invoke balancing by default. Instead, they mark volume as "unbalanced". To complete any operation with balancing specify option -B (--with-balance), or run volume.reiser4(8) utility with the option -b (--balance) later. This allows to speed up more than one operations over logical volume being performed at once. For example, if you want to add more than one brick to your volume at once, first add all the bricks, then run balancing. There is no need to balance a volume between the addition operations. 2. Removal completion Operation of brick removal always includes balancing procedure as its part. This procedure moves out all data block from the brick to be removed to remaining bricks of the volume. Thus, brick removal is usually a long operation, which may be interrupted for various reasons In such cases the volume is automatically marked with an "incomplete removal" flag. It is not allowed to perform essential volume operations on a volume marked as "with incomplete removal": first, user should complete removal by running volume.reiser4 utility with option -R (--finish-removal). Otherwise, the operation will return error (-EBUSY). There is no other restrictions: you are allowed to add a brick to unbalanced volume, and even remove a brick from an unbalanced volume (assuming it is not incomplete removal). Comment. "--finish-removal" is a temporary option. In the future the file system will detect incomplete removal and automatically perform removal completion by itself. 3. Balancing is always defined Operation of volume balancing (regardless of its balanced status) is always defined, and can be launched at any moment. If the volume is balanced, then the balancing procedure just scans the volume without any useful work. It is allowed to run more than one balancing threads on the same volume, however currently it will be inefficient: other threads will be always going after the single leader without doing useful work. Efficient volume balancing by many threads (true parallelism) is not a trivial task. We estimate its complexity as 2/5. 4. Restore regular distribution on the volume Custom (defined by user) file migration can break fairness of data distribution among the bricks. To restore regular (fair) distribution on the volume, run volume.reiser4 utility with the option -S (--restore-regular). It launches a balancing procedure, which performs mandatory data migration of all files (including the ones marked as "immobile") in accordance with regular distribution policy on the volume. Moreover, when the balancing procedure encounters a file marked as "immobile", its "immobile" flag is cleared up. 5. How to test The new functionality is available starting with the kernel patch reiser4-for-linux-5.10-rc3 and reiser4progs-2.0.4 (Software Framework Release number of both is 5.1.3). Links for download: https://sourceforge.net/projects/reiser4/files/v5-unstable/kernel/ https://sourceforge.net/projects/reiser4/files/v5-unstable/progs/ Find updated documentation on getting started with logical volumes: https://reiser4.wiki.kernel.org/index.php/Logical_Volumes_Administration https://reiser4.wiki.kernel.org/index.php/Proxy_Device_Administration https://reiser4.wiki.kernel.org/index.php/Transparent_File_Migration Also see manual pages for volume.reiser4(8) utility.
Re: PROBLEM: Reiser4 hard lockup
On 10/27/2020 08:36 PM, Theodore Y. Ts'o wrote: On Tue, Oct 27, 2020 at 01:53:31AM +0100, Edward Shishkin wrote: reiser4progs 1.1.x Software Framework Release Number (SFRN) 4.0.1 file system utilities should not be used to check/fix media formatted 'a priori' in SFRN 4.0.2 and vice-versa. Honestly, this is the first time I've heard about a Linux FS having versioning other than a major one This is because, unlike other Linux file systems, reiser4 is a framework. In vanilla kernel having a filesystem-as-framework is discouraged for ideological reasons. As they explained: "nobody's interested in plugins". A huge monolithic mess without any internal structure - welcome :) I wouldn't call it an ideological problem, but more about wanting to assure interoperability issues and wanting to reduce confusion on the part of users, especially if images get moved between systems. There is also plenty of way of introducing internal structure and code cleanliness without going completely undisciplined with respect to on-disk format extensions. :-) Have you made this up right now? I remember very well all the requests for merging reiser4 to upstream (in 2004, 2005 and 2006 years) - compatibility claims had never been raised. Especially, it is not a problem to add mechanisms for keeping track of compatibility at any time. Finally, I'll note that ext 2/3/4 does have a rather fine-grained set of feature flags, with specific rules about what the kernel --- and e2fsck --- should do if it finds a feature bit it doesn't understand in the incompat, ro_compat, and compat feature flags set. This is especially helpful since we have multiple implementations of ext 2/3/4 out there (in FreeBSD, the GRUB bootloader, GNU HURD, Fuchsia, etc.) and so using feature bits allow for safe and reliable interoperability with the user being warned if they can safely only mount the file system read-only, or not at all, if the file system has some new feature that their current OS version does not support. We can also give appropriate warnings if they are using an insufficiently recent version of the userspace tools. "Fine-grained" means per-volume decisions mount/not mount/read-only mount? It is even not yesterday technique. It is an ice age... Edward.
Re: PROBLEM: Reiser4 hard lockup
On 10/26/2020 02:07 AM, David Niklas wrote: I'll reply to both of you in this email. On Sun, 25 Oct 2020 02:04:22 -0700 (PDT) Metztli Information Technology wrote: Niltze, David- A few observations are in order below: On Sat, Oct 24, 2020 at 1:39 PM David Niklas wrote: Hello, reiser4progs 1.1.x Software Framework Release Number (SFRN) 4.0.1 file system utilities should not be used to check/fix media formatted 'a priori' in SFRN 4.0.2 and vice-versa. Honestly, this is the first time I've heard about a Linux FS having versioning other than a major one This is because, unlike other Linux file systems, reiser4 is a framework. In vanilla kernel having a filesystem-as-framework is discouraged for ideological reasons. As they explained: "nobody's interested in plugins". A huge monolithic mess without any internal structure - welcome :)
Re: [ANNOUNCE] Reiser5: Selective File Migration - User Interface
On 10/04/2020 11:59 AM, Pavel Machek wrote: Hi! In particular, using this functionality, user is able to push out "hot" files on any high-performance device (e.g. proxy device) and pin them there. What permissions are normally required for file migration? Hi Pavel, I guess, admin ones. With such operation it is possible to organize an attack on a collectively shared volume by clogging some its brick. So that other users, who rely on regular distribution (provided by per-volume distribution table) will get "no space left on device", while other bricks contain a lot of free space.. COMMENT. After ioctl successful completion the file is not necessarily written to the target device! To make sure of it, call fsync(2) after successful ioctl completion, or open the file with O_SYNC flag before migration. Ok. COMMENT. File migration is a volume operation (like adding, removing a device to/from a logical volumes), and all volume operations are serialized. So, any attempt to migrate a file, while performing other operation on that volume will fail. If some file migration procedure fails (with EBUSY, or other errors), or was interrupted by user, then it should be repeated in the current mount session. File migration procedures interrupted by system crash, hared reset, etc) should be repeated in the next mount sessions. Dunno. Returning -EBUSY is kind of "interesting" there. I'd expect kernel to queue the callers, because userland can't really do that easily. You are right. The current solution is temporary. Actually, we don't need to lock the whole volume in order to migrate a file (anyway, the file migration procedure takes an exclusive access to the file). User-defined migration of individual files should be serialized with brick removal. So it will be even per-brick lock rather than per-volume lock.. I think, that it should be a rw-semaphore. Brick removal procedure will take a write lock (with possible waiting) and user-defined migration will try to take a read lock. If busy, then return error (brick is under removal == doesn't exist for user). Thanks, Edward.
Re: PATCH reiser4 support for Linux 5.8.10
On 09/24/2020 07:21 PM, David Niklas wrote: I'm a kernel dev newbie. Please double check my work if in doubt. The patch for reiser4 support for Linux 5.8.1 didn't apply to 5.8.10. It needed only a one line change, but because of all the fuzzy matching and offset matching I thought I'd make a new one. The file that failed to patch is fs/fs-writeback.c. A struct got one of it's members removed. As the entire struct was removed by the patch Hi David, Precisely speaking, it is not removed, but moved to a header file. Anyway, I guess that the missing member wasn't used by reiser4, so feel free to ignore it. Thanks, Edward. I thought it good to ignore the missing member instead of trying to dig up what it was used for and why it was removed. Thanks, David
Re: [ANNOUNCE] Reiser5: Selective File Migration - User Interface
On 08/28/2020 01:50 AM, Edward Shishkin wrote: On 08/27/2020 11:53 PM, Metztli Information Technology wrote: On Wed, Aug 26, 2020 at 2:13 PM Edward Shishkin wrote: [...] FYI Although not officially, the Debian metaframework Buster AMD64 distribution might be the first to support native installation of Reiser4 SFRN 5.1.3, kernel and reiser4progs 2.0.3, file system utilities. I have already made a couple of successful Metztli Reiser4 SFRN 5 native installations onto ~100 GB slices, which root file system is formatted in 'Reiser5' and 1 GB /boot in JFS. https://metztli.it/reiser5 (Screenshot 600x338 size) The upgraded netboot installation media metztli-reiser4-sfrn5.iso is available at: https://sourceforge.net/projects/debian-reiser4/ as well as https://metztli.it/buster-reiser5/metztli-reiser4-sfrn5.iso https://metztli.it/buster-reiser5/metztli-reiser4-sfrn5.iso.SHA256SUM Likely the brick/volume feature(s) will be useful in Cloud fabric infrastructures, like Google's, where reiser4 excels. The current SFRN 5.1.3 -patched Zstd -compressed kernel in the installation media is Debian's 5.7.10. wow, reiser5 from the box? I might want to try.. Well, it is more of a 'reference implementation' as there are persons who reached out to me because their builds succeeded, they were able to format in reiser4 SFRN x.y.z, but they were not able to mount their partition(s). Turns out, they were inadvertently mixing SFRN 4.0.2 with 5.1.3, either in the reiser4 kernel patch -- released with the same in both instances -- or in the reiser4progs. Yeah, some confusion can take place. Plus unsupported old 4.0.2 volumes (a special build with CONFIG_REISER4_OLD=y is required to mount them), which is a payment for performance. The installer defaults to create the root system reiser5 -formatted partition as: mkfs.reiser4 -yo "create=reg42" "reg42" is default profile in reiser4progs-2.0.3 (check by "mkfs.reiser4 -p") - there is no need to specify it via option. Acknowledged. Thanks. Have you had a chance to play with logical volumes (add/remove bricks, etc)? That is coming up. I still have to create/customize an image of Metztli Reiser4 SFRN5 for a Google Compute Engine (GCE) minimal ~200GB instance for evaluation. Fact is 'not all clouds are created equal' -- even if KVM -based. For instance, reiser4 SFRN 4.0.2 on a trial Linode small ~80GB SSD slice(s) with 2 virtual cpus frequently hung under short sustained disk/network I/O usage. I have not experienced that with reiser4 SFRN 4.0.2 on GCE -- where sometimes I allocate eight to sixteen virtual cpus with 16, 32, or even 64, GBs of RAM, on a region hosting AMD Epyc, for fast kernel building ops. But testing a relatively small bootable image first will usually provide insight if adding one, two... eight, TB slices will make sense later on. I played with your media on a virtual machine. The basic volume operations work, however, I guess, adding brick(s) to "/" will cause problems at next boot: someone has to register all the bricks before mounting "/"... It is important to register all bricks *before* mounting "/", as the registration procedure collects information need for volume activation (including transaction replay, etc). So at boot time before mounting "/" we need to scan the system and for each found block device call a brick registration procedure. The problem is that I don't know what do we actually have before mounting "/". Brick registration can be performed by calling "volume.reiser4 -g". However, it accepts device name, that we obviously don't have, as all the names are in "/", which is not yet mounted. I guess that solution exists (and possibly locates in initrd), because, it is perfectly possible to boot e.g. with root over LVM (a special utility scans the system and collects information about devices- components of the logical volume). Any ideas? Thanks, Edward.
Re: [ANNOUNCE] Reiser5: Selective File Migration - User Interface
On 08/27/2020 11:53 PM, Metztli Information Technology wrote: On Wed, Aug 26, 2020 at 2:13 PM Edward Shishkin wrote: [...] FYI Although not officially, the Debian metaframework Buster AMD64 distribution might be the first to support native installation of Reiser4 SFRN 5.1.3, kernel and reiser4progs 2.0.3, file system utilities. I have already made a couple of successful Metztli Reiser4 SFRN 5 native installations onto ~100 GB slices, which root file system is formatted in 'Reiser5' and 1 GB /boot in JFS. https://metztli.it/reiser5 (Screenshot 600x338 size) The upgraded netboot installation media metztli-reiser4-sfrn5.iso is available at: https://sourceforge.net/projects/debian-reiser4/ as well as https://metztli.it/buster-reiser5/metztli-reiser4-sfrn5.iso https://metztli.it/buster-reiser5/metztli-reiser4-sfrn5.iso.SHA256SUM Likely the brick/volume feature(s) will be useful in Cloud fabric infrastructures, like Google's, where reiser4 excels. The current SFRN 5.1.3 -patched Zstd -compressed kernel in the installation media is Debian's 5.7.10. wow, reiser5 from the box? I might want to try.. Well, it is more of a 'reference implementation' as there are persons who reached out to me because their builds succeeded, they were able to format in reiser4 SFRN x.y.z, but they were not able to mount their partition(s). Turns out, they were inadvertently mixing SFRN 4.0.2 with 5.1.3, either in the reiser4 kernel patch -- released with the same in both instances -- or in the reiser4progs. Yeah, some confusion can take place. Plus unsupported old 4.0.2 volumes (a special build with CONFIG_REISER4_OLD=y is required to mount them), which is a payment for performance. The installer defaults to create the root system reiser5 -formatted partition as: mkfs.reiser4 -yo "create=reg42" "reg42" is default profile in reiser4progs-2.0.3 (check by "mkfs.reiser4 -p") - there is no need to specify it via option. Acknowledged. Thanks. Have you had a chance to play with logical volumes (add/remove bricks, etc)? That is coming up. I still have to create/customize an image of Metztli Reiser4 SFRN5 for a Google Compute Engine (GCE) minimal ~200GB instance for evaluation. Fact is 'not all clouds are created equal' -- even if KVM -based. For instance, reiser4 SFRN 4.0.2 on a trial Linode small ~80GB SSD slice(s) with 2 virtual cpus frequently hung under short sustained disk/network I/O usage. I have not experienced that with reiser4 SFRN 4.0.2 on GCE -- where sometimes I allocate eight to sixteen virtual cpus with 16, 32, or even 64, GBs of RAM, on a region hosting AMD Epyc, for fast kernel building ops. But testing a relatively small bootable image first will usually provide insight if adding one, two... eight, TB slices will make sense later on. I played with your media on a virtual machine. The basic volume operations work, however, I guess, adding brick(s) to "/" will cause problems at next boot: someone has to register all the bricks before mounting "/"... It seems that we need to maintain a kind of volume configuration (at /etc/reiser4, or so) to automate that process. Unfortunately, I am currently busy with making things stable. If anyone could take a look at this, I would be appreciated. Thanks, Edward.
Re: [ANNOUNCE] Reiser5: Selective File Migration - User Interface
[...] FYI Although not officially, the Debian metaframework Buster AMD64 distribution might be the first to support native installation of Reiser4 SFRN 5.1.3, kernel and reiser4progs 2.0.3, file system utilities. I have already made a couple of successful Metztli Reiser4 SFRN 5 native installations onto ~100 GB slices, which root file system is formatted in 'Reiser5' and 1 GB /boot in JFS. https://metztli.it/reiser5 (Screenshot 600x338 size) The upgraded netboot installation media metztli-reiser4-sfrn5.iso is available at: https://sourceforge.net/projects/debian-reiser4/ as well as https://metztli.it/buster-reiser5/metztli-reiser4-sfrn5.iso https://metztli.it/buster-reiser5/metztli-reiser4-sfrn5.iso.SHA256SUM Likely the brick/volume feature(s) will be useful in Cloud fabric infrastructures, like Google's, where reiser4 excels. The current SFRN 5.1.3 -patched Zstd -compressed kernel in the installation media is Debian's 5.7.10. wow, reiser5 from the box? I might want to try.. The installer defaults to create the root system reiser5 -formatted partition as: mkfs.reiser4 -yo "create=reg42" "reg42" is default profile in reiser4progs-2.0.3 (check by "mkfs.reiser4 -p") - there is no need to specify it via option. Have you had a chance to play with logical volumes (add/remove bricks, etc)? Thanks! Edward.
Re: PROBLEM: IO lockup on reiserfs FS.
On 08/06/2020 02:01 AM, hgntk...@vfemail.net wrote: On Wed, 5 Aug 2020 12:51:41 -0700 Linus Torvalds wrote: On Wed, Aug 5, 2020 at 9:53 AM wrote: It's been over 1 week since I sent this into the reiserfs-devel mailing list. I'm escalating this as the kernel docs recommend. I'm still willing to help debug and test a fix for this problem. The thing is, you're using an ancient 4.14 kernel, Sorry, I didn't realize kernel development went that fast. I did try to go to the 5.X series, but the AMDGPU drivers don't work on my SI card anymore (I need to bisect which takes time and many re-boots to find the problematic commit). I'll try the Radeon-SI driver and see if I can reproduce this reliably. and a filesystem that isn't really maintained any more. You'll find very few people interested in trying to debug that combination. You *might* have more luck with a more modern kernel, but even then ... reiserfs? Linus Why does no one (I've met others who share a similar sentiment), like reiserfs? I'm not looking for fight, I'm incredulous. It's a great FS that survives oops-es, power failures, and random crashes very very well. It's the only FLOSS FS with tail packing. Thanks, David Hi David, The feature of "tail packing", that you need, is brought to perfection in Reiser4 file system. Other file systems either don't provide tight packing of records in the storage tree, or they are read-only. You just need to manually patch (*) the kernel and install a pair of user-space packages (**). The latest stuff (against Linux-5.7) is stable. For older kernels you will need a backport for some fixups (***). We can prepare it for you. Reiser4 is fully supported. If any problems (including partition check/repair) - send a message to reiserfs-devel mailing list. (*) https://reiser4.wiki.kernel.org/index.php/Reiser4_Howto https://sourceforge.net/projects/reiser4/files/ (**) https://sourceforge.net/projects/reiser4/files/reiser4-utils/ (***) https://marc.info/?l=reiserfs-devel=158086248927420=2 Thanks, Edward.
[ANNOUNCE] Reiser5: Selective File Migration - User Interface
Reiser5: selective file migration. Setting/clearing file "immobile" status Earlier any migration of data blocks in reiser5 logical volumes occurred only in the context of some volume balancing procedure, which actually is a massive migration, aiming to keep fairness of distribution on the whole logical volume. Typically such migrations complete some volume operations, e.g. adding a device to a logical volume, removing a device from a logical volume, increasing data capacity of a device, flushing a proxy-device, etc). Now user can perform selective data migration. That is, migrate only data of some specified regular file to any specified device-component of the logical volume. Also, for any specified regular file user can mark it as "immobile", so that volume balancing procedures will ignore that file. Finally, for any specified regular file user can clear its "immobile" status, so that the file will be movable again by volume balancing procedures. In particular, using this functionality, user is able to push out "hot" files on any high-performance device (e.g. proxy device) and pin them there. To test the new functionality use reiser4-for-5.7.4.patch of v5-unstable branch(*) and reiser4progs-2.0.2 (or newer stuff) (*) https://sourceforge.net/projects/reiser4/files/v5-unstable/ File Migration: API - /* * Migrate file to specified target device. * @fd: file descriptor * @idx: serial number of target device in the logical volume */ /* * Provide correct path here. * This header file can be found in reiser4 kernel module, or * reiser4progs sources */ #include "reiser4/ioctl.h" struct reiser4_vol_op_args args; memset(, 0, sizeof(args)); args.opcode = REISER4_MIGRATE_FILE; args.val = idx; result = ioctl(fd, REISER4_IOC_VOLUME, ); -- COMMENT. After ioctl successful completion the file is not necessarily written to the target device! To make sure of it, call fsync(2) after successful ioctl completion, or open the file with O_SYNC flag before migration. COMMENT. File migration is a volume operation (like adding, removing a device to/from a logical volumes), and all volume operations are serialized. So, any attempt to migrate a file, while performing other operation on that volume will fail. If some file migration procedure fails (with EBUSY, or other errors), or was interrupted by user, then it should be repeated in the current mount session. File migration procedures interrupted by system crash, hared reset, etc) should be repeated in the next mount sessions. -- Set file immobile status: API - /* * Set file "immobile". * @fd: file descriptor */ /* * Provide correct path here. * This header file can be found in reiser4 kernel module, or * reiser4progs sources */ #include "reiser4/ioctl.h" struct reiser4_vol_op_args args; memset(, 0, sizeof(args)); args.opcode = REISER4_SET_FILE_IMMOBILE; result = ioctl(fd, REISER4_IOC_VOLUME, ); COMMENT. The immobile status guarantees that any data block of that file won't migrate to another device-component of the logical volume. Note, however, that such block can be easily relocated within device where it currently resides (once the file system finds better location for that block, etc). -- NOTE: All balancing procedures, which complete device removal, will ignore "immobile" status of any file. After device removal successful completion all data blocks of "immobile" files will be relocated to the remaining devices in accordance with current distribution policy. NOTE: Any selective file migration described above will ignore "immobile" status of the file! So the "immobile" status is honored only by volume balancing procedures, completing some operations such as adding a device to the logical volume, changing capacity of some device or flushing a proxy device. - Clear File immobile status: API /* * Clear file "immobile" status. * @fd: file descriptor */ /* * Provide correct path here. * This header file can be found in reiser4 kernel module, or * reiser4progs sources */ #include "reiser4/ioctl.h" struct reiser4_vol_op_args args; memset(, 0, sizeof(args)); args.opcode = REISER4_CLR_FILE_IMMOBILE; result = ioctl(fd, REISER4_IOC_VOLUME, ); -- NOTE: Selective file migration can make your distribution unfair! Currently it is strongly recommended to migrate files only to devices, which don't participate in regular data distribution e.g. proxy device In the future it will be possible to turn off builtin distribution on any volume. in this case user will be responsible for appointing a destination device for any file on that volume. File migration by
Re: [ANNOUNCE] Reiser5: Data Tiering. Burst Buffers. Speedup synchronous modifications
On 05/30/2020 12:13 PM, Pavel Machek wrote:
Hi!
For example, you can use proxy device to store hot data only. With
such strategy new logical blocks (which are always "cold") will always
go to the main storage (in contrast with Burst Buffers, where new
logical blocks first get written to the proxy disk). Once in a while
you need to scan your volume in order to push colder data out, and
pull hotter data in the proxy disk. Reiser5 contains a common
interface for this. It is possible to maintain per-file, or even per-
blocks-extent "temperature" of data (e.g. as a generation counter),
Would it be possible to offer userland interface for this? I can
probably say that mp3/video files should be cold, while some source
files should be hot, etc...
Best regards,
Pavel
Hi Pavel,
Yes, it is possible. One just needs to add an ioctl handler for regular
files managed by a plugin with STRIPED_FILE_PLUGIN_ID. That handler is
to set user-defined "temperature" to a file.
Also we'll need an additional on-disk file attribute (32 (or 64?)-bit
field in the private part of inode) to store the "temperature" in. It
can be added by standard way via implementation of respective stat-data
extension in the file reiser4/plugin/item/static_stat.c
Finally, we'll need to handle temperature in the common migration
procedure balance_volume_asym(), which is responsible for clearing up
the proxy device. It should look like this:
...
if (!IS_ERR(inode) && inode_file_plugin(inode)->balance &&
file_is_cold_enough(inode)) {
reiser4_iget_complete(inode);
/*
* migrate data blocks of this file
*/
...
Currently it works as if all files are "cold" (i.e. migrates
everything).
Once I find the current stuff more-or-less stable I'll add temperature
support and send the patch.
Thanks,
Edward.
Re: [ANNOUNCE] Reiser5: Data Tiering. Burst Buffers. Speedup synchronous modifications
On 05/30/2020 02:32 PM, jose@metztli.com wrote: On Mon, May 25, 2020 at 6:08 PM Edward Shishkin wrote: Reiser5: Data Tiering. Burst Buffers Speedup synchronous modifications Dumping peaks of IO load to a proxy device Now you can add a small high-performance block device to your large logical volume composed of relatively slow commodity disks and get an impression that the whole your volume has throughput which is as high, as the one of that "proxy" device! This is based on a simple observation that in real life IO load is going by peaks, and the idea is to dump those peaks to a high- performance "proxy" device. Usually you have enough time between peaks to flush the proxy device, that is, to migrate the "hot data" from the proxy device to slow media in background mode, so that your proxy device is always ready to accept a new portion of "peaks". Such technique, which is also known as "Burst Buffers", initially appeared in the area of HPC. Despite this fact, it is also important for usual applications. In particular, it allows to speedup the ones, which perform so-called "atomic updates". Speedup "atomic updates" in user-space There is a whole class of applications with high requirements to data integrity. Such applications (typically data bases) want to be sure that any data modifications either complete, or they don't. And they don't appear as partially occurred. Some applications has weaker requirements: with some restrictions they accept also partially occurred modifications. Atomic updates in user space are performed via a sequence of 3 steps. Suppose you need to modify data of some file "foo" in an atomic way. For this you need to: 1. write a new temporary file "foo.tmp" with modified data 2. issue fsync(2) against "foo.tmp" 3. rename "foo.tmp" to "foo". At step 1 the file system populates page cache with new data At step 2 the file system allocates disk addresses for all logical blocks of the file foo.tmp and writes that file to disk. At step 3 all blocks containing old data get released. Note that steps 2 and 3 become a reason of essential performance drop on slow media. The situation gets improved, when all dirty data are written to a dedicated high-performance proxy-disk, which exactly happens in a file system with Burst Buffers support. Speedup all synchronous modifications (TODO) Burst Buffers and transaction manager Not only dirty data pages, but also dirty meta-data pages can be dumped to the proxy-device, so that step (3) above also won't contribute to the performance drop. Moreover, not only new logical data blocks can be dumped to the proxy disk. All dirty data pages, including ones, which already have location on the main (slow) storage can also be relocated to the proxy disk, thus, speeding up synchronous modification of files in _all_ cases (not only in atomic updates via write-fsync-rename sequence described above). Indeed, let's remind that any modified page is always written to disk in a context of committing some transaction. Depending on the commit strategy (there are 2 ones "relocate" and "overwrite"), for each such modified dirty page there are only 2 possibility: a) to be written right away to a new location, b) to be written first to a temporary location (journal), then to be written back to permanent location. With Burst buffers support in the case (a) the file system writes dirty page right away to the proxy device. Then user should take care to migrate it back to the permanent storage (see section "Flushing proxy devise" below). In the case (b) the modified copy will be written to the proxy device (wandering logs), then at checkpoint time (playing a transaction) reiser4 transaction manager will write it to the permanent location (on commodity disks). In this case user doesn't need to worry on flushing proxy device, however, the procedure of commit takes more time, as user should also wait for "checkpoint completion". So from the standpoint of performance "write-anywhere" transaction model (reiser4 mount option "txmod=wa") is more preferable then journalling model (txmod=journal), or even hybrid model (txmod=hybrid) Predictable and non-predictable migration Meta-data migration As we already mentioned, not only dirty data pages, but also dirty meta-data pages can be dumped to the proxy-device. Note, however, that not predictable meta-data migration is not possible because of chicken-eggish problem. Indeed, non-predictable migration means that nobody knows, on what device of your logical volume a stripe of data will be relocated in the future. Such migration requires to record location of data stripes. Now note, that
[ANNOUNCE] Reiser5: Data Tiering. Burst Buffers. Speedup synchronous modifications
Reiser5: Data Tiering. Burst Buffers Speedup synchronous modifications Dumping peaks of IO load to a proxy device Now you can add a small high-performance block device to your large logical volume composed of relatively slow commodity disks and get an impression that the whole your volume has throughput which is as high, as the one of that "proxy" device! This is based on a simple observation that in real life IO load is going by peaks, and the idea is to dump those peaks to a high- performance "proxy" device. Usually you have enough time between peaks to flush the proxy device, that is, to migrate the "hot data" from the proxy device to slow media in background mode, so that your proxy device is always ready to accept a new portion of "peaks". Such technique, which is also known as "Burst Buffers", initially appeared in the area of HPC. Despite this fact, it is also important for usual applications. In particular, it allows to speedup the ones, which perform so-called "atomic updates". Speedup "atomic updates" in user-space There is a whole class of applications with high requirements to data integrity. Such applications (typically data bases) want to be sure that any data modifications either complete, or they don't. And they don't appear as partially occurred. Some applications has weaker requirements: with some restrictions they accept also partially occurred modifications. Atomic updates in user space are performed via a sequence of 3 steps. Suppose you need to modify data of some file "foo" in an atomic way. For this you need to: 1. write a new temporary file "foo.tmp" with modified data 2. issue fsync(2) against "foo.tmp" 3. rename "foo.tmp" to "foo". At step 1 the file system populates page cache with new data At step 2 the file system allocates disk addresses for all logical blocks of the file foo.tmp and writes that file to disk. At step 3 all blocks containing old data get released. Note that steps 2 and 3 become a reason of essential performance drop on slow media. The situation gets improved, when all dirty data are written to a dedicated high-performance proxy-disk, which exactly happens in a file system with Burst Buffers support. Speedup all synchronous modifications (TODO) Burst Buffers and transaction manager Not only dirty data pages, but also dirty meta-data pages can be dumped to the proxy-device, so that step (3) above also won't contribute to the performance drop. Moreover, not only new logical data blocks can be dumped to the proxy disk. All dirty data pages, including ones, which already have location on the main (slow) storage can also be relocated to the proxy disk, thus, speeding up synchronous modification of files in _all_ cases (not only in atomic updates via write-fsync-rename sequence described above). Indeed, let's remind that any modified page is always written to disk in a context of committing some transaction. Depending on the commit strategy (there are 2 ones "relocate" and "overwrite"), for each such modified dirty page there are only 2 possibility: a) to be written right away to a new location, b) to be written first to a temporary location (journal), then to be written back to permanent location. With Burst buffers support in the case (a) the file system writes dirty page right away to the proxy device. Then user should take care to migrate it back to the permanent storage (see section "Flushing proxy devise" below). In the case (b) the modified copy will be written to the proxy device (wandering logs), then at checkpoint time (playing a transaction) reiser4 transaction manager will write it to the permanent location (on commodity disks). In this case user doesn't need to worry on flushing proxy device, however, the procedure of commit takes more time, as user should also wait for "checkpoint completion". So from the standpoint of performance "write-anywhere" transaction model (reiser4 mount option "txmod=wa") is more preferable then journalling model (txmod=journal), or even hybrid model (txmod=hybrid) Predictable and non-predictable migration Meta-data migration As we already mentioned, not only dirty data pages, but also dirty meta-data pages can be dumped to the proxy-device. Note, however, that not predictable meta-data migration is not possible because of chicken-eggish problem. Indeed, non-predictable migration means that nobody knows, on what device of your logical volume a stripe of data will be relocated in the future. Such migration requires to record location of data stripes. Now note, that such records is always a part of meta-data. Hence, you are now able to migrate meta-data in non-predictable way. However, it is perfectly possible to distribute/migrate meta-data in a predictable way (it will be supported in so-called "symmetric" logical volumes - currently not implemented). Classic example of
Re: Reiser4 Linux 4.17.19-1 hangs in Google cloud VM, too.
On 10/23/2018 06:28 AM, Jose R R wrote: Thank you for replying, Al- On Mon, Oct 22, 2018 at 8:38 PM Al Viro wrote: On Mon, Oct 22, 2018 at 03:19:12AM -0700, Metztli Information Technology wrote: I installed reiser4 -enhanced Linux kernel 4.17.19-1 --thus replacing the prior hung reiser4 -patched kernel 4.18.15-1 in the Google Compute Engine (GCE) cloud instance. After less than 24 hours the 4.17.19-1 hung in similar way to the 4.18.15-1. Please note that I had been running my custom Metztli Reiser4 Debian Stretch image with reiser4 linux 4.14.20-1 without issues for several months < https://github.com/Metztli/reiser4-debian-kernel-packaging-4.14.20 > --until I decided to upgrade to newer kernel(s). Hello. Looks like a regression because of VFS/block-layer changes (I don't test new releases carefully enough). Once I am back from vacations, I'll have a look at this.. Thanks, Edward. That link you referenced is just my hack for the corresponding Debian kernel packaging (wrapper) to build 'Reiser4 the Debian Way', i.e, generating reiser4 module & kernel -- suitable for installation media -- in addition to Debian's. Er... Does anybody maintain reiser4 these days? I can't recall a single mail along the lines of "such-and-such VFS/VM/scheduler/etc. change would break reiser4" in quite a few years (more than a decade, most likely)... This is the actual patch for the Linux 4.14.xy series: < https://sourceforge.net/projects/reiser4/files/reiser4-for-linux-4.x/reiser4-for-4.14.1.patch.gz/download And yes, Mr. Edward Shishkin, still develops/maintains reiser4, please see: < https://github.com/edward6/reiser4 > I have a couple of reiser4 custom Google Compute Engine (GCE) cloud instances which have been running LAMP for a while. One of them runs reiser4 -enabled Linux kernel 4.15.x whereas the other one was running 4.14.x (both for several months/years already) until I decided to upgrade the 4.4.20-1 to newer reiser4 -enabled kernels. By the way this last kernel that I installed: uname -a Linux cohuatl 4.16.0-2+reiser4.0.2-amd64 #1 SMP Debian 4.16.18-2 (2018-06-27) x86_64 GNU/Linux seems to be performing nicely --if things continue fine I can assume that the drastic change affecting reiser4 hacked kernels occurred beginning with upstream Linux series 4.17.x and on... Best Professional Regards.
Re: Reiser4 Linux 4.17.19-1 hangs in Google cloud VM, too.
On 10/23/2018 06:28 AM, Jose R R wrote: Thank you for replying, Al- On Mon, Oct 22, 2018 at 8:38 PM Al Viro wrote: On Mon, Oct 22, 2018 at 03:19:12AM -0700, Metztli Information Technology wrote: I installed reiser4 -enhanced Linux kernel 4.17.19-1 --thus replacing the prior hung reiser4 -patched kernel 4.18.15-1 in the Google Compute Engine (GCE) cloud instance. After less than 24 hours the 4.17.19-1 hung in similar way to the 4.18.15-1. Please note that I had been running my custom Metztli Reiser4 Debian Stretch image with reiser4 linux 4.14.20-1 without issues for several months < https://github.com/Metztli/reiser4-debian-kernel-packaging-4.14.20 > --until I decided to upgrade to newer kernel(s). Hello. Looks like a regression because of VFS/block-layer changes (I don't test new releases carefully enough). Once I am back from vacations, I'll have a look at this.. Thanks, Edward. That link you referenced is just my hack for the corresponding Debian kernel packaging (wrapper) to build 'Reiser4 the Debian Way', i.e, generating reiser4 module & kernel -- suitable for installation media -- in addition to Debian's. Er... Does anybody maintain reiser4 these days? I can't recall a single mail along the lines of "such-and-such VFS/VM/scheduler/etc. change would break reiser4" in quite a few years (more than a decade, most likely)... This is the actual patch for the Linux 4.14.xy series: < https://sourceforge.net/projects/reiser4/files/reiser4-for-linux-4.x/reiser4-for-4.14.1.patch.gz/download And yes, Mr. Edward Shishkin, still develops/maintains reiser4, please see: < https://github.com/edward6/reiser4 > I have a couple of reiser4 custom Google Compute Engine (GCE) cloud instances which have been running LAMP for a while. One of them runs reiser4 -enabled Linux kernel 4.15.x whereas the other one was running 4.14.x (both for several months/years already) until I decided to upgrade the 4.4.20-1 to newer reiser4 -enabled kernels. By the way this last kernel that I installed: uname -a Linux cohuatl 4.16.0-2+reiser4.0.2-amd64 #1 SMP Debian 4.16.18-2 (2018-06-27) x86_64 GNU/Linux seems to be performing nicely --if things continue fine I can assume that the drastic change affecting reiser4 hacked kernels occurred beginning with upstream Linux series 4.17.x and on... Best Professional Regards.
Re: REISER4: Attention Edward Shishkin (reiser4progs-1.0.6)
[EMAIL PROTECTED] wrote:
REISER4: Attention Edward Shishkin (reiser4progs-1.0.6)
-
-
Hi Edward, it has been pointed out that you CHANGED reiser4progs-1.0.6
in your version
http://chichkin_i.zelnet.ru/namesys/reiser4progs-1.0.6.tar.gz
from the version previously supplied by namesys.com
ftp://ftp.namesys.com/pub/reiser4progs/reiser4progs-1.0.6.tar.gz
Hmm, but I have found they are synchronized...
Does this have any relevance for REISER4 that I should know about?
I guess you have downloaded your reiser4progs-1.0.6 before it was
announced at 14 Mar 2007 ( http://lkml.org/lkml/2007/3/14/446 )
There is nothing criminal here: the latest version uses more progressive
compression mode as default one, plus some options got other name.
Thanks,
Edward.
I have included a diff between the two versions.
-
-
diff -pruN reiser4progs-1.0.6-namesys/include/reiser4/plugin.h
reiser4progs-1.0.6-shinkin/include/reiser4/plugin.h
--- reiser4progs-1.0.6-namesys/include/reiser4/plugin.h 2006-11-01
14:50:34.0 +
+++ reiser4progs-1.0.6-shinkin/include/reiser4/plugin.h 2007-02-27
15:25:16.0 +
@@ -273,11 +273,10 @@ enum reiser4_crypto_id {
enum reiser4_compress_mode_id {
CMODE_NONE_ID = 0x0,
- CMODE_COL8_ID = 0x1,
- CMODE_COL16_ID = 0x2,
- CMODE_COL32_ID = 0x3,
+ CMODE_LATTD_ID = 0x1,
+ CMODE_ULTIM_ID = 0x2,
+ CMODE_FORCE_ID = 0x3,
CMODE_CONVX_ID = 0x4,
- CMODE_FORCE_ID = 0x5,
CMODE_LAST_ID
};
diff -pruN reiser4progs-1.0.6-namesys/libreiser4/factory.c
reiser4progs-1.0.6-shinkin/libreiser4/factory.c
--- reiser4progs-1.0.6-namesys/libreiser4/factory.c 2006-11-01
14:50:34.0 +
+++ reiser4progs-1.0.6-shinkin/libreiser4/factory.c 2007-02-27
15:40:43.0 +
@@ -269,11 +269,10 @@ errno_t reiser4_factory_init(void) {
__load_plug(gzip1);
__load_plug(nocompress);
- __load_plug(col8);
- __load_plug(col16);
- __load_plug(col32);
- __load_plug(convx);
+ __load_plug(lattd);
+ __load_plug(ultim);
__load_plug(force);
+ __load_plug(convx);
__load_plug(clust64);
__load_plug(clust32);
diff -pruN reiser4progs-1.0.6-namesys/libreiser4/profile.c
reiser4progs-1.0.6-shinkin/libreiser4/profile.c
--- reiser4progs-1.0.6-namesys/libreiser4/profile.c 2006-11-01
14:50:34.0 +
+++ reiser4progs-1.0.6-shinkin/libreiser4/profile.c 2007-01-20
11:08:31.0 +
@@ -145,7 +145,7 @@ reiser4_profile_t defprof = {
.hidden = 0,
.max = CMODE_LAST_ID,
#endif
- .id = {CMODE_COL8_ID, 0, CMODE_PLUG_TYPE},
+ .id = {CMODE_CONVX_ID, 0, CMODE_PLUG_TYPE},
},
[PROF_CRYPTO] = {
#ifndef ENABLE_MINIMAL
diff -pruN reiser4progs-1.0.6-namesys/plugin/compress/compress_mode.c
reiser4progs-1.0.6-shinkin/plugin/compress/compress_mode.c
--- reiser4progs-1.0.6-namesys/plugin/compress/compress_mode.c
2006-11-01 14:50:34.0 +
+++ reiser4progs-1.0.6-shinkin/plugin/compress/compress_mode.c
2007-02-27 15:32:30.0 +
@@ -19,22 +19,22 @@ reiser4_plug_t nocompress_plug = {
.desc = "'Don't compress' compression mode plugin.",
};
-reiser4_plug_t col8_plug = {
- .id= {CMODE_COL8_ID, 0, CMODE_PLUG_TYPE},
- .label = "col8",
- .desc = "'Check on lattice-8' compression mode plugin.",
+reiser4_plug_t lattd_plug = {
+ .id= {CMODE_LATTD_ID, 0, CMODE_PLUG_TYPE},
+ .label = "latt",
+ .desc = "'Check on dynamic lattice' compression mode plugin.",
};
-reiser4_plug_t col16_plug = {
- .id= {CMODE_COL16_ID, 0, CMODE_PLUG_TYPE},
- .label = "col16",
- .desc = "'Check on lattice-16' compression mode plugin.",
+reiser4_plug_t ultim_plug = {
+ .id= {CMODE_ULTIM_ID, 0, CMODE_PLUG_TYPE},
+ .label = "ultim",
+ .desc = "'Check ultimately' compression mode plugin.",
};
-reiser4_plug_t col32_plug = {
- .id= {CMODE_COL32_ID, 0, CMODE_PLUG_TYPE},
- .label = "col32",
- .desc = "'Check on lattice-32' compression mode plugin.",
+reiser4_plug_t force_plug = {
+ .id= {CMODE_FORCE_ID, 0, CMODE_PLUG_TYPE},
+ .label = "force",
+ .desc = "'Compress evrything' compression mode plugin.",
};
reiser4_plug_t convx_plug = {
@@ -42,11 +42,4 @@ reiser4_plug_t convx_plug = {
.label = "conv",
.desc = "'Convert to extent' compression mode plugin.",
};
-
-reiser4_plug_t force_plug = {
- .id= {CMODE_FORCE_ID, 0, CMODE_PLUG_TYPE},
- .label = "force",
- .desc = "'Compress evrything' compression mode plugin.",
-};
-
#endif
More new features than ever. Check out the new AOL Mail ! -
http://webmail.aol.com
--
To unsubscribe from this lis
Re: REISER4: Attention Edward Shishkin (reiser4progs-1.0.6)
[EMAIL PROTECTED] wrote:
REISER4: Attention Edward Shishkin (reiser4progs-1.0.6)
-
-
Hi Edward, it has been pointed out that you CHANGED reiser4progs-1.0.6
in your version
http://chichkin_i.zelnet.ru/namesys/reiser4progs-1.0.6.tar.gz
from the version previously supplied by namesys.com
ftp://ftp.namesys.com/pub/reiser4progs/reiser4progs-1.0.6.tar.gz
Hmm, but I have found they are synchronized...
Does this have any relevance for REISER4 that I should know about?
I guess you have downloaded your reiser4progs-1.0.6 before it was
announced at 14 Mar 2007 ( http://lkml.org/lkml/2007/3/14/446 )
There is nothing criminal here: the latest version uses more progressive
compression mode as default one, plus some options got other name.
Thanks,
Edward.
I have included a diff between the two versions.
-
-
diff -pruN reiser4progs-1.0.6-namesys/include/reiser4/plugin.h
reiser4progs-1.0.6-shinkin/include/reiser4/plugin.h
--- reiser4progs-1.0.6-namesys/include/reiser4/plugin.h 2006-11-01
14:50:34.0 +
+++ reiser4progs-1.0.6-shinkin/include/reiser4/plugin.h 2007-02-27
15:25:16.0 +
@@ -273,11 +273,10 @@ enum reiser4_crypto_id {
enum reiser4_compress_mode_id {
CMODE_NONE_ID = 0x0,
- CMODE_COL8_ID = 0x1,
- CMODE_COL16_ID = 0x2,
- CMODE_COL32_ID = 0x3,
+ CMODE_LATTD_ID = 0x1,
+ CMODE_ULTIM_ID = 0x2,
+ CMODE_FORCE_ID = 0x3,
CMODE_CONVX_ID = 0x4,
- CMODE_FORCE_ID = 0x5,
CMODE_LAST_ID
};
diff -pruN reiser4progs-1.0.6-namesys/libreiser4/factory.c
reiser4progs-1.0.6-shinkin/libreiser4/factory.c
--- reiser4progs-1.0.6-namesys/libreiser4/factory.c 2006-11-01
14:50:34.0 +
+++ reiser4progs-1.0.6-shinkin/libreiser4/factory.c 2007-02-27
15:40:43.0 +
@@ -269,11 +269,10 @@ errno_t reiser4_factory_init(void) {
__load_plug(gzip1);
__load_plug(nocompress);
- __load_plug(col8);
- __load_plug(col16);
- __load_plug(col32);
- __load_plug(convx);
+ __load_plug(lattd);
+ __load_plug(ultim);
__load_plug(force);
+ __load_plug(convx);
__load_plug(clust64);
__load_plug(clust32);
diff -pruN reiser4progs-1.0.6-namesys/libreiser4/profile.c
reiser4progs-1.0.6-shinkin/libreiser4/profile.c
--- reiser4progs-1.0.6-namesys/libreiser4/profile.c 2006-11-01
14:50:34.0 +
+++ reiser4progs-1.0.6-shinkin/libreiser4/profile.c 2007-01-20
11:08:31.0 +
@@ -145,7 +145,7 @@ reiser4_profile_t defprof = {
.hidden = 0,
.max = CMODE_LAST_ID,
#endif
- .id = {CMODE_COL8_ID, 0, CMODE_PLUG_TYPE},
+ .id = {CMODE_CONVX_ID, 0, CMODE_PLUG_TYPE},
},
[PROF_CRYPTO] = {
#ifndef ENABLE_MINIMAL
diff -pruN reiser4progs-1.0.6-namesys/plugin/compress/compress_mode.c
reiser4progs-1.0.6-shinkin/plugin/compress/compress_mode.c
--- reiser4progs-1.0.6-namesys/plugin/compress/compress_mode.c
2006-11-01 14:50:34.0 +
+++ reiser4progs-1.0.6-shinkin/plugin/compress/compress_mode.c
2007-02-27 15:32:30.0 +
@@ -19,22 +19,22 @@ reiser4_plug_t nocompress_plug = {
.desc = 'Don't compress' compression mode plugin.,
};
-reiser4_plug_t col8_plug = {
- .id= {CMODE_COL8_ID, 0, CMODE_PLUG_TYPE},
- .label = col8,
- .desc = 'Check on lattice-8' compression mode plugin.,
+reiser4_plug_t lattd_plug = {
+ .id= {CMODE_LATTD_ID, 0, CMODE_PLUG_TYPE},
+ .label = latt,
+ .desc = 'Check on dynamic lattice' compression mode plugin.,
};
-reiser4_plug_t col16_plug = {
- .id= {CMODE_COL16_ID, 0, CMODE_PLUG_TYPE},
- .label = col16,
- .desc = 'Check on lattice-16' compression mode plugin.,
+reiser4_plug_t ultim_plug = {
+ .id= {CMODE_ULTIM_ID, 0, CMODE_PLUG_TYPE},
+ .label = ultim,
+ .desc = 'Check ultimately' compression mode plugin.,
};
-reiser4_plug_t col32_plug = {
- .id= {CMODE_COL32_ID, 0, CMODE_PLUG_TYPE},
- .label = col32,
- .desc = 'Check on lattice-32' compression mode plugin.,
+reiser4_plug_t force_plug = {
+ .id= {CMODE_FORCE_ID, 0, CMODE_PLUG_TYPE},
+ .label = force,
+ .desc = 'Compress evrything' compression mode plugin.,
};
reiser4_plug_t convx_plug = {
@@ -42,11 +42,4 @@ reiser4_plug_t convx_plug = {
.label = conv,
.desc = 'Convert to extent' compression mode plugin.,
};
-
-reiser4_plug_t force_plug = {
- .id= {CMODE_FORCE_ID, 0, CMODE_PLUG_TYPE},
- .label = force,
- .desc = 'Compress evrything' compression mode plugin.,
-};
-
#endif
More new features than ever. Check out the new AOL Mail ! -
http://webmail.aol.com
--
To unsubscribe from this list: send the line unsubscribe
linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml
Re: [RFC] [PATCH -mm] reiser4: replace uid==0 check with capability
Serge E. Hallyn wrote: From c257cb67ce00c8769730cfa92379a53009d99b28 Mon Sep 17 00:00:00 2001 From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Wed, 5 Dec 2007 14:02:45 -0800 Subject: [RFC] [PATCH -mm] reiser4: replace uid==0 check with capability Reiser4 gives root some reserved blocks. Replace the uid==0 check, which is not safe in the face of user namespaces, with a CAP_SYS_RESOURCE check, which seems appropriate. Agreed. Thanks, Edward. The per-uid and per-guid reservations appear unimplemented so I'm ignoring them. Signed-off-by: Serge Hallyn <[EMAIL PROTECTED]> --- fs/reiser4/super.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/reiser4/super.c b/fs/reiser4/super.c index bc4113e..50e3d09 100644 --- a/fs/reiser4/super.c +++ b/fs/reiser4/super.c @@ -144,7 +144,7 @@ long reiser4_reserved_blocks(const struct super_block *super/* super block reserved += reserved_for_gid(super, gid); if (REISER4_SUPPORT_UID_SPACE_RESERVATION) reserved += reserved_for_uid(super, uid); - if (REISER4_SUPPORT_ROOT_SPACE_RESERVATION && (uid == 0)) + if (REISER4_SUPPORT_ROOT_SPACE_RESERVATION && capable(CAP_SYS_RESOURCE)) reserved += reserved_for_root(super); return reserved; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH -mm] reiser4: replace uid==0 check with capability
Serge E. Hallyn wrote: From c257cb67ce00c8769730cfa92379a53009d99b28 Mon Sep 17 00:00:00 2001 From: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Wed, 5 Dec 2007 14:02:45 -0800 Subject: [RFC] [PATCH -mm] reiser4: replace uid==0 check with capability Reiser4 gives root some reserved blocks. Replace the uid==0 check, which is not safe in the face of user namespaces, with a CAP_SYS_RESOURCE check, which seems appropriate. Agreed. Thanks, Edward. The per-uid and per-guid reservations appear unimplemented so I'm ignoring them. Signed-off-by: Serge Hallyn [EMAIL PROTECTED] --- fs/reiser4/super.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/reiser4/super.c b/fs/reiser4/super.c index bc4113e..50e3d09 100644 --- a/fs/reiser4/super.c +++ b/fs/reiser4/super.c @@ -144,7 +144,7 @@ long reiser4_reserved_blocks(const struct super_block *super/* super block reserved += reserved_for_gid(super, gid); if (REISER4_SUPPORT_UID_SPACE_RESERVATION) reserved += reserved_for_uid(super, uid); - if (REISER4_SUPPORT_ROOT_SPACE_RESERVATION (uid == 0)) + if (REISER4_SUPPORT_ROOT_SPACE_RESERVATION capable(CAP_SYS_RESOURCE)) reserved += reserved_for_root(super); return reserved; } -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/2] reiser4: new export ops
Christoph Hellwig wrote:
This code looks a little confusing to me..
*/
static char *decode_inode(struct super_block *s, char *addr,
reiser4_object_on_wire * obj)
@@ -41,7 +42,8 @@
fplug = file_plugin_by_disk_id(reiser4_get_tree(s), (d16 *) addr);
if (fplug != NULL) {
addr += sizeof(d16);
- obj->plugin = fplug;
+ if (obj)
+ obj->plugin = fplug;
You are adding quite a few of those if (obj) clauses. I can't see a
reason for that - care to explain? The new aops
new _export_ ops
should not disallow for
any functionality that has been there before.
Actually they don't disallow existing functionality, but
require a new one: earlier we performed decoding in
_each_ iteration (decode_fh), and now you want it to be
done separately (fh_to_dentry, fh_to_parent). So we need
something like "empty" iteration, which only moves to the
next position.
Every object in reiser4, that can be serialized, has
special non-zero "wire" methods. I guess that "empty"
iteration should be performed via wire->read() method
which is responsible for extracting on-wire object.
Can not promise to avoid "if" here: I think it is not
a good reason to add a new plugin method for such
empty skip.
The attached patch avoids other two ifs.
static struct dentry *reiser4_decode_fh(struct super_block *super, __u32 *fh,
+ int len, int fhtype, int parent)
{
reiser4_context *ctx;
reiser4_object_on_wire object;
char *addr;
ctx = reiser4_init_context(super);
if (IS_ERR(ctx))
@@ -80,25 +77,19 @@
assert("vs-1482",
fhtype == FH_WITH_PARENT || fhtype == FH_WITHOUT_PARENT);
addr = (char *)fh;
object_on_wire_init();
+
+ if (parent)
+ /* skip first onwire object */
+ addr = decode_inode(super, addr, NULL);
if (!IS_ERR(addr)) {
+ addr = decode_inode(super, addr, );
if (!IS_ERR(addr)) {
struct dentry *d;
+ d = reiser4_get_dentry(super, );
I'd suggest to directly poke into the place where the parent handle
is stored. XFS used a similar construct to the decode_inode helper,
but with the new aops it's faster and easier to read if you just have
a helper on how many bytes to skip. Did you take a look at how the
various other filesystem handle the export ops?
We don't have a number of u32s to poke, like other filesystems do;
packing/extracting serialized objects in reiser4 is more complex:
first extract object's plugin, which knows how to extract further, etc..
--- linux-2.6.23-mm1/fs/reiser4/dscale.c.orig
+++ linux-2.6.23-mm1/fs/reiser4/dscale.c
@@ -126,6 +126,24 @@
How are the changes to all these other files related to the export
operations changes?
So we have to define an "if" branch for wire_read_common()
(plugin/file_plugin_common.c). The best place to do it is kassign.c
(as we actually pack/extract key components). Plus a small change in
dscale.c where a packing taxonomy is implemented. Have I missed
something?
Thanks,
Edward.
Adjust reiser4 to new export ops.
Signed-off-by: Edward Shishkin <[EMAIL PROTECTED]>
---
linux-2.6.23-mm1/fs/reiser4/dscale.c| 20 ++
linux-2.6.23-mm1/fs/reiser4/dscale.h|3
linux-2.6.23-mm1/fs/reiser4/export_ops.c| 128 +---
linux-2.6.23-mm1/fs/reiser4/kassign.c | 20 ++
linux-2.6.23-mm1/fs/reiser4/kassign.h |1
linux-2.6.23-mm1/fs/reiser4/plugin/file_plugin_common.c |2
6 files changed, 117 insertions(+), 57 deletions(-)
--- linux-2.6.23-mm1/fs/reiser4/dscale.c.orig
+++ linux-2.6.23-mm1/fs/reiser4/dscale.c
@@ -126,6 +126,24 @@
return 1 << tag;
}
+/* number of bytes consumed */
+int dscale_bytes_to_read(unsigned char *address)
+{
+ int tag;
+
+ tag = gettag(address);
+ switch (tag) {
+ case 0:
+ case 1:
+ case 2:
+ return 1 << tag;
+ case 3:
+ return 9;
+ default:
+ return RETERR(-EIO);
+ }
+}
+
/* store @value at @address and return number of bytes consumed */
int dscale_write(unsigned char *address, __u64 value)
{
@@ -144,7 +162,7 @@
}
/* number of bytes required to store @value */
-int dscale_bytes(__u64 value)
+int dscale_bytes_to_write(__u64 value)
{
int bytes;
--- linux-2.6.23-mm1/fs/reiser4/dscale.h.orig
+++ linux-2.6.23-mm1/fs/reiser4/dscale.h
@@ -10,7 +10,8 @@
extern int dscale_read(unsigned char *address, __u64 * value);
extern int dscale_write(unsigned char *address, __u64 value);
-extern int dscale_bytes(__u64 value);
+extern int dscale_bytes_to_read(unsigned char *address);
+extern int dscale_bytes_to_write(__u64 value);
extern int dscale_fit(__u64 value, __u64 other);
/* __FS_REISER4_
Re: [patch 2/2] reiser4: new export ops
Christoph Hellwig wrote:
This code looks a little confusing to me..
*/
static char *decode_inode(struct super_block *s, char *addr,
reiser4_object_on_wire * obj)
@@ -41,7 +42,8 @@
fplug = file_plugin_by_disk_id(reiser4_get_tree(s), (d16 *) addr);
if (fplug != NULL) {
addr += sizeof(d16);
- obj-plugin = fplug;
+ if (obj)
+ obj-plugin = fplug;
You are adding quite a few of those if (obj) clauses. I can't see a
reason for that - care to explain? The new aops
new _export_ ops
should not disallow for
any functionality that has been there before.
Actually they don't disallow existing functionality, but
require a new one: earlier we performed decoding in
_each_ iteration (decode_fh), and now you want it to be
done separately (fh_to_dentry, fh_to_parent). So we need
something like empty iteration, which only moves to the
next position.
Every object in reiser4, that can be serialized, has
special non-zero wire methods. I guess that empty
iteration should be performed via wire-read() method
which is responsible for extracting on-wire object.
Can not promise to avoid if here: I think it is not
a good reason to add a new plugin method for such
empty skip.
The attached patch avoids other two ifs.
static struct dentry *reiser4_decode_fh(struct super_block *super, __u32 *fh,
+ int len, int fhtype, int parent)
{
reiser4_context *ctx;
reiser4_object_on_wire object;
char *addr;
ctx = reiser4_init_context(super);
if (IS_ERR(ctx))
@@ -80,25 +77,19 @@
assert(vs-1482,
fhtype == FH_WITH_PARENT || fhtype == FH_WITHOUT_PARENT);
addr = (char *)fh;
object_on_wire_init(object);
+
+ if (parent)
+ /* skip first onwire object */
+ addr = decode_inode(super, addr, NULL);
if (!IS_ERR(addr)) {
+ addr = decode_inode(super, addr, object);
if (!IS_ERR(addr)) {
struct dentry *d;
+ d = reiser4_get_dentry(super, object);
I'd suggest to directly poke into the place where the parent handle
is stored. XFS used a similar construct to the decode_inode helper,
but with the new aops it's faster and easier to read if you just have
a helper on how many bytes to skip. Did you take a look at how the
various other filesystem handle the export ops?
We don't have a number of u32s to poke, like other filesystems do;
packing/extracting serialized objects in reiser4 is more complex:
first extract object's plugin, which knows how to extract further, etc..
--- linux-2.6.23-mm1/fs/reiser4/dscale.c.orig
+++ linux-2.6.23-mm1/fs/reiser4/dscale.c
@@ -126,6 +126,24 @@
How are the changes to all these other files related to the export
operations changes?
So we have to define an if branch for wire_read_common()
(plugin/file_plugin_common.c). The best place to do it is kassign.c
(as we actually pack/extract key components). Plus a small change in
dscale.c where a packing taxonomy is implemented. Have I missed
something?
Thanks,
Edward.
Adjust reiser4 to new export ops.
Signed-off-by: Edward Shishkin [EMAIL PROTECTED]
---
linux-2.6.23-mm1/fs/reiser4/dscale.c| 20 ++
linux-2.6.23-mm1/fs/reiser4/dscale.h|3
linux-2.6.23-mm1/fs/reiser4/export_ops.c| 128 +---
linux-2.6.23-mm1/fs/reiser4/kassign.c | 20 ++
linux-2.6.23-mm1/fs/reiser4/kassign.h |1
linux-2.6.23-mm1/fs/reiser4/plugin/file_plugin_common.c |2
6 files changed, 117 insertions(+), 57 deletions(-)
--- linux-2.6.23-mm1/fs/reiser4/dscale.c.orig
+++ linux-2.6.23-mm1/fs/reiser4/dscale.c
@@ -126,6 +126,24 @@
return 1 tag;
}
+/* number of bytes consumed */
+int dscale_bytes_to_read(unsigned char *address)
+{
+ int tag;
+
+ tag = gettag(address);
+ switch (tag) {
+ case 0:
+ case 1:
+ case 2:
+ return 1 tag;
+ case 3:
+ return 9;
+ default:
+ return RETERR(-EIO);
+ }
+}
+
/* store @value at @address and return number of bytes consumed */
int dscale_write(unsigned char *address, __u64 value)
{
@@ -144,7 +162,7 @@
}
/* number of bytes required to store @value */
-int dscale_bytes(__u64 value)
+int dscale_bytes_to_write(__u64 value)
{
int bytes;
--- linux-2.6.23-mm1/fs/reiser4/dscale.h.orig
+++ linux-2.6.23-mm1/fs/reiser4/dscale.h
@@ -10,7 +10,8 @@
extern int dscale_read(unsigned char *address, __u64 * value);
extern int dscale_write(unsigned char *address, __u64 value);
-extern int dscale_bytes(__u64 value);
+extern int dscale_bytes_to_read(unsigned char *address);
+extern int dscale_bytes_to_write(__u64 value);
extern int dscale_fit(__u64 value, __u64 other);
/* __FS_REISER4_DSCALE_H__ */
--- linux-2.6.23-mm1/fs/reiser4/export_ops.c.orig
+++ linux-2.6.23-mm1/fs
[patch 2/2] reiser4: new export ops
[EMAIL PROTECTED] wrote:
The patch titled
git-nfsd-broke-reiser4
has been removed from the -mm tree. Its filename was
git-nfsd-broke-reiser4.patch
This patch was dropped because it was folded into reiser4.patch
--
Subject: git-nfsd-broke-reiser4
From: Andrew Morton <[EMAIL PROTECTED]>
fs/reiser4/export_ops.c: In function 'reiser4_decode_fh':
fs/reiser4/export_ops.c:96: error: 'const struct export_operations' has no
member named 'find_exported_dentry'
fs/reiser4/export_ops.c:96: warning: type defaults to 'int' in declaration of
'fn'
fs/reiser4/export_ops.c:98: error: 'const struct export_operations' has no
member named 'find_exported_dentry'
fs/reiser4/export_ops.c:99: warning: comparison between pointer and integer
fs/reiser4/export_ops.c:101: error: called object 'fn' is not a function
fs/reiser4/export_ops.c: At top level:
fs/reiser4/export_ops.c:282: error: unknown field 'decode_fh' specified in
initializer
fs/reiser4/export_ops.c:282: warning: initialization from incompatible pointer
type
fs/reiser4/export_ops.c:284: error: unknown field 'get_dentry' specified in
initializer
fs/reiser4/export_ops.c:285: warning: excess elements in struct initializer
fs/reiser4/export_ops.c:285: warning: (near initialization for
'reiser4_export_operations')
help!
done
Thanks,
Edward.
Adjust reiser4 for the new export ops.
Signed-off-by: Edward Shishkin <[EMAIL PROTECTED]>
---
linux-2.6.23-mm1/fs/reiser4/dscale.c| 20
linux-2.6.23-mm1/fs/reiser4/dscale.h|3
linux-2.6.23-mm1/fs/reiser4/export_ops.c| 72
linux-2.6.23-mm1/fs/reiser4/kassign.c | 19 +++-
linux-2.6.23-mm1/fs/reiser4/kassign.h |1
linux-2.6.23-mm1/fs/reiser4/plugin/file_plugin_common.c |2
6 files changed, 78 insertions(+), 39 deletions(-)
--- linux-2.6.23-mm1/fs/reiser4/export_ops.c.orig
+++ linux-2.6.23-mm1/fs/reiser4/export_ops.c
@@ -29,7 +29,8 @@
/*
* read serialized object identity from @addr and store information about
- * object in @obj. This is dual to encode_inode().
+ * object in @obj. If @obj == NULL, then don't read, just skip the encoded
+ * object (only return updated position).
*/
static char *decode_inode(struct super_block *s, char *addr,
reiser4_object_on_wire * obj)
@@ -41,7 +42,8 @@
fplug = file_plugin_by_disk_id(reiser4_get_tree(s), (d16 *) addr);
if (fplug != NULL) {
addr += sizeof(d16);
- obj->plugin = fplug;
+ if (obj)
+ obj->plugin = fplug;
assert("nikita-3520", fplug->wire.read != NULL);
/* plugin specific encoding of object identity. */
addr = fplug->wire.read(addr, obj);
@@ -50,28 +52,23 @@
return addr;
}
+static struct dentry *reiser4_get_dentry(struct super_block *super,
+ void *data);
/**
- * reiser4_decode_fh - decode_fh of export operations
- * @super: super block
- * @fh: nfsd file handle
- * @len: length of file handle
- * @fhtype: type of file handle
- * @acceptable: acceptability testing function
- * @context: argument for @acceptable
+ * reiser4_decode_fh: decode onwire object - helper function
+ * for fh_to_dentry, fh_to_parent export operations;
+ * @super: super block;
+ * @fh: here are onwire objects to be extracted for decoding;
+ * @parent: skip first onwire object and decode parent.
*
- * Returns dentry referring to the same file as @fh.
+ * Returns dentry referring to the object being decoded.
*/
static struct dentry *reiser4_decode_fh(struct super_block *super, __u32 *fh,
- int len, int fhtype,
- int (*acceptable) (void *context,
- struct dentry *de),
- void *context)
+ int len, int fhtype, int parent)
{
reiser4_context *ctx;
reiser4_object_on_wire object;
- reiser4_object_on_wire parent;
char *addr;
- int with_parent;
ctx = reiser4_init_context(super);
if (IS_ERR(ctx))
@@ -80,25 +77,19 @@
assert("vs-1482",
fhtype == FH_WITH_PARENT || fhtype == FH_WITHOUT_PARENT);
- with_parent = (fhtype == FH_WITH_PARENT);
-
addr = (char *)fh;
object_on_wire_init();
- object_on_wire_init();
-#if 0
- addr = decode_inode(super, addr, );
+
+ if (parent)
+ /* skip first onwire object */
+ addr = decode_inode(super, addr, NULL);
if (!IS_ERR(addr)) {
- if (with_parent)
- addr = decode_inode(super, addr, );
+ addr = decode_inode(super, addr, );
if (!IS_ERR(addr)) {
struct dentry *d;
- typeof(super->s_export_op->find_exported_dentry) fn;
- fn = super->s_export_op->find_exported_dentry;
- assert("nikita-3521", fn != NULL);
- d = fn(super, , with_parent ? : NULL,
- acceptable, context);
+ d = reiser4_get_dentry(super, );
if (d != NULL && !IS_ERR(d))
/* FIXME check for -ENOMEM */
reiser4_get_dentry_fsdata(d)->stateless = 1;
@@ -106,13 +97,24 @@
}
}
object_on_wire_done();
- object_on_wire_
[patch 2/2] reiser4: new export ops
[EMAIL PROTECTED] wrote:
The patch titled
git-nfsd-broke-reiser4
has been removed from the -mm tree. Its filename was
git-nfsd-broke-reiser4.patch
This patch was dropped because it was folded into reiser4.patch
--
Subject: git-nfsd-broke-reiser4
From: Andrew Morton [EMAIL PROTECTED]
fs/reiser4/export_ops.c: In function 'reiser4_decode_fh':
fs/reiser4/export_ops.c:96: error: 'const struct export_operations' has no
member named 'find_exported_dentry'
fs/reiser4/export_ops.c:96: warning: type defaults to 'int' in declaration of
'fn'
fs/reiser4/export_ops.c:98: error: 'const struct export_operations' has no
member named 'find_exported_dentry'
fs/reiser4/export_ops.c:99: warning: comparison between pointer and integer
fs/reiser4/export_ops.c:101: error: called object 'fn' is not a function
fs/reiser4/export_ops.c: At top level:
fs/reiser4/export_ops.c:282: error: unknown field 'decode_fh' specified in
initializer
fs/reiser4/export_ops.c:282: warning: initialization from incompatible pointer
type
fs/reiser4/export_ops.c:284: error: unknown field 'get_dentry' specified in
initializer
fs/reiser4/export_ops.c:285: warning: excess elements in struct initializer
fs/reiser4/export_ops.c:285: warning: (near initialization for
'reiser4_export_operations')
help!
done
Thanks,
Edward.
Adjust reiser4 for the new export ops.
Signed-off-by: Edward Shishkin [EMAIL PROTECTED]
---
linux-2.6.23-mm1/fs/reiser4/dscale.c| 20
linux-2.6.23-mm1/fs/reiser4/dscale.h|3
linux-2.6.23-mm1/fs/reiser4/export_ops.c| 72
linux-2.6.23-mm1/fs/reiser4/kassign.c | 19 +++-
linux-2.6.23-mm1/fs/reiser4/kassign.h |1
linux-2.6.23-mm1/fs/reiser4/plugin/file_plugin_common.c |2
6 files changed, 78 insertions(+), 39 deletions(-)
--- linux-2.6.23-mm1/fs/reiser4/export_ops.c.orig
+++ linux-2.6.23-mm1/fs/reiser4/export_ops.c
@@ -29,7 +29,8 @@
/*
* read serialized object identity from @addr and store information about
- * object in @obj. This is dual to encode_inode().
+ * object in @obj. If @obj == NULL, then don't read, just skip the encoded
+ * object (only return updated position).
*/
static char *decode_inode(struct super_block *s, char *addr,
reiser4_object_on_wire * obj)
@@ -41,7 +42,8 @@
fplug = file_plugin_by_disk_id(reiser4_get_tree(s), (d16 *) addr);
if (fplug != NULL) {
addr += sizeof(d16);
- obj-plugin = fplug;
+ if (obj)
+ obj-plugin = fplug;
assert(nikita-3520, fplug-wire.read != NULL);
/* plugin specific encoding of object identity. */
addr = fplug-wire.read(addr, obj);
@@ -50,28 +52,23 @@
return addr;
}
+static struct dentry *reiser4_get_dentry(struct super_block *super,
+ void *data);
/**
- * reiser4_decode_fh - decode_fh of export operations
- * @super: super block
- * @fh: nfsd file handle
- * @len: length of file handle
- * @fhtype: type of file handle
- * @acceptable: acceptability testing function
- * @context: argument for @acceptable
+ * reiser4_decode_fh: decode onwire object - helper function
+ * for fh_to_dentry, fh_to_parent export operations;
+ * @super: super block;
+ * @fh: here are onwire objects to be extracted for decoding;
+ * @parent: skip first onwire object and decode parent.
*
- * Returns dentry referring to the same file as @fh.
+ * Returns dentry referring to the object being decoded.
*/
static struct dentry *reiser4_decode_fh(struct super_block *super, __u32 *fh,
- int len, int fhtype,
- int (*acceptable) (void *context,
- struct dentry *de),
- void *context)
+ int len, int fhtype, int parent)
{
reiser4_context *ctx;
reiser4_object_on_wire object;
- reiser4_object_on_wire parent;
char *addr;
- int with_parent;
ctx = reiser4_init_context(super);
if (IS_ERR(ctx))
@@ -80,25 +77,19 @@
assert(vs-1482,
fhtype == FH_WITH_PARENT || fhtype == FH_WITHOUT_PARENT);
- with_parent = (fhtype == FH_WITH_PARENT);
-
addr = (char *)fh;
object_on_wire_init(object);
- object_on_wire_init(parent);
-#if 0
- addr = decode_inode(super, addr, object);
+
+ if (parent)
+ /* skip first onwire object */
+ addr = decode_inode(super, addr, NULL);
if (!IS_ERR(addr)) {
- if (with_parent)
- addr = decode_inode(super, addr, parent);
+ addr = decode_inode(super, addr, object);
if (!IS_ERR(addr)) {
struct dentry *d;
- typeof(super-s_export_op-find_exported_dentry) fn;
- fn = super-s_export_op-find_exported_dentry;
- assert(nikita-3521, fn != NULL);
- d = fn(super, object, with_parent ? parent : NULL,
- acceptable, context);
+ d = reiser4_get_dentry(super, object);
if (d != NULL !IS_ERR(d))
/* FIXME check for -ENOMEM */
reiser4_get_dentry_fsdata(d)-stateless = 1;
@@ -106,13 +97,24 @@
}
}
object_on_wire_done(object);
- object_on_wire_done(parent);
-
reiser4_exit_context(ctx
Re: [PATCH] Reiser4: Drop 'size' argument from bio_endio and bi_end_io
Laurent Riffard wrote:
Reiser4: Drop 'size' argument from bio_endio and bi_end_io
This patch pushes into Reiser4 the changes introduced by
commit 6712ecf8f648118c3363c142196418f89a510b90:
As bi_end_io is only called once when the request is complete,
the 'size' argument is now redundant. Remove it.
Now there is no need for bio_endio to subtract the size completed
from bi_size. So don't do that either.
While we are at it, change bi_end_io to return void.
Please review.
Thanks!
Signed-Off-By: Edward Shishkin <[EMAIL PROTECTED]>
Signed-Off-By: Laurent Riffard <[EMAIL PROTECTED]>
---
fs/reiser4/flush_queue.c | 10 ++
fs/reiser4/page_cache.c | 24
fs/reiser4/status_flags.c |7 +--
3 files changed, 7 insertions(+), 34 deletions(-)
Index: linux-2.6-mm/fs/reiser4/flush_queue.c
===
--- linux-2.6-mm.orig/fs/reiser4/flush_queue.c
+++ linux-2.6-mm/fs/reiser4/flush_queue.c
@@ -391,9 +391,8 @@ int atom_fq_parts_are_clean(txn_atom * a
}
#endif
/* Bio i/o completion routine for reiser4 write operations. */
-static int
-end_io_handler(struct bio *bio, unsigned int bytes_done UNUSED_ARG,
- int err)
+static void
+end_io_handler(struct bio *bio, int err)
{
int i;
int nr_errors = 0;
@@ -401,10 +400,6 @@ end_io_handler(struct bio *bio, unsigned
assert("zam-958", bio->bi_rw & WRITE);
- /* i/o op. is not fully completed */
- if (bio->bi_size != 0)
- return 1;
-
if (err == -EOPNOTSUPP)
set_bit(BIO_EOPNOTSUPP, >bi_flags);
@@ -447,7 +442,6 @@ end_io_handler(struct bio *bio, unsigned
}
bio_put(bio);
- return 0;
}
/* Count I/O requests which will be submitted by @bio in given flush queues
Index: linux-2.6-mm/fs/reiser4/page_cache.c
===
--- linux-2.6-mm.orig/fs/reiser4/page_cache.c
+++ linux-2.6-mm/fs/reiser4/page_cache.c
@@ -320,18 +320,11 @@ reiser4_tree *reiser4_tree_by_page(const
mpage_end_io_read() would also do. But it's static.
*/
-static int
-end_bio_single_page_read(struct bio *bio, unsigned int bytes_done UNUSED_ARG,
-int err UNUSED_ARG)
+static void
+end_bio_single_page_read(struct bio *bio, int err UNUSED_ARG)
{
struct page *page;
- if (bio->bi_size != 0) {
- warning("nikita-3332", "Truncated single page read: %i",
- bio->bi_size);
- return 1;
- }
-
page = bio->bi_io_vec[0].bv_page;
if (test_bit(BIO_UPTODATE, >bi_flags)) {
@@ -342,7 +335,6 @@ end_bio_single_page_read(struct bio *bio
}
unlock_page(page);
bio_put(bio);
- return 0;
}
/* completion handler for single page bio-based write.
@@ -350,25 +342,17 @@ end_bio_single_page_read(struct bio *bio
mpage_end_io_write() would also do. But it's static.
*/
-static int
-end_bio_single_page_write(struct bio *bio, unsigned int bytes_done UNUSED_ARG,
- int err UNUSED_ARG)
+static void
+end_bio_single_page_write(struct bio *bio, int err UNUSED_ARG)
{
struct page *page;
- if (bio->bi_size != 0) {
- warning("nikita-", "Truncated single page write: %i",
- bio->bi_size);
- return 1;
- }
-
page = bio->bi_io_vec[0].bv_page;
if (!test_bit(BIO_UPTODATE, >bi_flags))
SetPageError(page);
end_page_writeback(page);
bio_put(bio);
- return 0;
}
/* ->readpage() method for formatted nodes */
Index: linux-2.6-mm/fs/reiser4/status_flags.c
===
--- linux-2.6-mm.orig/fs/reiser4/status_flags.c
+++ linux-2.6-mm/fs/reiser4/status_flags.c
@@ -15,12 +15,8 @@
/* This is our end I/O handler that marks page uptodate if IO was successful.
It also
unconditionally unlocks the page, so we can see that io was done.
We do not free bio, because we hope to reuse that. */
-static int reiser4_status_endio(struct bio *bio, unsigned int bytes_done,
- int err)
+static void reiser4_status_endio(struct bio *bio, int err)
{
- if (bio->bi_size)
- return 1;
-
if (test_bit(BIO_UPTODATE, >bi_flags)) {
SetPageUptodate(bio->bi_io_vec->bv_page);
} else {
@@ -28,7 +24,6 @@ static int reiser4_status_endio(struct b
SetPageError(bio->bi_io_vec->bv_page);
}
unlock_page(bio->bi_io_vec->bv_page);
- return 0;
}
/* Initialise status code. This is expected to be called from the disk format
-
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of
Re: [PATCH] Reiser4: Drop 'size' argument from bio_endio and bi_end_io
Laurent Riffard wrote:
Reiser4: Drop 'size' argument from bio_endio and bi_end_io
This patch pushes into Reiser4 the changes introduced by
commit 6712ecf8f648118c3363c142196418f89a510b90:
As bi_end_io is only called once when the request is complete,
the 'size' argument is now redundant. Remove it.
Now there is no need for bio_endio to subtract the size completed
from bi_size. So don't do that either.
While we are at it, change bi_end_io to return void.
Please review.
Thanks!
Signed-Off-By: Edward Shishkin [EMAIL PROTECTED]
Signed-Off-By: Laurent Riffard [EMAIL PROTECTED]
---
fs/reiser4/flush_queue.c | 10 ++
fs/reiser4/page_cache.c | 24
fs/reiser4/status_flags.c |7 +--
3 files changed, 7 insertions(+), 34 deletions(-)
Index: linux-2.6-mm/fs/reiser4/flush_queue.c
===
--- linux-2.6-mm.orig/fs/reiser4/flush_queue.c
+++ linux-2.6-mm/fs/reiser4/flush_queue.c
@@ -391,9 +391,8 @@ int atom_fq_parts_are_clean(txn_atom * a
}
#endif
/* Bio i/o completion routine for reiser4 write operations. */
-static int
-end_io_handler(struct bio *bio, unsigned int bytes_done UNUSED_ARG,
- int err)
+static void
+end_io_handler(struct bio *bio, int err)
{
int i;
int nr_errors = 0;
@@ -401,10 +400,6 @@ end_io_handler(struct bio *bio, unsigned
assert(zam-958, bio-bi_rw WRITE);
- /* i/o op. is not fully completed */
- if (bio-bi_size != 0)
- return 1;
-
if (err == -EOPNOTSUPP)
set_bit(BIO_EOPNOTSUPP, bio-bi_flags);
@@ -447,7 +442,6 @@ end_io_handler(struct bio *bio, unsigned
}
bio_put(bio);
- return 0;
}
/* Count I/O requests which will be submitted by @bio in given flush queues
Index: linux-2.6-mm/fs/reiser4/page_cache.c
===
--- linux-2.6-mm.orig/fs/reiser4/page_cache.c
+++ linux-2.6-mm/fs/reiser4/page_cache.c
@@ -320,18 +320,11 @@ reiser4_tree *reiser4_tree_by_page(const
mpage_end_io_read() would also do. But it's static.
*/
-static int
-end_bio_single_page_read(struct bio *bio, unsigned int bytes_done UNUSED_ARG,
-int err UNUSED_ARG)
+static void
+end_bio_single_page_read(struct bio *bio, int err UNUSED_ARG)
{
struct page *page;
- if (bio-bi_size != 0) {
- warning(nikita-3332, Truncated single page read: %i,
- bio-bi_size);
- return 1;
- }
-
page = bio-bi_io_vec[0].bv_page;
if (test_bit(BIO_UPTODATE, bio-bi_flags)) {
@@ -342,7 +335,6 @@ end_bio_single_page_read(struct bio *bio
}
unlock_page(page);
bio_put(bio);
- return 0;
}
/* completion handler for single page bio-based write.
@@ -350,25 +342,17 @@ end_bio_single_page_read(struct bio *bio
mpage_end_io_write() would also do. But it's static.
*/
-static int
-end_bio_single_page_write(struct bio *bio, unsigned int bytes_done UNUSED_ARG,
- int err UNUSED_ARG)
+static void
+end_bio_single_page_write(struct bio *bio, int err UNUSED_ARG)
{
struct page *page;
- if (bio-bi_size != 0) {
- warning(nikita-, Truncated single page write: %i,
- bio-bi_size);
- return 1;
- }
-
page = bio-bi_io_vec[0].bv_page;
if (!test_bit(BIO_UPTODATE, bio-bi_flags))
SetPageError(page);
end_page_writeback(page);
bio_put(bio);
- return 0;
}
/* -readpage() method for formatted nodes */
Index: linux-2.6-mm/fs/reiser4/status_flags.c
===
--- linux-2.6-mm.orig/fs/reiser4/status_flags.c
+++ linux-2.6-mm/fs/reiser4/status_flags.c
@@ -15,12 +15,8 @@
/* This is our end I/O handler that marks page uptodate if IO was successful.
It also
unconditionally unlocks the page, so we can see that io was done.
We do not free bio, because we hope to reuse that. */
-static int reiser4_status_endio(struct bio *bio, unsigned int bytes_done,
- int err)
+static void reiser4_status_endio(struct bio *bio, int err)
{
- if (bio-bi_size)
- return 1;
-
if (test_bit(BIO_UPTODATE, bio-bi_flags)) {
SetPageUptodate(bio-bi_io_vec-bv_page);
} else {
@@ -28,7 +24,6 @@ static int reiser4_status_endio(struct b
SetPageError(bio-bi_io_vec-bv_page);
}
unlock_page(bio-bi_io_vec-bv_page);
- return 0;
}
/* Initialise status code. This is expected to be called from the disk format
-
To unsubscribe from this list: send the line unsubscribe reiserfs-devel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line
[patch] reiser4: do not allocate struct file on stack
Edward Shishkin wrote:
Dave Hansen wrote:
...
I think that stack allocation is a pretty nasty trick for a structure
that's supposed to be pretty persistent and dynamically allocated, and
is certainly something that needs to get fixed up in a proper way.
agreed.
This works around the problem for now, but this could potentially cause
more bugs any time we add some member to 'struct file' and depend on its
state being sane anywhere in the VFS. If there's a list anywhere of
merge-stopper reiser4 bugs around, this should probably go in there.
will be fixed.
The promised fixup is attached.
Andrew, please apply.
Thanks,
Edward.
Do not allocate struct file on stack, pass the persistent one instead.
Signed-off-by: Edward Shishkin <[EMAIL PROTECTED]>
---
linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/file.c| 35 --
linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/file.h|2
linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/tail_conversion.c | 23 ++
3 files changed, 26 insertions(+), 34 deletions(-)
--- linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/file.c.orig
+++ linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/file.c
@@ -566,23 +566,18 @@
* items or add them to represent a hole at the end of file. The caller has to
* obtain exclusive access to the file.
*/
-static int truncate_file_body(struct inode *inode, loff_t new_size)
+static int truncate_file_body(struct inode *inode, struct iattr *attr)
{
int result;
+ loff_t new_size = attr->ia_size;
if (inode->i_size < new_size) {
/* expanding truncate */
- struct dentry dentry;
- struct file file;
- struct unix_file_info *uf_info;
+ struct file * file = attr->ia_file;
+ struct unix_file_info *uf_info = unix_file_inode_data(inode);
+
+ assert("edward-1532", attr->ia_valid & ATTR_FILE);
- dentry.d_inode = inode;
- file.f_dentry =
- file.private_data = NULL;
- file.f_pos = new_size;
- file.private_data = NULL;
- file.f_vfsmnt = NULL;
- uf_info = unix_file_inode_data(inode);
result = find_file_state(inode, uf_info);
if (result)
return result;
@@ -615,19 +610,19 @@
return result;
}
}
- result = reiser4_write_extent(, NULL, 0,
+ result = reiser4_write_extent(file, NULL, 0,
_size);
if (result)
return result;
uf_info->container = UF_CONTAINER_EXTENTS;
} else {
if (uf_info->container == UF_CONTAINER_EXTENTS) {
-result = reiser4_write_extent(, NULL, 0,
+result = reiser4_write_extent(file, NULL, 0,
_size);
if (result)
return result;
} else {
-result = reiser4_write_tail(, NULL, 0,
+result = reiser4_write_tail(file, NULL, 0,
_size);
if (result)
return result;
@@ -636,10 +631,10 @@
}
BUG_ON(result > 0);
INODE_SET_FIELD(inode, i_size, new_size);
- file_update_time();
+ file_update_time(file);
result = reiser4_update_sd(inode);
BUG_ON(result != 0);
- reiser4_free_file_fsdata();
+ reiser4_free_file_fsdata(file);
} else
result = shorten_file(inode, new_size);
return result;
@@ -2092,7 +2087,7 @@
* first item is formatting item, therefore there was
* incomplete extent2tail conversion. Complete it
*/
- result = extent2tail(unix_file_inode_data(inode));
+ result = extent2tail(file, unix_file_inode_data(inode));
else
result = -EIO;
@@ -2372,7 +2367,7 @@
uf_info->container == UF_CONTAINER_EXTENTS &&
!should_have_notail(uf_info, inode->i_size) &&
!rofs_inode(inode)) {
- result = extent2tail(uf_info);
+ result = extent2tail(file, uf_info);
if (result != 0) {
warning("nikita-3233",
"Failed (%d) to convert in %s (%llu)",
@@ -2638,7 +2633,7 @@
if (result == 0)
result = safe_link_add(inode, SAFE_TRUNCATE);
if (result == 0)
- result = truncate_file_body(inode, attr->ia_size);
+ result = truncate_file_body(inode, attr);
if (result)
warning("vs-1588", "truncate_file failed: oid %lli, "
"old size %lld, new size %lld, retval %d",
@@ -2724,7 +2719,7 @@
/* truncate file bogy first */
uf_info = unix_file_inode_data(inode);
get_exclusive_access(uf_info);
- result = truncate_file_body(inode, 0 /* size */ );
+ result = shorten_file(inode, 0 /* size */ );
drop_exclusive_access(uf_info);
if (result)
--- linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/file.h.orig
+++ linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/file.h
@@ -237,7 +237,7 @@
#define WRITE_GRANULARITY 32
int tail2extent(struct unix_file_info *);
-int extent2tail(struct unix_file_info *);
+int extent2tail(struct file *, struct unix_file_info *);
int goto_right_neighbor(coord_t *, lock_handle *);
int find_or_create_extent(struct page *);
--- linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/tail_conversion.c.orig
+++ linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/tail_conversion.c
@@ -546,7 +546,7 @@
/* for
[patch] reiserfs: do not repair wrong journal params
Jan Engelhardt wrote:
On Aug 23 2007 15:59, Martin Vogt wrote:
...
Even if knoppix should not be used as a rescue/live CD, then
the reiserfs module should not try to correct something,
this should be done by another tool.(fsck.reiserfs or a module option...)
The attached patch fixes this badness.
Thanks,
Edward.
When mounting a file system with wrong journal params
do not try to repair them, suggest fsck instead.
Signed-off-by: Edward Shishkin <[EMAIL PROTECTED]>
---
linux-2.6.23-rc8-mm2/fs/reiserfs/journal.c | 100 -
1 files changed, 57 insertions(+), 43 deletions(-)
--- linux-2.6.23-rc8-mm2/fs/reiserfs/journal.c.orig
+++ linux-2.6.23-rc8-mm2/fs/reiserfs/journal.c
@@ -2649,6 +2649,61 @@
return result;
}
+/**
+ * When creating/tuning a file system user can assign some
+ * journal params within boundaries which depend on the ratio
+ * blocksize/standard_blocksize.
+ *
+ * For blocks >= standard_blocksize transaction size should
+ * be not less then JOURNAL_TRANS_MIN_DEFAULT, and not more
+ * then JOURNAL_TRANS_MAX_DEFAULT.
+ *
+ * For blocks < standard_blocksize these boundaries should be
+ * decreased proportionally.
+ */
+#define REISERFS_STANDARD_BLKSIZE (4096)
+
+static int check_advise_trans_params(struct super_block *p_s_sb,
+ struct reiserfs_journal *journal)
+{
+if (journal->j_trans_max) {
+ /* Non-default journal params.
+ Do sanity check for them. */
+ int ratio = 1;
+ if (p_s_sb->s_blocksize < REISERFS_STANDARD_BLKSIZE)
+ ratio = REISERFS_STANDARD_BLKSIZE / p_s_sb->s_blocksize;
+
+ if (journal->j_trans_max > JOURNAL_TRANS_MAX_DEFAULT / ratio ||
+ journal->j_trans_max < JOURNAL_TRANS_MIN_DEFAULT / ratio ||
+ SB_ONDISK_JOURNAL_SIZE(p_s_sb) / journal->j_trans_max <
+ JOURNAL_MIN_RATIO) {
+ reiserfs_warning(p_s_sb,
+ "sh-462: bad transaction max size (%u). FSCK?",
+ journal->j_trans_max);
+ return 1;
+ }
+ if (journal->j_max_batch != (journal->j_trans_max) *
+ JOURNAL_MAX_BATCH_DEFAULT/JOURNAL_TRANS_MAX_DEFAULT) {
+ reiserfs_warning(p_s_sb,
+"sh-463: bad transaction max batch (%u). FSCK?",
+journal->j_max_batch);
+ return 1;
+ }
+ } else {
+ /* Default journal params.
+ The file system was created by old version
+ of mkreiserfs, so some fields contain zeros,
+ and we need to advise proper values for them */
+ if (p_s_sb->s_blocksize != REISERFS_STANDARD_BLKSIZE)
+ reiserfs_panic(p_s_sb, "sh-464: bad blocksize (%u)",
+ p_s_sb->s_blocksize);
+ journal->j_trans_max = JOURNAL_TRANS_MAX_DEFAULT;
+ journal->j_max_batch = JOURNAL_MAX_BATCH_DEFAULT;
+ journal->j_max_commit_age = JOURNAL_MAX_COMMIT_AGE;
+ }
+ return 0;
+}
+
/*
** must be called once on fs mount. calls journal_read for you
*/
@@ -2744,49 +2799,8 @@
le32_to_cpu(jh->jh_journal.jp_journal_max_commit_age);
journal->j_max_trans_age = JOURNAL_MAX_TRANS_AGE;
- if (journal->j_trans_max) {
- /* make sure these parameters are available, assign it if they are not */
- __u32 initial = journal->j_trans_max;
- __u32 ratio = 1;
-
- if (p_s_sb->s_blocksize < 4096)
- ratio = 4096 / p_s_sb->s_blocksize;
-
- if (SB_ONDISK_JOURNAL_SIZE(p_s_sb) / journal->j_trans_max <
- JOURNAL_MIN_RATIO)
- journal->j_trans_max =
- SB_ONDISK_JOURNAL_SIZE(p_s_sb) / JOURNAL_MIN_RATIO;
- if (journal->j_trans_max > JOURNAL_TRANS_MAX_DEFAULT / ratio)
- journal->j_trans_max =
- JOURNAL_TRANS_MAX_DEFAULT / ratio;
- if (journal->j_trans_max < JOURNAL_TRANS_MIN_DEFAULT / ratio)
- journal->j_trans_max =
- JOURNAL_TRANS_MIN_DEFAULT / ratio;
-
- if (journal->j_trans_max != initial)
- reiserfs_warning(p_s_sb,
- "sh-461: journal_init: wrong transaction max size (%u). Changed to %u",
- initial, journal->j_trans_max);
-
- journal->j_max_batch = journal->j_trans_max *
- JOURNAL_MAX_BATCH_DEFAULT / JOURNAL_TRANS_MAX_DEFAULT;
- }
-
- if (!journal->j_trans_max) {
- /*we have the file system was created by old version of mkreiserfs
- so this field contains zero value */
- journal->j_trans_max = JOURNAL_TRANS_MAX_DEFAULT;
- journal->j_max_batch = JOURNAL_MAX_BATCH_DEFAULT;
- journal->j_max_commit_age = JOURNAL_MAX_COMMIT_AGE;
-
- /* for blocksize >= 4096 - max transaction size is 1024. For block size < 4096
- trans max size is decreased proportionally */
- if (p_s_sb->s_blocksize < 4096) {
- journal->j_trans_max /= (4096 / p_s_sb->s_blocksize);
- journal->j_max_batch = (journal->j_trans_max) * 9 / 10;
- }
- }
-
+ if (check_advise_trans_params(p_s_sb, journal) != 0)
+ goto free_and_return;
journal->j_default_max_commit_age = journal->j_max_commit_age;
if (commit_max_age != 0) {
[patch] reiser4: do not allocate struct file on stack
Edward Shishkin wrote:
Dave Hansen wrote:
...
I think that stack allocation is a pretty nasty trick for a structure
that's supposed to be pretty persistent and dynamically allocated, and
is certainly something that needs to get fixed up in a proper way.
agreed.
This works around the problem for now, but this could potentially cause
more bugs any time we add some member to 'struct file' and depend on its
state being sane anywhere in the VFS. If there's a list anywhere of
merge-stopper reiser4 bugs around, this should probably go in there.
will be fixed.
The promised fixup is attached.
Andrew, please apply.
Thanks,
Edward.
Do not allocate struct file on stack, pass the persistent one instead.
Signed-off-by: Edward Shishkin [EMAIL PROTECTED]
---
linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/file.c| 35 --
linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/file.h|2
linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/tail_conversion.c | 23 ++
3 files changed, 26 insertions(+), 34 deletions(-)
--- linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/file.c.orig
+++ linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/file.c
@@ -566,23 +566,18 @@
* items or add them to represent a hole at the end of file. The caller has to
* obtain exclusive access to the file.
*/
-static int truncate_file_body(struct inode *inode, loff_t new_size)
+static int truncate_file_body(struct inode *inode, struct iattr *attr)
{
int result;
+ loff_t new_size = attr-ia_size;
if (inode-i_size new_size) {
/* expanding truncate */
- struct dentry dentry;
- struct file file;
- struct unix_file_info *uf_info;
+ struct file * file = attr-ia_file;
+ struct unix_file_info *uf_info = unix_file_inode_data(inode);
+
+ assert(edward-1532, attr-ia_valid ATTR_FILE);
- dentry.d_inode = inode;
- file.f_dentry = dentry;
- file.private_data = NULL;
- file.f_pos = new_size;
- file.private_data = NULL;
- file.f_vfsmnt = NULL;
- uf_info = unix_file_inode_data(inode);
result = find_file_state(inode, uf_info);
if (result)
return result;
@@ -615,19 +610,19 @@
return result;
}
}
- result = reiser4_write_extent(file, NULL, 0,
+ result = reiser4_write_extent(file, NULL, 0,
new_size);
if (result)
return result;
uf_info-container = UF_CONTAINER_EXTENTS;
} else {
if (uf_info-container == UF_CONTAINER_EXTENTS) {
-result = reiser4_write_extent(file, NULL, 0,
+result = reiser4_write_extent(file, NULL, 0,
new_size);
if (result)
return result;
} else {
-result = reiser4_write_tail(file, NULL, 0,
+result = reiser4_write_tail(file, NULL, 0,
new_size);
if (result)
return result;
@@ -636,10 +631,10 @@
}
BUG_ON(result 0);
INODE_SET_FIELD(inode, i_size, new_size);
- file_update_time(file);
+ file_update_time(file);
result = reiser4_update_sd(inode);
BUG_ON(result != 0);
- reiser4_free_file_fsdata(file);
+ reiser4_free_file_fsdata(file);
} else
result = shorten_file(inode, new_size);
return result;
@@ -2092,7 +2087,7 @@
* first item is formatting item, therefore there was
* incomplete extent2tail conversion. Complete it
*/
- result = extent2tail(unix_file_inode_data(inode));
+ result = extent2tail(file, unix_file_inode_data(inode));
else
result = -EIO;
@@ -2372,7 +2367,7 @@
uf_info-container == UF_CONTAINER_EXTENTS
!should_have_notail(uf_info, inode-i_size)
!rofs_inode(inode)) {
- result = extent2tail(uf_info);
+ result = extent2tail(file, uf_info);
if (result != 0) {
warning(nikita-3233,
Failed (%d) to convert in %s (%llu),
@@ -2638,7 +2633,7 @@
if (result == 0)
result = safe_link_add(inode, SAFE_TRUNCATE);
if (result == 0)
- result = truncate_file_body(inode, attr-ia_size);
+ result = truncate_file_body(inode, attr);
if (result)
warning(vs-1588, truncate_file failed: oid %lli,
old size %lld, new size %lld, retval %d,
@@ -2724,7 +2719,7 @@
/* truncate file bogy first */
uf_info = unix_file_inode_data(inode);
get_exclusive_access(uf_info);
- result = truncate_file_body(inode, 0 /* size */ );
+ result = shorten_file(inode, 0 /* size */ );
drop_exclusive_access(uf_info);
if (result)
--- linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/file.h.orig
+++ linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/file.h
@@ -237,7 +237,7 @@
#define WRITE_GRANULARITY 32
int tail2extent(struct unix_file_info *);
-int extent2tail(struct unix_file_info *);
+int extent2tail(struct file *, struct unix_file_info *);
int goto_right_neighbor(coord_t *, lock_handle *);
int find_or_create_extent(struct page *);
--- linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/tail_conversion.c.orig
+++ linux-2.6.23-rc8-mm2/fs/reiser4/plugin/file/tail_conversion.c
@@ -546,7 +546,7 @@
/* for every page of file: read page, cut part of extent pointing to this page,
put data of page tree by tail item */
-int
[patch] reiserfs: do not repair wrong journal params
Jan Engelhardt wrote:
On Aug 23 2007 15:59, Martin Vogt wrote:
...
Even if knoppix should not be used as a rescue/live CD, then
the reiserfs module should not try to correct something,
this should be done by another tool.(fsck.reiserfs or a module option...)
The attached patch fixes this badness.
Thanks,
Edward.
When mounting a file system with wrong journal params
do not try to repair them, suggest fsck instead.
Signed-off-by: Edward Shishkin [EMAIL PROTECTED]
---
linux-2.6.23-rc8-mm2/fs/reiserfs/journal.c | 100 -
1 files changed, 57 insertions(+), 43 deletions(-)
--- linux-2.6.23-rc8-mm2/fs/reiserfs/journal.c.orig
+++ linux-2.6.23-rc8-mm2/fs/reiserfs/journal.c
@@ -2649,6 +2649,61 @@
return result;
}
+/**
+ * When creating/tuning a file system user can assign some
+ * journal params within boundaries which depend on the ratio
+ * blocksize/standard_blocksize.
+ *
+ * For blocks = standard_blocksize transaction size should
+ * be not less then JOURNAL_TRANS_MIN_DEFAULT, and not more
+ * then JOURNAL_TRANS_MAX_DEFAULT.
+ *
+ * For blocks standard_blocksize these boundaries should be
+ * decreased proportionally.
+ */
+#define REISERFS_STANDARD_BLKSIZE (4096)
+
+static int check_advise_trans_params(struct super_block *p_s_sb,
+ struct reiserfs_journal *journal)
+{
+if (journal-j_trans_max) {
+ /* Non-default journal params.
+ Do sanity check for them. */
+ int ratio = 1;
+ if (p_s_sb-s_blocksize REISERFS_STANDARD_BLKSIZE)
+ ratio = REISERFS_STANDARD_BLKSIZE / p_s_sb-s_blocksize;
+
+ if (journal-j_trans_max JOURNAL_TRANS_MAX_DEFAULT / ratio ||
+ journal-j_trans_max JOURNAL_TRANS_MIN_DEFAULT / ratio ||
+ SB_ONDISK_JOURNAL_SIZE(p_s_sb) / journal-j_trans_max
+ JOURNAL_MIN_RATIO) {
+ reiserfs_warning(p_s_sb,
+ sh-462: bad transaction max size (%u). FSCK?,
+ journal-j_trans_max);
+ return 1;
+ }
+ if (journal-j_max_batch != (journal-j_trans_max) *
+ JOURNAL_MAX_BATCH_DEFAULT/JOURNAL_TRANS_MAX_DEFAULT) {
+ reiserfs_warning(p_s_sb,
+sh-463: bad transaction max batch (%u). FSCK?,
+journal-j_max_batch);
+ return 1;
+ }
+ } else {
+ /* Default journal params.
+ The file system was created by old version
+ of mkreiserfs, so some fields contain zeros,
+ and we need to advise proper values for them */
+ if (p_s_sb-s_blocksize != REISERFS_STANDARD_BLKSIZE)
+ reiserfs_panic(p_s_sb, sh-464: bad blocksize (%u),
+ p_s_sb-s_blocksize);
+ journal-j_trans_max = JOURNAL_TRANS_MAX_DEFAULT;
+ journal-j_max_batch = JOURNAL_MAX_BATCH_DEFAULT;
+ journal-j_max_commit_age = JOURNAL_MAX_COMMIT_AGE;
+ }
+ return 0;
+}
+
/*
** must be called once on fs mount. calls journal_read for you
*/
@@ -2744,49 +2799,8 @@
le32_to_cpu(jh-jh_journal.jp_journal_max_commit_age);
journal-j_max_trans_age = JOURNAL_MAX_TRANS_AGE;
- if (journal-j_trans_max) {
- /* make sure these parameters are available, assign it if they are not */
- __u32 initial = journal-j_trans_max;
- __u32 ratio = 1;
-
- if (p_s_sb-s_blocksize 4096)
- ratio = 4096 / p_s_sb-s_blocksize;
-
- if (SB_ONDISK_JOURNAL_SIZE(p_s_sb) / journal-j_trans_max
- JOURNAL_MIN_RATIO)
- journal-j_trans_max =
- SB_ONDISK_JOURNAL_SIZE(p_s_sb) / JOURNAL_MIN_RATIO;
- if (journal-j_trans_max JOURNAL_TRANS_MAX_DEFAULT / ratio)
- journal-j_trans_max =
- JOURNAL_TRANS_MAX_DEFAULT / ratio;
- if (journal-j_trans_max JOURNAL_TRANS_MIN_DEFAULT / ratio)
- journal-j_trans_max =
- JOURNAL_TRANS_MIN_DEFAULT / ratio;
-
- if (journal-j_trans_max != initial)
- reiserfs_warning(p_s_sb,
- sh-461: journal_init: wrong transaction max size (%u). Changed to %u,
- initial, journal-j_trans_max);
-
- journal-j_max_batch = journal-j_trans_max *
- JOURNAL_MAX_BATCH_DEFAULT / JOURNAL_TRANS_MAX_DEFAULT;
- }
-
- if (!journal-j_trans_max) {
- /*we have the file system was created by old version of mkreiserfs
- so this field contains zero value */
- journal-j_trans_max = JOURNAL_TRANS_MAX_DEFAULT;
- journal-j_max_batch = JOURNAL_MAX_BATCH_DEFAULT;
- journal-j_max_commit_age = JOURNAL_MAX_COMMIT_AGE;
-
- /* for blocksize = 4096 - max transaction size is 1024. For block size 4096
- trans max size is decreased proportionally */
- if (p_s_sb-s_blocksize 4096) {
- journal-j_trans_max /= (4096 / p_s_sb-s_blocksize);
- journal-j_max_batch = (journal-j_trans_max) * 9 / 10;
- }
- }
-
+ if (check_advise_trans_params(p_s_sb, journal) != 0)
+ goto free_and_return;
journal-j_default_max_commit_age = journal-j_max_commit_age;
if (commit_max_age != 0) {
Re: 2.6.23-rc8-mm2 NULL dereference in __mnt_is_readonly in ftruncate
Dave Hansen wrote: On Fri, 2007-09-28 at 01:30 -0700, Andrew Morton wrote: On Thu, 27 Sep 2007 15:54:20 -0600 Zan Lynx <[EMAIL PROTECTED]> wrote: Near the end of my boot sequence, there is a kernel error. I am not sure exactly what user-space is doing to make this happen, but I know that a simple shell and some filesystem operations do not cause it. This error also occurred in 2.6.23-rc8-mm1 but I didn't have time to post it and hoped it would just go away. I never tested 2.6.23-rc7-mm*, and the error did not happen in rc6-mm1. console [netcon0] enabled netconsole: network logging started eth0: no IPv6 routers present Unable to handle kernel NULL pointer dereference at 0053 RIP: [] __mnt_is_readonly+0x0/0x20 PGD 0 Oops: [1] SMP last sysfs file: /block/sr0/size CPU 0 Modules linked in: netconsole configfs sg ipv6 evdev usbhid hid usb_storage libusual psmouse serio_raw ssb video output ehci_hcd ohci_hcd usbcore snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd snd_page_alloc Pid: 7291, comm: smbd Not tainted 2.6.23-rc8-mm2 #1 RIP: 0010:[] [] __mnt_is_readonly+0x0/0x20 RSP: 0018:8100068b1b60 EFLAGS: 00010296 RAX: 810007108000 RBX: 81000261d8c0 RCX: 8093aca0 RDX: 0004 RSI: 8092e950 RDI: 0003 RBP: 0003 R08: 0003 R09: 8061f7cd R10: b256aacb R11: R12: ffe2 R13: 8100068b1bd8 R14: 8100068b1ee8 R15: 81000655a910 FS: 7f6f0930c6f0() GS:806ce000() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0053 CR3: 07cb2000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process smbd (pid: 7291, threadinfo 8100068b, task 810007108000) last branch before last exception/interrupt from [] mnt_want_write+0x3a/0x90 to [] __mnt_is_readonly+0x0/0x20 Stack: 802cc37f 8100078cd9a0 8100068b1bd8 8100078cd9a0 802c82bc 8100078cd780 8100078cd9a0 8100068b1bd8 8100068b1ee8 3000 Call Trace: [] mnt_want_write+0x3f/0x90 [] file_update_time+0x2c/0xe0 [] truncate_file_body+0x148/0x3f0 [] __lock_acquire+0x583/0x1180 [] _spin_unlock+0x17/0x20 [] store_black_box+0x82/0x90 [] safe_link_add+0x75/0xd0 [] setattr_unix_file+0x207/0x220 [] _spin_unlock_irq+0x24/0x30 [] __down_write_nested+0xa1/0xc0 [] notify_change+0xf7/0x2c0 [] do_truncate+0x5e/0x80 [] sys_ftruncate+0x119/0x130 [] system_call+0x7e/0x83 But you oopsed in a different place, via resier4. I don't know if Dave considers that part of his mandate - he could reasonably ask the reiser4 guys to help fix things up. First of all, thanks a bunch for the report. It really helps. This could probably be considered a reiser4 bug, excited by the r/o bind mount changes. See how that pointer is 0x...053? That's a weird offset for a structure that should be mostly word-aligned. I think that's because reiser4 stack-allocates a 'struct file', and then only initializes parts of it, *not* including the vfsmount. The test in file_update_time() is for f->f_vfsmnt == NULL, and I think we had something like 0x1 in there. I think that stack allocation is a pretty nasty trick for a structure that's supposed to be pretty persistent and dynamically allocated, and is certainly something that needs to get fixed up in a proper way. agreed. This works around the problem for now, but this could potentially cause more bugs any time we add some member to 'struct file' and depend on its state being sane anywhere in the VFS. If there's a list anywhere of merge-stopper reiser4 bugs around, this should probably go in there. will be fixed. In general, I think reiser4 also lets the 'struct file' get way too deep into its internals. For instance, I would expect reiser4_write_extent() to take a plain inode, not a 'struct file'. This uses struct file's private data for so-called hints (speedup technique). Why not plain inode? I think because this is remains of removed file-as-directory stuff. Signed-off-by: Dave Hansen <[EMAIL PROTECTED]> --- lxc-dave/fs/reiser4/plugin/file/file.c |1 + 1 file changed, 1 insertion(+) diff -puN fs/reiser4/plugin/file/file.c~reiser4-need-to-initialize-file-f_mnt fs/reiser4/plugin/file/file.c --- lxc/fs/reiser4/plugin/file/file.c~reiser4-need-to-initialize-file-f_mnt 2007-09-28 09:10:51.0 -0700 +++ lxc-dave/fs/reiser4/plugin/file/file.c 2007-09-28 09:11:20.0 -0700 @@ -581,6 +581,7 @@ static int truncate_file_body(struct ino file.private_data = NULL; file.f_pos = new_size; file.private_data = NULL; + file.f_vfsmnt = NULL; uf_info = unix_file_inode_data(inode); result =
Re: 2.6.23-rc8-mm2 NULL dereference in __mnt_is_readonly in ftruncate
Dave Hansen wrote: On Fri, 2007-09-28 at 01:30 -0700, Andrew Morton wrote: On Thu, 27 Sep 2007 15:54:20 -0600 Zan Lynx [EMAIL PROTECTED] wrote: Near the end of my boot sequence, there is a kernel error. I am not sure exactly what user-space is doing to make this happen, but I know that a simple shell and some filesystem operations do not cause it. This error also occurred in 2.6.23-rc8-mm1 but I didn't have time to post it and hoped it would just go away. I never tested 2.6.23-rc7-mm*, and the error did not happen in rc6-mm1. console [netcon0] enabled netconsole: network logging started eth0: no IPv6 routers present Unable to handle kernel NULL pointer dereference at 0053 RIP: [802c96c0] __mnt_is_readonly+0x0/0x20 PGD 0 Oops: [1] SMP last sysfs file: /block/sr0/size CPU 0 Modules linked in: netconsole configfs sg ipv6 evdev usbhid hid usb_storage libusual psmouse serio_raw ssb video output ehci_hcd ohci_hcd usbcore snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd snd_page_alloc Pid: 7291, comm: smbd Not tainted 2.6.23-rc8-mm2 #1 RIP: 0010:[802c96c0] [802c96c0] __mnt_is_readonly+0x0/0x20 RSP: 0018:8100068b1b60 EFLAGS: 00010296 RAX: 810007108000 RBX: 81000261d8c0 RCX: 8093aca0 RDX: 0004 RSI: 8092e950 RDI: 0003 RBP: 0003 R08: 0003 R09: 8061f7cd R10: b256aacb R11: R12: ffe2 R13: 8100068b1bd8 R14: 8100068b1ee8 R15: 81000655a910 FS: 7f6f0930c6f0() GS:806ce000() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0053 CR3: 07cb2000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process smbd (pid: 7291, threadinfo 8100068b, task 810007108000) last branch before last exception/interrupt from [802cc37a] mnt_want_write+0x3a/0x90 to [802c96c0] __mnt_is_readonly+0x0/0x20 Stack: 802cc37f 8100078cd9a0 8100068b1bd8 8100078cd9a0 802c82bc 8100078cd780 8100078cd9a0 8100068b1bd8 8100068b1ee8 3000 Call Trace: [802cc37f] mnt_want_write+0x3f/0x90 [802c82bc] file_update_time+0x2c/0xe0 [803506a8] truncate_file_body+0x148/0x3f0 [802647a3] __lock_acquire+0x583/0x1180 [80537f17] _spin_unlock+0x17/0x20 [80363822] store_black_box+0x82/0x90 [8034a845] safe_link_add+0x75/0xd0 [803521f7] setattr_unix_file+0x207/0x220 [80538274] _spin_unlock_irq+0x24/0x30 [805377f1] __down_write_nested+0xa1/0xc0 [802c8857] notify_change+0xf7/0x2c0 [802b051e] do_truncate+0x5e/0x80 [802b0659] sys_ftruncate+0x119/0x130 [8020c39e] system_call+0x7e/0x83 But you oopsed in a different place, via resier4. I don't know if Dave considers that part of his mandate - he could reasonably ask the reiser4 guys to help fix things up. First of all, thanks a bunch for the report. It really helps. This could probably be considered a reiser4 bug, excited by the r/o bind mount changes. See how that pointer is 0x...053? That's a weird offset for a structure that should be mostly word-aligned. I think that's because reiser4 stack-allocates a 'struct file', and then only initializes parts of it, *not* including the vfsmount. The test in file_update_time() is for f-f_vfsmnt == NULL, and I think we had something like 0x1 in there. I think that stack allocation is a pretty nasty trick for a structure that's supposed to be pretty persistent and dynamically allocated, and is certainly something that needs to get fixed up in a proper way. agreed. This works around the problem for now, but this could potentially cause more bugs any time we add some member to 'struct file' and depend on its state being sane anywhere in the VFS. If there's a list anywhere of merge-stopper reiser4 bugs around, this should probably go in there. will be fixed. In general, I think reiser4 also lets the 'struct file' get way too deep into its internals. For instance, I would expect reiser4_write_extent() to take a plain inode, not a 'struct file'. This uses struct file's private data for so-called hints (speedup technique). Why not plain inode? I think because this is remains of removed file-as-directory stuff. Signed-off-by: Dave Hansen [EMAIL PROTECTED] --- lxc-dave/fs/reiser4/plugin/file/file.c |1 + 1 file changed, 1 insertion(+) diff -puN fs/reiser4/plugin/file/file.c~reiser4-need-to-initialize-file-f_mnt fs/reiser4/plugin/file/file.c --- lxc/fs/reiser4/plugin/file/file.c~reiser4-need-to-initialize-file-f_mnt 2007-09-28 09:10:51.0 -0700 +++ lxc-dave/fs/reiser4/plugin/file/file.c 2007-09-28 09:11:20.0 -0700 @@ -581,6
Re: 2.6.23-rc1-mm1: reiser4 <-> lzo compile error
Adrian Bunk wrote:
<-- snip -->
...
LD .tmp_vmlinux1
lib/built-in.o: In function `lzo1x_1_compress':
(.text+0x13eae): multiple definition of `lzo1x_1_compress'
fs/built-in.o:(.text+0x117075): first defined here
make[1]: *** [.tmp_vmlinux1] Error 1
<-- snip -->
AFAIR, we once had a patch in -mm changing reiser4 to use the
LZO code that is now in the kernel?
cu
Adrian
Sorry, guys, I am not happy with the modified LZO:
the compressor tries to test bytes which are out of bounds.
The attached module testlzo.c causes an oops in the second pass:
AFAIK, both, @m and @m_pos should be in [wrkmem, wrkmem + 64K);
I have attached trace.txt with their actual values.
Not ready to migrate to this library.
Any ideas?
Thanks,
Edward.
P.S.
kernel: 2.6.23-rc1-mm1
box: x86
#include
#include
#include
#include
#include
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Compress 64K zeroed chunk");
#define CHUNK_SIZE 65536
#define NR_PASSES 2
static int __init lkp_init( void )
{
int i;
int ret;
void * wrkmem;
unsigned char * src_buf;
unsigned char * dst_buf;
size_t src_len;
size_t dst_len;
src_len = CHUNK_SIZE;
dst_len = lzo1x_worst_compress(src_len);
printk("<1> Testing LZO: start...\n");
wrkmem = vmalloc(LZO1X_1_MEM_COMPRESS);
if (!wrkmem)
goto enomem;
src_buf = vmalloc(src_len);
if (!src_buf) {
vfree(wrkmem);
goto enomem;
}
memset(src_buf, 0, src_len);
dst_buf = vmalloc(dst_len);
if (!dst_buf) {
vfree(wrkmem);
vfree(src_buf);
goto enomem;
}
for (i = 0; i < NR_PASSES; i++) {
size_t out_len;
ret = lzo1x_1_compress(src_buf, src_len,
dst_buf, _len,
wrkmem);
if (ret)
break;
printk("pass %d: compressed to %d bytes\n", i, out_len);
}
vfree(wrkmem);
vfree(src_buf);
vfree(dst_buf);
return ret;
enomem:
printk("vmalloc failed\n");
return -ENOMEM;
}
static void __exit lkp_cleanup( void )
{
printk("<1>Testing LZO : finish\n");
}
module_init(lkp_init);
module_exit(lkp_cleanup);
Program received signal SIGSEGV, Segmentation fault.
0xc02efec8 in _lzo1x_1_do_compress (in=0xe08c9000 "", in_len=Variable "in_len"
is not available.
) at lzo1x_compress.c:130
130 ip++;
(gdb) p m
$2 = (const unsigned char *) 0xe08d9000
(gdb) p wrkmem
$3 = (void *) 0xe08b8000
(gdb) p m - wrkmem
$4 = 135168
(gdb) p m_pos
$5 = (const unsigned char *) 0xe08c9005 ""
(gdb) p m_pos - wrkmem
$6 = 69637
Re: 2.6.23-rc1-mm1: reiser4 - lzo compile error
Adrian Bunk wrote:
-- snip --
...
LD .tmp_vmlinux1
lib/built-in.o: In function `lzo1x_1_compress':
(.text+0x13eae): multiple definition of `lzo1x_1_compress'
fs/built-in.o:(.text+0x117075): first defined here
make[1]: *** [.tmp_vmlinux1] Error 1
-- snip --
AFAIR, we once had a patch in -mm changing reiser4 to use the
LZO code that is now in the kernel?
cu
Adrian
Sorry, guys, I am not happy with the modified LZO:
the compressor tries to test bytes which are out of bounds.
The attached module testlzo.c causes an oops in the second pass:
AFAIK, both, @m and @m_pos should be in [wrkmem, wrkmem + 64K);
I have attached trace.txt with their actual values.
Not ready to migrate to this library.
Any ideas?
Thanks,
Edward.
P.S.
kernel: 2.6.23-rc1-mm1
box: x86
#include linux/module.h
#include linux/kernel.h
#include linux/init.h
#include linux/lzo.h
#include linux/vmalloc.h
MODULE_LICENSE(GPL);
MODULE_DESCRIPTION(Compress 64K zeroed chunk);
#define CHUNK_SIZE 65536
#define NR_PASSES 2
static int __init lkp_init( void )
{
int i;
int ret;
void * wrkmem;
unsigned char * src_buf;
unsigned char * dst_buf;
size_t src_len;
size_t dst_len;
src_len = CHUNK_SIZE;
dst_len = lzo1x_worst_compress(src_len);
printk(1 Testing LZO: start...\n);
wrkmem = vmalloc(LZO1X_1_MEM_COMPRESS);
if (!wrkmem)
goto enomem;
src_buf = vmalloc(src_len);
if (!src_buf) {
vfree(wrkmem);
goto enomem;
}
memset(src_buf, 0, src_len);
dst_buf = vmalloc(dst_len);
if (!dst_buf) {
vfree(wrkmem);
vfree(src_buf);
goto enomem;
}
for (i = 0; i NR_PASSES; i++) {
size_t out_len;
ret = lzo1x_1_compress(src_buf, src_len,
dst_buf, out_len,
wrkmem);
if (ret)
break;
printk(pass %d: compressed to %d bytes\n, i, out_len);
}
vfree(wrkmem);
vfree(src_buf);
vfree(dst_buf);
return ret;
enomem:
printk(vmalloc failed\n);
return -ENOMEM;
}
static void __exit lkp_cleanup( void )
{
printk(1Testing LZO : finish\n);
}
module_init(lkp_init);
module_exit(lkp_cleanup);
Program received signal SIGSEGV, Segmentation fault.
0xc02efec8 in _lzo1x_1_do_compress (in=0xe08c9000 , in_len=Variable in_len
is not available.
) at lzo1x_compress.c:130
130 ip++;
(gdb) p m
$2 = (const unsigned char *) 0xe08d9000 Address 0xe08d9000 out of bounds
(gdb) p wrkmem
$3 = (void *) 0xe08b8000
(gdb) p m - wrkmem
$4 = 135168
(gdb) p m_pos
$5 = (const unsigned char *) 0xe08c9005
(gdb) p m_pos - wrkmem
$6 = 69637
Re: 2.6.23-rc1-mm1: reiser4 <-> lzo compile error
Adrian Bunk wrote: <-- snip --> ... LD .tmp_vmlinux1 lib/built-in.o: In function `lzo1x_1_compress': (.text+0x13eae): multiple definition of `lzo1x_1_compress' fs/built-in.o:(.text+0x117075): first defined here make[1]: *** [.tmp_vmlinux1] Error 1 <-- snip --> AFAIR, we once had a patch in -mm changing reiser4 to use the LZO code that is now in the kernel? Yup, I'll take a look.. cu Adrian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc1-mm1: reiser4 - lzo compile error
Adrian Bunk wrote: -- snip -- ... LD .tmp_vmlinux1 lib/built-in.o: In function `lzo1x_1_compress': (.text+0x13eae): multiple definition of `lzo1x_1_compress' fs/built-in.o:(.text+0x117075): first defined here make[1]: *** [.tmp_vmlinux1] Error 1 -- snip -- AFAIR, we once had a patch in -mm changing reiser4 to use the LZO code that is now in the kernel? Yup, I'll take a look.. cu Adrian - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 3/3] reiser4: fix unix-file readpages filler
Protect page (via incrementing page count) from
being reclaimed when looking for extent pointer
in unix-file specific readpages filler.
Signed-off-by: Edward Shishkin <[EMAIL PROTECTED]>
---
linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/file.c | 32 +++--
1 files changed, 18 insertions(+), 14 deletions(-)
--- linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/file.c.orig
+++ linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/file.c
@@ -1607,6 +1607,8 @@
unlock_page(page);
return 0;
}
+ page_cache_get(page);
+
if (rc->lh.node == 0) {
/* no twig lock - have to do tree search. */
reiser4_key key;
@@ -1619,21 +1621,19 @@
, >coord, >lh,
ZNODE_READ_LOCK, FIND_EXACT,
TWIG_LEVEL, TWIG_LEVEL, CBK_UNIQUE, NULL);
- if (ret)
- return ret;
+ if (unlikely(ret))
+ goto exit;
lock_page(page);
cbk_done = 1;
}
ret = zload(rc->coord.node);
- if (ret) {
- unlock_page(page);
- return ret;
- }
+ if (unlikely(ret))
+ goto unlock;
if (!coord_is_existing_item(>coord) ||
!item_is_extent(>coord)) {
zrelse(rc->coord.node);
- unlock_page(page);
- return RETERR(-EIO);
+ ret = RETERR(-EIO);
+ goto unlock;
}
ext = extent_by_coord(>coord);
ext_index = extent_unit_index(>coord);
@@ -1647,22 +1647,26 @@
/* we can be here after a CBK call only in case of
corruption of the tree or the tree lookup algorithm bug. */
if (unlikely(cbk_done)) {
- unlock_page(page);
- return RETERR(-EIO);
+ ret = RETERR(-EIO);
+ goto unlock;
}
goto repeat;
}
node = jnode_of_page(page);
if (unlikely(IS_ERR(node))) {
zrelse(rc->coord.node);
- unlock_page(page);
- return PTR_ERR(node);
+ ret = PTR_ERR(node);
+ goto unlock;
}
ret = reiser4_do_readpage_extent(ext, page->index - ext_index, page);
jput(node);
zrelse(rc->coord.node);
- if (ret)
- unlock_page(page);
+ if (likely(!ret))
+ goto exit;
+ unlock:
+ unlock_page(page);
+ exit:
+ page_cache_release(page);
return ret;
}
[patch 1/3] reiser4: fix extent2tail
Fixed bug in extent2tail conversion.
Bug description:
when converting partially converted file
(with flag REISER4_PART_MIXED installed)
reiser4_cut_tree() starts to cut old metatada
from wrong offset. Result is data corruption.
Signed-off-by: Edward Shishkin <[EMAIL PROTECTED]>
---
linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/file.c|7 ---
linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/tail_conversion.c |2 +-
2 files changed, 1 insertion(+), 8 deletions(-)
--- linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/file.c.orig
+++ linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/file.c
@@ -194,13 +194,6 @@
assert("vs-1164", level == LEAF_LEVEL || level == TWIG_LEVEL);
if (uf_info->container == UF_CONTAINER_UNKNOWN) {
- /*
- * container is unknown, therefore conversion can not be in
- * progress
- */
- assert("",
- !reiser4_inode_get_flag(unix_file_info_to_inode(uf_info),
- REISER4_PART_IN_CONV));
if (cbk_result == CBK_COORD_NOTFOUND)
uf_info->container = UF_CONTAINER_EMPTY;
else if (level == LEAF_LEVEL)
--- linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/tail_conversion.c.orig
+++ linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/tail_conversion.c
@@ -620,7 +620,7 @@
}
/* cut part of file we have read */
- start_byte = (__u64) (i << PAGE_CACHE_SHIFT);
+ start_byte = (__u64) ((i + start_page) << PAGE_CACHE_SHIFT);
set_key_offset(, start_byte);
set_key_offset(, start_byte + PAGE_CACHE_SIZE - 1);
/*
[patch 2/3] reiser4: fix read_tail
Update hint when reading tails Signed-off-by: Edward Shishkin <[EMAIL PROTECTED]> --- linux-2.6.22-rc6-mm1/fs/reiser4/plugin/item/tail.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) --- linux-2.6.22-rc6-mm1/fs/reiser4/plugin/item/tail.c.orig +++ linux-2.6.22-rc6-mm1/fs/reiser4/plugin/item/tail.c @@ -758,7 +758,7 @@ coord->unit_pos--; coord->between = AFTER_UNIT; } - + reiser4_set_hint(hint, >key, ZNODE_READ_LOCK); return 0; }
[patch 0/3] reiser4 fixups
Zan Lynx wrote: ... Unable to handle kernel NULL pointer dereference at RIP: [] reiser4_tree_by_page+0x4/0x20 PGD 17594067 PUD d025067 PMD 0 Oops: [1] PREEMPT SMP CPU 0 Modules linked in: nls_iso8859_1 isofs nls_base snd_pcm_oss snd_mixer_oss netconsole ipv6 usbhid hid snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer psmouse serio_raw evdev snd snd_page_alloc ohci_hcd ehci_hcd usbcore sg Pid: 469720, comm: rhythmbox Not tainted 2.6.22-rc6-mm1 #4 RIP: 0010:[] [] reiser4_tree_by_page+0x4/0x20 RSP: 0018:81000ba03940 EFLAGS: 00010296 RAX: RBX: RCX: 000c RDX: 0559 RSI: RDI: 810001433a88 RBP: 810001433a88 R08: R09: 0001 R10: R11: 8035a350 R12: 810001433a88 R13: 81000ba03a90 R14: 8100125e0224 R15: 8100125e0224 FS: 43806940(0063) GS:8075b000() knlGS:f7cd76b0 CS: 0010 DS: ES: CR0: 8005003b CR2: CR3: 04b9e000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process rhythmbox (pid: 469720, threadinfo 81000ba02000, task 810013c4edd0) Stack: 8032649a 81000ba03a90 810001433a88 81000ba03a58 81000ba03a90 8100125e0224 8100125e0224 8034db75 8102 8102 8102 Call Trace: [] jnode_of_page+0x2a/0x2c0 [] uf_readpages_filler+0x235/0x300 [] uf_readpages_filler+0x0/0x300 [] read_cache_pages+0x96/0xc0 [] readpages_unix_file+0x56/0xc0 [] __do_page_cache_readahead+0x1e1/0x2c0 [] ondemand_readahead+0xbb/0x120 [] do_generic_mapping_read+0x1b6/0x4b0 [] file_read_actor+0x0/0x1b0 [] generic_file_aio_read+0x106/0x1c0 [] do_sync_read+0xd9/0x120 [] check_bytes_and_report+0x4b/0x100 [] check_object+0x224/0x260 [] autoremove_wake_function+0x0/0x30 [] _spin_unlock+0x29/0x50 [] reiser4_grab+0x8c/0xd0 [] read_unix_file+0x49f/0x4c0 [] vfs_read+0xc5/0x180 [] sys_read+0x53/0x90 [] system_call+0x7e/0x83 This is bug in Zam's new file_read: unlocked page was reclaimed, then reiser4_tree_by_page() looks at page->mapping->host. The patch #3 fixes this problem. Andrew, please apply the following series. Thanks, Edward. INFO: lockdep is turned off. Code: 48 8b 00 48 8b 80 d0 01 00 00 48 8b 80 18 04 00 00 48 83 c0 RIP [] reiser4_tree_by_page+0x4/0x20 RSP CR2: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 0/3] reiser4 fixups
Zan Lynx wrote: ... Unable to handle kernel NULL pointer dereference at RIP: [8033d324] reiser4_tree_by_page+0x4/0x20 PGD 17594067 PUD d025067 PMD 0 Oops: [1] PREEMPT SMP CPU 0 Modules linked in: nls_iso8859_1 isofs nls_base snd_pcm_oss snd_mixer_oss netconsole ipv6 usbhid hid snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer psmouse serio_raw evdev snd snd_page_alloc ohci_hcd ehci_hcd usbcore sg Pid: 469720, comm: rhythmbox Not tainted 2.6.22-rc6-mm1 #4 RIP: 0010:[8033d324] [8033d324] reiser4_tree_by_page+0x4/0x20 RSP: 0018:81000ba03940 EFLAGS: 00010296 RAX: RBX: RCX: 000c RDX: 0559 RSI: RDI: 810001433a88 RBP: 810001433a88 R08: R09: 0001 R10: R11: 8035a350 R12: 810001433a88 R13: 81000ba03a90 R14: 8100125e0224 R15: 8100125e0224 FS: 43806940(0063) GS:8075b000() knlGS:f7cd76b0 CS: 0010 DS: ES: CR0: 8005003b CR2: CR3: 04b9e000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process rhythmbox (pid: 469720, threadinfo 81000ba02000, task 810013c4edd0) Stack: 8032649a 81000ba03a90 810001433a88 81000ba03a58 81000ba03a90 8100125e0224 8100125e0224 8034db75 8102 8102 8102 Call Trace: [8032649a] jnode_of_page+0x2a/0x2c0 [8034db75] uf_readpages_filler+0x235/0x300 [8034d940] uf_readpages_filler+0x0/0x300 [8028a586] read_cache_pages+0x96/0xc0 [8034dc96] readpages_unix_file+0x56/0xc0 [8028a381] __do_page_cache_readahead+0x1e1/0x2c0 [8028a66b] ondemand_readahead+0xbb/0x120 [80282bc6] do_generic_mapping_read+0x1b6/0x4b0 [80281fb0] file_read_actor+0x0/0x1b0 [80284f46] generic_file_aio_read+0x106/0x1c0 [802ad019] do_sync_read+0xd9/0x120 [802a723b] check_bytes_and_report+0x4b/0x100 [802a7704] check_object+0x224/0x260 [80254580] autoremove_wake_function+0x0/0x30 [8052e669] _spin_unlock+0x29/0x50 [80330e2c] reiser4_grab+0x8c/0xd0 [8034cf9f] read_unix_file+0x49f/0x4c0 [802ad995] vfs_read+0xc5/0x180 [802ade93] sys_read+0x53/0x90 [8020c1de] system_call+0x7e/0x83 This is bug in Zam's new file_read: unlocked page was reclaimed, then reiser4_tree_by_page() looks at page-mapping-host. The patch #3 fixes this problem. Andrew, please apply the following series. Thanks, Edward. INFO: lockdep is turned off. Code: 48 8b 00 48 8b 80 d0 01 00 00 48 8b 80 18 04 00 00 48 83 c0 RIP [8033d324] reiser4_tree_by_page+0x4/0x20 RSP 81000ba03940 CR2: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/3] reiser4: fix extent2tail
Fixed bug in extent2tail conversion.
Bug description:
when converting partially converted file
(with flag REISER4_PART_MIXED installed)
reiser4_cut_tree() starts to cut old metatada
from wrong offset. Result is data corruption.
Signed-off-by: Edward Shishkin [EMAIL PROTECTED]
---
linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/file.c|7 ---
linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/tail_conversion.c |2 +-
2 files changed, 1 insertion(+), 8 deletions(-)
--- linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/file.c.orig
+++ linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/file.c
@@ -194,13 +194,6 @@
assert(vs-1164, level == LEAF_LEVEL || level == TWIG_LEVEL);
if (uf_info-container == UF_CONTAINER_UNKNOWN) {
- /*
- * container is unknown, therefore conversion can not be in
- * progress
- */
- assert(,
- !reiser4_inode_get_flag(unix_file_info_to_inode(uf_info),
- REISER4_PART_IN_CONV));
if (cbk_result == CBK_COORD_NOTFOUND)
uf_info-container = UF_CONTAINER_EMPTY;
else if (level == LEAF_LEVEL)
--- linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/tail_conversion.c.orig
+++ linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/tail_conversion.c
@@ -620,7 +620,7 @@
}
/* cut part of file we have read */
- start_byte = (__u64) (i PAGE_CACHE_SHIFT);
+ start_byte = (__u64) ((i + start_page) PAGE_CACHE_SHIFT);
set_key_offset(from, start_byte);
set_key_offset(to, start_byte + PAGE_CACHE_SIZE - 1);
/*
[patch 2/3] reiser4: fix read_tail
Update hint when reading tails Signed-off-by: Edward Shishkin [EMAIL PROTECTED] --- linux-2.6.22-rc6-mm1/fs/reiser4/plugin/item/tail.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) --- linux-2.6.22-rc6-mm1/fs/reiser4/plugin/item/tail.c.orig +++ linux-2.6.22-rc6-mm1/fs/reiser4/plugin/item/tail.c @@ -758,7 +758,7 @@ coord-unit_pos--; coord-between = AFTER_UNIT; } - + reiser4_set_hint(hint, f-key, ZNODE_READ_LOCK); return 0; }
[patch 3/3] reiser4: fix unix-file readpages filler
Protect page (via incrementing page count) from
being reclaimed when looking for extent pointer
in unix-file specific readpages filler.
Signed-off-by: Edward Shishkin [EMAIL PROTECTED]
---
linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/file.c | 32 +++--
1 files changed, 18 insertions(+), 14 deletions(-)
--- linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/file.c.orig
+++ linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/file.c
@@ -1607,6 +1607,8 @@
unlock_page(page);
return 0;
}
+ page_cache_get(page);
+
if (rc-lh.node == 0) {
/* no twig lock - have to do tree search. */
reiser4_key key;
@@ -1619,21 +1621,19 @@
key, rc-coord, rc-lh,
ZNODE_READ_LOCK, FIND_EXACT,
TWIG_LEVEL, TWIG_LEVEL, CBK_UNIQUE, NULL);
- if (ret)
- return ret;
+ if (unlikely(ret))
+ goto exit;
lock_page(page);
cbk_done = 1;
}
ret = zload(rc-coord.node);
- if (ret) {
- unlock_page(page);
- return ret;
- }
+ if (unlikely(ret))
+ goto unlock;
if (!coord_is_existing_item(rc-coord) ||
!item_is_extent(rc-coord)) {
zrelse(rc-coord.node);
- unlock_page(page);
- return RETERR(-EIO);
+ ret = RETERR(-EIO);
+ goto unlock;
}
ext = extent_by_coord(rc-coord);
ext_index = extent_unit_index(rc-coord);
@@ -1647,22 +1647,26 @@
/* we can be here after a CBK call only in case of
corruption of the tree or the tree lookup algorithm bug. */
if (unlikely(cbk_done)) {
- unlock_page(page);
- return RETERR(-EIO);
+ ret = RETERR(-EIO);
+ goto unlock;
}
goto repeat;
}
node = jnode_of_page(page);
if (unlikely(IS_ERR(node))) {
zrelse(rc-coord.node);
- unlock_page(page);
- return PTR_ERR(node);
+ ret = PTR_ERR(node);
+ goto unlock;
}
ret = reiser4_do_readpage_extent(ext, page-index - ext_index, page);
jput(node);
zrelse(rc-coord.node);
- if (ret)
- unlock_page(page);
+ if (likely(!ret))
+ goto exit;
+ unlock:
+ unlock_page(page);
+ exit:
+ page_cache_release(page);
return ret;
}
Re: 2.6.22-rc6-mm1 reiser4_tree_by_page NULL pointer
I have found the bug, which kills data
when booting after crash, power loss, etc.
The patch is attached.
Please, ping me, if it doesn't help..
Thanks,
Edward.
Zan Lynx wrote:
This bug is annoying enough that I mostly stopped using rc6-mm1, which
is why it took this long to make a report. Previous crashes were
tainted.
I recall seeing something about page table problems with this rc6-mm1
but I don't know if that's what happened to me.
System highlights are: x86_64, SLUB, Reiser4, ZONE_MOVABLE
(kernelcore=384M), PATA with libata.
So here it is:
netconsole: network logging started
eth0: no IPv6 routers present
Hangcheck: hangcheck value past margin!
ISO 9660 Extensions: Microsoft Joliet Level 3
ISO 9660 Extensions: RRIP_1991A
Hangcheck: hangcheck value past margin!
Hangcheck: hangcheck value past margin!
Hangcheck: hangcheck value past margin!
Hangcheck: hangcheck value past margin!
Hangcheck: hangcheck value past margin!
Unable to handle kernel NULL pointer dereference at RIP:
[] reiser4_tree_by_page+0x4/0x20
PGD 9a69067 PUD 9a57067 PMD 0
Oops: [1] PREEMPT SMP
CPU 0
Modules linked in: nls_iso8859_1 isofs nls_base netconsole usbhid hid snd_pcm_oss snd_mixer_oss ipv6 snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd snd_page_alloc ehci_hcd ohci_hcd usbcore evdev psmouse serio_raw sg
Pid: 10479, comm: rhythmbox Not tainted 2.6.22-rc6-mm1 #3
RIP: 0010:[] []
reiser4_tree_by_page+0x4/0x20
RSP: 0018:810011c21940 EFLAGS: 00010296
RAX: RBX: RCX: 000c
RDX: 00f0 RSI: RDI: 810002135d80
RBP: 810002135d80 R08: R09: 0001
R10: 02b2 R11: 8035a350 R12: 810002135d80
R13: 810011c21a90 R14: 81000e5fcdbc R15: 81000e5fcdbc
FS: 42003940(0063) GS:8075b000() knlGS:f7ddf6b0
CS: 0010 DS: ES: CR0: 8005003b
CR2: CR3: 04368000 CR4: 06e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process rhythmbox (pid: 10479, threadinfo 810011c2, task
817b2f10)
Stack: 8032649a 810011c21a90 810002135d80
810011c21a58 810011c21a90 81000e5fcdbc 81000e5fcdbc
8102 [] readpages_unix_file+0x56/0xc0
[] do_generic_mapping_read+0x2f5/0x4b0
[] autoremove_wake_function+0x0/0x30
[] read_unix_file+0x49f/0x4c0
[] vfs_read+0xc5/0x180
Code: 80 00 04
RSP
Bad page state in process 'gdb'
page:810002135d80 flags:0xc001 mapping:
mapcount:0 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
Call Trace:
[] bad_page+0x6b/0x120
[] get_page_from_freelist+0x435/0x520
[] __alloc_pages+0x9e/0x3c0
[] __handle_mm_fault+0x4eb/0x930
[] do_page_fault+0x14e/0x8c0
[] do_page_fault+0x1cb/0x8c0
[] dequeue_entity+0xaf/0xf0
[] _spin_unlock_irq+0x2f/0x50
[] error_exit+0x0/0x96
[] file_read_actor+0x10d/0x1b0
[] do_generic_mapping_read+0x231/0x4b0
[] file_read_actor+0x0/0x1b0
[] generic_file_aio_read+0x106/0x1c0
[] do_sync_read+0xd9/0x120
[] check_bytes_and_report+0x4b/0x100
[] check_object+0x224/0x260
[] autoremove_wake_function+0x0/0x30
[] _spin_unlock+0x29/0x50
[] reiser4_grab+0x8c/0xd0
[] read_unix_file+0x49f/0x4c0
[] cp_new_stat+0xe5/0x100
[] vfs_read+0xc5/0x180
[] sys_read+0x53/0x90
[] system_call+0x7e/0x83
INFO: lockdep is turned off.
Hexdump:
000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
010: 00 00 00 00 00 00 00 00SysRq : Emergency Sync
Emergency Sync complete
SysRq : Emergency Sync
Emergency Sync complete
Hangcheck: hangcheck value past margin!
SysRq : Emergency Sync
Emergency Sync complete
SysRq : Resetting
Fixed bug in extent2tail conversion.
Bug description:
when converting partially converted file
(with flag REISER4_PART_MIXED installed)
reiser4_cut_tree() starts to cut old metatada
from wrong offset. Result is data corruption.
Signed-off-by: Edward Shishkin <[EMAIL PROTECTED]>
---
linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/file.c|7 ---
linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/tail_conversion.c |2 +-
2 files changed, 1 insertion(+), 8 deletions(-)
--- linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/tail_conversion.c.orig
+++ linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/tail_conversion.c
@@ -620,7 +620,7 @@
}
/* cut part of file we have read */
- start_byte = (__u64) (i << PAGE_CACHE_SHIFT);
+ start_byte = (__u64) ((i + start_page) << PAGE_CACHE_SHIFT);
set_key_offset(, start_byte);
set_key_offset(, start_byte + PAGE_CACHE_SIZE - 1);
/*
--- linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/file.c.orig
+++ linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/file.c
@@ -195,13 +195,6 @@
assert("vs-1164", level == LEAF_LEVEL || level == TWIG_LEVEL);
if (uf_info->container == UF_CONTAINER_UNKNOWN) {
- /*
- *
Re: 2.6.22-rc6-mm1 reiser4_tree_by_page NULL pointer
I have found the bug, which kills data when booting after crash, power loss, etc. The patch is attached. Please, ping me, if it doesn't help.. Thanks, Edward. Zan Lynx wrote: This bug is annoying enough that I mostly stopped using rc6-mm1, which is why it took this long to make a report. Previous crashes were tainted. I recall seeing something about page table problems with this rc6-mm1 but I don't know if that's what happened to me. System highlights are: x86_64, SLUB, Reiser4, ZONE_MOVABLE (kernelcore=384M), PATA with libata. So here it is: netconsole: network logging started eth0: no IPv6 routers present Hangcheck: hangcheck value past margin! ISO 9660 Extensions: Microsoft Joliet Level 3 ISO 9660 Extensions: RRIP_1991A Hangcheck: hangcheck value past margin! Hangcheck: hangcheck value past margin! Hangcheck: hangcheck value past margin! Hangcheck: hangcheck value past margin! Hangcheck: hangcheck value past margin! Unable to handle kernel NULL pointer dereference at RIP: [8033d324] reiser4_tree_by_page+0x4/0x20 PGD 9a69067 PUD 9a57067 PMD 0 Oops: [1] PREEMPT SMP CPU 0 Modules linked in: nls_iso8859_1 isofs nls_base netconsole usbhid hid snd_pcm_oss snd_mixer_oss ipv6 snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd snd_page_alloc ehci_hcd ohci_hcd usbcore evdev psmouse serio_raw sg Pid: 10479, comm: rhythmbox Not tainted 2.6.22-rc6-mm1 #3 RIP: 0010:[8033d324] [8033d324] reiser4_tree_by_page+0x4/0x20 RSP: 0018:810011c21940 EFLAGS: 00010296 RAX: RBX: RCX: 000c RDX: 00f0 RSI: RDI: 810002135d80 RBP: 810002135d80 R08: R09: 0001 R10: 02b2 R11: 8035a350 R12: 810002135d80 R13: 810011c21a90 R14: 81000e5fcdbc R15: 81000e5fcdbc FS: 42003940(0063) GS:8075b000() knlGS:f7ddf6b0 CS: 0010 DS: ES: CR0: 8005003b CR2: CR3: 04368000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process rhythmbox (pid: 10479, threadinfo 810011c2, task 817b2f10) Stack: 8032649a 810011c21a90 810002135d80 810011c21a58 810011c21a90 81000e5fcdbc 81000e5fcdbc 8102 [8034dc96] readpages_unix_file+0x56/0xc0 [80282d05] do_generic_mapping_read+0x2f5/0x4b0 [80254580] autoremove_wake_function+0x0/0x30 [8034cf9f] read_unix_file+0x49f/0x4c0 [802ad995] vfs_read+0xc5/0x180 Code: 80 00 04 RSP 810011c21940 Bad page state in process 'gdb' page:810002135d80 flags:0xc001 mapping: mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Call Trace: [80286c0b] bad_page+0x6b/0x120 [80287f65] get_page_from_freelist+0x435/0x520 [8028812e] __alloc_pages+0x9e/0x3c0 [80292e6b] __handle_mm_fault+0x4eb/0x930 [80530d1e] do_page_fault+0x14e/0x8c0 [80530d9b] do_page_fault+0x1cb/0x8c0 [80234a0f] dequeue_entity+0xaf/0xf0 [8052e7df] _spin_unlock_irq+0x2f/0x50 [8052ee0d] error_exit+0x0/0x96 [802820bd] file_read_actor+0x10d/0x1b0 [80282c41] do_generic_mapping_read+0x231/0x4b0 [80281fb0] file_read_actor+0x0/0x1b0 [80284f46] generic_file_aio_read+0x106/0x1c0 [802ad019] do_sync_read+0xd9/0x120 [802a723b] check_bytes_and_report+0x4b/0x100 [802a7704] check_object+0x224/0x260 [80254580] autoremove_wake_function+0x0/0x30 [8052e669] _spin_unlock+0x29/0x50 [80330e2c] reiser4_grab+0x8c/0xd0 [8034cf9f] read_unix_file+0x49f/0x4c0 [802b0da5] cp_new_stat+0xe5/0x100 [802ad995] vfs_read+0xc5/0x180 [802ade93] sys_read+0x53/0x90 [8020c1de] system_call+0x7e/0x83 INFO: lockdep is turned off. Hexdump: 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 010: 00 00 00 00 00 00 00 00SysRq : Emergency Sync Emergency Sync complete SysRq : Emergency Sync Emergency Sync complete Hangcheck: hangcheck value past margin! SysRq : Emergency Sync Emergency Sync complete SysRq : Resetting Fixed bug in extent2tail conversion. Bug description: when converting partially converted file (with flag REISER4_PART_MIXED installed) reiser4_cut_tree() starts to cut old metatada from wrong offset. Result is data corruption. Signed-off-by: Edward Shishkin [EMAIL PROTECTED] --- linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/file.c|7 --- linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/tail_conversion.c |2 +- 2 files changed, 1 insertion(+), 8 deletions(-) --- linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/tail_conversion.c.orig +++ linux-2.6.22-rc6-mm1/fs/reiser4/plugin/file/tail_conversion.c @@ -620,7 +620,7 @@ } /* cut part of file
Re: 2.6.22-rc3-mm1 reiser4 bug
Hello. I looked at your long attachment. It seems, you have problems with hardware. Would you please check your root drive (sde) by badblocks program? Thanks, Edward. Berck E. Nash wrote: All appears to work fine, until I try to boot a kernel with a Reiser4 / partition. Then I get endless errors of the sort: [ 206.349450] sd 1:0:0:0: [sdc] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK (See attached dmesg for more, I only sent the first 1,000 lines, it goes on until a hard reboot.) The same partition and the same kernel work great as long as that partition isn't the current system root. The same kernel and the same hard drive works fine as long as the partition is formatted ReiserFS. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc3-mm1 reiser4 bug
Hello. I looked at your long attachment. It seems, you have problems with hardware. Would you please check your root drive (sde) by badblocks program? Thanks, Edward. Berck E. Nash wrote: All appears to work fine, until I try to boot a kernel with a Reiser4 / partition. Then I get endless errors of the sort: [ 206.349450] sd 1:0:0:0: [sdc] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK (See attached dmesg for more, I only sent the first 1,000 lines, it goes on until a hard reboot.) The same partition and the same kernel work great as long as that partition isn't the current system root. The same kernel and the same hard drive works fine as long as the partition is formatted ReiserFS. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] reiser4: remove lzo compression security hole
Richard Purdie wrote:
Switch reiser4 to use lzo1x_decompress_safe instead of lzo1x_decompress
as otherwise it presents a security hole (lzo1x_decompress doesn't
perform bounds checking on the decompressed data).
Signed-off-by: Richard Purdie <[EMAIL PROTECTED]>
---
fs/reiser4/plugin/compress/compress.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.21/fs/reiser4/plugin/compress/compress.c
===
--- linux-2.6.21.orig/fs/reiser4/plugin/compress/compress.c 2007-05-16
20:47:45.0 +0100
+++ linux-2.6.21/fs/reiser4/plugin/compress/compress.c 2007-05-24
23:43:28.0 +0100
@@ -319,7 +319,7 @@ lzo1_decompress(coa_t coa, __u8 * src_fi
assert("edward-851", coa == NULL);
assert("edward-852", src_len != 0);
- result = lzo1x_decompress(src_first, src_len, dst_first, , NULL);
+ result = lzo1x_decompress_safe(src_first, src_len, dst_first, ,
NULL);
if (result != LZO_E_OK)
warning("edward-853", "lzo1x_1_decompress failed\n");
*dst_len = dstlen;
Signed-off-by: Edward Shishkin <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] reiser4: remove lzo compression security hole
Richard Purdie wrote: Switch reiser4 to use lzo1x_decompress_safe instead of lzo1x_decompress as otherwise it presents a security hole (lzo1x_decompress doesn't perform bounds checking on the decompressed data). Signed-off-by: Richard Purdie [EMAIL PROTECTED] --- fs/reiser4/plugin/compress/compress.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.21/fs/reiser4/plugin/compress/compress.c === --- linux-2.6.21.orig/fs/reiser4/plugin/compress/compress.c 2007-05-16 20:47:45.0 +0100 +++ linux-2.6.21/fs/reiser4/plugin/compress/compress.c 2007-05-24 23:43:28.0 +0100 @@ -319,7 +319,7 @@ lzo1_decompress(coa_t coa, __u8 * src_fi assert(edward-851, coa == NULL); assert(edward-852, src_len != 0); - result = lzo1x_decompress(src_first, src_len, dst_first, dstlen, NULL); + result = lzo1x_decompress_safe(src_first, src_len, dst_first, dstlen, NULL); if (result != LZO_E_OK) warning(edward-853, lzo1x_1_decompress failed\n); *dst_len = dstlen; Signed-off-by: Edward Shishkin [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1
Richard Purdie wrote: On Wed, 2007-05-16 at 10:06 -0700, Andrew Morton wrote: On Wed, 16 May 2007 18:00:43 +0100 Richard Purdie <[EMAIL PROTECTED]> wrote: On Wed, 2007-05-16 at 09:50 -0700, Randy Dunlap wrote: On Tue, 15 May 2007 20:19:14 -0700 Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc1/2.6.22-rc1-mm1/ LZO build fails on allyesconfig: lib/built-in.o: In function `lzo1x_1_compress': lib/lzo/minilzo.c:724: multiple definition of `lzo1x_1_compress' fs/built-in.o:fs/reiser4/plugin/compress/minilzo.c:1307: first defined here ld: Warning: size of symbol `lzo1x_1_compress' changed from 1541 in fs/built-in.o to 244 in lib/built-in.o lib/built-in.o: In function `lzo1x_decompress': lib/lzo/minilzo.c:885: multiple definition of `lzo1x_decompress' fs/built-in.o:fs/reiser4/plugin/compress/minilzo.c:1466: first defined here ld: Warning: size of symbol `lzo1x_decompress' changed from 1047 in fs/built-in.o to 678 in lib/built-in.o make: *** [.tmp_vmlinux1] Error 1 make: Target `all' not remade because of errors. Looks like reiser4 contains a copy of minilzo used as some kind of compression plugin. It can be dropped in favour of the version in lib/lzo/, they'll be compatible. Andrew: Do you want a patch to remove it from reiser4? yes please. Sent. I also noticed that reiser4 is using lzo1x_decompress(), not lzo1x_decompress_safe(). The unsafe version is open to buffer overflows through malicious data since it performs no validation of where it writes output to. Hm, if you accept unknown drive, then yes, it is open.. I'm not sure whether thats acceptable in filesystem code, I'd suspect not? Ok, we will consider safe decompression, moreover, as I remember, it doesn't lead to sensible performance drop.. Thanks for this point, Edward. Fixing it is a case of s/lzo1x_decompress(/lzo1x_decompress_safe(/ in fs/reiser4/plugin/compress/compress.c... Richard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1
Richard Purdie wrote: On Wed, 2007-05-16 at 10:06 -0700, Andrew Morton wrote: On Wed, 16 May 2007 18:00:43 +0100 Richard Purdie [EMAIL PROTECTED] wrote: On Wed, 2007-05-16 at 09:50 -0700, Randy Dunlap wrote: On Tue, 15 May 2007 20:19:14 -0700 Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc1/2.6.22-rc1-mm1/ LZO build fails on allyesconfig: lib/built-in.o: In function `lzo1x_1_compress': lib/lzo/minilzo.c:724: multiple definition of `lzo1x_1_compress' fs/built-in.o:fs/reiser4/plugin/compress/minilzo.c:1307: first defined here ld: Warning: size of symbol `lzo1x_1_compress' changed from 1541 in fs/built-in.o to 244 in lib/built-in.o lib/built-in.o: In function `lzo1x_decompress': lib/lzo/minilzo.c:885: multiple definition of `lzo1x_decompress' fs/built-in.o:fs/reiser4/plugin/compress/minilzo.c:1466: first defined here ld: Warning: size of symbol `lzo1x_decompress' changed from 1047 in fs/built-in.o to 678 in lib/built-in.o make: *** [.tmp_vmlinux1] Error 1 make: Target `all' not remade because of errors. Looks like reiser4 contains a copy of minilzo used as some kind of compression plugin. It can be dropped in favour of the version in lib/lzo/, they'll be compatible. Andrew: Do you want a patch to remove it from reiser4? yes please. Sent. I also noticed that reiser4 is using lzo1x_decompress(), not lzo1x_decompress_safe(). The unsafe version is open to buffer overflows through malicious data since it performs no validation of where it writes output to. Hm, if you accept unknown drive, then yes, it is open.. I'm not sure whether thats acceptable in filesystem code, I'd suspect not? Ok, we will consider safe decompression, moreover, as I remember, it doesn't lead to sensible performance drop.. Thanks for this point, Edward. Fixing it is a case of s/lzo1x_decompress(/lzo1x_decompress_safe(/ in fs/reiser4/plugin/compress/compress.c... Richard - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about Reiser4
[EMAIL PROTECTED] wrote: As I understand it, the default Reiser4 DOES NOT USE any compression at all, not even tail compression, ^tail compression^tail conversion Reiser4 does use tail conversion by default. but saves space by eliminating block alignment wastage (tail compression is an option). So lets LOSE the statistics that involve compression. The results now look like this: .-. | FILESYSTEM | TIME |DISK | | TYPE |(secs)|USAGE| .-. |REISER4 | 3462 | 692 | |EXT2| 4092 | 816 | |JFS | 4225 | 806 | |EXT4| 4408 | 816 | |EXT3| 4421 | 816 | |XFS | 4625 | 779 | |REISER3 | 6178 | 793 | |FAT32 |12342 | 988 | |NTFS-3g |10414 | 772 | .-. These results are still EXTREMELY GOOD for REISER4. Everything is not so simple in the science of testing.. Would you please change direction of your activity to stressing instead of benchmarking? Caught oopses would have great value.. OK? Regards, Edward. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about Reiser4
Andi Kleen wrote: Because there are unaddressed items in this todo list: http://pub.namesys.com/Reiser4/ToDo The main issues here are xattrs and support for blocksize != pagesize. I would consider both to be optional. We have various file systems in tree that don't support either (e.g. JFS only supports 4K blocks and OCFS2 doesn't support xattr) They shouldn't block merging. xattrs also were considered as some guarantee of vendor support. If possible, then we'll address it as low-priority issue. Maybe somebody will help.. (xattrs support should go as incremental update of FPL-subversion for reiser4 kernel module and reiser4progs). 2. Who will maintain this? Currently there are two namesys employees working mostly on enthusiasm. Divide them into 2 file systems, plus many people who really help with fixing problems. Merging will probably be a peak of work for the necessary changes, then hopefully the work will be less once you're in tree because you don't need to track mainline anymore (assuming not to many bugs come in from users) -Andi Hope we survive this, at least such peaks is not something new in our practice. Well, gentlemen, so we'll address other items (except #26, 27) and resume this discussion. Thanks, Edward. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about Reiser4
Andi Kleen wrote: Because there are unaddressed items in this todo list: http://pub.namesys.com/Reiser4/ToDo The main issues here are xattrs and support for blocksize != pagesize. I would consider both to be optional. We have various file systems in tree that don't support either (e.g. JFS only supports 4K blocks and OCFS2 doesn't support xattr) They shouldn't block merging. xattrs also were considered as some guarantee of vendor support. If possible, then we'll address it as low-priority issue. Maybe somebody will help.. (xattrs support should go as incremental update of FPL-subversion for reiser4 kernel module and reiser4progs). 2. Who will maintain this? Currently there are two namesys employees working mostly on enthusiasm. Divide them into 2 file systems, plus many people who really help with fixing problems. Merging will probably be a peak of work for the necessary changes, then hopefully the work will be less once you're in tree because you don't need to track mainline anymore (assuming not to many bugs come in from users) -Andi Hope we survive this, at least such peaks is not something new in our practice. Well, gentlemen, so we'll address other items (except #26, 27) and resume this discussion. Thanks, Edward. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about Reiser4
[EMAIL PROTECTED] wrote: As I understand it, the default Reiser4 DOES NOT USE any compression at all, not even tail compression, ^tail compression^tail conversion Reiser4 does use tail conversion by default. but saves space by eliminating block alignment wastage (tail compression is an option). So lets LOSE the statistics that involve compression. The results now look like this: .-. | FILESYSTEM | TIME |DISK | | TYPE |(secs)|USAGE| .-. |REISER4 | 3462 | 692 | |EXT2| 4092 | 816 | |JFS | 4225 | 806 | |EXT4| 4408 | 816 | |EXT3| 4421 | 816 | |XFS | 4625 | 779 | |REISER3 | 6178 | 793 | |FAT32 |12342 | 988 | |NTFS-3g |10414 | 772 | .-. These results are still EXTREMELY GOOD for REISER4. Everything is not so simple in the science of testing.. Would you please change direction of your activity to stressing instead of benchmarking? Caught oopses would have great value.. OK? Regards, Edward. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about Reiser4
Hello everyone. Begin forwarded message: Date: 23 Apr 2007 21:05:13 +0200 From: Andi Kleen <[EMAIL PROTECTED]> To: Andrew Morton <[EMAIL PROTECTED]> Cc: Eric Hopper <[EMAIL PROTECTED]>, linux-kernel@vger.kernel.org Subject: Re: Question about Reiser4 Andrew Morton <[EMAIL PROTECTED]> writes: To get it unstuck we'd need a general push, get people looking at and testing the code, get the vendors to have a serious think about it, etc. We could do that - it'd require that the namesys people (and I) start making threatening noises about merging it, I guess. My impression was that a lot of negative discussion came out of some of the user interface inventions in r4 (like sys_reiser4 and the new incompatible EA interface). sys_reiser4 and metas interface were removed (current -mm stuff doesn't contain them). I guess a good strategy to get it going would be to extract just a "core reiser4" out of it that is just a file system without any new interfaces like this. I think that current reiser4 is exactly that "core", which responds solely to VFS. The popular opinion that plugins make more sense in the VFS is a great delusion, as plugins are entities related to reiser4 disk layouts. There are many aspects where plugin architecture is useful, I tried to describe one of them -- backward compatibility that was got with minimal efforts: http://dev.namesys.com/Version4.X.Y If this needs more comments, then we will proceed the documentation. I would expect that reviewing that would be much smoother because people could actually concentrate on the technical details. -Andi Other comments: 1. Why Namesys developers aren't presently asking for inclusion? Because there are unaddressed items in this todo list: http://pub.namesys.com/Reiser4/ToDo The main issues here are xattrs and support for blocksize != pagesize. I think that adding xattrs will take ~1 month of full-time working. Not sure about blocksize support. Also, the statement about "main issues" may be too optimistic. Let's try to estimate.. 2. Who will maintain this? Currently there are two namesys employees working mostly on enthusiasm. Divide them into 2 file systems, plus many people who really help with fixing problems. So we need to estimate how dramatic the situation with reiser4 is (experts are welcome). In the worst case (no funding for this in the perspective) I hope to devote ~25% of my working time to this project. Vladimir might want to add something here, but he is sick for now. By the way, he has its own opinion what part of current reiser4 should go to mainline (separating tail's support (which makes things complicated) as special incremental update available on our website). Thanks, Edward. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about Reiser4
Hello everyone. Begin forwarded message: Date: 23 Apr 2007 21:05:13 +0200 From: Andi Kleen [EMAIL PROTECTED] To: Andrew Morton [EMAIL PROTECTED] Cc: Eric Hopper [EMAIL PROTECTED], linux-kernel@vger.kernel.org Subject: Re: Question about Reiser4 Andrew Morton [EMAIL PROTECTED] writes: To get it unstuck we'd need a general push, get people looking at and testing the code, get the vendors to have a serious think about it, etc. We could do that - it'd require that the namesys people (and I) start making threatening noises about merging it, I guess. My impression was that a lot of negative discussion came out of some of the user interface inventions in r4 (like sys_reiser4 and the new incompatible EA interface). sys_reiser4 and metas interface were removed (current -mm stuff doesn't contain them). I guess a good strategy to get it going would be to extract just a core reiser4 out of it that is just a file system without any new interfaces like this. I think that current reiser4 is exactly that core, which responds solely to VFS. The popular opinion that plugins make more sense in the VFS is a great delusion, as plugins are entities related to reiser4 disk layouts. There are many aspects where plugin architecture is useful, I tried to describe one of them -- backward compatibility that was got with minimal efforts: http://dev.namesys.com/Version4.X.Y If this needs more comments, then we will proceed the documentation. I would expect that reviewing that would be much smoother because people could actually concentrate on the technical details. -Andi Other comments: 1. Why Namesys developers aren't presently asking for inclusion? Because there are unaddressed items in this todo list: http://pub.namesys.com/Reiser4/ToDo The main issues here are xattrs and support for blocksize != pagesize. I think that adding xattrs will take ~1 month of full-time working. Not sure about blocksize support. Also, the statement about main issues may be too optimistic. Let's try to estimate.. 2. Who will maintain this? Currently there are two namesys employees working mostly on enthusiasm. Divide them into 2 file systems, plus many people who really help with fixing problems. So we need to estimate how dramatic the situation with reiser4 is (experts are welcome). In the worst case (no funding for this in the perspective) I hope to devote ~25% of my working time to this project. Vladimir might want to add something here, but he is sick for now. By the way, he has its own opinion what part of current reiser4 should go to mainline (separating tail's support (which makes things complicated) as special incremental update available on our website). Thanks, Edward. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: REISER4: fix for reiser4_write_extent
Laurent Riffard wrote: Le 06.04.2007 00:42, Ignatich a écrit : While trying to find the cause of problems with reiser4 in recent kernels I came across this. Incomplete write handling seem to be missing from reiser4_write_extent() thanks to reiser4-temp-fix.patch. Strangely, there is a patch by Edward Shishkin that should address that issue, but it is missing from -mm tree. Please check. Max This patch was added to -mm tree the 14 Dec 2006 (see http://www.mail-archive.com/mm-commits@vger.kernel.org/msg05338.html). It was then dropped from -mm tree the 05 Mar 2007 (see http://www.mail-archive.com/mm-commits@vger.kernel.org/msg10818.html), with this comment: "This patch was dropped because it is obsolete" No idea why it was obsolete. Does somebody know ? This uses not settled interface filemap_copy_from_user_atomic/nonatomic However, those things should be fixed. I'll prepare the patch a bit later.. Thanks, Edward. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: REISER4: fix for reiser4_write_extent
Laurent Riffard wrote: Le 06.04.2007 00:42, Ignatich a écrit : While trying to find the cause of problems with reiser4 in recent kernels I came across this. Incomplete write handling seem to be missing from reiser4_write_extent() thanks to reiser4-temp-fix.patch. Strangely, there is a patch by Edward Shishkin that should address that issue, but it is missing from -mm tree. Please check. Max This patch was added to -mm tree the 14 Dec 2006 (see http://www.mail-archive.com/mm-commits@vger.kernel.org/msg05338.html). It was then dropped from -mm tree the 05 Mar 2007 (see http://www.mail-archive.com/mm-commits@vger.kernel.org/msg10818.html), with this comment: This patch was dropped because it is obsolete No idea why it was obsolete. Does somebody know ? This uses not settled interface filemap_copy_from_user_atomic/nonatomic However, those things should be fixed. I'll prepare the patch a bit later.. Thanks, Edward. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: reiser4 bugs in 2.6.21-rc4]
Ignatich wrote: Subject: reiser4 bugs in 2.6.21-rc4 From: Ignatich <[EMAIL PROTECTED]> Date: Tue, 27 Mar 2007 23:29:18 +0400 To: linux-kernel@vger.kernel.org To: linux-kernel@vger.kernel.org Message-ID: <[EMAIL PROTECTED]> User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit There are two bugs I found in current -mm reiser4 code. 1. Some files seem to be zeroed out randomly. Usually it's /lib/security/pam_limits.so and /lib/security/pam_deny.so. As fsck.reiser4 didn't find anything wrong I decided to create clean installation in vmware and see if this bug appears on newly formatted partition. It did. 2. Sometimes I get oppses in reiser4_do_readpage_extent. Assert codes are vs-1426 and nikita-2688. A patch was posted on namesys list to address this problem, but it didn't help. Kernel: 2.6.21-rc4 with manually applied reiser4 patches from -mm. Arch: x86-64 We are working on this. Thanks for reports, Edward. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: reiser4 bugs in 2.6.21-rc4]
Ignatich wrote: Subject: reiser4 bugs in 2.6.21-rc4 From: Ignatich [EMAIL PROTECTED] Date: Tue, 27 Mar 2007 23:29:18 +0400 To: linux-kernel@vger.kernel.org To: linux-kernel@vger.kernel.org Message-ID: [EMAIL PROTECTED] User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit There are two bugs I found in current -mm reiser4 code. 1. Some files seem to be zeroed out randomly. Usually it's /lib/security/pam_limits.so and /lib/security/pam_deny.so. As fsck.reiser4 didn't find anything wrong I decided to create clean installation in vmware and see if this bug appears on newly formatted partition. It did. 2. Sometimes I get oppses in reiser4_do_readpage_extent. Assert codes are vs-1426 and nikita-2688. A patch was posted on namesys list to address this problem, but it didn't help. Kernel: 2.6.21-rc4 with manually applied reiser4 patches from -mm. Arch: x86-64 We are working on this. Thanks for reports, Edward. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
Andrew Morton wrote: On Tue, 20 Mar 2007 17:23:54 -0600 Zan Lynx <[EMAIL PROTECTED]> wrote: On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ First impressions: Several of the same bugs as rc3-mm*: * Freezes immediately if I touch the wlan0 device after loading the new Broadcom wireless driver. cc linux-wireless * Freezes immediately if I allow Bluetooth to configure. cc bluez-devel * All freezes simply stop, no BUG or panic happens, no watchdog, soft or NMI ever triggers. Thinking about it, I wonder if disabling EDAC_K8 would help here? Does it steal NMI? I'll try that later. Mabe that will be fixed by the just-uploaded ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/hot-fixes/tty-in-tiocsctty-when-we-steal-a-tty-hang-it-up-fix.patch * I am using Reiser4 and after one of the above freezes and hard power cycle, files that were in use *read*only* are filled with zeros. did you enable compression announced not so long ago? anyway, it would be better to check your fs by fsck.reiser4 For example, while testing and experiencing the above freezes, I lost /etc/ld.so.preload and /lib/security/pam_limits.so. What the heck? cc reiserfs-dev - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
Andrew Morton wrote: On Tue, 20 Mar 2007 17:23:54 -0600 Zan Lynx [EMAIL PROTECTED] wrote: On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ First impressions: Several of the same bugs as rc3-mm*: * Freezes immediately if I touch the wlan0 device after loading the new Broadcom wireless driver. cc linux-wireless * Freezes immediately if I allow Bluetooth to configure. cc bluez-devel * All freezes simply stop, no BUG or panic happens, no watchdog, soft or NMI ever triggers. Thinking about it, I wonder if disabling EDAC_K8 would help here? Does it steal NMI? I'll try that later. Mabe that will be fixed by the just-uploaded ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/hot-fixes/tty-in-tiocsctty-when-we-steal-a-tty-hang-it-up-fix.patch * I am using Reiser4 and after one of the above freezes and hard power cycle, files that were in use *read*only* are filled with zeros. did you enable compression announced not so long ago? anyway, it would be better to check your fs by fsck.reiser4 For example, while testing and experiencing the above freezes, I lost /etc/ld.so.preload and /lib/security/pam_limits.so. What the heck? cc reiserfs-dev - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Reiser4: Transparent compression support. Further development and compatibility.
ess file plugin with gzip1 compression. Description of all cryptcompress-related settings can be found here: http://dev.namesys.com/CryptcompressSettings 5. Mount the reiser4 file system (better with noatime option). 6. Have a fun. NOTE: If you use cryptcompress plugin, then the only way to monitor real disk space usage is looking at a counter of free blocks in superblock (for example, df (1)), but first of all make sure (for example, by sync (1)), that there is no dirty pages in memory, otherwise df will show incorrect information (will be fixed). du (1) statistics does not reflect (online) real space usage, as i_bytes and i_blocks are unsupported by cryptcompress plugin (supporting those fields "on-line" leads to performance drop). However, their proper values can be set "offline" by reiser4.fsck. NOTE: 1. Currently ciphering is unsupported (for this to work, some human key manager is needed). 2. Don't create loopback devices over files managed by cryptcompress plugin, as it doesn't work properly for now. 3. Make sure your boot partition does not contain files managed by cryptcompress plugin, as grub does not support this. C. Compatibility WARNING: Don't try to check/repair your partition that contains cryptcompress files with reiser4progs of version less then 1.0.6. Also don't try to mount such partition in old kernels < 2.6.18-mm3. We hope to completely avoid such compatibility problems (and therefore to get rid of "don't mount to kernelXXX" and "don't check by reiser4progsYYY" stuff) in future via using a simple technique based on plugin architecture as it is described in the document appended below. All comments, suggestions and, of course, bugreports are welcome: , . Hope, you'll find this stuff useful. Reiserfs team. Appendix D. Devoted to resolving backward compatibility problems in Reiser4. Directed to file system developers and anyone with an interest in Reiser4 and plugin architecture. Reiser4 file system: development, versions and compatibility. Edward Shishkin 1. Backward compatibility problems Such problems arise when user downgrades kernel or fsprogs package: old ones can be not aware of new objects on his partition. We have tried to resolve backward compatibility problems using plugin architecture that reiser4 is based on. The main idea is very simple: to reduce them to a problem of "unknown" plugins". However, this puts some restrictions to the development model. Such approach (introduced in 2.6.18-mm3 and reiser4progs-1.0.6) is considered below in details. On one's way we try to clarify reiser4 possibilities in the development aspect. 2. Core and plugins. SPL and FPL Reiser4 kernel module consists of core code and plugins. Core includes balancing, transaction manager, flush manager, etc. code manipulates with virtual objects like formatted nodes, items, etc. Such virtualization technology is not new and is used everywhere (manipulations with VFS is a good example). Now it should be easy to understand a concept of reiser4 plugin, the basic concept of reiser4 file system. Reiser4 plugin is a kernel data structure filled by pointers to some functions (its "methods"). Each reiser4 plugin is labeled by a unique pair (type, id), globally persistent plugin identifier, so plugins with the same first components are of the same type of data (struct typename_plugin). Plugin name is composed of id name (first) and type name. For example: "extent item plugin" means plugin of item type which manages extent pointers in reiser4. All plugins of any type are initialized by the array typename_plugins. Every reiser4 plugin has its counterpart in reiser4progs (1**). Every reiser4 plugin belongs to one of the following two libraries (the same for reiser4progs): First library, SPL (per-Superblock Plugins Library), aggregates plugins that work with low-level disk layouts (superblock, formatted nodes, bitmap nodes, journal, etc). (Disk) format in reiser4 is a disk format plugin (i.e plugin labeled by the pair (disk_format, id)). Disk format are assigned per superblock. Disk format plugin installs node plugin and some other SPL members to reiser4 superblock in mount time. SPL has a version number defined as greatest supported disk format plugin id. Second library, FPL (per-File Plugins Library), aggregates so called file managers which are to work with disk layouts (like item plugin), represent some formatting policy (like formatting plugin), etc. The "uppermost" plugins of file type are to service VFS entry points. File managers are pointed by inode's plugin table (pset) described by data structure plugin_set filled by pointers to plugins. Attributes (type, id) of non-default file managers pointed in object's pset are packed/extracted like other attributes to/from disk stat-data by special stat-data item plugin.
Reiser4: Transparent compression support. Further development and compatibility.
://dev.namesys.com/CryptcompressSettings
5. Mount the reiser4 file system (better with noatime option).
6. Have a fun.
NOTE: If you use cryptcompress plugin, then the only way to monitor
real disk space usage is looking at a counter of free blocks in
superblock (for example, df (1)), but first of all make sure (for
example, by sync (1)), that there is no dirty pages in memory,
otherwise df will show incorrect information (will be fixed).
du (1) statistics does not reflect (online) real space usage, as
i_bytes and i_blocks are unsupported by cryptcompress plugin
(supporting those fields on-line leads to performance drop).
However, their proper values can be set offline by reiser4.fsck.
NOTE:
1. Currently ciphering is unsupported (for this to work, some human
key manager is needed).
2. Don't create loopback devices over files managed by cryptcompress
plugin, as it doesn't work properly for now.
3. Make sure your boot partition does not contain files managed by
cryptcompress plugin, as grub does not support this.
C. Compatibility
WARNING: Don't try to check/repair your partition that contains
cryptcompress files with reiser4progs of version less then 1.0.6. Also
don't try to mount such partition in old kernels 2.6.18-mm3.
We hope to completely avoid such compatibility problems (and therefore
to get rid of don't mount to kernelXXX and don't check by
reiser4progsYYY stuff) in future via using a simple technique based
on plugin architecture as it is described in the document appended
below. All comments, suggestions and, of course, bugreports are
welcome:
reiserfs-dev at namesys dot com,
reiserfs-list at namesys dot com.
Hope, you'll find this stuff useful.
Reiserfs team.
Appendix D.
Devoted to resolving backward compatibility problems in Reiser4.
Directed to file system developers and anyone with an interest in
Reiser4 and plugin architecture.
Reiser4 file system: development, versions and compatibility.
Edward Shishkin
1. Backward compatibility problems
Such problems arise when user downgrades kernel or fsprogs package:
old ones can be not aware of new objects on his partition. We have
tried to resolve backward compatibility problems using plugin
architecture that reiser4 is based on. The main idea is very simple:
to reduce them to a problem of unknown plugins. However, this puts
some restrictions to the development model. Such approach (introduced
in 2.6.18-mm3 and reiser4progs-1.0.6) is considered below in details.
On one's way we try to clarify reiser4 possibilities in the
development aspect.
2. Core and plugins. SPL and FPL
Reiser4 kernel module consists of core code and plugins. Core includes
balancing, transaction manager, flush manager, etc. code manipulates
with virtual objects like formatted nodes, items, etc. Such
virtualization technology is not new and is used everywhere
(manipulations with VFS is a good example). Now it should be easy to
understand a concept of reiser4 plugin, the basic concept of reiser4
file system. Reiser4 plugin is a kernel data structure filled by
pointers to some functions (its methods). Each reiser4 plugin is
labeled by a unique pair (type, id), globally persistent plugin
identifier, so plugins with the same first components are of the same
type of data (struct typename_plugin). Plugin name is composed of id
name (first) and type name. For example: extent item plugin means
plugin of item type which manages extent pointers in reiser4. All
plugins of any type are initialized by the array typename_plugins.
Every reiser4 plugin has its counterpart in reiser4progs (1**).
Every reiser4 plugin belongs to one of the following two libraries
(the same for reiser4progs):
First library, SPL (per-Superblock Plugins Library), aggregates
plugins that work with low-level disk layouts (superblock, formatted
nodes, bitmap nodes, journal, etc). (Disk) format in reiser4 is a disk
format plugin (i.e plugin labeled by the pair (disk_format, id)). Disk
format are assigned per superblock. Disk format plugin installs node
plugin and some other SPL members to reiser4 superblock in mount time.
SPL has a version number defined as greatest supported disk format
plugin id.
Second library, FPL (per-File Plugins Library), aggregates so called
file managers which are to work with disk layouts (like item plugin),
represent some formatting policy (like formatting plugin), etc.
The uppermost plugins of file type are to service VFS entry points.
File managers are pointed by inode's plugin table (pset) described by
data structure plugin_set filled by pointers to plugins. Attributes
(type, id) of non-default file managers pointed in object's pset are
packed/extracted like other attributes to/from disk stat-data by
special stat-data item plugin. We associate FPL with a set of pairs
{(type, id) | type = file, directory, item, hash, ...}. FPL version
number is defined by another, more economic way (2**).
Every plugin
Re: 2.6.20-rc3-mm1: umount reiser4 FS stuck in D state
Laurent Riffard wrote: Le 01.02.2007 21:04, Edward Shishkin a écrit : Laurent Riffard wrote: Le 23.01.2007 16:46, Jens Axboe a écrit : On Tue, Jan 23 2007, Vladimir V. Saveliev wrote: Hello On Saturday 13 January 2007 01:56, Laurent Riffard wrote: Le 06.01.2007 19:58, Vladimir V. Saveliev a écrit : Hello On Saturday 06 January 2007 13:58, Laurent Riffard wrote: Hello, got this with 2.6.20-rc3-mm1: === SysRq : Show Blocked State freesibling task PCstack pid father child younger older umountD C013135E 6044 1168 1150 (NOTLB) de591ae4 0086 de591abc c013135e dff979c8 c012a6fe 0046 0007dfd94ac0 128d3000 0026 dfd94bcc dff979c8 de591ae4 dffda0380002 dff979c0 dff979bc dff979c8 de591b10 c012d600 dff979f8 Call Trace: [] synchronize_qrcu+0x70/0x8c [] __make_request+0x4c/0x29b [] generic_make_request+0x1b0/0x1de [] submit_bio+0xda/0xe2 [] write_jnodes_to_disk_extent+0x920/0x974 [reiser4] [] update_journal_footer+0x29f/0x2b7 [reiser4] [] write_tx_back+0x149/0x185 [reiser4] [] reiser4_write_logs+0xea4/0xfd2 [reiser4] [] try_commit_txnh+0x7e6/0xa4f [reiser4] [] reiser4_txn_end+0x148/0x3cf [reiser4] [] reiser4_txn_restart+0xb/0x1a [reiser4] [] reiser4_txn_restart_current+0x73/0x75 [reiser4] [] force_commit_atom+0x258/0x261 [reiser4] [] txnmgr_force_commit_all+0x406/0x697 [reiser4] [] release_format40+0x10c/0x193 [reiser4] [] reiser4_put_super+0x134/0x16a [reiser4] [] generic_shutdown_super+0x55/0xd8 [] kill_block_super+0x20/0x32 [] deactivate_super+0x3f/0x51 [] mntput_no_expire+0x42/0x5f [] path_release_on_umount+0x15/0x18 [] sys_umount+0x1a3/0x1cb [] sys_oldumount+0x19/0x1b [] sysenter_past_esp+0x5f/0x99 === Scenario: - umount a reiser4 FS (no need to write something before) Hmm, I can not reproduce this with 2.6.20-rc3-mm1. Probably I need to config the kernel more close to your system. Earlier kernels were OK. This still happens with 2.6.20-rc4-mm1... Should I open a bug report at http://bugzilla.kernel.org? Which device with reiser4 did you try to umount? Jens wrote that it could be a barrier related. If there are no multidevices involved - please report to bugzilla. Make sure that your kernel contains this fix: http://git.kernel.dk/?p=linux-2.6-block.git;a=commitdiff;h=4af09c42ee1af70356471f51c1f40c1ff7881b68;hp=036f6008f43b5b4dd8c825365f15434d75005c6d I think it missed 2.6.20-rc3-mm1. Again, that assumes you are using md or dm. I've got 2 reiser4 FS: - one with /dev/sdb6 - the other with /dev/vglinux1/ccache (vglinux1 is built on /dev/sda4 and /dev/sdb7). There is no md here, only dm. I applied the above patch on top of 2.6.20-rc4-mm1, but the problem still happens with the two devices. thanks Laurent, would you please try 2.6.20-rc6-mm3 + this patch: http://lkml.org/lkml/diff/2007/2/1/195/1 Reiser4 works fine with 2.6.20-rc6-mm2 or 2.6.20-rc6-mm3 without any additional patch (it was broken in rc6-mm1). FWIW, Andrew removed git-block.patch from 2.6.20-rc6-mm2, and he restored git-block.patch without some problematic CFQ updates in 2.6.20-rc6-mm3. In this case, does this patch need testing in rc6-mm3 ? Yes. This is against git-block patch to prevent endless waiting for IO completion. I have reproduced it by ./iozone -B -a -n 524288 -f /mnt/foo on x86 box with 512M RAM available. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc3-mm1: umount reiser4 FS stuck in D state
Laurent Riffard wrote: Le 23.01.2007 16:46, Jens Axboe a écrit : On Tue, Jan 23 2007, Vladimir V. Saveliev wrote: Hello On Saturday 13 January 2007 01:56, Laurent Riffard wrote: Le 06.01.2007 19:58, Vladimir V. Saveliev a écrit : Hello On Saturday 06 January 2007 13:58, Laurent Riffard wrote: Hello, got this with 2.6.20-rc3-mm1: === SysRq : Show Blocked State freesibling task PCstack pid father child younger older umountD C013135E 6044 1168 1150 (NOTLB) de591ae4 0086 de591abc c013135e dff979c8 c012a6fe 0046 0007dfd94ac0 128d3000 0026 dfd94bcc dff979c8 de591ae4 dffda0380002 dff979c0 dff979bc dff979c8 de591b10 c012d600 dff979f8 Call Trace: [] synchronize_qrcu+0x70/0x8c [] __make_request+0x4c/0x29b [] generic_make_request+0x1b0/0x1de [] submit_bio+0xda/0xe2 [] write_jnodes_to_disk_extent+0x920/0x974 [reiser4] [] update_journal_footer+0x29f/0x2b7 [reiser4] [] write_tx_back+0x149/0x185 [reiser4] [] reiser4_write_logs+0xea4/0xfd2 [reiser4] [] try_commit_txnh+0x7e6/0xa4f [reiser4] [] reiser4_txn_end+0x148/0x3cf [reiser4] [] reiser4_txn_restart+0xb/0x1a [reiser4] [] reiser4_txn_restart_current+0x73/0x75 [reiser4] [] force_commit_atom+0x258/0x261 [reiser4] [] txnmgr_force_commit_all+0x406/0x697 [reiser4] [] release_format40+0x10c/0x193 [reiser4] [] reiser4_put_super+0x134/0x16a [reiser4] [] generic_shutdown_super+0x55/0xd8 [] kill_block_super+0x20/0x32 [] deactivate_super+0x3f/0x51 [] mntput_no_expire+0x42/0x5f [] path_release_on_umount+0x15/0x18 [] sys_umount+0x1a3/0x1cb [] sys_oldumount+0x19/0x1b [] sysenter_past_esp+0x5f/0x99 === Scenario: - umount a reiser4 FS (no need to write something before) Hmm, I can not reproduce this with 2.6.20-rc3-mm1. Probably I need to config the kernel more close to your system. Earlier kernels were OK. This still happens with 2.6.20-rc4-mm1... Should I open a bug report at http://bugzilla.kernel.org? Which device with reiser4 did you try to umount? Jens wrote that it could be a barrier related. If there are no multidevices involved - please report to bugzilla. Make sure that your kernel contains this fix: http://git.kernel.dk/?p=linux-2.6-block.git;a=commitdiff;h=4af09c42ee1af70356471f51c1f40c1ff7881b68;hp=036f6008f43b5b4dd8c825365f15434d75005c6d I think it missed 2.6.20-rc3-mm1. Again, that assumes you are using md or dm. I've got 2 reiser4 FS: - one with /dev/sdb6 - the other with /dev/vglinux1/ccache (vglinux1 is built on /dev/sda4 and /dev/sdb7). There is no md here, only dm. I applied the above patch on top of 2.6.20-rc4-mm1, but the problem still happens with the two devices. thanks Laurent, would you please try 2.6.20-rc6-mm3 + this patch: http://lkml.org/lkml/diff/2007/2/1/195/1 Thanks, Edward. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption
Zan Lynx wrote:
On Sat, 2007-01-20 at 03:34 +0300, Vladimir V. Saveliev wrote:
Hello
On Friday 19 January 2007 20:58, Zan Lynx wrote:
I have been running 2.6.20-rc2-mm1 without problems, but both rc3-mm1
and rc4-mm1 have been giving me these freezes. They were happening
inside X and without external console it was impossible to get anything,
plus I was reluctant to test it since the freeze sometimes requires a
full fsck.reiser4 --build-fs to recover the filesystem.
But I finally got some output in a console session. I wasn't able to
get it all, I made some notes of what I think the problem is. I may try
again later once I get netconsole working (netconsole fails as a
built-in, I'll try it as a module next).
[snip]
yes, please provide more information. Full kernel output at time of freeze is
very desirable.
Here comes a full sized bug report, as best as I can do it. This is
kernel 2.6.20-rc6-mm3 instead of rc4-mm1. Still has the problem.
Thanks for the dump.
[ 3138.456588] [] current_atom_finish_all_fq+0x12e/0x280
[ 3138.456661] [] autoremove_wake_function+0x0/0x30
[ 3138.456674] [] submit_wb_list+0x11c/0x130
[ 3138.456690] [] reiser4_txn_end+0x349/0x530
[ 3138.456710] [] reiser4_txn_restart+0x9/0x20
[ 3138.456781] [] force_commit_atom+0x50/0x60
[ 3138.456793] [] writepages_unix_file+0x671/0x780
[ 3138.456824] [] do_writepages+0x43/0x80
[ 3138.456838] [] __filemap_fdatawrite_range+0x58/0x70
[ 3138.456914] [] do_fsync+0x3d/0xe0
[ 3138.456930] [] sys_msync+0x143/0x1f0
[ 3138.456945] [] system_call+0x7e/0x83
This is waiting for IO completion, and no success because of new plugging
policy introduced by block layer folks. The attached patch should help.
Andrew, please apply.
Thanks,
Edward.
Signed-off-by: Edward Shishkin <[EMAIL PROTECTED]>
---
linux-2.6.20-rc6-mm3/fs/reiser4/status_flags.c |2 ++
linux-2.6.20-rc6-mm3/fs/reiser4/wander.c | 18 +++---
2 files changed, 13 insertions(+), 7 deletions(-)
--- linux-2.6.20-rc6-mm3/fs/reiser4/status_flags.c.orig
+++ linux-2.6.20-rc6-mm3/fs/reiser4/status_flags.c
@@ -63,6 +63,7 @@
}
lock_page(page);
submit_bio(READ, bio);
+ blk_replug_current_nested();
wait_on_page_locked(page);
if (!PageUptodate(page)) {
warning("green-2007",
@@ -157,6 +158,7 @@
lock_page(get_super_private(sb)->status_page); // Safe as nobody should touch our page.
/* We can block now, but we have no other choice anyway */
submit_bio(WRITE, bio);
+ blk_replug_current_nested();
return 0; // We do not wait for io to finish.
}
--- linux-2.6.20-rc6-mm3/fs/reiser4/wander.c.orig
+++ linux-2.6.20-rc6-mm3/fs/reiser4/wander.c
@@ -718,6 +718,7 @@
jnode *first, int nr, const reiser4_block_nr *block_p,
flush_queue_t *fq, int flags)
{
+ int ret = 0;
struct super_block *super = reiser4_get_current_sb();
int write_op = ( flags & WRITEOUT_BARRIER ) ? WRITE_BARRIER : WRITE;
int max_blocks;
@@ -738,9 +739,10 @@
int nr_used;
bio = bio_alloc(GFP_NOIO, nr_blocks);
- if (!bio)
- return RETERR(-ENOMEM);
-
+ if (!bio) {
+ ret = RETERR(-ENOMEM);
+ break;
+ }
bio->bi_bdev = super->s_bdev;
bio->bi_sector = block * (super->s_blocksize >> 9);
for (nr_used = 0, i = 0; i < nr_blocks; i++) {
@@ -843,8 +845,10 @@
reiser4_submit_bio(write_op, bio);
not_supported = bio_flagged(bio, BIO_EOPNOTSUPP);
bio_put(bio);
-if (not_supported)
- return -EOPNOTSUPP;
+if (not_supported) {
+ ret = -EOPNOTSUPP;
+ break;
+}
}
block += nr_used - 1;
@@ -855,8 +859,8 @@
}
nr -= nr_used;
}
-
- return 0;
+ blk_replug_current_nested();
+ return ret;
}
/* This is a procedure which recovers a contiguous sequences of disk block
Re: linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption
Zan Lynx wrote:
On Sat, 2007-01-20 at 03:34 +0300, Vladimir V. Saveliev wrote:
Hello
On Friday 19 January 2007 20:58, Zan Lynx wrote:
I have been running 2.6.20-rc2-mm1 without problems, but both rc3-mm1
and rc4-mm1 have been giving me these freezes. They were happening
inside X and without external console it was impossible to get anything,
plus I was reluctant to test it since the freeze sometimes requires a
full fsck.reiser4 --build-fs to recover the filesystem.
But I finally got some output in a console session. I wasn't able to
get it all, I made some notes of what I think the problem is. I may try
again later once I get netconsole working (netconsole fails as a
built-in, I'll try it as a module next).
[snip]
yes, please provide more information. Full kernel output at time of freeze is
very desirable.
Here comes a full sized bug report, as best as I can do it. This is
kernel 2.6.20-rc6-mm3 instead of rc4-mm1. Still has the problem.
Thanks for the dump.
[ 3138.456588] [8033f5de] current_atom_finish_all_fq+0x12e/0x280
[ 3138.456661] [80296510] autoremove_wake_function+0x0/0x30
[ 3138.456674] [803350ac] submit_wb_list+0x11c/0x130
[ 3138.456690] [80335409] reiser4_txn_end+0x349/0x530
[ 3138.456710] [803355f9] reiser4_txn_restart+0x9/0x20
[ 3138.456781] [80335680] force_commit_atom+0x50/0x60
[ 3138.456793] [8034cfb1] writepages_unix_file+0x671/0x780
[ 3138.456824] [802590b3] do_writepages+0x43/0x80
[ 3138.456838] [8024dbf8] __filemap_fdatawrite_range+0x58/0x70
[ 3138.456914] [8024e19d] do_fsync+0x3d/0xe0
[ 3138.456930] [802c2473] sys_msync+0x143/0x1f0
[ 3138.456945] [8025c11e] system_call+0x7e/0x83
This is waiting for IO completion, and no success because of new plugging
policy introduced by block layer folks. The attached patch should help.
Andrew, please apply.
Thanks,
Edward.
Signed-off-by: Edward Shishkin [EMAIL PROTECTED]
---
linux-2.6.20-rc6-mm3/fs/reiser4/status_flags.c |2 ++
linux-2.6.20-rc6-mm3/fs/reiser4/wander.c | 18 +++---
2 files changed, 13 insertions(+), 7 deletions(-)
--- linux-2.6.20-rc6-mm3/fs/reiser4/status_flags.c.orig
+++ linux-2.6.20-rc6-mm3/fs/reiser4/status_flags.c
@@ -63,6 +63,7 @@
}
lock_page(page);
submit_bio(READ, bio);
+ blk_replug_current_nested();
wait_on_page_locked(page);
if (!PageUptodate(page)) {
warning(green-2007,
@@ -157,6 +158,7 @@
lock_page(get_super_private(sb)-status_page); // Safe as nobody should touch our page.
/* We can block now, but we have no other choice anyway */
submit_bio(WRITE, bio);
+ blk_replug_current_nested();
return 0; // We do not wait for io to finish.
}
--- linux-2.6.20-rc6-mm3/fs/reiser4/wander.c.orig
+++ linux-2.6.20-rc6-mm3/fs/reiser4/wander.c
@@ -718,6 +718,7 @@
jnode *first, int nr, const reiser4_block_nr *block_p,
flush_queue_t *fq, int flags)
{
+ int ret = 0;
struct super_block *super = reiser4_get_current_sb();
int write_op = ( flags WRITEOUT_BARRIER ) ? WRITE_BARRIER : WRITE;
int max_blocks;
@@ -738,9 +739,10 @@
int nr_used;
bio = bio_alloc(GFP_NOIO, nr_blocks);
- if (!bio)
- return RETERR(-ENOMEM);
-
+ if (!bio) {
+ ret = RETERR(-ENOMEM);
+ break;
+ }
bio-bi_bdev = super-s_bdev;
bio-bi_sector = block * (super-s_blocksize 9);
for (nr_used = 0, i = 0; i nr_blocks; i++) {
@@ -843,8 +845,10 @@
reiser4_submit_bio(write_op, bio);
not_supported = bio_flagged(bio, BIO_EOPNOTSUPP);
bio_put(bio);
-if (not_supported)
- return -EOPNOTSUPP;
+if (not_supported) {
+ ret = -EOPNOTSUPP;
+ break;
+}
}
block += nr_used - 1;
@@ -855,8 +859,8 @@
}
nr -= nr_used;
}
-
- return 0;
+ blk_replug_current_nested();
+ return ret;
}
/* This is a procedure which recovers a contiguous sequences of disk block
Re: 2.6.20-rc3-mm1: umount reiser4 FS stuck in D state
Laurent Riffard wrote: Le 23.01.2007 16:46, Jens Axboe a écrit : On Tue, Jan 23 2007, Vladimir V. Saveliev wrote: Hello On Saturday 13 January 2007 01:56, Laurent Riffard wrote: Le 06.01.2007 19:58, Vladimir V. Saveliev a écrit : Hello On Saturday 06 January 2007 13:58, Laurent Riffard wrote: Hello, got this with 2.6.20-rc3-mm1: === SysRq : Show Blocked State freesibling task PCstack pid father child younger older umountD C013135E 6044 1168 1150 (NOTLB) de591ae4 0086 de591abc c013135e dff979c8 c012a6fe 0046 0007dfd94ac0 128d3000 0026 dfd94bcc dff979c8 de591ae4 dffda0380002 dff979c0 dff979bc dff979c8 de591b10 c012d600 dff979f8 Call Trace: [c012d600] synchronize_qrcu+0x70/0x8c [c01bede4] __make_request+0x4c/0x29b [c01bd24b] generic_make_request+0x1b0/0x1de [c01bf354] submit_bio+0xda/0xe2 [e12674bd] write_jnodes_to_disk_extent+0x920/0x974 [reiser4] [e12678dd] update_journal_footer+0x29f/0x2b7 [reiser4] [e1268b65] write_tx_back+0x149/0x185 [reiser4] [e126a8e7] reiser4_write_logs+0xea4/0xfd2 [reiser4] [e125626a] try_commit_txnh+0x7e6/0xa4f [reiser4] [e125661b] reiser4_txn_end+0x148/0x3cf [reiser4] [e12568ad] reiser4_txn_restart+0xb/0x1a [reiser4] [e125692f] reiser4_txn_restart_current+0x73/0x75 [reiser4] [e1256b89] force_commit_atom+0x258/0x261 [reiser4] [e1257703] txnmgr_force_commit_all+0x406/0x697 [reiser4] [e12e5e08] release_format40+0x10c/0x193 [reiser4] [e1279922] reiser4_put_super+0x134/0x16a [reiser4] [c015c930] generic_shutdown_super+0x55/0xd8 [c015c9d3] kill_block_super+0x20/0x32 [c015ca75] deactivate_super+0x3f/0x51 [c016d903] mntput_no_expire+0x42/0x5f [c0160f37] path_release_on_umount+0x15/0x18 [c016df77] sys_umount+0x1a3/0x1cb [c016dfb8] sys_oldumount+0x19/0x1b [c0103ed2] sysenter_past_esp+0x5f/0x99 === Scenario: - umount a reiser4 FS (no need to write something before) Hmm, I can not reproduce this with 2.6.20-rc3-mm1. Probably I need to config the kernel more close to your system. Earlier kernels were OK. This still happens with 2.6.20-rc4-mm1... Should I open a bug report at http://bugzilla.kernel.org? Which device with reiser4 did you try to umount? Jens wrote that it could be a barrier related. If there are no multidevices involved - please report to bugzilla. Make sure that your kernel contains this fix: http://git.kernel.dk/?p=linux-2.6-block.git;a=commitdiff;h=4af09c42ee1af70356471f51c1f40c1ff7881b68;hp=036f6008f43b5b4dd8c825365f15434d75005c6d I think it missed 2.6.20-rc3-mm1. Again, that assumes you are using md or dm. I've got 2 reiser4 FS: - one with /dev/sdb6 - the other with /dev/vglinux1/ccache (vglinux1 is built on /dev/sda4 and /dev/sdb7). There is no md here, only dm. I applied the above patch on top of 2.6.20-rc4-mm1, but the problem still happens with the two devices. thanks Laurent, would you please try 2.6.20-rc6-mm3 + this patch: http://lkml.org/lkml/diff/2007/2/1/195/1 Thanks, Edward. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc3-mm1: umount reiser4 FS stuck in D state
Laurent Riffard wrote: Le 01.02.2007 21:04, Edward Shishkin a écrit : Laurent Riffard wrote: Le 23.01.2007 16:46, Jens Axboe a écrit : On Tue, Jan 23 2007, Vladimir V. Saveliev wrote: Hello On Saturday 13 January 2007 01:56, Laurent Riffard wrote: Le 06.01.2007 19:58, Vladimir V. Saveliev a écrit : Hello On Saturday 06 January 2007 13:58, Laurent Riffard wrote: Hello, got this with 2.6.20-rc3-mm1: === SysRq : Show Blocked State freesibling task PCstack pid father child younger older umountD C013135E 6044 1168 1150 (NOTLB) de591ae4 0086 de591abc c013135e dff979c8 c012a6fe 0046 0007dfd94ac0 128d3000 0026 dfd94bcc dff979c8 de591ae4 dffda0380002 dff979c0 dff979bc dff979c8 de591b10 c012d600 dff979f8 Call Trace: [c012d600] synchronize_qrcu+0x70/0x8c [c01bede4] __make_request+0x4c/0x29b [c01bd24b] generic_make_request+0x1b0/0x1de [c01bf354] submit_bio+0xda/0xe2 [e12674bd] write_jnodes_to_disk_extent+0x920/0x974 [reiser4] [e12678dd] update_journal_footer+0x29f/0x2b7 [reiser4] [e1268b65] write_tx_back+0x149/0x185 [reiser4] [e126a8e7] reiser4_write_logs+0xea4/0xfd2 [reiser4] [e125626a] try_commit_txnh+0x7e6/0xa4f [reiser4] [e125661b] reiser4_txn_end+0x148/0x3cf [reiser4] [e12568ad] reiser4_txn_restart+0xb/0x1a [reiser4] [e125692f] reiser4_txn_restart_current+0x73/0x75 [reiser4] [e1256b89] force_commit_atom+0x258/0x261 [reiser4] [e1257703] txnmgr_force_commit_all+0x406/0x697 [reiser4] [e12e5e08] release_format40+0x10c/0x193 [reiser4] [e1279922] reiser4_put_super+0x134/0x16a [reiser4] [c015c930] generic_shutdown_super+0x55/0xd8 [c015c9d3] kill_block_super+0x20/0x32 [c015ca75] deactivate_super+0x3f/0x51 [c016d903] mntput_no_expire+0x42/0x5f [c0160f37] path_release_on_umount+0x15/0x18 [c016df77] sys_umount+0x1a3/0x1cb [c016dfb8] sys_oldumount+0x19/0x1b [c0103ed2] sysenter_past_esp+0x5f/0x99 === Scenario: - umount a reiser4 FS (no need to write something before) Hmm, I can not reproduce this with 2.6.20-rc3-mm1. Probably I need to config the kernel more close to your system. Earlier kernels were OK. This still happens with 2.6.20-rc4-mm1... Should I open a bug report at http://bugzilla.kernel.org? Which device with reiser4 did you try to umount? Jens wrote that it could be a barrier related. If there are no multidevices involved - please report to bugzilla. Make sure that your kernel contains this fix: http://git.kernel.dk/?p=linux-2.6-block.git;a=commitdiff;h=4af09c42ee1af70356471f51c1f40c1ff7881b68;hp=036f6008f43b5b4dd8c825365f15434d75005c6d I think it missed 2.6.20-rc3-mm1. Again, that assumes you are using md or dm. I've got 2 reiser4 FS: - one with /dev/sdb6 - the other with /dev/vglinux1/ccache (vglinux1 is built on /dev/sda4 and /dev/sdb7). There is no md here, only dm. I applied the above patch on top of 2.6.20-rc4-mm1, but the problem still happens with the two devices. thanks Laurent, would you please try 2.6.20-rc6-mm3 + this patch: http://lkml.org/lkml/diff/2007/2/1/195/1 Reiser4 works fine with 2.6.20-rc6-mm2 or 2.6.20-rc6-mm3 without any additional patch (it was broken in rc6-mm1). FWIW, Andrew removed git-block.patch from 2.6.20-rc6-mm2, and he restored git-block.patch without some problematic CFQ updates in 2.6.20-rc6-mm3. In this case, does this patch need testing in rc6-mm3 ? Yes. This is against git-block patch to prevent endless waiting for IO completion. I have reproduced it by ./iozone -B -a -n 524288 -f /mnt/foo on x86 box with 512M RAM available. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption
Zan Lynx wrote: I have been running 2.6.20-rc2-mm1 without problems, but both rc3-mm1 and rc4-mm1 have been giving me these freezes. I didn't investigate it in details yet, other file systems also freeze for me: http://marc.theaimsgroup.com/?l=linux-kernel=116809282829254=2 They were happening inside X and without external console it was impossible to get anything, plus I was reluctant to test it since the freeze sometimes requires a full fsck.reiser4 --build-fs to recover the filesystem. Why did you decide to recover? Got oops after mount, or? But I finally got some output in a console session. I wasn't able to get it all, I made some notes of what I think the problem is. I may try again later once I get netconsole working (netconsole fails as a built-in, I'll try it as a module next). 1 lock held by pdflush/185: #0: (>s_umount_key#15) ... writeback_inodes+0x89 3 locks held by realsync/12942: #0: (>s_umount_key#15) at ... __sync_inodes+0x78 #1: (>commit_mutex) ... reiser4_txn_end+0x37a #2: (>mutex) ... synchronize_qrcu+0x19 So, I *think* the problem is two locks on s_umount_key#15. Does that sound likely? I also noticed QRCU may be involved. Perhaps someone will look at this and instantly know what the problem is. If not, I'll be following up with more details like .config and perhaps a full sysrq-T dump as soon as that fsck finishes. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption
Zan Lynx wrote: I have been running 2.6.20-rc2-mm1 without problems, but both rc3-mm1 and rc4-mm1 have been giving me these freezes. I didn't investigate it in details yet, other file systems also freeze for me: http://marc.theaimsgroup.com/?l=linux-kernelm=116809282829254w=2 They were happening inside X and without external console it was impossible to get anything, plus I was reluctant to test it since the freeze sometimes requires a full fsck.reiser4 --build-fs to recover the filesystem. Why did you decide to recover? Got oops after mount, or? But I finally got some output in a console session. I wasn't able to get it all, I made some notes of what I think the problem is. I may try again later once I get netconsole working (netconsole fails as a built-in, I'll try it as a module next). 1 lock held by pdflush/185: #0: (type-s_umount_key#15) ... writeback_inodes+0x89 3 locks held by realsync/12942: #0: (type-s_umount_key#15) at ... __sync_inodes+0x78 #1: (mgr-commit_mutex) ... reiser4_txn_end+0x37a #2: (qp-mutex) ... synchronize_qrcu+0x19 So, I *think* the problem is two locks on s_umount_key#15. Does that sound likely? I also noticed QRCU may be involved. Perhaps someone will look at this and instantly know what the problem is. If not, I'll be following up with more details like .config and perhaps a full sysrq-T dump as soon as that fsck finishes. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how to use compression with reiser4
Louis-David Mitterrand wrote: Hello, I just converted a server to reiser4 for a big speed gain. Thanks, this looks really promising. How can I activate compression on certain parts of the filesystem? (I digged google for this without finding anything). Hello. Reiser4 will support a special kind of regular files - so called cryptcompress objects. Unfortunately this is not for product using for a while, but benchmarks really show a speed gain for some conditions (if cpu is powerful, compression algorithm is fast, and data is compressible). Thanks, Edward. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how to use compression with reiser4
Louis-David Mitterrand wrote: Hello, I just converted a server to reiser4 for a big speed gain. Thanks, this looks really promising. How can I activate compression on certain parts of the filesystem? (I digged google for this without finding anything). Hello. Reiser4 will support a special kind of regular files - so called cryptcompress objects. Unfortunately this is not for product using for a while, but benchmarks really show a speed gain for some conditions (if cpu is powerful, compression algorithm is fast, and data is compressible). Thanks, Edward. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc5-mm1
Mathieu Segaud wrote:
Mathieu Segaud <[EMAIL PROTECTED]> disait derniÃrement que :
Hum, one hunk didn't make it.
The complete patch is attached
fs/reiser4/plugin/item/ctail.c: In function `check_ctail':
fs/reiser4/plugin/item/ctail.c:250: attention : l'adresse de ÃÂ ctail_ok ÃÂ sera toujours ÃÂvaluÃÂe comme
ÃÂtant ÃÂ true ÃÂ
fs/reiser4/plugin/item/ctail.c: In function `convert_ctail':
fs/reiser4/plugin/item/ctail.c:1669: attention : l'adresse de ÃÂ coord_is_unprepped_ctail ÃÂ sera toujours
ÃÂvaluÃÂe comme ÃÂtant ÃÂ true ÃÂ
Signed-off-by: Mathieu Segaud <[EMAIL PROTECTED]>
Thanks for catching this.
Edward.
--- fs/reiser4/plugin/item/ctail.c 2005-03-01 14:57:52.756014040 +0100
+++ fs/reiser4/plugin/item/ctail.c.new 2005-03-01 14:57:19.791025480 +0100
@@ -247,7 +247,7 @@
reiser4_internal int
check_ctail (const coord_t * coord, const char **error)
{
- if (!ctail_ok) {
+ if (!ctail_ok(coord)) {
if (error)
*error = "bad cluster shift in ctail";
return 1;
@@ -1666,7 +1666,7 @@
detach_convert_idata(pos->sq);
break;
case CRC_OVERWRITE_ITEM:
- if (coord_is_unprepped_ctail) {
+ if (coord_is_unprepped_ctail(>coord)) {
/* convert unpprepped ctail to prepped one */
int shift;
shift =
inode_cluster_shift(item_convert_data(pos)->inode);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc5-mm1
Mathieu Segaud wrote:
Mathieu Segaud [EMAIL PROTECTED] disait dernirement que :
Hum, one hunk didn't make it.
The complete patch is attached
fs/reiser4/plugin/item/ctail.c: In function `check_ctail':
fs/reiser4/plugin/item/ctail.c:250: attention : l'adresse de ctail_ok sera toujours value comme
tant true
fs/reiser4/plugin/item/ctail.c: In function `convert_ctail':
fs/reiser4/plugin/item/ctail.c:1669: attention : l'adresse de coord_is_unprepped_ctail sera toujours
value comme tant true
Signed-off-by: Mathieu Segaud [EMAIL PROTECTED]
Thanks for catching this.
Edward.
--- fs/reiser4/plugin/item/ctail.c 2005-03-01 14:57:52.756014040 +0100
+++ fs/reiser4/plugin/item/ctail.c.new 2005-03-01 14:57:19.791025480 +0100
@@ -247,7 +247,7 @@
reiser4_internal int
check_ctail (const coord_t * coord, const char **error)
{
- if (!ctail_ok) {
+ if (!ctail_ok(coord)) {
if (error)
*error = bad cluster shift in ctail;
return 1;
@@ -1666,7 +1666,7 @@
detach_convert_idata(pos-sq);
break;
case CRC_OVERWRITE_ITEM:
- if (coord_is_unprepped_ctail) {
+ if (coord_is_unprepped_ctail(pos-coord)) {
/* convert unpprepped ctail to prepped one */
int shift;
shift =
inode_cluster_shift(item_convert_data(pos)-inode);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
