Regarding jffs2 failure to report extended attributes

[Ronak Desai]

Hi,

We are having a product which is running an old Linux kernel 2.6.27
and using jffs2 filesystem. We use SELinux policy and security labels
on this system.

One of the jffs2 partition we use as rw and copy some files and read
back those files at regular interval. Now, following is the scenario
we encounter in the field and that is completely random.

Directory structure for example, /mnt/dir_abc/file_xyz
SELinux security label (stored as extended attributes) on "dir_abc" is
not reported and instead it shows the default label "file_t" while
security label on "file_xyz" is intact. No process touches the
"dir_abc" during the process and it's inode number remains the same as
whatever is set by default in jffs2.img. We can see that the inode
version number is changed though in the jffs2dump analysis. So
definitely garbage collection is moving the data around.

When looking at the hexdump of this mtd partition, we can see that the
security label for "dir_abc" is in there but somehow filesystem does
not report it and instead report the default label "file_t".

Now, after doing multiple power cycles on the same unit and
mount/unmount on this partition, the issue disappears and filesystem
stats showing the correct label again.

We understand that it is an old kernel and may be missing fixes but it
is not possible to update to latest kernel. So, are there any specific
commit list on jffs2 that we should review and try to back-port to
avoid problems like this. We are looking for areas for which we should
review commits as definitely there are number of commits after 2.6.27
on jffs2 subsystem.

Best Regards,
Ronak Desai