[Bug 244089] lsextattr on a specific UFS file locks system

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244089

            Bug ID: 244089
           Summary: lsextattr on a specific UFS file locks system
           Product: Base System
           Version: 12.1-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs at FreeBSD.org
          Reporter: ml at netfence.it

I've got a 11.3p6/amd64 UFS-based system, where Samba 4.10 is running in a jail
as an AD member.

Yesterday I tried enabling vfs_fruit and streams_xattr: apparently everything
worked fine for a while and extended attributes were created on files/directory
a Mac client accessed.
After a while the client lost connection to the server: I checked and saw a
smbd process taking 100% CPU; such a process was unkillable to the point it
even prevented rebooting. Reset button had to be pressed.

I pinpointed this to reading the extended attributes that were attached to some
file in a particular directory.
I.e.
Something like:
 find {dir} -exec lsextattr user "{}" ";"
produces a process:
 lsextattr user {file}
taking 100% cpu and not willing to die in any way.

Again, only the reset button could get me out of this situation.
"fsck -y" found no sign of troubles on that filesystem.



I was able to use rsync to make a copy of the whole share without extended
attributes, so the server is working again.
However, for now, I'm keeping the "bad" copy around for testing.



System is 11.3p6/amd64 with custom kernel, i.e.:
_ UFS_ACL, UFS_GJOURNAL, QUOTA, MD_ROOT, NFS*, COMPAT*, AUDIT, CAPABILIT*, MAC,
RACCT*, RCTL were removed, along with unused drivers;
_ GEOM_MIRROR, aesni and NULLFS were added.

# tunefs -p /dev/mirror/gm0f 
tunefs: POSIX.1e ACLs: (-a)                                disabled
tunefs: NFSv4 ACLs: (-N)                                   disabled
tunefs: MAC multilabel: (-l)                               disabled
tunefs: soft updates: (-n)                                 enabled
tunefs: soft update journaling: (-j)                       disabled
tunefs: gjournal: (-J)                                     disabled
tunefs: trim: (-t)                                         disabled
tunefs: maximum blocks per file in a cylinder group: (-e)  4096
tunefs: average file size: (-f)                            16384
tunefs: average number of files in a directory: (-s)       64
tunefs: minimum percentage of free space: (-m)             8%
tunefs: space to hold for metadata blocks: (-k)            6408
tunefs: optimization preference: (-o)                      time

Note soft update journaling is now temporarily disabled, but was enabled when
the problem first arose.




One intersting thing would be to exfiltrate this "bad" directory and copy it to
a test server, as I cannot perform many things on this remote production system
(especially considering I cannot press reset remotely).
However just reading the data hangs it, so I have no idea how to do this.

-- 
You are receiving this mail because:
You are the assignee for the bug.