LinuxQuestions.org - slackware64-live-14.2

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - slackware64-live-14.2 (https://www.linuxquestions.org/questions/slackware-14/slackware64-live-14-2-a-4175585764/)

slackware64-live-14.2

Finally got slackware-live working. Downloaded it,
burned to a dvd-rw.

Tried it on my desktop machine. Boot starts fine, gets to
where it's printing something about vram(?) and reboots.

Tried on my laptop (lenovo Thinkpad W540. Starts out with the
initial grub message (only two words), then hangs. Hit a carriage
return and it boots up just fine.

Burnt it to a pen drive and it works in both machines. Kinda neat!

Hit a bug with Slackware Live and the new 4.4.16 kernel...reported as https://bugzilla.kernel.org/show_bug.cgi?id=150711
Basically, I can not create the ISO on kernel 4.4.16 and also the live OS craps out when installing certain (not all) packages.
Still investigating.

Good Catch Eric !

I have already installed 4.4.16 on my Production 14.2 Laptop and this bug scared me a bit when I saw it ...

Looking at your BUG dumps on kernel.org, the bug is isolated to Overlay File Systems, and may have been triggered by this change in fs/overlayfs/inode.c:

https://git.kernel.org/cgit/linux/ke...16&id2=v4.4.15

Before 4.4.16, inode->i_mode was 'anded' with S_IFMT before writing mode into the inode structure ( mode &= S_IFMT ).

But with 4.4.16, `mode &= S_IFMT` is performed after writing the mode into the inode structure which appears to cause the BUG() in fs/attr.c:238 ...

If I understand the code, fs/attr.c lines 240 and 246 look like a catch-22 situation when compared to the test at line 236 that caused the BUG() to be thrown.

fs/attr.c lines 229..254:

Code:

        /*

        * We now pass ATTR_KILL_S*ID to the lower level setattr function so

        * that the function has the ability to reinterpret a mode change

        * that's due to these bits. This adds an implicit restriction that

        * no function will ever call notify_change with both ATTR_MODE and

        * ATTR_KILL_S*ID set.

        */

        if ((ia_valid & (ATTR_KILL_SUID|ATTR_KILL_SGID)) &&    // this is line 236

            (ia_valid & ATTR_MODE))

                BUG();                                          // this is attr.c line 238



        if (ia_valid & ATTR_KILL_SUID) {                        // this is line 240

                if (mode & S_ISUID) {

                        ia_valid = attr->ia_valid |= ATTR_MODE;

                        attr->ia_mode = (inode->i_mode & ~S_ISUID);

                }

        }

        if (ia_valid & ATTR_KILL_SGID) {                        // this is line 246

                if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) {

                        if (!(ia_valid & ATTR_MODE)) {

                                ia_valid = attr->ia_valid |= ATTR_MODE;

                                attr->ia_mode = inode->i_mode;

                        }

                        attr->ia_mode &= ~S_ISGID;

                }

        }

But then again, I can't say I understand the kernel code :)

No worries for me since I don't use the OverlayFS on my Prod Systems but it appears that this bug will prevent adding inodes to an overlayfs for files with the SUID / SGID Bits set ...

Thanks for the report !

-- kjh

This is the change to fs/overlayfs/inode.c referenced by the above URL

Code:

diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c

index 05ac9a9..0597820 100644

--- a/fs/overlayfs/inode.c

+++ b/fs/overlayfs/inode.c

@@ -412,12 +412,11 @@ struct inode *ovl_new_inode(struct super_block *sb, umode_t mode,

        if (!inode)

                return NULL;

 

-        mode &= S_IFMT;

-

        inode->i_ino = get_next_ino();

        inode->i_mode = mode;

        inode->i_flags |= S_NOATIME | S_NOCMTIME;

 

+        mode &= S_IFMT;

        switch (mode) {

        case S_IFDIR:

                inode->i_private = oe;

I just posted on the bug and had somehow missed your comment on it. It's definitely that commit.

Thanks Robbie.

Just read your comment on Eric's Bug Report.

I've never participated in the Kernel Bugzilla Process and I like your comment better than mine :)

-- kjh

Looks like the Kernel Developers are on it:

https://bugzilla.kernel.org/show_bug.cgi?id=150711#c5

-- kjh

Hello,

Note that the commit which causes that issue, also affects, in a different way, the kernels 4.6/4.7 as stated here and there :

Quote:

> > > commit 07a2daab49c549a37b5b744cbebb6e3f445f12bc upstream.
...
> > > inode's ->i_mode from underlying inode ->i_mode but we retain only
> > > file type bits (S_IFMT) and discard permission bits.
...
> > This patch introduced a hang when writing to suid file, fstests
> > generic/355 could reproduce the hang easily, it only failed the test
> > without this patch and didn't hang the kernel.

...
> Does Linus's tree have the same problem?

Yes, 4.7 kernel hangs as well.

>
> > (The 4.6-stable tree faces the same question)

--
SeB

Finally got around to applying the patch and rebuilding my kernel
and reburning the dvd..

Slightly improved results with the dvd. My desktop still reboots
during the boot process, but the laptop boots up properly.

Haven't tried on a pen drive yet. Midnight here and I need my
beauty sleep. Will try it tomorrow, but don't expect any problems.