jffs2: remove unlinked device from the dev_common trees

[adamgreloch]

Device unlinking should also be reflected in the dev_common->dev_ino, dev_common->dev_oid rbtrees. Otherwise, they will forever map the device oid to the inode of the unlinked device, making future create calls for the same oid ineffective

JIRA: RTOS-915

Description

Motivation and Context

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Chore (refactoring, style fixes, git/CI config, submodule management, no code logic changes)

How Has This Been Tested?

• Already covered by automatic testing.
• New test added: (add PR link here).
• Tested by hand on: (list targets here).

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing linter checks and tests passed.
• My changes generate no new compilation warnings for any of the targets.

Special treatment

• This PR needs additional PRs to work (list the PRs, preferably in merge-order).
• I will merge this PR by myself when appropriate.

[github-actions]

Unit Test Results

7 700 tests  ±0   6 985 ✅ ±0   39m 12s ⏱️ +22s
  436 suites ±0     715 💤 ±0 
    1 files   ±0       0 ❌ ±0 

Results for commit 3840e07. ± Comparison against base commit 63e36a5.

[nalajcie]

Seems valid, didn't test it. I was debating whether we shouldn't delay dev_destroy until last iput (nlink == 0, evicting inode) - "unlinking while the device is still open", but it shouldn't make any difference - it's still up to the device creator to ensure the new oid is unique (eg. we don't want to create new named pipe and be connected to the old "pending reader").

Alas, please note that creating devices on non-volatile storage (like jffs2 partition) is obsolete and strongly discouraged (port numbers are not stable between reboots so created devices are useless) - please think about moving device files to ramdisk (dummyfs) in your particular use case.

[adamgreloch]

Alas, please note that creating devices on non-volatile storage (like jffs2 partition) is obsolete and strongly discouraged (port numbers are not stable between reboots so created devices are useless) - please think about moving device files to ramdisk (dummyfs) in your particular use case.

This came up during my investigation of erroneous named unix socket behavior created under /tmp on armv7a9-zynq7000 qemu/hw, which turned out to be caused by the jffs2, hence this bugfix. So my use-case depends on the location of /tmp - preferably it should be on a ramdisk, but I assume that's a target's choice

[nalajcie]

Alas, please note that creating devices on non-volatile storage (like jffs2 partition) is obsolete and strongly discouraged (port numbers are not stable between reboots so created devices are useless) - please think about moving device files to ramdisk (dummyfs) in your particular use case.

This came up during my investigation of erroneous named unix socket behavior created under /tmp on armv7a9-zynq7000 qemu/hw, which turned out to be caused by the jffs2, hence this bugfix. So my use-case depends on the location of /tmp - preferably it should be on a ramdisk, but I assume that's a target's choice

IMHO we could add /tmp ramdisk in our reference projects (on big targets) without serious side-effects (AFAIK it could be done by adding W /sbin/dummyfs -m /tmp -D to the respective rc.psh) as currently it could still backfire (unix socket is a special case as it's currently handled by kernel itself, but we should still promote the safer approach (keeping device files on ramdisk)).