Re: [PATCH 2/5] UML: remove unused cmd_vdso_install
- Ursprüngliche Mail - > Von: "masahiroy" > An: "linux-kbuild" > CC: "linux-kernel" , "linux-arm-kernel" > , > linux-c...@vger.kernel.org, "linux-parisc" , > linux-ri...@lists.infradead.org, > linux-s...@vger.kernel.org, "linux-um" , > "loongarch" , > "sparclinux" , "x86" , > "masahiroy" , "anton ivanov" > , "bp" , "dave hansen" > , "hpa" > , "mingo" , "Johannes Berg" > , "richard" , > "tglx" > Gesendet: Montag, 9. Oktober 2023 14:42:07 > Betreff: [PATCH 2/5] UML: remove unused cmd_vdso_install > You cannot run this code because arch/um/Makefile does not define the > vdso_install target. > > It appears that this code was blindly copied from another architecture. > > Remove the dead code. > > Signed-off-by: Masahiro Yamada Acked-by: Richard Weinberger Thanks, //richard
Re: [PATCH 00/13] [RFC] Rust support
On Thu, Apr 15, 2021 at 2:41 AM wrote: > Regarding compilers, we support Clang-built kernels as well as > `LLVM=1` builds where possible (i.e. as long as supported by > the ClangBuiltLinux project). We also maintain some configurations > of GCC-built kernels working, but they are not intended to be used > at the present time. Having a `bindgen` backend for GCC would be > ideal to improve support for those builds. Sp this effectively means gcc is a second class citizen and even if gcc is supported at some point one needs a super recent gcc *and* rust toolchain to build a rust-enabeled kernel? I understand that this is right now not a big deal, but as soon a non-trival subsystem is rust-only people are forced to upgrade. Don't get me wrong, I'm all for having rust support in Linux. But I'm a bit worried about new dependencies on compiler toolchains. As someone who works a lot with long supported embedded systems I learned that as soon an application gains a hard dependency on clang or rust I'm in trouble. -- Thanks, //richard
[GIT PULL] MTD fixes for 5.12-rc7
Linus, The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15: Linux 5.12-rc2 (2021-03-05 17:33:41 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git tags/fixes-for-5.12-rc7 for you to fetch changes up to 2fb164f0ce95e504e2688b4f984893c29ebd19ab: mtd: rawnand: mtk: Fix WAITRDY break condition and timeout (2021-03-11 12:23:11 +0100) This pull request contains the following bug fix for MTD: - nand: Fix WAITRDY break condition and timeout in mtk driver Hauke Mehrtens (1): mtd: rawnand: mtk: Fix WAITRDY break condition and timeout drivers/mtd/nand/raw/mtk_nand.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Re: [PATCH] ubifs: default to zstd compression
On Mon, Apr 5, 2021 at 5:36 PM Rui Salvaterra wrote: > > Compared to lzo and zlib, zstd is the best all-around performer, both in terms > of speed and compression ratio. Set it as the default, if available. I was about to NACK this patch but by looking at the diff I realized that you change the default compressor only for the default filesystem as created by UBIFS itself. Queued for the merge window. :-) -- Thanks, //richard
Re: [PATCH 4/6] fs/jffs2: Delete obsolete TODO file
On Tue, Mar 30, 2021 at 9:07 AM Wang Qing wrote: > > The TODO file here has not been updated for 14 years, and the function > development described in the file have been implemented or abandoned. > > Its existence will mislead developers seeking to view outdated information. Did you check whether all items in this list are really outdated? Nobody shall ever blindly follow a TODO list without checking first which points are still valid or not. Removing that file does not magically solve the issues it describes. -- Thanks, //richard
Re: [PATCH] ubifs: fix read fail but return ok
On Wed, Mar 31, 2021 at 8:29 AM wangfangpeng wrote: > do_readpage() may return err, but ubifs_readpage() always return ok. > The vfs will ignore the err happen in ubifs. Are you sure about that? In case of an error UBIFS sets the error flag of the page and does not mark it as uptodate, so vfs will emit -EIO. At least this is the theory. :-) -- Thanks, //richard
Re: [PATCH v1 1/1] ubifs: only check replay with inode type to judge if inode linked
On Tue, Mar 16, 2021 at 10:00 AM wrote:
>
> From: Guochun Mao
>
> Conside the following case, it just write a big file into flash,
> when complete writing, delete the file, and then power off promptly.
> Next time power on, we'll get a replay list like:
> ...
> LEB 1105:211344 len 4144 deletion 0 sqnum 428783 key type 1 inode 80
> LEB 15:233544 len 160 deletion 1 sqnum 428785 key type 0 inode 80
> LEB 1105:215488 len 4144 deletion 0 sqnum 428787 key type 1 inode 80
> ...
> In the replay list, data nodes' deletion are 0, and the inode node's
> deletion is 1. In current logic, the file's dentry will be removed,
> but inode and the flash space it occupied will be reserved.
> User will see that much free space been disappeared.
>
> We only need to check the deletion value of the following inode type
> node of the replay entry.
>
> Signed-off-by: Guochun Mao
> ---
> fs/ubifs/replay.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ubifs/replay.c b/fs/ubifs/replay.c
> index 0f8a6a16421b..1929ec63a0cb 100644
> --- a/fs/ubifs/replay.c
> +++ b/fs/ubifs/replay.c
> @@ -223,7 +223,8 @@ static bool inode_still_linked(struct ubifs_info *c,
> struct replay_entry *rino)
> */
> list_for_each_entry_reverse(r, >replay_list, list) {
> ubifs_assert(c, r->sqnum >= rino->sqnum);
> - if (key_inum(c, >key) == key_inum(c, >key))
> + if (key_inum(c, >key) == key_inum(c, >key) &&
> + key_type(c, >key) == UBIFS_INO_KEY)
This change makes sense. Thanks a lot for hunting this down.
It will be part of the merge window.
--
Thanks,
//richard
Re: [PATCH v1 0/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
Sumit, - Ursprüngliche Mail - > Von: "Sumit Garg" > IIUC, this would require support for multiple trusted keys backends at > runtime but currently the trusted keys subsystem only supports a > single backend which is selected via kernel module parameter during > boot. > > So the trusted keys framework needs to evolve to support multiple > trust sources at runtime but I would like to understand the use-cases > first. IMO, selecting the best trust source available on a platform > for trusted keys should be a one time operation, so why do we need to > have other backends available at runtime as well? I thought about devices with a TPM-Chip and CAAM. IMHO allowing only one backend at the same time is a little over simplified. Thanks, //richard
Re: [PATCH v1 0/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
Ahmad, - Ursprüngliche Mail - > Von: "Ahmad Fatoum" >> But using LUKS would mean that cryptsetup has access to the plain disc >> encryption key material? >> This would be a no-go for many systems out there, key material must not >> accessible to userspace. >> I know, distrusting userspace root is not easy, but doable. :) > > The LUKS2 format supports tokens. I see no reason why the encrypted blob > couldn't be stored there along with the usual metadata. cryptsetup would > then load it as kernel trusted key and use it for dmcrypt decryption. > > This will mean we have to part ways with features such as having multiple > keys, but I think it's worth it to have a plug and play solution for > trusted keys. Ah, now I can follow your thoughts! Yes, that would be nice to have. :) I kind of assumed you want to use LUKS with passphrases and CAAM blobs. Thanks, //richard
Re: [PATCH v1 0/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
Sumit, - Ursprüngliche Mail - > Von: "Sumit Garg" > In this case why would one prefer to use CAAM when you have standards > compliant TPM-Chip which additionally offers sealing to specific PCR > (integrity measurement) values. I don't think we can dictate what good/sane solutions are and which are not. Both CAAM and TPM have pros and cons, I don't see why supporting both is a bad idea. >> > IMHO allowing only one backend at the same time is a little over >> > simplified. >> >> It is, but I'd rather leave this until it's actually needed. >> What can be done now is adopting a format for the exported keys that would >> make this extension seamless in future. >> > > +1 As long we don't make multiple backends at runtime impossible I'm fine and will happily add support for it when needed. :-) Thanks, //richard
Re: [PATCH v1 0/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
Ahmad, - Ursprüngliche Mail - > Von: "Ahmad Fatoum" >> I don't want you to force to use cryptsetup. > > I'd love to use cryptsetup with LUKS and trusted keys eventually. I'll take But using LUKS would mean that cryptsetup has access to the plain disc encryption key material? This would be a no-go for many systems out there, key material must not accessible to userspace. I know, distrusting userspace root is not easy, but doable. :) Thanks, //richard
Re: [PATCH v1 0/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
Ahmad, - Ursprüngliche Mail - > Do you mean systemd-cryptsetup? It looks to me like it's just a way to supply > the keyphrase. With trusted keys and a keyphrase unknown to userspace, this > won't work. Nah, I meant existing scripts/service Files. > I don't (yet) see the utility of it without LUKS. Perhaps a command dump on > how > to do the same I did with dmsetup, but with cryptsetup plain instead could > help me to see the benefits? My reasoning is simple, why do I need a different tool when there is already one that could do the task too? Usually the systems I get my hands on use already dm-crypt with cryptsetup in some way. So I have the tooling already in my initramfs, etc.. and need to adopt the callers of cryptsetup a little. If I need all of a sudden different/additional tooling, it means more work, more docs to write, more hassle with crypto/system reviewers, etc... I don't want you to force to use cryptsetup. The only goal was pointing out that it can be done with cryptsetup and that there is already code such that no work is done twice. One the kernel side it does not matter. Thanks, //richard
Re: [PATCH v1 0/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
Ahmad, - Ursprüngliche Mail - > Von: "Ahmad Fatoum" >> I'm pretty sure with minimal changes it will work with your recent approach >> too. > > I am using dmsetup directly in my project. I am not familiar with cryptsetup > plain. What benefits do you see with this over direct dmsetup? cryptsetup is the de-facto standard to setup encrypted block devices. There is a lot of existing tooling around cryptsetup already (systemd, etc..), so being able to use CAAM keys for dm-crypt with cryptsetup seems natural to me. Plain mode allows setting up dm-crypt without LUKS. Thanks, //richard
Re: [PATCH v1 3/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
Ahmad, - Ursprüngliche Mail - > Von: "Ahmad Fatoum" >> That way existing blobs can also be used with this implementation. >> IIRC the NXP vendor tree uses "SECURE_KEY" as default modifier. > > Being binary compatible with other implementations is not an objective > for this patch set. If you need to migrate I'd suggest to get out a > clear text password and side-load it into the trusted key framework. Compatibility is only one argument, IMHO the much stronger argument is that there are people out there that want to salt the CAAM blob with a key modifier of their own choice. Thanks, //richard
Re: [PATCH v1 0/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
James,
- Ursprüngliche Mail -
> Von: "James Bottomley"
> Well, yes. For the TPM, there's a defined ASN.1 format for the keys:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/tree/tpm2-asn.h
>
> and part of the design of the file is that it's distinguishable either
> in DER or PEM (by the guards) format so any crypto application can know
> it's dealing with a TPM key simply by inspecting the file. I think you
> need the same thing for CAAM and any other format.
>
> We're encouraging new ASN.1 formats to be of the form
>
> SEQUENCE {
>type OBJECT IDENTIFIER
>... key specific fields ...
> }
>
> Where you choose a defined OID to represent the key and that means
> every key even in DER form begins with a unique binary signature.
I like this idea.
Ahmad, what do you think?
That way we could also get rid off the kernel parameter and all the fall back
logic,
given that we find a way to reliable detect TEE blobs too...
Thanks,
//richard
Re: [PATCH v1 0/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
James, - Ursprüngliche Mail - > Von: "James Bottomley" >> On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum > > wrote: >> > keyctl add trusted $KEYNAME "load $(cat ~/kmk.blob)" @s >> >> Is there a reason why we can't pass the desired backend name in the >> trusted key parameters? >> e.g. >> keyctl add trusted $KEYNAME "backendtype caam load $(cat ~/kmk.blob)" >> @s > > Why would you want to in the load? The blob should be type specific, > so a TPM key shouldn't load as a CAAM key and vice versa ... and if > they're not they need to be made so before the patches go upstream. I fear right now there is no good way to detect whether a blob is desired for CAAM or TPM. > I could possibly see that you might want to be type specific in the > create, but once you're simply loading an already created key, the > trusted key subsystem should be able to figure what to do on its own. So you have some kind of container format in mind which denotes the type of the blob? Thanks, //richard
Re: [PATCH v1 3/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
Ahmad, On Tue, Mar 16, 2021 at 6:24 PM Ahmad Fatoum wrote: > +#define KEYMOD "kernel:trusted" why is the CAAM key modifier hard coded? I'd love to have way to pass my own modifier. That way existing blobs can also be used with this implementation. IIRC the NXP vendor tree uses "SECURE_KEY" as default modifier. -- Thanks, //richard
Re: [PATCH v1 0/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
Ahmad, On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum wrote: > keyctl add trusted $KEYNAME "load $(cat ~/kmk.blob)" @s Is there a reason why we can't pass the desired backend name in the trusted key parameters? e.g. keyctl add trusted $KEYNAME "backendtype caam load $(cat ~/kmk.blob)" @s -- Thanks, //richard
Re: [PATCH v1 0/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
Ahmad, On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum wrote: > TABLE="0 $BLOCKS crypt $ALGO :32:trusted:$KEYNAME 0 $DEV 0 1 > allow_discards" > echo $TABLE | dmsetup create mydev > echo $TABLE | dmsetup load mydev Do you also plan to add support for this to cryptsetup? David and I have added (rough) support for our CAAM/DCP based keyrings to cryptsetup: https://github.com/sigma-star/cryptsetup/tree/rw/plain I'm pretty sure with minimal changes it will work with your recent approach too. -- Thanks, //richard
Re: [PATCH v1 3/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
Ahmad, On Wed, Mar 17, 2021 at 3:03 PM Ahmad Fatoum wrote: > > I didn't closely follow the previous discussions, but is a module > > parameter really the right approach? > > Is there also a way to set it via something like device tree? > > Compiled-on sources are considered in the order: tpm, tee then caam. > Module parameters are the only override currently available. Okay. So in the ideal case only one of these backends is compiled in, but the list can get long. I'm asking because David and I currently port another caam-like mechanism to the most recent kernel which will also hook in there. Out driver adds trusted keys support (with caam alike blobs) for i.mx SoCs that come with DCP instead of CAAM. Patches will hopefully materialize soon. -- Thanks, //richard
Re: [PATCH] mtd: require write permissions for locking and badblock ioctls
- Ursprüngliche Mail -
> Von: "Rafał Miłecki"
> An: "Michael Walle" , "linux-mtd"
> , "linux-kernel"
>
> CC: "Miquel Raynal" , "richard" ,
> "Vignesh Raghavendra" ,
> "Greg Kroah-Hartman"
> Gesendet: Montag, 22. März 2021 17:39:41
> Betreff: Re: [PATCH] mtd: require write permissions for locking and badblock
> ioctls
> On 03.03.2021 16:57, Michael Walle wrote:
>> MEMLOCK, MEMUNLOCK and OTPLOCK modify protection bits. Thus require
>> write permission. Depending on the hardware MEMLOCK might even be
>> write-once, e.g. for SPI-NOR flashes with their WP# tied to GND. OTPLOCK
>> is always write-once.
>>
>> MEMSETBADBLOCK modifies the bad block table.
>>
>> Fixes: f7e6b19bc764 ("mtd: properly check all write ioctls for permissions")
>> Signed-off-by: Michael Walle
>
> Should be fine for OpenWrt tools to my best knowledge (and quick testing).
>
> Acked-by: Rafał Miłecki
Nice!
Acked-by: Richard Weinberger
Thanks,
//richard
Re: [PATCH v1 3/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
Sumit, - Ursprüngliche Mail - >> > module_param_named(source, trusted_key_source, charp, 0); >> > -MODULE_PARM_DESC(source, "Select trusted keys source (tpm or tee)"); >> > +MODULE_PARM_DESC(source, "Select trusted keys source (tpm, tee or caam)"); >> >> I didn't closely follow the previous discussions, but is a module >> parameter really the right approach? >> Is there also a way to set it via something like device tree? >> > > It's there to support a platform which possesses multiple trusted keys > backends. So that a user is able to select during boot which one to > use as a backend. I understand the use case, my question was whether it makes actually sense to have a module parameter for it, or additionally another way to define the preferred backend. Thanks, //richard
Re: [PATCH v1 3/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
Ahmad, On Tue, Mar 16, 2021 at 6:24 PM Ahmad Fatoum wrote: > +#include > +#include > +#include > +#include > +#include > + > +struct caam_blob_priv *blobifier; Who is using this pointer too? Otherwise I'd suggest marking it static. > module_param_named(source, trusted_key_source, charp, 0); > -MODULE_PARM_DESC(source, "Select trusted keys source (tpm or tee)"); > +MODULE_PARM_DESC(source, "Select trusted keys source (tpm, tee or caam)"); I didn't closely follow the previous discussions, but is a module parameter really the right approach? Is there also a way to set it via something like device tree? -- Thanks, //richard
Re: [PATCH v1 0/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
Ahmad, On Tue, Mar 16, 2021 at 6:24 PM Ahmad Fatoum wrote: > > The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core > built into many newer i.MX and QorIQ SoCs by NXP. > > Its blob mechanism can AES encrypt/decrypt user data using a unique > never-disclosed device-specific key. There has been multiple > discussions on how to represent this within the kernel: > > - [RFC] crypto: caam - add red blobifier >Steffen implemented[1] a PoC sysfs driver to start a discussion on how to >best integrate the blob mechanism. >Mimi suggested that it could be used to implement trusted keys. >Trusted keys back then were a TPM-only feature. > > - security/keys/secure_key: Adds the secure key support based on CAAM. >Udit added[2] a new "secure" key type with the CAAM as backend. The key >material stays within the kernel only. >Mimi and James agreed that this needs a generic interface, not specific >to CAAM. Mimi suggested trusted keys. Jan noted that this could serve as >basis for TEE-backed keys. > > - [RFC] drivers: crypto: caam: key: Add caam_tk key type >Franck added[3] a new "caam_tk" key type based on Udit's work. The key >material stays within the kernel only, but can optionally be user-set >instead of coming from RNG. James voiced the opinion that there should >be just one user-facing generic wrap/unwrap key type with multiple >possible handlers. David suggested trusted keys. > > - Introduce TEE based Trusted Keys support >Sumit reworked[4] trusted keys to support multiple possible backends with >one chosen at boot time and added a new TEE backend along with TPM. >This now sits in Jarkko's master branch to be sent out for v5.13 > > This patch series builds on top of Sumit's rework to have the CAAM as yet > another > trusted key backend. > > The CAAM bits are based on Steffen's initial patch from 2015. His work had > been > used in the field for some years now, so I preferred not to deviate too much > from it. > > This series has been tested with dmcrypt[5] on an i.MX6DL. Do have this series also in a git repo to pull from? I'd like to give it a test on various systems. > Looking forward to your feedback. Thanks for working on this! David and I will have a closer look these days. -- Thanks, //richard
Re: [PATCH] mtd: require write permissions for locking and badblock ioctls
- Ursprüngliche Mail - >>> Thanks for auditing the rest of these from my original patch. If this >>> is ok with userspace tools, it's fine with me, but I don't even have >>> this hardware to test with :) >> >> That's my fear. Michael, did you verify? > > I don't know any tools except the mtd-utils. So no. openwrt folks have their own tooling, Anrdoid too. >> In general you need to be root to open these device files. >> So, I don't see a security problem here. > > Then this begs the question, why is this check there in > the first place? I fear historical reasons. As soon you can open the device node you can do evil things. > This come up because I was adding a OTPERASE which > was suggested that is was a "dangerous" command. So I > was puzzled why the ones above are considered "safe" ;) :-) Thanks, //richard
Re: [PATCH] mtd: require write permissions for locking and badblock ioctls
Michael,
- Ursprüngliche Mail -
> Von: "Greg Kroah-Hartman"
> An: "Michael Walle"
> CC: "linux-mtd" , "linux-kernel"
> , "Miquel Raynal"
> , "richard" , "Vignesh
> Raghavendra"
> Gesendet: Mittwoch, 3. März 2021 17:08:56
> Betreff: Re: [PATCH] mtd: require write permissions for locking and badblock
> ioctls
> On Wed, Mar 03, 2021 at 04:57:35PM +0100, Michael Walle wrote:
>> MEMLOCK, MEMUNLOCK and OTPLOCK modify protection bits. Thus require
>> write permission. Depending on the hardware MEMLOCK might even be
>> write-once, e.g. for SPI-NOR flashes with their WP# tied to GND. OTPLOCK
>> is always write-once.
>>
>> MEMSETBADBLOCK modifies the bad block table.
>>
>> Fixes: f7e6b19bc764 ("mtd: properly check all write ioctls for permissions")
>> Signed-off-by: Michael Walle
>> ---
>> drivers/mtd/mtdchar.c | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> Thanks for auditing the rest of these from my original patch. If this
> is ok with userspace tools, it's fine with me, but I don't even have
> this hardware to test with :)
That's my fear. Michael, did you verify?
In general you need to be root to open these device files.
So, I don't see a security problem here.
Thanks,
//richard
[GIT PULL] JFFS2/UBIFS and UBI changes for 5.12
Linus, The following changes since commit 92bf22614b21a2706f4993b278017e437f7785b3: Linux 5.11-rc7 (2021-02-07 13:57:38 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs.git tags/for-linus-5.12-rc1 for you to fetch changes up to 42119dbe571eb419dae99b81dd20fa42f47464e1: ubifs: Fix error return code in alloc_wbufs() (2021-02-13 22:58:44 +0100) This pull request contains changes (actually just fixes) for UBIFS JFFS2: - Fix for use-after-free in jffs2_sum_write_data() - Fix for out-of-bounds access in jffs2_zlib_compress() UBI: - Remove dead/useless code UBIFS: - Fix for a memory leak in ubifs_init_authentication() - Fix for high stack usage - Fix for a off-by-one error in xattrs code Arnd Bergmann (1): ubifs: replay: Fix high stack usage, again Dinghao Liu (1): ubifs: Fix memleak in ubifs_init_authentication Jubin Zhong (1): ubi: remove dead code in validate_vid_hdr() Sascha Hauer (1): ubifs: Fix off-by-one error Tom Rix (1): jffs2: fix use after free in jffs2_sum_write_data() Wang ShaoBo (1): ubifs: Fix error return code in alloc_wbufs() Yang Yang (1): jffs2: check the validity of dstlen in jffs2_zlib_compress() Zheng Yongjun (1): ubi: eba: Delete useless kfree code drivers/mtd/ubi/eba.c | 1 - drivers/mtd/ubi/io.c | 7 +-- fs/jffs2/compr_rtime.c | 3 +++ fs/jffs2/summary.c | 3 +++ fs/ubifs/auth.c| 2 +- fs/ubifs/journal.c | 2 +- fs/ubifs/replay.c | 4 +++- fs/ubifs/super.c | 4 +++- fs/ubifs/xattr.c | 2 +- 9 files changed, 16 insertions(+), 12 deletions(-)
[GIT PULL] UML changes for 5.12
Linus, The following changes since commit 92bf22614b21a2706f4993b278017e437f7785b3: Linux 5.11-rc7 (2021-02-07 13:57:38 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git tags/for-linux-5.12-rc1 for you to fetch changes up to ddad5187fc2a12cb84c9d1ac8ecb816708a2986b: um: irq.h: include (2021-02-12 21:40:14 +0100) This pull request contains the following changes for UML: - Many cleanups and fixes for our virtio code - Add support for a pseudo RTC - Fix for a possible jailbreak - Minor fixes (spelling, header files) Christophe Leroy (1): mm: Remove arch_remap() and mm-arch-hooks.h Colin Ian King (1): um: fix spelling mistake in Kconfig "privleges" -> "privileges" Johannes Berg (15): um: virtio: clean up a comment um: virtio: fix handling of messages without payload um: virtio: disable VQs during suspend um: time-travel: rework interrupt handling in ext mode um: virtio: allow devices to be configured for wakeup um: hostfs: use a kmem cache for inodes um: print register names in wait_for_stub um: mm: check more comprehensively for stub changes um: defer killing userspace on page table update failures um: separate child and parent errors in clone stub um: rework userspace stubs to not hard-code stub location um: remove process stub VMA um: add a pseudo RTC um: io.h: include um: irq.h: include arch/um/drivers/Kconfig | 13 +- arch/um/drivers/Makefile| 2 + arch/um/drivers/rtc.h | 15 +++ arch/um/drivers/rtc_kern.c | 211 arch/um/drivers/rtc_user.c | 80 arch/um/drivers/virtio_uml.c| 145 +++--- arch/um/include/asm/Kbuild | 2 +- arch/um/include/asm/io.h| 1 + arch/um/include/asm/irq.h | 1 + arch/um/include/asm/mmu_context.h | 29 + arch/um/include/linux/time-internal.h | 17 +++ arch/um/include/shared/as-layout.h | 17 +-- arch/um/include/shared/common-offsets.h | 6 + arch/um/include/shared/irq_kern.h | 60 + arch/um/include/shared/skas/mm_id.h | 1 + arch/um/include/shared/skas/stub-data.h | 2 +- arch/um/kernel/exec.c | 4 +- arch/um/kernel/irq.c| 171 ++ arch/um/kernel/skas/clone.c | 28 ++--- arch/um/kernel/skas/mmu.c | 87 - arch/um/kernel/time.c | 17 ++- arch/um/kernel/tlb.c| 14 +-- arch/um/kernel/um_arch.c| 5 + arch/um/os-Linux/skas/mem.c | 2 + arch/um/os-Linux/skas/process.c | 86 ++--- arch/x86/um/os-Linux/task_size.c| 2 +- arch/x86/um/shared/sysdep/stub_32.h | 33 +++-- arch/x86/um/shared/sysdep/stub_64.h | 36 -- arch/x86/um/stub_32.S | 17 ++- arch/x86/um/stub_64.S | 5 +- arch/x86/um/stub_segv.c | 5 +- fs/hostfs/hostfs_kern.c | 10 +- include/asm-generic/Kbuild | 1 - include/asm-generic/mm-arch-hooks.h | 16 --- include/linux/mm-arch-hooks.h | 22 mm/mremap.c | 3 - 36 files changed, 841 insertions(+), 325 deletions(-) create mode 100644 arch/um/drivers/rtc.h create mode 100644 arch/um/drivers/rtc_kern.c create mode 100644 arch/um/drivers/rtc_user.c delete mode 100644 include/asm-generic/mm-arch-hooks.h delete mode 100644 include/linux/mm-arch-hooks.h
[GIT PULL] MTD changes for 5.12
Linus, The following changes since commit 19c329f6808995b142b3966301f217c831e7cf31: Linux 5.11-rc4 (2021-01-17 16:37:05 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git tags/mtd/for-5.12 for you to fetch changes up to 6e9dff6fe3fbc452f16566e4a7e293b0decefdba: dt-bindings: mtd: add binding for BCM4908 partitions (2021-02-12 22:24:48 +0100) MTD core changes: * Initial support for BCM4908 partitions Raw NAND controller drivers: * Intel: Fix an error handling path in 'ebu_dma_start()' * Tango: Remove the driver * Marvell: Convert comma to semicolon * MXC: Convert comma to semicolon * Qcom: Add support for Qcom SMEM parser Related MTD changes: * parsers: Add Qcom SMEM parser SPI NOR core changes: * Add non-uniform erase fixes. * Add Global Block Unlock command. It is defined by few flash vendors, and it is used for now just by sst. SPI NOR controller drivers changes: * intel-spi: Add support for Intel Alder Lake-P SPI serial flash. * hisi-sfc: Put child node np on error path. Arnd Bergmann (1): mtd: rawnand: tango: Remove the driver Christophe JAILLET (1): mtd: rawnand: intel: Fix an error handling path in 'ebu_dma_start()' Colin Ian King (1): mtd: remove redundant assignment to pointer eb Dan Carpenter (1): mtd: parser: imagetag: fix error codes in bcm963xx_parse_imagetag_partitions() Manivannan Sadhasivam (4): dt-bindings: mtd: partitions: Add binding for Qcom SMEM parser mtd: parsers: Add Qcom SMEM parser mtd: rawnand: qcom: Add support for Qcom SMEM parser mtd: parsers: afs: Fix freeing the part name memory in failure Mika Westerberg (1): mtd: spi-nor: intel-spi: Add support for Intel Alder Lake-P SPI serial flash Pan Bian (1): mtd: spi-nor: hisi-sfc: Put child node np on error path Rafał Miłecki (2): dt-bindings: mtd: move partition binding to its own file dt-bindings: mtd: add binding for BCM4908 partitions Richard Weinberger (2): Merge tag 'nand/for-5.12' of git://git.kernel.org/.../mtd/linux into mtd/next Merge tag 'spi-nor/for-5.12' of git://git.kernel.org/.../mtd/linux into mtd/next Takahiro Kuwano (4): mtd: spi-nor: sfdp: Fix wrong erase type bitmask for overlaid region mtd: spi-nor: sfdp: Fix last erase region marking mtd: spi-nor: core: Fix erase type discovery for overlaid region mtd: spi-nor: core: Add erase size check for erase command initialization Tudor Ambarus (2): mtd: spi-nor: Add Global Block Unlock command mtd: spi-nor: sst: Add support for Global Unlock on sst26vf Zheng Yongjun (4): mtd: rawnand: mxc: Convert comma to semicolon mtd: convert comma to semicolon mtd: st_spi_fsm: convert comma to semicolon mtd: rawnand: marvell: convert comma to semicolon yangerkun (1): mtd: phram: use div_u64_rem to stop overwrite len in phram_setup .../mtd/partitions/brcm,bcm4908-partitions.yaml| 70 ++ .../bindings/mtd/partitions/fixed-partitions.yaml | 33 +- .../bindings/mtd/partitions/partition.yaml | 47 ++ .../bindings/mtd/partitions/qcom,smem-part.yaml| 33 + drivers/mtd/devices/phram.c| 6 +- drivers/mtd/devices/st_spi_fsm.c | 2 +- drivers/mtd/maps/pci.c | 8 +- drivers/mtd/mtdswap.c | 1 - drivers/mtd/nand/raw/Kconfig | 7 - drivers/mtd/nand/raw/Makefile | 1 - drivers/mtd/nand/raw/intel-nand-controller.c | 6 +- drivers/mtd/nand/raw/marvell_nand.c| 2 +- drivers/mtd/nand/raw/mxc_nand.c| 2 +- drivers/mtd/nand/raw/qcom_nandc.c | 4 +- drivers/mtd/nand/raw/tango_nand.c | 727 - drivers/mtd/parsers/Kconfig| 8 + drivers/mtd/parsers/Makefile | 1 + drivers/mtd/parsers/afs.c | 4 +- drivers/mtd/parsers/parser_imagetag.c | 4 + drivers/mtd/parsers/qcomsmempart.c | 170 + drivers/mtd/spi-nor/controllers/hisi-sfc.c | 4 +- drivers/mtd/spi-nor/controllers/intel-spi-pci.c| 1 + drivers/mtd/spi-nor/core.c | 49 +- drivers/mtd/spi-nor/core.h | 2 + drivers/mtd/spi-nor/sfdp.c | 5 +- drivers/mtd/spi-nor/sst.c | 52 +- include/linux/mtd/spi-nor.h| 1 + 27 files changed, 457 insertions(+), 793 deletions(-) create mode 100644 Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml create mode 100644 Documentation/devicetree/bindings/mtd/partitions/partition.yaml create mode 100644
Re: [PATCH] mtd: use refcount to prevent corruption
On Sat, Feb 13, 2021 at 6:12 PM Winkler, Tomas wrote: > > Well, the trick in glubi (and other MTDs with "hotplug" support) is not to > > reject removal of the sub-device. ->_put_device() is of return type void. > > The key is grabbing a reference on the sub-device in ->_get_device() such > > that the layer below doesn't even try to remove while the MTD is in use. > > I understand that. But in that case the kernel is in the mercy of user space > to close the handle, > the whole perception here is that of hotplug that the device is physically > removed it cannot wait > for the user space to complete. What's the fix is trying to do is to bail out > gracefully. > > > > so we postpone the mtd unregister to mtd_info->_put_device() but it > > > that state we have nothing to hold on as the device is gone in > > > remove() User will fail anyway, as the underlying device is not > > > functional in that state. > > > Anyway I've tried your suggestion, the kernel is crashing, hope I > > > haven't done some silly bug. > > > > Can you point us to the affected code? > > This would help a lot to understand the issue better. > > I'm sure we can find a solution. > > Got green light on releasing the patches will send soon. I'm eager to see them. :-) As said, I'm sure we can find a nice solution. -- Thanks, //richard
Re: [PATCH] fs: ubifs: set s_uuid in super block to support ima/evm uuid options
- Ursprüngliche Mail - >> Hmm, I didn't know that helper. >> The only user in fs/ seems to be zonefs, all other filesystems do a plain >> memcpy(). >> Do you want me do a patch that converts all users in fs/ to import_uuid()? > Not sure about all fs, but in new code, like here I think it makes sense. Also > check export_uuid() and uuid_copy(). Okay. I've dropped the patch from linux-next. Juergen, please address Andy's comments and resend. Thanks, //richard
Re: [PATCH] fs: ubifs: set s_uuid in super block to support ima/evm uuid options
Andy, - Ursprüngliche Mail - >> + memcpy(>s_uuid, >uuid, sizeof(c-> > Shouldn’t it be `import_uuid()`? Hmm, I didn't know that helper. The only user in fs/ seems to be zonefs, all other filesystems do a plain memcpy(). Do you want me do a patch that converts all users in fs/ to import_uuid()? Thanks, //richard
Re: [PATCH] fs: ubifs: set s_uuid in super block to support ima/evm uuid options
On Tue, Feb 2, 2021 at 1:55 PM Juergen Borleis wrote:
>
> From: Steffen Trumtrar
>
> This is required to provide uuid based integrity functionality for:
> ima_policy (fsuuid option) and the 'evmctl' command ('--uuid' option).
>
> Signed-off-by: Steffen Trumtrar
> Signed-off-by: Oleksij Rempel
> Acked-by: Juergen Borleis
I took this patch, thanks a lot for this but I have changed the sob-chain to:
Co-developed-by: Oleksij Rempel
Co-developed-by: Juergen Borleis
Signed-off-by: Steffen Trumtrar
Namely, "patch was created by Steffen Trumtrar, Oleksij Rempel and
Juergen Borleis.
Steffen Trumtrar committed it and Juergen Borleis later sent it to the
mailing list".
Is this right?
--
Thanks,
//richard
Re: [PATCH 0/8] MUSE: Userspace backed MTD v3
- Ursprüngliche Mail - >> By single request we meant FUSE op-codes. The NAND simulator in Userspace >> will see just one call. My plan is to abstract it in libfuse. > > If libfuse abstracts it, as long as MTD only sees a single request I'm > fine :) :-) I'll prototype that in the next few weeks. Let's see whether my plans are doable to not. Thanks, //richard
Re: [PATCH 0/8] MUSE: Userspace backed MTD v3
Miquel, - Ursprüngliche Mail - >> Does in-band and OOB data need to be handled together? > > Short answer: yes. > >> If so, then two requests is not a good option. > > More detailed answer: > > There is a type of MTD device (NAND devices) which are composed, for > each page, of X in-band bytes plus Y out-of-band metadata bytes. > > Accessing either the in-band data, or the out-of-band data, or both at > the same time are all valid use cases. > > * Read operation details: > From a hardware point of view, the out-of-band data is (almost) > always retrieved when the in-band data is read because it contains > meta-data used to correct eventual bitflips. In this case, if both > areas are requested, it is highly non-efficient to do two requests, > that's why the MTD core allows to do both at the same time. > * Write operation details: > Even worse, in the write case, you *must* write both at the same > time. It is physically impossible to do one after the other (still > with actual hardware, of course). > > That is why it is preferable that MUSE will be able to access both in > a single request. By single request we meant FUSE op-codes. The NAND simulator in Userspace will see just one call. My plan is to abstract it in libfuse. Thanks, //richard
Re: [PATCH 0/8] MUSE: Userspace backed MTD v3
On Wed, Feb 10, 2021 at 11:18 AM Miklos Szeredi wrote: > > Does this more or less what you had in mind? > > Just moving the whole internal header file is not nice. I did a > mechanical public/private separation of the interface based on what > CUSE uses. Incremental patch attached. > > But this is just a start. From the big structures still left in > CUSE only uses the following fields: > > fc: .minor, max_read, max_write, rcu, release, initialized, num_waiting > fm: .fc > ff: .fm > fud: .fc > > Dealing with the last 3 is trivial: create and alloc function for the > fm, and create accessor functions for the accessed fields. Ah, ok. So the goal is that provides the bare minimum such that CUSE and MUSE can reside outside of fs/fuse? > Dealing with fc properly is probably a bit more involved, but does not > seem to be too compex at first glance. > > Do you want to take a stab at cleaning this up further? Yes. I guess for MUSE the interface needs little adaptations as well. But I won't be able to do this for the 5.12 merge window. -- Thanks, //richard
Re: [PATCH 0/8] MUSE: Userspace backed MTD v3
On Wed, Feb 10, 2021 at 11:22 AM Miklos Szeredi wrote: > > In MUSE one use case would be attaching two distinct (variable length) > > buffers to a > > single FUSE request, in both directions. > > If I read fuse_do_ioctl() correctly, it attaches always a single buffer per > > request > > but does multiple requests. > > Right. > > > In MUSE we cold go the same path and issue up to two requests. > > One for in-band and optionally a second one for the out-of-band data. > > Hmmm? > > Does in-band and OOB data need to be handled together? If so, then > two requests is not a good option. They can be handled separately. All I need to figure who to abstract this nicely in libfuse. -- Thanks, //richard
Re: [PATCH 0/8] MUSE: Userspace backed MTD v3
Miklos, - Ursprüngliche Mail - > If you look at fuse_do_ioctl() it does variable length input and > output at the same time. I guess you need something similar to that. I'm not sure whether I understand correctly. In MUSE one use case would be attaching two distinct (variable length) buffers to a single FUSE request, in both directions. If I read fuse_do_ioctl() correctly, it attaches always a single buffer per request but does multiple requests. In MUSE we cold go the same path and issue up to two requests. One for in-band and optionally a second one for the out-of-band data. Hmmm? Thanks, //richard
Re: [PATCH 0/8] MUSE: Userspace backed MTD v3
Miklos, - Ursprüngliche Mail - >> I do wonder if MUSE should go to drivers/mtd/ instead. Long term >> goal would be move CUSE to drivers/char and move the transport part of >> fuse into net/fuse leaving only the actual filesystems (fuse and >> virtiofs) under fs/. >> >> But for now just moving the minimal interface needed for MUSE into a >> separate header () would work, I guess. >> >> Do you think that would make sense? > > Yes, I'm all for having MUSE in drivers/mtd/. > > I placed MUSE initially in fs/fuse/ because CUSE was already there and muse.c > includes > fuse_i.h. So tried to be as little invasive as possible. I did a quick patch series which moves CUSE into drivers/char/ https://git.kernel.org/pub/scm/linux/kernel/git/rw/misc.git/log/?h=fs_fuse_split Does this more or less what you had in mind? If so, I'd submit these patches, rebase MUSE on them and do a v4 soon. Thanks, //richard
Re: [fuse-devel] [PATCH 0/8] MUSE: Userspace backed MTD v3
- Ursprüngliche Mail - > On 09/02/21 17:29, Richard Weinberger wrote: >> The mmap() call itself. Of course you need to touch code. >> Maybe just cuse_lowlevel.c, maybe kernel too. > > A patch had been submitted some years ago, more than once, asking for > inclusion in the kernel, but facts are that at that time nobody in the > FUSE group considered it. So much work and time lost, unfortunately. Well, I think having a generic mmap() for CUSE is hard to achieve. Thanks, //richard
Re: [fuse-devel] [PATCH 0/8] MUSE: Userspace backed MTD v3
- Ursprüngliche Mail - >> A simple (but ugly!) approach would be redirecting mmap() requests on CUSE >> devices to /dev/mem. >> hmm? > > what requests are you talking about given that at the moment the CUSE > client interface (cuse_lowlevel_ops) does not expose mmap? The mmap() call itself. Of course you need to touch code. Maybe just cuse_lowlevel.c, maybe kernel too. Thanks, //richard
Re: [fuse-devel] [PATCH 0/8] MUSE: Userspace backed MTD v3
- Ursprüngliche Mail - > for example, many existing video applications use mmap() to map the > device memory to userspace memory. Adding support for mmap() to CUSE > would allow these apps to work without any modifications with CUSE-based > device drivers other than kernel drivers. So you want to access device memory via CUSE? We have plenty of mechanisms in Linux to allow userspace accessing device memory. E.g. /dev/mem, UIO, VFIO. A simple (but ugly!) approach would be redirecting mmap() requests on CUSE devices to /dev/mem. hmm? Thanks, //richard
Re: [fuse-devel] [PATCH 0/8] MUSE: Userspace backed MTD v3
> a bit OT probably: is there any chance for you to also implement mmap() > for CUSE? That would be much appreciated. What exactly do you have in mind? I wonder about the use case. mmap() between a FUSE server and a client is more or less shared memory in userspace. Thanks, //richard
Re: [PATCH 0/8] MUSE: Userspace backed MTD v3
Miklos, - Ursprüngliche Mail - >> The core goal of MUSE is having the complexity on the userspace side and >> only a small MTD driver in kernelspace. >> While playing with different approaches I realized that FUSE offers >> everything >> we need. So MUSE is a little like CUSE except that it does not implement a >> bare character device but an MTD. > > Looks fine. I'm glad to hear that! > I do wonder if MUSE should go to drivers/mtd/ instead. Long term > goal would be move CUSE to drivers/char and move the transport part of > fuse into net/fuse leaving only the actual filesystems (fuse and > virtiofs) under fs/. > > But for now just moving the minimal interface needed for MUSE into a > separate header () would work, I guess. > > Do you think that would make sense? Yes, I'm all for having MUSE in drivers/mtd/. I placed MUSE initially in fs/fuse/ because CUSE was already there and muse.c includes fuse_i.h. So tried to be as little invasive as possible. >> >> Notes: >> -- >> >> - OOB support is currently limited. Currently MUSE has no support for >> processing >> in- and out-band in the same MTD operation. It is good enough to make JFFS2 >> happy. This limitation is because FUSE has no support more than one >> variable >> length buffer in a FUSE request. >> At least I didn’t find a good way to pass more than one buffer to a >> request. >> Maybe FUSE folks can correct me. :-) > > If you look at fuse_do_ioctl() it does variable length input and > output at the same time. I guess you need something similar to that. I'll dig into this! Thanks, //richard
Re: [PATCH v2] mtd: convert sysfs sprintf/snprintf family to sysfs_emit
On Sun, Feb 7, 2021 at 8:54 AM Jiapeng Chong wrote: > > Fix the following coccicheck warning: > > convert sysfs snprintf family to sysfs_emit in 'mtdcore.c'. The patch still does not explain why this is needed and what it fixes. :-( "A bot told me to change that line of code" is not a valid patch description. -- Thanks, //richard
Re: [PATCH 0/3] fs/efs: Follow kernel style guide
On Fri, Feb 5, 2021 at 11:26 PM Amy Parker wrote: > > On Fri, Feb 5, 2021 at 5:1 AM David Sterba wrote: > > > > On Thu, Feb 04, 2021 at 08:52:14PM -0800, Amy Parker wrote: > > > As the EFS driver is old and non-maintained, > > > > Is anybody using EFS on current kernels? There's not much point updating > > it to current coding style, deleting fs/efs is probably the best option. > > > > Wouldn't be surprised if there's a few systems out there that haven't > migrated at all. Before ripping it from the kernel source you could do a FUSE port of EFS. That way old filesystems can still get used on Linux. -- Thanks, //richard
Re: [PATCH] drivers: mtd: Better word replace a not so good word in the file mtd_blkdevs.c
- Ursprüngliche Mail - > Von: "Bhaskar Chowdhury" > An: "Miquel Raynal" > CC: "richard" , "Vignesh Raghavendra" , > "linux-mtd" , > "linux-kernel" , "Randy Dunlap" > > Gesendet: Freitag, 5. Februar 2021 14:36:39 > Betreff: Re: [PATCH] drivers: mtd: Better word replace a not so good word in > the file mtd_blkdevs.c > On 14:26 Fri 05 Feb 2021, Miquel Raynal wrote: >>Hi Bhaskar, >> >>Bhaskar Chowdhury wrote on Fri, 5 Feb 2021 >>18:11:51 +0530: >> >>> s/fucking/invite/ If you are afraid of "fucking", please replace it with "f*cking" or such. "invite" makes no sense. Thanks, //richard
Re: [PATCH] mtd: convert sysfs sprintf/snprintf family to sysfs_emit
- Ursprüngliche Mail - >> Fix the following coccicheck warning: >> >> ./drivers/mtd/mtdcore.c: WARNING: use scnprintf or sprintf. > > That's not what you do in the below change :) Well, sysfs_emit() is the sysfs equivalent of scnprintf(). But the patch fails to explain *why* it is needed. Thanks, //richard
[GIT PULL] UML fixes for 5.11-rc7
Linus, The following changes since commit 4992eb41ab1b5d08479193afdc94f9678e5ded13: Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm (2021-01-26 11:10:14 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git tags/for-linus-5.11-rc7 for you to fetch changes up to 7f3414226b58b0df0426104c8ab5e8d50ae71d11: um: time: fix initialization in time-travel mode (2021-01-26 22:11:38 +0100) This pull request contains the following bug fixes for UML: - Make sure to set a default console, otherwise ttynull is selected. - Revert initial ARCH_HAS_SET_MEMORY support, this needs more work. - Fix a regression due to ubd refactoring. - Various small fixes. Hajime Tazaki (1): um: ubd: fix command line handling of ubd Johannes Berg (6): um: return error from ioremap() um: virtio: free vu_dev only with the contained struct device Revert "um: allocate a guard page to helper threads" Revert "um: support some of ARCH_HAS_SET_MEMORY" um: fix os_idle_sleep() to not hang um: time: fix initialization in time-travel mode Thomas Meyer (2): um: stdio_console: Make preferred console um: kmsg_dumper: always dump when not tty console arch/um/Kconfig| 1 - arch/um/drivers/ubd_kern.c | 6 ++--- arch/um/drivers/virtio_uml.c | 3 ++- arch/um/include/asm/io.h | 2 +- arch/um/include/asm/pgtable.h | 3 --- arch/um/include/asm/set_memory.h | 1 - arch/um/include/shared/kern_util.h | 2 +- arch/um/kernel/kmsg_dump.c | 9 +-- arch/um/kernel/process.c | 11 +++- arch/um/kernel/time.c | 50 +-- arch/um/kernel/tlb.c | 54 -- arch/um/kernel/um_arch.c | 22 +--- arch/um/os-Linux/helper.c | 4 +-- arch/um/os-Linux/time.c| 15 ++- 14 files changed, 84 insertions(+), 99 deletions(-) delete mode 100644 arch/um/include/asm/set_memory.h
Re: [PATCH printk-rework 09/12] um: synchronize kmsg_dumper
John, - Ursprüngliche Mail - >>> The line was previously synchronized for the kmsg_dump_get_line() >>> call. But yes, it was not synchronized after the call, which is a bug if >>> the dump is triggered on multiple CPUs simultaneously. The commit >>> message should also mention that it is handling that bug. >>> IMHO, this patch is not needed. >>> >>> I am not familiar enough with ARCH=um to know if dumps can be triggered >>> on multiple CPUs simultaneously. Perhaps ThomasM or Richard can chime in >>> here. >> >> Well, uml has no SMP support, so no parallel dumps. :-) > > When I grep through arch/um, I see many uses of spinlocks. This would > imply that uml at least has some sort of preemption model where they are > needed. Dumps can trigger from any context and from multiple paths. > > If you are sure that this is no concern, then I will drop this patch > from my series. Currently uml selects ARCH_NO_PREEMPT, so no preemtion too. We have spinlocks at obvious places in arch/um/ just to be ready if uml supports SMP at some point. Does your patch have drawbacks right now for uml? If not, I'd suggest to keep it. Thanks, //richard
Re: [PATCH printk-rework 09/12] um: synchronize kmsg_dumper
John,
- Ursprüngliche Mail -
> Von: "John Ogness"
> An: "Petr Mladek"
> CC: "Sergey Senozhatsky" , "Sergey
> Senozhatsky" ,
> "Steven Rostedt" , "tglx" ,
> "linux-kernel" ,
> "Thomas Meyer" , "richard"
> Gesendet: Montag, 1. Februar 2021 17:51:14
> Betreff: Re: [PATCH printk-rework 09/12] um: synchronize kmsg_dumper
> (Added CC: Thomas Meyer, Richard Weinberger)
>
> On 2021-02-01, Petr Mladek wrote:
>>> In preparation for removing printk's @logbuf_lock, dumpers that have
>>> assumed to be protected against parallel calls must provide their own
>>> synchronization. Add a locally static spinlock to synchronize the
>>> kmsg_dump call and temporary buffer usage.
>>>
>>> Signed-off-by: John Ogness
>>> ---
>>> arch/um/kernel/kmsg_dump.c | 8
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/arch/um/kernel/kmsg_dump.c b/arch/um/kernel/kmsg_dump.c
>>> index f38349ad00ea..173999422ed8 100644
>>> --- a/arch/um/kernel/kmsg_dump.c
>>> +++ b/arch/um/kernel/kmsg_dump.c
>>> @@ -1,5 +1,6 @@
>>> // SPDX-License-Identifier: GPL-2.0
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -9,8 +10,10 @@ static void kmsg_dumper_stdout(struct kmsg_dumper *dumper,
>>> enum kmsg_dump_reason reason,
>>> struct kmsg_dumper_iter *iter)
>>> {
>>> + static DEFINE_SPINLOCK(lock);
>>> static char line[1024];
>>> struct console *con;
>>> + unsigned long flags;
>>> size_t len = 0;
>>>
>>> /* only dump kmsg when no console is available */
>>> @@ -25,11 +28,16 @@ static void kmsg_dumper_stdout(struct kmsg_dumper
>>> *dumper,
>>> if (con)
>>> return;
>>>
>>> + if (!spin_trylock_irqsave(, flags))
>>> + return;
>>> +
>>> printf("kmsg_dump:\n");
>>> while (kmsg_dump_get_line(iter, true, line, sizeof(line), )) {
>>> line[len] = '\0';
>>> printf("%s", line);
>>> }
>>> +
>>> + spin_unlock_irqrestore(, flags);
>>
>> What exactly is synchronized here, please?
>> Access to @line buffer or @iter or both?
>
> @line is being synchronized. @iter does not require synchronization.
>
>> It looks to me that the access to @line buffer was not synchronized
>> before. kmsg_dump_get_line() used a lock internally but
>> it was not synchronized with the later printf("%s", line);
>
> The line was previously synchronized for the kmsg_dump_get_line()
> call. But yes, it was not synchronized after the call, which is a bug if
> the dump is triggered on multiple CPUs simultaneously. The commit
> message should also mention that it is handling that bug.
>
>> IMHO, this patch is not needed.
>
> I am not familiar enough with ARCH=um to know if dumps can be triggered
> on multiple CPUs simultaneously. Perhaps ThomasM or Richard can chime in
> here.
Well, uml has no SMP support, so no parallel dumps. :-)
Thanks,
//richard
Re: [PATCH 0/8] MUSE: Userspace backed MTD v3
*friendly FUSE maintainer ping* :-) On Mon, Jan 25, 2021 at 12:24 AM Richard Weinberger wrote: > > I'm happy to announce the first non-RFC version of this patch set. > Over the xmas holidays I found some time to experiment with various userspace > implementations of MTDs and gave the kernel side more fine-tuning. > > Rationale: > -- > > When working with flash devices a common task is emulating them to run various > tests or inspect dumps from real hardware. To achieve that we have plenty of > emulators in the MTD subsystem: mtdram, block2mtd, nandsim. > > Each of them implements an ad-hoc MTD and have various drawbacks. > Over the last years some developers tried to extend them but these attempts > often got rejected because they added just more adhoc feature instead of > addressing overall problems. > > MUSE is a novel approach to address the need of advanced MTD emulators. > Advanced means in this context supporting different (vendor specific) image > formats, different ways for fault injection (fuzzing) and recoding/replaying > IOs to emulate power cuts. > > The core goal of MUSE is having the complexity on the userspace side and > only a small MTD driver in kernelspace. > While playing with different approaches I realized that FUSE offers everything > we need. So MUSE is a little like CUSE except that it does not implement a > bare character device but an MTD. > > Notes: > -- > > - OOB support is currently limited. Currently MUSE has no support for > processing > in- and out-band in the same MTD operation. It is good enough to make JFFS2 > happy. This limitation is because FUSE has no support more than one variable > length buffer in a FUSE request. > At least I didn’t find a good way to pass more than one buffer to a request. > Maybe FUSE folks can correct me. :-) > > - Every MTD read/write operation maps 1:1 to a MUSE_READ/WRITE opcode. > Since FUSE requests are not cheap, the amount of read/written bytes in a MTD > operation as a huge impact on the performance. Especially when NOR style > MTDs > are implemented in userspace a large writebufsize should be requested to > gain > good write performance. > On the other hand, MTD operations with lengths larger than writesize are > *not* > split up into multiple MUSE_READ/WRITE requests. This means that userspace > has to split them manually when doing power-cut emulation. > > - MUSE is not super fast. On my i5 workstation nandsim is almost twice as fast > as a NAND flash in userspace. But MUSE is still magnitudes faster than any > real world MTD out there. So it is good enough for the use cases I have in > mind. > > Changelog: > -- > > Changes since v2 (RFC): > - OOB support > - MUSE_READ/WRITE opcodes are no longer a min IO MTD unit > - MTD partitions support via mtdparts string > - More code cleanup > - Code rebased to 5.11-rc4 > > Changes since v1 (RFC): > - Rewrote IO path, fuse_direct_io() is no longer used. > Instead of cheating fuse_direct_io() use custom ops to implement > reading and writing. That way MUSE no longer needs a dummy file object > nor a fuse file object. > In MTD all IO is synchronous and operations on kernel buffers, this > makes IO processing simple for MUSE. > - Support for bad blocks. > - No more (ab)use of FUSE ops such as FUSE_FSYNC. > - Major code cleanup. > > This series can also be found at: > git://git.kernel.org/pub/scm/linux/kernel/git/rw/misc.git muse_v3 > > Richard Weinberger (8): > fuse: Export fuse_simple_request > fuse: Export IO helpers > fuse: Make cuse_parse_one a common helper > mtd: Add MTD_MUSE flag > mtd: Allow passing a custom cmdline to cmdline line parser > fuse: Add MUSE specific defines FUSE interface > fuse: Implement MUSE - MTD in userspace > MAINTAINERS: Add entry for MUSE > > Documentation/ABI/testing/sysfs-class-mtd |8 + > MAINTAINERS |7 + > drivers/mtd/parsers/cmdlinepart.c | 73 +- > fs/fuse/Kconfig | 15 + > fs/fuse/Makefile |2 + > fs/fuse/cuse.c| 58 +- > fs/fuse/dev.c |1 + > fs/fuse/file.c| 16 +- > fs/fuse/fuse_i.h | 18 + > fs/fuse/helper.c | 70 ++ > fs/fuse/muse.c| 1086 + > include/linux/mtd/partitions.h|2 + > include/uapi/linux/fuse.h | 76 ++ > include/uapi/mtd/mtd-abi.h|1 + > 14 files changed, 1346 insertions(+), 87 deletions(-) > create mode 100644 fs/fuse/helper.c > create mode 100644 fs/fuse/muse.c > > -- > 2.26.2 > -- Thanks, //richard
Re: [PATCH] mtd: use refcount to prevent corruption
Tomas, - Ursprüngliche Mail - >> As Richard was saying, we are really open to enhance MTD refcounting. >> >> However, the issue you are facing is, IMHO, not related to MTD but to MFD. >> There should be a way to avoid MFD to vanish by taking a reference of it >> through mtd->_get_device(). I don't think addressing the case where MFD >> vanishes while MTD (as a user) is still active is the right approach. > > I think it won't work because MFD sub-driver remove() is called and it must > succeed because the main device is not accessible unlike glueubi which just > returns -EBUSY. Well, the trick in glubi (and other MTDs with "hotplug" support) is not to reject removal of the sub-device. ->_put_device() is of return type void. The key is grabbing a reference on the sub-device in ->_get_device() such that the layer below doesn't even try to remove while the MTD is in use. > so we postpone the mtd unregister to mtd_info->_put_device() but it that > state > we have nothing to hold > on as the device is gone in remove() > User will fail anyway, as the underlying device is not functional in that > state. > Anyway I've tried your suggestion, the kernel is crashing, hope I haven't done > some silly bug. Can you point us to the affected code? This would help a lot to understand the issue better. I'm sure we can find a solution. Thanks, //richard
Re: [PATCH] jffs2: check the validity of dstlen in jffs2_zlib_compress()
- Ursprüngliche Mail - > Von: "Joakim Tjernlund" > An: "menglong8 dong" , "David Woodhouse" > > CC: "yang yang29" , "stable" > , "linux-kernel" > , "richard" , "linux-mtd" > > Gesendet: Donnerstag, 28. Januar 2021 12:17:34 > Betreff: Re: [PATCH] jffs2: check the validity of dstlen in > jffs2_zlib_compress() > On Thu, 2021-01-28 at 02:55 -0800, menglong8.d...@gmail.com wrote: >> From: Yang Yang >> >> KASAN reports a BUG when download file in jffs2 filesystem.It is >> because when dstlen == 1, cpage_out will write array out of bounds. >> Actually, data will not be compressed in jffs2_zlib_compress() if >> data's length less than 4. > > Ouch, data corruption will ensue. Good find! > I think this needs to go to stable as well. Indeed! Do you know whether this is a regression? Seems to be like that since ever. Thanks, //richard
Re: [PATCH] mtd: use refcount to prevent corruption
Tomas, - Ursprüngliche Mail - >> >> Can you please explain a little more what devices are involved? >> >> Does it implement _get_device() and _put_device()? >> > No this is not connected to those handlers of the underlying device >> > and those won't help. >> > I have a spi device provided by MFD framework so it can go away anytime. >> >> Can it go away physically or just in software? > Software, but since this is mfd it's basically hotplug. The kernel is crashing > when I simulate hardware failure. >> >> Usually the pattern is that you make sure in the device driver that nobody >> can >> orphan the MTD while it is in use. >> e.g. drivers/mtd/ubi/gluebi.c does so. In _get_device() it grabs a reference >> on >> the underlying UBI volume to make sure it cannot go away while the MTD (on >> top of UBI) is in use. > > I can try that if it helps, because we are simulating possible lower level > crash. > In an case I believe that the proper refcouting is much more robust solution, > than the current one. > I'd appreciate if someone can review the actual implementation. This happens right now, I try to understand why exactly the current way is not good in enough. :-) Your approach makes sure that the MTD itself does not go away while it has users but how does this help in the case where the underlying MFD just vanishes? The MTD can be in use and the MFD can go away while e.g. mtd_read() or such takes place. Thanks, //richard
Re: [PATCH] mtd: use refcount to prevent corruption
- Ursprüngliche Mail - >> > When underlying device is removed mtd core will crash in case user >> > space is still holding an open handle to a mtd device node. >> > A proper refcounting is needed so device is release only when a >> > partition has no active users. The current simple counter is not >> > sufficient. >> >> Can you please explain a little more what devices are involved? >> Does it implement _get_device() and _put_device()? > No this is not connected to those handlers of the underlying device and those > won't help. > I have a spi device provided by MFD framework so it can go away anytime. Can it go away physically or just in software? Usually the pattern is that you make sure in the device driver that nobody can orphan the MTD while it is in use. e.g. drivers/mtd/ubi/gluebi.c does so. In _get_device() it grabs a reference on the underlying UBI volume to make sure it cannot go away while the MTD (on top of UBI) is in use. Thanks, //richard
Re: [PATCH] mtd: use refcount to prevent corruption
Tomas, - Ursprüngliche Mail - > Von: "Tomas Winkler" > An: "Miquel Raynal" , "richard" , > "Vignesh Raghavendra" , > "linux-mtd" , "linux-kernel" > > CC: "Tomas Winkler" > Gesendet: Mittwoch, 27. Januar 2021 21:03:19 > Betreff: [PATCH] mtd: use refcount to prevent corruption > When underlying device is removed mtd core will crash > in case user space is still holding an open handle to a mtd device node. > A proper refcounting is needed so device is release only when a > partition has no active users. The current simple counter is not > sufficient. Can you please explain a little more what devices are involved? Does it implement _get_device() and _put_device()? Thanks, //richard
Re: [PATCH 3/4] ubifs: Update directory size when creating whiteouts
On Mon, Jan 25, 2021 at 2:12 AM Zhihao Cheng wrote: > > 在 2021/1/23 10:45, Zhihao Cheng 写道: > > >> @@ -430,6 +433,7 @@ static int do_tmpfile(struct inode *dir, struct > >> dentry *dentry, > >> return 0; > >> out_cancel: > Still one question: > > Does this need a judgment? Like this, The idea was that in the !whiteout case, sz_change is always 0. -- Thanks, //richard
[PATCH 7/8] fuse: Implement MUSE - MTD in userspace
MUSE allows implementing a MTD in userspace.
So far userspace has control over mtd_read, mtd_write, mtd_erase,
mtd_block_isbad, mtd_block_markbad, and mtd_sync.
It can also set the various MTD parameters such as
name, flags, site, writesize and erasesize.
That way advanced simulators for many types of flashes
can be implemented in userspace such that the complexity
is in userspace. Furthermore at some point we can depricate
ad-hoc in-kernel MTD simulators such as nandsim.
Signed-off-by: Richard Weinberger
---
Documentation/ABI/testing/sysfs-class-mtd |8 +
fs/fuse/Kconfig | 11 +
fs/fuse/Makefile |1 +
fs/fuse/muse.c| 1086 +
4 files changed, 1106 insertions(+)
create mode 100644 fs/fuse/muse.c
diff --git a/Documentation/ABI/testing/sysfs-class-mtd
b/Documentation/ABI/testing/sysfs-class-mtd
index 3bc7c0a95c92..1aa8d7855f9c 100644
--- a/Documentation/ABI/testing/sysfs-class-mtd
+++ b/Documentation/ABI/testing/sysfs-class-mtd
@@ -240,3 +240,11 @@ Contact: linux-...@lists.infradead.org
Description:
Number of bytes available for a client to place data into
the out of band area.
+
+What: /sys/class/mtd/mtdX/muse_pid
+Date: January 2021
+KernelVersion: 5.12
+Contact: linux-...@lists.infradead.org
+Description:
+ If this MTD is a userspace driven MTD, muse_pid shows the PID
+ of the process behind it at creation time.
diff --git a/fs/fuse/Kconfig b/fs/fuse/Kconfig
index 9c8cc1e7b3a5..2fc63dc18a53 100644
--- a/fs/fuse/Kconfig
+++ b/fs/fuse/Kconfig
@@ -56,3 +56,14 @@ config FUSE_DAX
If you want to allow mounting a Virtio Filesystem with the "dax"
option, answer Y.
+
+config MUSE
+ tristate "Memory Technology Device (MTD) in Userspace support"
+ depends on FUSE_FS
+ select FUSE_HELPER
+ select MTD
+ help
+ This FUSE extension allows an MTD to be implemented in userspace.
+
+ If you want to develop or use a userspace MTD based on MUSE,
+ answer Y or M.
diff --git a/fs/fuse/Makefile b/fs/fuse/Makefile
index 7a5768cce6be..67a7af3fb047 100644
--- a/fs/fuse/Makefile
+++ b/fs/fuse/Makefile
@@ -6,6 +6,7 @@
obj-$(CONFIG_FUSE_FS) += fuse.o
obj-$(CONFIG_CUSE) += cuse.o
obj-$(CONFIG_VIRTIO_FS) += virtiofs.o
+obj-$(CONFIG_MUSE) += muse.o
fuse-y := dev.o dir.o file.o inode.o control.o xattr.o acl.o readdir.o
fuse-$(CONFIG_FUSE_DAX) += dax.o
diff --git a/fs/fuse/muse.c b/fs/fuse/muse.c
new file mode 100644
index ..43f8e400abcd
--- /dev/null
+++ b/fs/fuse/muse.c
@@ -0,0 +1,1086 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MUSE: MTD in userspace
+ * Copyright (C) 2021 sigma star gmbh
+ * Author: Richard Weinberger
+ */
+
+#define pr_fmt(fmt) "MUSE: " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "fuse_i.h"
+
+/*
+ * struct muse_conn - MUSE connection object.
+ *
+ * @fm: FUSE mount object.
+ * @fc: FUSE connection object.
+ * @mtd: MTD object.
+ * @creator: PID of the creating process.
+ * @want_exit: Denotes that userspace is disconncted and the MTD shall be
+ * removed as soon the last user vanishes.
+ * @mtd_registered: true if this MUSE connection sucessfully registered an MTD.
+ * @mtd_exit_work: work context for async MTD removal.
+ * @ref_mutex: synchronizes @want_exit and MTD put/get.
+ *
+ * Describes a connection to a userspace server.
+ * Each connection implements a single (master) MTD.
+ *
+ */
+struct muse_conn {
+ struct fuse_mount fm;
+ struct fuse_conn fc;
+ struct mtd_info mtd;
+ pid_t creator;
+ bool want_exit;
+ bool mtd_registered;
+ struct work_struct mtd_exit_work;
+ struct mutex ref_mutex;
+};
+
+/*
+ * struct muse_init_args - MUSE init arguments.
+ *
+ * @ap: FUSE argument pages object.
+ * @in: MUSE init parameters sent to userspace.
+ * @out: MUSE init parameters sent from userspace.
+ * @page: A single pages used to pass stringy key-value parameters
+ *from userspace to this module.
+ * @desc: FUSE page description object.
+ *
+ * Descripes arguments used by the MUSE_INIT FUSE opcode.
+ *
+ */
+struct muse_init_args {
+ struct fuse_args_pages ap;
+ struct muse_init_in in;
+ struct muse_init_out out;
+ struct page *page;
+ struct fuse_page_desc desc;
+};
+
+/*
+ * struct muse_mtd_create_req - MUSE MTD creation request.
+ *
+ * @name: Name of the (master) MTD, usually something like muse-.
+ * @type: Type of the MTD, one out of MTD_RAM, MTD_ROM, MTD_NORFLASH,
+ *MTD_NANDFLASH, MTD_DATAFLASH or MTD_MLCNANDFLASH.
+ * @size: Total size of the MTD.
+ * @writesize: writesize of the MTD.
+ * @writebufsize: writebufsize of the MTD, usually euqal to @writesize.
+ * @erasesize: erasesize of the MTD.
+ * @oobsize: To
[PATCH 6/8] fuse: Add MUSE specific defines FUSE interface
Raise the FUSE API minor version to 34 and add all
MUSE specific operations and data structures.
MUSE_INIT: Initialize a new connection and installs the MTD
MUSE_ERASE: Erases a block
MUSE_READ: Reads a page with or without OOB
MUSE_WRITE: Writes a page with or without OOB
MUSE_MARKBAD: Marks a block as bad
MUSE_ISBAD: Checks whether a block is bad
MUSE_SYNC: Flushes all cached data
Signed-off-by: Richard Weinberger
---
include/uapi/linux/fuse.h | 76 +++
1 file changed, 76 insertions(+)
diff --git a/include/uapi/linux/fuse.h b/include/uapi/linux/fuse.h
index 98ca64d1beb6..1c8fa9e42e73 100644
--- a/include/uapi/linux/fuse.h
+++ b/include/uapi/linux/fuse.h
@@ -179,6 +179,10 @@
* 7.33
* - add FUSE_HANDLE_KILLPRIV_V2, FUSE_WRITE_KILL_SUIDGID, FATTR_KILL_SUIDGID
* - add FUSE_OPEN_KILL_SUIDGID
+ *
+ * 7.34
+ * - add support for MUSE: MUSE_INIT, MUSE_ERASE, MUSE_READ, MUSE_WRITE,
+ *MUSE_MARKBAD, MUSE_ISBAD and MUSE_SYNC
*/
#ifndef _LINUX_FUSE_H
@@ -503,6 +507,15 @@ enum fuse_opcode {
/* CUSE specific operations */
CUSE_INIT = 4096,
+ /* MUSE specific operations */
+ MUSE_INIT = 8192,
+ MUSE_ERASE = 8193,
+ MUSE_READ = 8194,
+ MUSE_WRITE = 8195,
+ MUSE_MARKBAD= 8196,
+ MUSE_ISBAD = 8197,
+ MUSE_SYNC = 8198,
+
/* Reserved opcodes: helpful to detect structure endian-ness */
CUSE_INIT_BSWAP_RESERVED= 1048576, /* CUSE_INIT << 8 */
FUSE_INIT_BSWAP_RESERVED= 436207616,/* FUSE_INIT << 24 */
@@ -956,4 +969,67 @@ struct fuse_removemapping_one {
#define FUSE_REMOVEMAPPING_MAX_ENTRY \
(PAGE_SIZE / sizeof(struct fuse_removemapping_one))
+#define MUSE_INIT_INFO_MAX 4096
+
+struct muse_init_in {
+ uint32_tfuse_major;
+ uint32_tfuse_minor;
+};
+
+struct muse_init_out {
+ uint32_tfuse_major;
+ uint32_tfuse_minor;
+ uint32_tmax_read;
+ uint32_tmax_write;
+};
+
+struct muse_erase_in {
+ uint64_taddr;
+ uint64_tlen;
+};
+
+#define MUSE_IO_INBAND (1 << 0)
+#define MUSE_IO_OOB_AUTO (1 << 1)
+#define MUSE_IO_OOB_PLACE (1 << 2)
+#define MUSE_IO_RAW(1 << 3)
+
+struct muse_read_in {
+ uint64_taddr;
+ uint64_tlen;
+ uint32_tflags;
+ uint32_tpadding;
+};
+
+struct muse_read_out {
+ uint64_tlen;
+ uint32_tsoft_error;
+ uint32_tpadding;
+};
+
+struct muse_write_in {
+ uint64_taddr;
+ uint64_tlen;
+ uint32_tflags;
+ uint32_tpadding;
+};
+
+struct muse_write_out {
+ uint64_tlen;
+ uint32_tsoft_error;
+ uint32_tpadding;
+};
+
+struct muse_markbad_in {
+ uint64_taddr;
+};
+
+struct muse_isbad_in {
+ uint64_taddr;
+};
+
+struct muse_isbad_out {
+ uint32_tresult;
+ uint32_tpadding;
+};
+
#endif /* _LINUX_FUSE_H */
--
2.26.2
[PATCH 1/8] fuse: Export fuse_simple_request
MUSE will use this function to issue requests,
so export it.
Signed-off-by: Richard Weinberger
---
fs/fuse/dev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index 588f8d1240aa..8b7209537683 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -522,6 +522,7 @@ ssize_t fuse_simple_request(struct fuse_mount *fm, struct
fuse_args *args)
return ret;
}
+EXPORT_SYMBOL_GPL(fuse_simple_request);
static bool fuse_request_queue_background(struct fuse_req *req)
{
--
2.26.2
[PATCH 8/8] MAINTAINERS: Add entry for MUSE
Since MUSE lives in fs/fuse/, make sure that linux-mtd@ is CC'ed on patches such that MTD related aspects of changes can be reviewed. Signed-off-by: Richard Weinberger --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index f79ec98bbb29..dabd9fd2e5e4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12151,6 +12151,13 @@ L: linux-...@vger.kernel.org S: Maintained F: drivers/usb/musb/ +MUSE: MTD IN USERSPACE DRIVER +M: Richard Weinberger +L: linux-...@lists.infradead.org +L: linux-fsde...@vger.kernel.org +S: Maintained +F: fs/fuse/muse.c + MXL301RF MEDIA DRIVER M: Akihiro Tsukada L: linux-me...@vger.kernel.org -- 2.26.2
[PATCH 4/8] mtd: Add MTD_MUSE flag
This flag will be set if an MTD is implemeted in userspace
using MUSE.
Signed-off-by: Richard Weinberger
---
include/uapi/mtd/mtd-abi.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/mtd/mtd-abi.h b/include/uapi/mtd/mtd-abi.h
index 65b9db936557..2ad2217e3a96 100644
--- a/include/uapi/mtd/mtd-abi.h
+++ b/include/uapi/mtd/mtd-abi.h
@@ -105,6 +105,7 @@ struct mtd_write_req {
#define MTD_NO_ERASE 0x1000 /* No erase necessary */
#define MTD_POWERUP_LOCK 0x2000 /* Always locked after reset */
#define MTD_SLC_ON_MLC_EMULATION 0x4000/* Emulate SLC behavior on MLC
NANDs */
+#define MTD_MUSE 0x8000 /* This MTD is implemented in userspace
*/
/* Some common devices / combinations of capabilities */
#define MTD_CAP_ROM0
--
2.26.2
[PATCH 5/8] mtd: Allow passing a custom cmdline to cmdline line parser
The cmdline parser uses usually the mtdparts string from the kernel cmdline.
For special purpose MTDs like MUSE it is useful to pass a custom
mtdparts string to the parser. This allows the MTD simulator in
userspace directly passing a mtdparts string and the new MTD
partitioned.
To achieve this, struct mtd_part_parser_data now has a mtdparts pointer
where a custom mtdparts string can be provided, it overrules the kernel
cmdline.
Since the cmdline parser stays for ever in the kernel, the memory lifecycle
had to be changed a little such that custom mtdparts string don't result
in memory leaks.
Signed-off-by: Richard Weinberger
---
drivers/mtd/parsers/cmdlinepart.c | 73 ---
include/linux/mtd/partitions.h| 2 +
2 files changed, 58 insertions(+), 17 deletions(-)
diff --git a/drivers/mtd/parsers/cmdlinepart.c
b/drivers/mtd/parsers/cmdlinepart.c
index 0ddff1a4b51f..f0fe87267380 100644
--- a/drivers/mtd/parsers/cmdlinepart.c
+++ b/drivers/mtd/parsers/cmdlinepart.c
@@ -64,7 +64,7 @@ struct cmdline_mtd_partition {
};
/* mtdpart_setup() parses into here */
-static struct cmdline_mtd_partition *partitions;
+static struct cmdline_mtd_partition *cmdline_partitions;
/* the command line passed to mtdpart_setup() */
static char *mtdparts;
@@ -138,9 +138,6 @@ static struct mtd_partition * newpart(char *s,
name_len = 13; /* Partition_000 */
}
- /* record name length for memory allocation later */
- extra_mem_size += name_len + 1;
-
/* test for options */
if (strncmp(s, "ro", 2) == 0) {
mask_flags |= MTD_WRITEABLE;
@@ -192,12 +189,17 @@ static struct mtd_partition * newpart(char *s,
parts[this_part].offset = offset;
parts[this_part].mask_flags = mask_flags;
parts[this_part].add_flags = add_flags;
+
+ /*
+* Will get free()'ed in ->cleanup()
+*/
if (name)
- strlcpy(extra_mem, name, name_len + 1);
+ parts[this_part].name = kmemdup_nul(name, name_len, GFP_KERNEL);
else
- sprintf(extra_mem, "Partition_%03d", this_part);
- parts[this_part].name = extra_mem;
- extra_mem += name_len + 1;
+ parts[this_part].name = kasprintf(GFP_KERNEL, "Partition_%03d",
this_part);
+
+ if (!parts[this_part].name)
+ return ERR_PTR(-ENOMEM);
dbg(("partition %d: name <%s>, offset %llx, size %llx, mask flags %x\n",
this_part, parts[this_part].name, parts[this_part].offset,
@@ -217,7 +219,7 @@ static struct mtd_partition * newpart(char *s,
/*
* Parse the command line.
*/
-static int mtdpart_setup_real(char *s)
+static int mtdpart_setup_real(char *s, struct cmdline_mtd_partition
**partitions)
{
cmdline_parsed = 1;
@@ -301,8 +303,8 @@ static int mtdpart_setup_real(char *s)
strlcpy(this_mtd->mtd_id, mtd_id, mtd_id_len + 1);
/* link into chain */
- this_mtd->next = partitions;
- partitions = this_mtd;
+ this_mtd->next = *partitions;
+ *partitions = this_mtd;
dbg(("mtdid=<%s> num_parts=<%d>\n",
this_mtd->mtd_id, this_mtd->num_parts));
@@ -335,13 +337,23 @@ static int parse_cmdline_partitions(struct mtd_info
*master,
struct mtd_part_parser_data *data)
{
unsigned long long offset;
- int i, err;
+ int i, err, num_parts;
struct cmdline_mtd_partition *part;
const char *mtd_id = master->name;
+ struct cmdline_mtd_partition *parsed_parts = cmdline_partitions;
+ bool free_parts = false;
+
+ if (data && data->mtdparts) {
+ parsed_parts = NULL;
- /* parse command line */
- if (!cmdline_parsed) {
- err = mtdpart_setup_real(cmdline);
+ err = mtdpart_setup_real(data->mtdparts, _parts);
+ if (err)
+ return err;
+
+ free_parts = true;
+ } else if (!cmdline_parsed) {
+ /* parse command line */
+ err = mtdpart_setup_real(cmdline, _partitions);
if (err)
return err;
}
@@ -350,7 +362,7 @@ static int parse_cmdline_partitions(struct mtd_info *master,
* Search for the partition definition matching master->name.
* If master->name is not set, stop at first partition definition.
*/
- for (part = partitions; part; part = part->next) {
+ for (part = parsed_parts; part; part = part->next) {
if ((!mtd_id) || (!strcmp(part->mtd_id, mtd_id)))
break;
}
@@ -384,12 +396,38 @@ static int parse_cmdline_partitions(struct mtd_info
*master,
}
}
+ /*
+
[PATCH 2/8] fuse: Export IO helpers
MUSE will use this functions in its IO path,
so export them.
Signed-off-by: Richard Weinberger
---
fs/fuse/file.c | 16 +++-
fs/fuse/fuse_i.h | 16
2 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index 8cccecb55fb8..d41660b7f5bc 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -20,8 +20,8 @@
#include
#include
-static struct page **fuse_pages_alloc(unsigned int npages, gfp_t flags,
- struct fuse_page_desc **desc)
+struct page **fuse_pages_alloc(unsigned int npages, gfp_t flags,
+ struct fuse_page_desc **desc)
{
struct page **pages;
@@ -31,6 +31,7 @@ static struct page **fuse_pages_alloc(unsigned int npages,
gfp_t flags,
return pages;
}
+EXPORT_SYMBOL_GPL(fuse_pages_alloc);
static int fuse_send_open(struct fuse_mount *fm, u64 nodeid, struct file *file,
int opcode, struct fuse_open_out *outargp)
@@ -1356,17 +1357,6 @@ static inline void fuse_page_descs_length_init(struct
fuse_page_desc *descs,
descs[i].length = PAGE_SIZE - descs[i].offset;
}
-static inline unsigned long fuse_get_user_addr(const struct iov_iter *ii)
-{
- return (unsigned long)ii->iov->iov_base + ii->iov_offset;
-}
-
-static inline size_t fuse_get_frag_size(const struct iov_iter *ii,
- size_t max_size)
-{
- return min(iov_iter_single_seg_count(ii), max_size);
-}
-
static int fuse_get_user_pages(struct fuse_args_pages *ap, struct iov_iter *ii,
size_t *nbytesp, int write,
unsigned int max_pages)
diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h
index 7c4b8cb93f9f..8c56a3fd2c4e 100644
--- a/fs/fuse/fuse_i.h
+++ b/fs/fuse/fuse_i.h
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
/** Default max number of pages that can be used in a single read request */
#define FUSE_DEFAULT_MAX_PAGES_PER_REQ 32
@@ -871,6 +872,17 @@ static inline bool fuse_is_bad(struct inode *inode)
return unlikely(test_bit(FUSE_I_BAD, _fuse_inode(inode)->state));
}
+static inline unsigned long fuse_get_user_addr(const struct iov_iter *ii)
+{
+ return (unsigned long)ii->iov->iov_base + ii->iov_offset;
+}
+
+static inline size_t fuse_get_frag_size(const struct iov_iter *ii,
+ size_t max_size)
+{
+ return min(iov_iter_single_seg_count(ii), max_size);
+}
+
/** Device operations */
extern const struct file_operations fuse_dev_operations;
@@ -1213,4 +1225,8 @@ void fuse_dax_inode_cleanup(struct inode *inode);
bool fuse_dax_check_alignment(struct fuse_conn *fc, unsigned int
map_alignment);
void fuse_dax_cancel_work(struct fuse_conn *fc);
+/* file.c */
+struct page **fuse_pages_alloc(unsigned int npages, gfp_t flags,
+ struct fuse_page_desc **desc);
+
#endif /* _FS_FUSE_I_H */
--
2.26.2
[PATCH 3/8] fuse: Make cuse_parse_one a common helper
This function will be used by MUSE too, let's share it.
Signed-off-by: Richard Weinberger
---
fs/fuse/Kconfig | 4 +++
fs/fuse/Makefile | 1 +
fs/fuse/cuse.c | 58 +--
fs/fuse/fuse_i.h | 2 ++
fs/fuse/helper.c | 70
5 files changed, 78 insertions(+), 57 deletions(-)
create mode 100644 fs/fuse/helper.c
diff --git a/fs/fuse/Kconfig b/fs/fuse/Kconfig
index 40ce9a1c12e5..9c8cc1e7b3a5 100644
--- a/fs/fuse/Kconfig
+++ b/fs/fuse/Kconfig
@@ -18,9 +18,13 @@ config FUSE_FS
If you want to develop a userspace FS, or if you want to use
a filesystem based on FUSE, answer Y or M.
+config FUSE_HELPER
+ def_bool n
+
config CUSE
tristate "Character device in Userspace support"
depends on FUSE_FS
+ select FUSE_HELPER
help
This FUSE extension allows character devices to be
implemented in userspace.
diff --git a/fs/fuse/Makefile b/fs/fuse/Makefile
index 8c7021fb2cd4..7a5768cce6be 100644
--- a/fs/fuse/Makefile
+++ b/fs/fuse/Makefile
@@ -9,5 +9,6 @@ obj-$(CONFIG_VIRTIO_FS) += virtiofs.o
fuse-y := dev.o dir.o file.o inode.o control.o xattr.o acl.o readdir.o
fuse-$(CONFIG_FUSE_DAX) += dax.o
+fuse-$(CONFIG_FUSE_HELPER) += helper.o
virtiofs-y := virtio_fs.o
diff --git a/fs/fuse/cuse.c b/fs/fuse/cuse.c
index 45082269e698..fe8515844064 100644
--- a/fs/fuse/cuse.c
+++ b/fs/fuse/cuse.c
@@ -199,62 +199,6 @@ struct cuse_devinfo {
const char *name;
};
-/**
- * cuse_parse_one - parse one key=value pair
- * @pp: i/o parameter for the current position
- * @end: points to one past the end of the packed string
- * @keyp: out parameter for key
- * @valp: out parameter for value
- *
- * *@pp points to packed strings - "key0=val0\0key1=val1\0" which ends
- * at @end - 1. This function parses one pair and set *@keyp to the
- * start of the key and *@valp to the start of the value. Note that
- * the original string is modified such that the key string is
- * terminated with '\0'. *@pp is updated to point to the next string.
- *
- * RETURNS:
- * 1 on successful parse, 0 on EOF, -errno on failure.
- */
-static int cuse_parse_one(char **pp, char *end, char **keyp, char **valp)
-{
- char *p = *pp;
- char *key, *val;
-
- while (p < end && *p == '\0')
- p++;
- if (p == end)
- return 0;
-
- if (end[-1] != '\0') {
- pr_err("info not properly terminated\n");
- return -EINVAL;
- }
-
- key = val = p;
- p += strlen(p);
-
- if (valp) {
- strsep(, "=");
- if (!val)
- val = key + strlen(key);
- key = strstrip(key);
- val = strstrip(val);
- } else
- key = strstrip(key);
-
- if (!strlen(key)) {
- pr_err("zero length info key specified\n");
- return -EINVAL;
- }
-
- *pp = p;
- *keyp = key;
- if (valp)
- *valp = val;
-
- return 1;
-}
-
/**
* cuse_parse_dev_info - parse device info
* @p: device info string
@@ -275,7 +219,7 @@ static int cuse_parse_devinfo(char *p, size_t len, struct
cuse_devinfo *devinfo)
int rc;
while (true) {
- rc = cuse_parse_one(, end, , );
+ rc = fuse_kv_parse_one(, end, , );
if (rc < 0)
return rc;
if (!rc)
diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h
index 8c56a3fd2c4e..555856b0d998 100644
--- a/fs/fuse/fuse_i.h
+++ b/fs/fuse/fuse_i.h
@@ -1228,5 +1228,7 @@ void fuse_dax_cancel_work(struct fuse_conn *fc);
/* file.c */
struct page **fuse_pages_alloc(unsigned int npages, gfp_t flags,
struct fuse_page_desc **desc);
+/* helper.c */
+int fuse_kv_parse_one(char **pp, char *end, char **keyp, char **valp);
#endif /* _FS_FUSE_I_H */
diff --git a/fs/fuse/helper.c b/fs/fuse/helper.c
new file mode 100644
index ..0c828daf8e8a
--- /dev/null
+++ b/fs/fuse/helper.c
@@ -0,0 +1,70 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Helper functions used by CUSE and MUSE
+ *
+ * Copyright (C) 2008-2009 SUSE Linux Products GmbH
+ * Copyright (C) 2008-2009 Tejun Heo
+ *
+ */
+
+#include
+#include
+
+#include "fuse_i.h"
+
+/**
+ * fuse_kv_parse_one - parse one key=value pair
+ * @pp: i/o parameter for the current position
+ * @end: points to one past the end of the packed string
+ * @keyp: out parameter for key
+ * @valp: out parameter for value
+ *
+ * *@pp points to packed strings - "key0=val0\0key1=val1\0" which ends
+ * at @end - 1. This function parses one pair and set *@keyp to the
+ * start of the key and *@valp to the start of the value. Note that
+ * the original string is modified such that the key string is
+ * termin
[PATCH 0/8] MUSE: Userspace backed MTD v3
I'm happy to announce the first non-RFC version of this patch set. Over the xmas holidays I found some time to experiment with various userspace implementations of MTDs and gave the kernel side more fine-tuning. Rationale: -- When working with flash devices a common task is emulating them to run various tests or inspect dumps from real hardware. To achieve that we have plenty of emulators in the MTD subsystem: mtdram, block2mtd, nandsim. Each of them implements an ad-hoc MTD and have various drawbacks. Over the last years some developers tried to extend them but these attempts often got rejected because they added just more adhoc feature instead of addressing overall problems. MUSE is a novel approach to address the need of advanced MTD emulators. Advanced means in this context supporting different (vendor specific) image formats, different ways for fault injection (fuzzing) and recoding/replaying IOs to emulate power cuts. The core goal of MUSE is having the complexity on the userspace side and only a small MTD driver in kernelspace. While playing with different approaches I realized that FUSE offers everything we need. So MUSE is a little like CUSE except that it does not implement a bare character device but an MTD. Notes: -- - OOB support is currently limited. Currently MUSE has no support for processing in- and out-band in the same MTD operation. It is good enough to make JFFS2 happy. This limitation is because FUSE has no support more than one variable length buffer in a FUSE request. At least I didn’t find a good way to pass more than one buffer to a request. Maybe FUSE folks can correct me. :-) - Every MTD read/write operation maps 1:1 to a MUSE_READ/WRITE opcode. Since FUSE requests are not cheap, the amount of read/written bytes in a MTD operation as a huge impact on the performance. Especially when NOR style MTDs are implemented in userspace a large writebufsize should be requested to gain good write performance. On the other hand, MTD operations with lengths larger than writesize are *not* split up into multiple MUSE_READ/WRITE requests. This means that userspace has to split them manually when doing power-cut emulation. - MUSE is not super fast. On my i5 workstation nandsim is almost twice as fast as a NAND flash in userspace. But MUSE is still magnitudes faster than any real world MTD out there. So it is good enough for the use cases I have in mind. Changelog: -- Changes since v2 (RFC): - OOB support - MUSE_READ/WRITE opcodes are no longer a min IO MTD unit - MTD partitions support via mtdparts string - More code cleanup - Code rebased to 5.11-rc4 Changes since v1 (RFC): - Rewrote IO path, fuse_direct_io() is no longer used. Instead of cheating fuse_direct_io() use custom ops to implement reading and writing. That way MUSE no longer needs a dummy file object nor a fuse file object. In MTD all IO is synchronous and operations on kernel buffers, this makes IO processing simple for MUSE. - Support for bad blocks. - No more (ab)use of FUSE ops such as FUSE_FSYNC. - Major code cleanup. This series can also be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rw/misc.git muse_v3 Richard Weinberger (8): fuse: Export fuse_simple_request fuse: Export IO helpers fuse: Make cuse_parse_one a common helper mtd: Add MTD_MUSE flag mtd: Allow passing a custom cmdline to cmdline line parser fuse: Add MUSE specific defines FUSE interface fuse: Implement MUSE - MTD in userspace MAINTAINERS: Add entry for MUSE Documentation/ABI/testing/sysfs-class-mtd |8 + MAINTAINERS |7 + drivers/mtd/parsers/cmdlinepart.c | 73 +- fs/fuse/Kconfig | 15 + fs/fuse/Makefile |2 + fs/fuse/cuse.c| 58 +- fs/fuse/dev.c |1 + fs/fuse/file.c| 16 +- fs/fuse/fuse_i.h | 18 + fs/fuse/helper.c | 70 ++ fs/fuse/muse.c| 1086 + include/linux/mtd/partitions.h|2 + include/uapi/linux/fuse.h | 76 ++ include/uapi/mtd/mtd-abi.h|1 + 14 files changed, 1346 insertions(+), 87 deletions(-) create mode 100644 fs/fuse/helper.c create mode 100644 fs/fuse/muse.c -- 2.26.2
Re: [PATCH] mtd: rawnand: Fix an error handling path in 'ebu_dma_start()'
On Sun, Jan 24, 2021 at 9:13 PM Markus Elfring wrote:
>
> > If 'dmaengine_prep_slave_single()' fails, we must undo a previous
> > 'dma_map_single()' call, as already done in all the other error handling
> > paths of this function.
>
> Would you ever like to use an imperative wording for the change description?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=fdbc80bdc4365078a0f7d65631171cb80e3ffd6e#n89
>
>
> …
> > +++ b/drivers/mtd/nand/raw/intel-nand-controller.c
> > @@ -318,8 +318,10 @@ static int ebu_dma_start(struct ebu_nand_controller
> > *ebu_host, u32 dir,
> > }
> >
> > tx = dmaengine_prep_slave_single(chan, buf_dma, len, dir, flags);
> > - if (!tx)
> > - return -ENXIO;
> > + if (!tx) {
> > + ret = -ENXIO;
> > + goto err_unmap;
> > + }
> >
> > tx->callback = callback;
> …
>
> By the way:
> Can it be nicer to achieve the statement “ret = -EIO;” by a jump for
> a target like “e_io” so that less exception handling code would be duplicated
> for this function implementation?
Please feel free to ignore Markus.
https://lore.kernel.org/lkml/x+x3pianr18ep...@kroah.com/
--
Thanks,
//richard
Re: [PATCH 3/4] ubifs: Update directory size when creating whiteouts
- Ursprüngliche Mail - > Von: "chengzhihao1" > An: "richard" , "linux-mtd" > CC: "david" , "linux-kernel" > , "stable" > Gesendet: Samstag, 23. Januar 2021 03:45:15 > Betreff: Re: [PATCH 3/4] ubifs: Update directory size when creating whiteouts > 在 2021/1/23 5:22, Richard Weinberger 写道: >> Although whiteouts are unlinked files they will get re-linked later, > I just want to make sure, is this where the count is increased? > do_rename -> inc_nlink(whiteout) Exactly. The logic is a little wicked, I agree. Let me think again whether there isn't a better way to address the problem. Thanks, //richard P.s: Thanks a lot for reviewing!
[PATCH 4/4] ubifs: Harden ubifs_jnl_write_inode()
Make sure that ubifs_jnl_write_inode() cannot be abused and will
not write less data then expected.
Signed-off-by: Richard Weinberger
---
fs/ubifs/journal.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fs/ubifs/journal.c b/fs/ubifs/journal.c
index 03410ae0813a..1b28fcc5b9fe 100644
--- a/fs/ubifs/journal.c
+++ b/fs/ubifs/journal.c
@@ -844,10 +844,12 @@ int ubifs_jnl_write_inode(struct ubifs_info *c, const
struct inode *inode)
struct ubifs_ino_node *ino, *ino_start;
struct ubifs_inode *ui = ubifs_inode(inode);
int sync = 0, write_len = 0, ilen = UBIFS_INO_NODE_SZ;
- int last_reference = !inode->i_nlink;
+ int last_reference = !inode->i_nlink, xattr_inos_written = 0;
int kill_xattrs = ui->xattr_cnt && last_reference;
u8 hash[UBIFS_HASH_ARR_SZ];
+ ubifs_assert(c, !ui->xattr);
+
dbg_jnl("ino %lu, nlink %u", inode->i_ino, inode->i_nlink);
/*
@@ -917,12 +919,14 @@ int ubifs_jnl_write_inode(struct ubifs_info *c, const
struct inode *inode)
pack_inode(c, ino, xino, 0);
ino = (void *)ino + UBIFS_INO_NODE_SZ;
iput(xino);
+ xattr_inos_written++;
kfree(pxent);
pxent = xent;
key_read(c, >key, );
}
kfree(pxent);
+ ubifs_assert(c, xattr_inos_written == ui->xattr_cnt);
}
pack_inode(c, ino, inode, 1);
--
2.26.2
Re: [PATCH 3/3] mtd: parsers: ofpart: support BCM4908 fixed partitions
On Tue, Jan 19, 2021 at 5:01 PM Miquel Raynal wrote: > > Signed-off-by: Rafał Miłecki > > The approach looks fine by me, let's see what other maintainers think. Same, looks good to me! :-) -- Thanks, //richard
[PATCH 2/4] ubifs: Don't add fscrypt context to xattrs
In UBIFS xattrs are inodes too, make sure that these inodes
don't get a fscrypt context.
Otherwise we will end up with undeletable xattrs which will
waste memory on the flash.
Cc: sta...@vger.kernel.org
Fixes: d475a507457b ("ubifs: Add skeleton for fscrypto")
Signed-off-by: Richard Weinberger
---
fs/ubifs/dir.c | 23 +--
fs/ubifs/ubifs.h | 2 +-
fs/ubifs/xattr.c | 2 +-
3 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
index 04912dedca48..8a34e0118ee9 100644
--- a/fs/ubifs/dir.c
+++ b/fs/ubifs/dir.c
@@ -68,13 +68,14 @@ static int inherit_flags(const struct inode *dir, umode_t
mode)
* @c: UBIFS file-system description object
* @dir: parent directory inode
* @mode: inode mode flags
+ * @omit_fscrypt_ctx: Don't create a fscrypt context for this inode
*
* This function finds an unused inode number, allocates new inode and
* initializes it. Returns new inode in case of success and an error code in
* case of failure.
*/
struct inode *ubifs_new_inode(struct ubifs_info *c, struct inode *dir,
- umode_t mode)
+ umode_t mode, int omit_fscrypt_ctx)
{
int err;
struct inode *inode;
@@ -99,10 +100,12 @@ struct inode *ubifs_new_inode(struct ubifs_info *c, struct
inode *dir,
current_time(inode);
inode->i_mapping->nrpages = 0;
- err = fscrypt_prepare_new_inode(dir, inode, );
- if (err) {
- ubifs_err(c, "fscrypt_prepare_new_inode failed: %i", err);
- goto out_iput;
+ if (!omit_fscrypt_ctx) {
+ err = fscrypt_prepare_new_inode(dir, inode, );
+ if (err) {
+ ubifs_err(c, "fscrypt_prepare_new_inode failed: %i",
err);
+ goto out_iput;
+ }
}
switch (mode & S_IFMT) {
@@ -309,7 +312,7 @@ static int ubifs_create(struct inode *dir, struct dentry
*dentry, umode_t mode,
sz_change = CALC_DENT_SIZE(fname_len());
- inode = ubifs_new_inode(c, dir, mode);
+ inode = ubifs_new_inode(c, dir, mode, 0);
if (IS_ERR(inode)) {
err = PTR_ERR(inode);
goto out_fname;
@@ -385,7 +388,7 @@ static int do_tmpfile(struct inode *dir, struct dentry
*dentry,
return err;
}
- inode = ubifs_new_inode(c, dir, mode);
+ inode = ubifs_new_inode(c, dir, mode, 0);
if (IS_ERR(inode)) {
err = PTR_ERR(inode);
goto out_budg;
@@ -971,7 +974,7 @@ static int ubifs_mkdir(struct inode *dir, struct dentry
*dentry, umode_t mode)
sz_change = CALC_DENT_SIZE(fname_len());
- inode = ubifs_new_inode(c, dir, S_IFDIR | mode);
+ inode = ubifs_new_inode(c, dir, S_IFDIR | mode, 0);
if (IS_ERR(inode)) {
err = PTR_ERR(inode);
goto out_fname;
@@ -1058,7 +1061,7 @@ static int ubifs_mknod(struct inode *dir, struct dentry
*dentry,
sz_change = CALC_DENT_SIZE(fname_len());
- inode = ubifs_new_inode(c, dir, mode);
+ inode = ubifs_new_inode(c, dir, mode, 0);
if (IS_ERR(inode)) {
kfree(dev);
err = PTR_ERR(inode);
@@ -1140,7 +1143,7 @@ static int ubifs_symlink(struct inode *dir, struct dentry
*dentry,
sz_change = CALC_DENT_SIZE(fname_len());
- inode = ubifs_new_inode(c, dir, S_IFLNK | S_IRWXUGO);
+ inode = ubifs_new_inode(c, dir, S_IFLNK | S_IRWXUGO, 0);
if (IS_ERR(inode)) {
err = PTR_ERR(inode);
goto out_fname;
diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h
index fc2cdde3b549..dc9b6ba41e77 100644
--- a/fs/ubifs/ubifs.h
+++ b/fs/ubifs/ubifs.h
@@ -1994,7 +1994,7 @@ int ubifs_update_time(struct inode *inode, struct
timespec64 *time, int flags);
/* dir.c */
struct inode *ubifs_new_inode(struct ubifs_info *c, struct inode *dir,
- umode_t mode);
+ umode_t mode, int omit_fscrypt_ctx);
int ubifs_getattr(const struct path *path, struct kstat *stat,
u32 request_mask, unsigned int flags);
int ubifs_check_dir_empty(struct inode *dir);
diff --git a/fs/ubifs/xattr.c b/fs/ubifs/xattr.c
index a0b9b349efe6..430abe9e56af 100644
--- a/fs/ubifs/xattr.c
+++ b/fs/ubifs/xattr.c
@@ -110,7 +110,7 @@ static int create_xattr(struct ubifs_info *c, struct inode
*host,
if (err)
return err;
- inode = ubifs_new_inode(c, host, S_IFREG | S_IRWXUGO);
+ inode = ubifs_new_inode(c, host, S_IFREG | S_IRWXUGO, 1);
if (IS_ERR(inode)) {
err = PTR_ERR(inode);
goto out_budg;
--
2.26.2
[PATCH 1/4] ubifs: Correctly set inode size in ubifs_link()
We need to use fscrypt filename handling wrappers
when calculating the size of a directory entry, otherwise
UBIFS will report the wrong value (size of plain instead of cihper text)
for st_size of a directory if fscrypt is enabled.
Cc: sta...@vger.kernel.org
Fixes: f4f61d2cc6d8 ("ubifs: Implement encrypted filenames")
Signed-off-by: Richard Weinberger
---
fs/ubifs/dir.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
index 9a6b8660425a..04912dedca48 100644
--- a/fs/ubifs/dir.c
+++ b/fs/ubifs/dir.c
@@ -693,7 +693,7 @@ static int ubifs_link(struct dentry *old_dentry, struct
inode *dir,
struct inode *inode = d_inode(old_dentry);
struct ubifs_inode *ui = ubifs_inode(inode);
struct ubifs_inode *dir_ui = ubifs_inode(dir);
- int err, sz_change = CALC_DENT_SIZE(dentry->d_name.len);
+ int err, sz_change;
struct ubifs_budget_req req = { .new_dent = 1, .dirtied_ino = 2,
.dirtied_ino_d = ALIGN(ui->data_len, 8) };
struct fscrypt_name nm;
@@ -731,6 +731,8 @@ static int ubifs_link(struct dentry *old_dentry, struct
inode *dir,
if (inode->i_nlink == 0)
ubifs_delete_orphan(c, inode->i_ino);
+ sz_change = CALC_DENT_SIZE(fname_len());
+
inc_nlink(inode);
ihold(inode);
inode->i_ctime = current_time(inode);
--
2.26.2
[PATCH 3/4] ubifs: Update directory size when creating whiteouts
Although whiteouts are unlinked files they will get re-linked later,
therefore the size of the parent directory needs to be updated too.
Cc: sta...@vger.kernel.org
Fixes: 9e0a1fff8db5 ("ubifs: Implement RENAME_WHITEOUT")
Signed-off-by: Richard Weinberger
---
fs/ubifs/dir.c | 4
1 file changed, 4 insertions(+)
diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
index 8a34e0118ee9..b5d523e5854f 100644
--- a/fs/ubifs/dir.c
+++ b/fs/ubifs/dir.c
@@ -361,6 +361,7 @@ static int do_tmpfile(struct inode *dir, struct dentry
*dentry,
struct ubifs_budget_req ino_req = { .dirtied_ino = 1 };
struct ubifs_inode *ui, *dir_ui = ubifs_inode(dir);
int err, instantiated = 0;
+ int sz_change = 0;
struct fscrypt_name nm;
/*
@@ -411,6 +412,8 @@ static int do_tmpfile(struct inode *dir, struct dentry
*dentry,
mark_inode_dirty(inode);
drop_nlink(inode);
*whiteout = inode;
+ sz_change = CALC_DENT_SIZE(fname_len());
+ dir->i_size += sz_change;
} else {
d_tmpfile(dentry, inode);
}
@@ -430,6 +433,7 @@ static int do_tmpfile(struct inode *dir, struct dentry
*dentry,
return 0;
out_cancel:
+ dir->i_size -= sz_change;
mutex_unlock(_ui->ui_mutex);
out_inode:
make_bad_inode(inode);
--
2.26.2
[PATCH 0/4] Assorted UBIFS fixes
I'm currently hunting down a filesystem corruption, while reviewing various parts of UBIFS I've found some other bugs. This patches fix these bugs. In another series I'll add a feature to be able to remove stale fscrypt contexts and wrong directory size counters. Richard Weinberger (4): ubifs: Correctly set inode size in ubifs_link() ubifs: Don't add fscrypt context to xattrs ubifs: Update directory size when creating whiteouts ubifs: Harden ubifs_jnl_write_inode() fs/ubifs/dir.c | 31 --- fs/ubifs/journal.c | 6 +- fs/ubifs/ubifs.h | 2 +- fs/ubifs/xattr.c | 2 +- 4 files changed, 27 insertions(+), 14 deletions(-) -- 2.26.2
Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)
[CC'in linux-um since there is a similar issue]
On Thu, Jan 7, 2021 at 12:38 AM Vineet Gupta wrote:
>
> +CC Buildroot folks
>
> Hi Petr,
>
> On 11/11/20 5:54 AM, Petr Mladek wrote:
> > stdin, stdout, and stderr standard I/O stream are created for the init
> > process. They are not available when there is no console registered
> > for /dev/console. It might lead to a crash when the init process
> > tries to use them, see the commit 48021f98130880dd742 ("printk: handle
> > blank console arguments passed in.").
> >
> > Normally, ttySX and ttyX consoles are used as a fallback when no consoles
> > are defined via the command line, device tree, or SPCR. But there
> > will be no console registered when an invalid console name is configured
> > or when the configured consoles do not exist on the system.
> >
> > Users even try to avoid the console intentionally, for example,
> > by using console="" or console=null. It is used on production
> > systems where the serial port or terminal are not visible to
> > users. Pushing messages to these consoles would just unnecessary
> > slowdown the system.
> >
> > Make sure that stdin, stdout, stderr, and /dev/console are always
> > available by a fallback to the existing ttynull driver. It has
> > been implemented for exactly this purpose but it was used only
> > when explicitly configured.
> >
> > Signed-off-by: Petr Mladek
>
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -1470,8 +1470,14 @@ void __init console_on_rootfs(void)
> > struct file *file = filp_open("/dev/console", O_RDWR, 0);
> >
> > if (IS_ERR(file)) {
> > - pr_err("Warning: unable to open an initial console.\n");
> > - return;
> > + pr_err("Warning: unable to open an initial console. Fallback
> > to ttynull.\n");
> > + register_ttynull_console();
> > +
> > + file = filp_open("/dev/console", O_RDWR, 0);
> > + if (IS_ERR(file)) {
> > + pr_err("Warning: Failed to add ttynull console. No
> > stdin, stdout, and stderr for the init process!\n");
> > + return;
> > + }
>
>
> This breaks ARC booting (no output on console).
>
> Our Buildroot based setup has dynamic /dev where /dev/console doesn't
> exist statically and there's a primoridla /init shell script which does
> following
>
> /bin/mount -t devtmpfs devtmpfs /dev
> exec 0 exec 1>/dev/console
> exec 2>/dev/console
> exec /sbin/init "$@"
>
> Buildroot has had this way of handling missing /dev/console since 2011
> [1] and [2].
>
> Please advise what needs to be done to unbork boot. Otherwise this seems
> like a kernel change which breaks user-space and needs to be backed-out
> (or perhaps conditionalize on CONFIG_NULL_TTY. I'm surprised it hasn't
> been reported by any other embedded folks
>
> Thx,
> -Vineet
>
> [1] http://lists.busybox.net/pipermail/buildroot/2011-July/044505.html
> [2] http://lists.busybox.net/pipermail/buildroot/2011-August/044832.html
--
Thanks,
//richard
Re: linux.git is broken on a case-insensitive filesystem
Theodore, On Sat, Dec 26, 2020 at 11:41 PM Theodore Dubois wrote: > > I'm currently hacking on Linux trying to run a sort of UML-style thing on > macOS (please don't question my sanity :), and I've run into various issues > stemming from macOS having a case-insensitive filesystem. Sounds interesting, if you have questions on UML internals, just ask. > The one you run into immediately is: there are a number of files (mostly in > netfilter) that have different uppercase and lowercase versions. > net/netfilter/xt_DSCP.c and net/netfilter/xt_dscp.c are quite different. Last > I checked, git would pseudo-randomly pick one of these to check out, and then > show the other one as having unstaged changes making it look like the first > one. This causes problems when switching branches. I've worked around this > with a sparse checkout that excludes these files, but it's not great. > > The gitignore also contains the pattern *.s, which excludes *.S as well when > git is ignoring case. > > Is there any interest in fixing these? I fear it is a little more complicated. We have different upper and lower case variants in include/uapi/. If you rename them, existing programs will fail to build. ...which will make users sad and Linus grumpy. -- Thanks, //richard
Re: [PATCH v2] ubifs: Fix read out-of-bounds in ubifs_jnl_write_inode()
Chengsong Ke,
- Ursprüngliche Mail -
> The memory area allocated in ubifs_jnl_write_inode() is not aligned with 8
> bytes:
> ino_start = ino = kmalloc(write_len, GFP_NOFS);
>
> When ino_start passed into write_head -> ubifs_wbuf_write_nolock:
>n = aligned_len >> c->max_write_shift;
>if (n) {
> n <<= c->max_write_shift;
> err = ubifs_leb_write(c, wbuf->lnum, buf + written, wbuf->offs, n);
> // Read oob occurs here, read n bytes from buf, and buf is passed from
> @ino_start which is
> // not 8 bytes aligned(write_len < n). Program read (n - write_len) more
> bytes.
>}
>
> Reproducer:
> 0. config KASAN && apply print.patch
> 1. mount ubifs on /root/temp
> 2. run test.sh
What does test.sh do?
> 3. cd /root/temp && ls // change atime for link_file
> 4. wait 1~2 minutes
>
> In order to solve the read oob problem in ubifs_wbuf_write_nolock, just align
> the write_len to
> 8 bytes when alloc the memory. So that this patch will not affect the use of
> write_len in other
> functions, such as ubifs_jnl_write_inode->make_reservation and
> ubifs_jnl_write_inode->ubifs_node_calc_hash.
I gave this a second thought and I'm not so sure anymore what exactly is going
on.
The problem is real, I fully agree with you but I need to dig deeper into
the journal and wbuf code to double check that we really fix the right thing
and not just paper other something.
Thanks,
//richard
Re: [PATCH -next] ubi: eba: Delete useless kfree code
On Wed, Dec 16, 2020 at 2:13 PM Zheng Yongjun wrote:
>
> The parameter of kfree function is NULL, so kfree code is useless, delete it.
>
> Signed-off-by: Zheng Yongjun
> ---
> drivers/mtd/ubi/eba.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/mtd/ubi/eba.c b/drivers/mtd/ubi/eba.c
> index 0edecfdbd01f..9c2840ffd2e9 100644
> --- a/drivers/mtd/ubi/eba.c
> +++ b/drivers/mtd/ubi/eba.c
> @@ -142,7 +142,6 @@ struct ubi_eba_table *ubi_eba_create_table(struct
> ubi_volume *vol,
> return tbl;
>
> err:
> - kfree(tbl->entries);
> kfree(tbl);
>
> return ERR_PTR(err);
On Sat, Dec 19, 2020 at 1:52 PM Jubin Zhong wrote:
>
> data_size is already checked against zero when vol_type matches
> UBI_VID_STATIC. Remove the following dead code.
>
> Signed-off-by: Jubin Zhong
> ---
> drivers/mtd/ubi/io.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c
> index 2f3312c..8a7306c 100644
> --- a/drivers/mtd/ubi/io.c
> +++ b/drivers/mtd/ubi/io.c
> @@ -913,12 +913,7 @@ static int validate_vid_hdr(const struct ubi_device *ubi,
> ubi_err(ubi, "bad data_size");
> goto bad;
> }
> - } else if (lnum == used_ebs - 1) {
> - if (data_size == 0) {
> - ubi_err(ubi, "bad data_size at last LEB");
> - goto bad;
> - }
> - } else {
> + } else if (lnum > used_ebs - 1) {
> ubi_err(ubi, "too high lnum");
> goto bad;
> }
> --
Looks good, applied to my 5.12 queue!
--
Thanks,
//richard
Re: [PATCH] ubifs: Fix read out-of-bounds in ubifs_jnl_write_inode()
Chengsong Ke,
- Ursprüngliche Mail -
> The memory area allocated in ubifs_jnl_write_inode() is not aligned with 8
> bytes:
> ino_start = ino = kmalloc(write_len, GFP_NOFS);
>
> When ino_start passed into write_head -> ubifs_wbuf_write_nolock:
>n = aligned_len >> c->max_write_shift;
>if (n) {
> n <<= c->max_write_shift;
> err = ubifs_leb_write(c, wbuf->lnum, buf + written, wbuf->offs, n);
> // Read oob occurs here, read n bytes from buf, and buf is passed from
> @ino_start which is
> // not 8 bytes aligned(write_len < n). Program read (n - write_len) more
> bytes.
>}
>
> Reproducer:
> 0. config KASAN && apply print.patch
> 1. mount ubifs on /root/temp
> 2. run test.sh
> 3. cd /root/temp && ls // change atime for link_file
> 4. wait 1~2 minutes
>
> Cc:
> Fixes: 1e51764a3c2ac0 ("UBIFS: add new flash file system")
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=210865
>
> Signed-off-by: Chengsong Ke
> ---
> fs/ubifs/io.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
Good catch!
Please address the problem in ubifs_jnl_write_inode().
The length there needs to be properly aligned like all other journal
functions do.
I think you managed to trigger the issue because ui->data_len is not aligned.
Thanks,
//richard
Re: [PATCH] ubi: remove dead code in validate_vid_hdr()
On Sat, Dec 19, 2020 at 1:52 PM Jubin Zhong wrote:
>
> data_size is already checked against zero when vol_type matches
> UBI_VID_STATIC. Remove the following dead code.
>
> Signed-off-by: Jubin Zhong
> ---
> drivers/mtd/ubi/io.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c
> index 2f3312c..8a7306c 100644
> --- a/drivers/mtd/ubi/io.c
> +++ b/drivers/mtd/ubi/io.c
> @@ -913,12 +913,7 @@ static int validate_vid_hdr(const struct ubi_device *ubi,
> ubi_err(ubi, "bad data_size");
> goto bad;
> }
> - } else if (lnum == used_ebs - 1) {
> - if (data_size == 0) {
> - ubi_err(ubi, "bad data_size at last LEB");
> - goto bad;
> - }
> - } else {
> + } else if (lnum > used_ebs - 1) {
> ubi_err(ubi, "too high lnum");
> goto bad;
> }
> --
Looks good, applied to my 5.12 queue!
--
Thanks,
//richard
[GIT PULL] JFFS2, UBI and UBIFS updates for 5.11-rc1
Linus, The following changes since commit b65054597872ce3aefbc6a666385eabdf9e288da: Linux 5.10-rc6 (2020-11-29 15:50:50 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs.git tags/for-linus-5.11-rc1 for you to fetch changes up to b80a974b8c58164ed57b0f025a47b8f003198d9e: ubifs: ubifs_dump_node: Dump all branches of the index node (2020-12-13 22:12:42 +0100) This pull request contains changes for JFFS2, UBI and UBIFS: JFFS2: - Fix for a remount regression - Fix for an abnormal GC exit - Fix for a possible NULL pointer issue while mounting UBI: - Add support ECC-ed NOR flash - Removal of dead code UBIFS: - Make node dumping debug code more reliable - Various cleanups: less ifdefs, less typos - Fix for an info leak Chengguang Xu (1): ubifs: Code cleanup by removing ifdef macro surrounding Chengsong Ke (2): ubifs: Fix the printing type of c->big_lpt ubifs: Remove the redundant return in dbg_check_nondata_nodes_order Fangping Liang (1): ubifs: Fixed print foramt mismatch in ubifs Jamie Iles (1): jffs2: Fix NULL pointer dereference in rp_size fs option parsing Pratyush Yadav (1): ubi: Do not zero out EC and VID on ECC-ed NOR flashes Randy Dunlap (2): ubifs: Delete duplicated words + other fixes jffs2: Fix if/else empty body warnings Richard Weinberger (1): ubifs: wbuf: Don't leak kernel memory to flash Tom Rix (1): jffs2: remove trailing semicolon in macro definition Wang ShaoBo (1): ubifs: Fix error return code in ubifs_init_authentication() Zhe Li (1): jffs2: Fix GC exit abnormally Zhihao Cheng (5): ubifs: Limit dumping length by size of memory which is allocated for the node Revert "ubifs: Fix out-of-bounds memory access caused by abnormal value of node_len" ubifs: Pass node length in all node dumping callers ubifs: ubifs_dump_sleb: Remove unused function ubifs: ubifs_dump_node: Dump all branches of the index node k00524021 (1): ubi: Remove useless code in bytes_str_to_int lizhe (2): jffs2: Fix ignoring mounting options problem during remounting jffs2: Allow setting rp_size to zero during remounting drivers/mtd/ubi/build.c | 6 +-- drivers/mtd/ubi/io.c| 9 +++- fs/jffs2/debug.h| 23 +- fs/jffs2/jffs2_fs_sb.h | 1 + fs/jffs2/nodelist.h | 4 +- fs/jffs2/readinode.c| 16 +++ fs/jffs2/super.c| 32 ++--- fs/ubifs/auth.c | 4 +- fs/ubifs/commit.c | 4 +- fs/ubifs/debug.c| 116 fs/ubifs/debug.h| 5 +-- fs/ubifs/dir.c | 4 +- fs/ubifs/file.c | 8 +--- fs/ubifs/io.c | 52 ++ fs/ubifs/journal.c | 3 +- fs/ubifs/lpt.c | 4 +- fs/ubifs/master.c | 4 +- fs/ubifs/orphan.c | 6 ++- fs/ubifs/recovery.c | 6 +-- fs/ubifs/replay.c | 6 +-- fs/ubifs/sb.c | 2 +- fs/ubifs/scan.c | 4 +- fs/ubifs/super.c| 6 +-- fs/ubifs/tnc.c | 10 ++--- fs/ubifs/tnc_misc.c | 7 ++- fs/ubifs/ubifs.h| 10 +++-- 26 files changed, 203 insertions(+), 149 deletions(-)
[GIT PULL] UML updates for 5.11-rc1
Linus, The following changes since commit b65054597872ce3aefbc6a666385eabdf9e288da: Linux 5.10-rc6 (2020-11-29 15:50:50 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git tags/for-linus-5.11-rc1 for you to fetch changes up to 1fb1abc83636f5329c26cd29f0f19f3faeb697a5: um: Fix build w/o CONFIG_PM_SLEEP (2020-12-14 21:15:32 +0100) This pull request contains the following changes for UML: - IRQ handling cleanups - Support for suspend - Various fixes for UML specific drivers: ubd, vector, xterm Allen Pais (1): um: Convert tasklets to use new tasklet_setup() API Andy Shevchenko (1): um: Increase stack frame size threshold for signal.c Anton Ivanov (5): um: Remove use of asprinf in umid.c um: Fetch registers only for signals which need them um: Monitor error events in IRQ controller um: tty: Fix handling of close in tty lines um: chan_xterm: Fix fd leak Christopher Obbard (2): um: random: Register random as hwrng-core device um: ubd: Set device serial attribute from cmdline Gabriel Krisman Bertazi (1): um: ubd: Submit all data segments atomically Jens Axboe (1): um: Add support for TIF_NOTIFY_SIGNAL Johannes Berg (21): um: Fix time-travel mode um: line: Don't free winch (with IRQ) under spinlock um: sigio: Return error from add_sigio_fd() um: Support dynamic IRQ allocation um: virtio: Use dynamic IRQ allocation um: Clean up alarm IRQ chip name um: irq: Clean up and rename struct irq_fd um: irq: Reduce irq_reg allocation um: Remove IRQ_NONE type um: Simplify IRQ handling code um: Simplify os_idle_sleep() and sleep longer um: time: Fix read_persistent_clock64() in time-travel um: Allow PM with suspend-to-idle um: Support suspend to RAM um: time-travel: avoid multiple identical propagations um: support some of ARCH_HAS_SET_MEMORY um: allocate a guard page to helper threads um: time-travel: Actually apply "free-until" optimisation um: irq/sigio: Support suspend/resume handling of workaround IRQs um: time-travel: Correct time event IRQ delivery um: Fix build w/o CONFIG_PM_SLEEP arch/um/Kconfig | 6 + arch/um/drivers/chan_user.c | 4 +- arch/um/drivers/line.c | 30 +- arch/um/drivers/mconsole_kern.c | 2 +- arch/um/drivers/net_kern.c | 2 +- arch/um/drivers/port_kern.c | 4 +- arch/um/drivers/random.c| 105 ++- arch/um/drivers/ubd_kern.c | 273 ++-- arch/um/drivers/vector_kern.c | 10 +- arch/um/drivers/virtio_uml.c| 31 +- arch/um/drivers/xterm.c | 5 + arch/um/drivers/xterm_kern.c| 2 +- arch/um/include/asm/irq.h | 9 +- arch/um/include/asm/pgtable.h | 3 + arch/um/include/asm/set_memory.h| 1 + arch/um/include/asm/thread_info.h | 2 + arch/um/include/linux/time-internal.h | 4 +- arch/um/include/shared/common-offsets.h | 3 + arch/um/include/shared/irq_kern.h | 13 +- arch/um/include/shared/irq_user.h | 21 +- arch/um/include/shared/kern_util.h | 5 +- arch/um/include/shared/os.h | 23 +- arch/um/kernel/irq.c| 534 +--- arch/um/kernel/process.c| 27 +- arch/um/kernel/sigio.c | 2 +- arch/um/kernel/time.c | 97 +- arch/um/kernel/tlb.c| 54 arch/um/kernel/um_arch.c| 67 arch/um/os-Linux/Makefile | 2 + arch/um/os-Linux/helper.c | 4 +- arch/um/os-Linux/irq.c | 4 +- arch/um/os-Linux/sigio.c| 70 +++-- arch/um/os-Linux/signal.c | 22 +- arch/um/os-Linux/skas/process.c | 15 +- arch/um/os-Linux/time.c | 17 +- arch/um/os-Linux/umid.c | 17 +- drivers/char/hw_random/Kconfig | 16 +- 37 files changed, 909 insertions(+), 597 deletions(-) create mode 100644 arch/um/include/asm/set_memory.h
Re: [PATCH] ext4: Don't leak old mountpoint samples
- Ursprüngliche Mail - >>Fix this by using strncpy() instead of strlcpy(). The superblock >>field is defined to be a fixed-size char array, and it is already >>marked using __nonstring in fs/ext4/ext4.h. The consumer of the field >>in e2fsprogs already assumes that in the case of a 64+ byte mount >>path, that s_last_mounted will not be NUL terminated. >> >>Reported-by: Richard Weinberger >>Signed-off-by: Theodore Ts'o > > Color me confused, but I don't see how this change makes any difference? > If "cp" is only "/" then it will *still* not overwrite "edia/johnjdeveloper" > at the end of the s_last_mounted array. To my mind, the only difference > between using strlcpy() and strncpy() would be whether the last byte in > the array can be used or not, but doesn't affect the remaining bytes. strncpy() zeros all remaining bytes. Thanks, //richard
Re: [PATCH v3 1/3] UBI: Do not zero out EC and VID on ECC-ed NOR flashes
On Tue, Dec 8, 2020 at 7:17 PM Pratyush Yadav wrote: > > Richard, > > On 01/12/20 03:57PM, Pratyush Yadav wrote: > > For NOR flashes EC and VID are zeroed out before an erase is issued to > > make sure UBI does not mistakenly treat the PEB as used and associate it > > with an LEB. > > > > But on some flashes, like the Cypress Semper S28 SPI NOR flash family, > > multi-pass page programming is not allowed on the default ECC scheme. > > This means zeroing out these magic numbers will result in the flash > > throwing a page programming error. > > > > Do not zero out EC and VID for such flashes. A writesize > 1 is an > > indication of an ECC-ed flash. > > Patches 2/3 and 3/3 have been picked up in the spi-nor tree. Can you > please pick this patch up? Yep, patch is in my next tree. -- Thanks, //richard
Re: [PATCH] mtd: remove redundant assignment to pointer eb
On Fri, Sep 11, 2020 at 5:59 PM Miquel Raynal wrote:
>
> Hi Colin,
>
> Colin King wrote on Fri, 11 Sep 2020
> 11:23:21 +0100:
>
> > From: Colin Ian King
> >
> > Pointer eb is being assigned a value that is never read, the assignment
> > is redundant and can be removed.
> >
> > Addresses-Coverity: ("Unused value")
> > Signed-off-by: Colin Ian King
> > ---
> > drivers/mtd/mtdswap.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/mtd/mtdswap.c b/drivers/mtd/mtdswap.c
> > index 58eefa43af14..795dec4483c2 100644
> > --- a/drivers/mtd/mtdswap.c
> > +++ b/drivers/mtd/mtdswap.c
> > @@ -1053,7 +1053,6 @@ static int mtdswap_writesect(struct mtd_blktrans_dev
> > *dev,
> > if (ret < 0)
> > return ret;
> >
> > - eb = d->eb_data + (newblock / d->pages_per_eblk);
> > d->page_data[page] = newblock;
> >
> > return 0;
>
> Yes it looks unused but perhaps it helps to catch the logic here. This
> is not a strong disagreement but I'd keep it this way. Let's see what
> other maintainers think.
This looks like dead code, let's rip it out.
--
Thanks,
//richard
Re: linux-next: Fixes tag needs some work in the uml tree
Stephen,
On Fri, Dec 11, 2020 at 11:21 AM Stephen Rothwell wrote:
>
> Hi all,
>
> In commit
>
> 1aa1cfc19405 ("um: Remove use of asprinf in umid.c")
>
> Fixes tag
>
> Fixes: 492edce1306f (um: remove uses of variable length arrays)
>
> has these problem(s):
>
> - Target SHA1 does not exist
>
> Maybe you meant:
>
> Fixes: 0d4e5ac7e780 ("um: remove uses of variable length arrays")
Thanks for letting me know!
--
Thanks,
//richard
Re: [PATCH v2] mtd:ubi: Remove useless code in bytes_str_to_int
On Fri, Dec 11, 2020 at 4:38 AM Chengsong Ke wrote: > > I just send the v1 with the wrong module name 'ubifs'. > > [PATCH] ubifs: Remove useless code in bytes_str_to_int > > :-) > > Thanks, > > //Chengsong Ke > ping Both patches are in my next tree and should appear soon on linux-next. Thanks for your patience. -- Thanks, //richard
Re: BUG: Invalid wait context with KMEMLEAK and KASAN enabled
Boqun,
- Ursprüngliche Mail -
>> Does this ring a bell?
>>
>> [2.298447] =
>> [2.298971] [ BUG: Invalid wait context ]
>> [2.298971] 5.10.0-rc6+ #388 Not tainted
>> [2.298971] -
>> [2.298971] ksoftirqd/1/15 is trying to lock:
>> [2.298971] 888100b94598 (>list_lock){}-{3:3}, at:
>> free_debug_processing+0x3d/0x210
>
> I guest you also had CONFIG_PROVE_RAW_LOCK_NESTING=y, right?
Yes, this is the case!
Thanks,
//richard
BUG: Invalid wait context with KMEMLEAK and KASAN enabled
Hi!
With both KMEMLEAK and KASAN enabled, I'm facing the following lockdep
splat at random times on Linus' tree as of today.
Sometimes it happens at bootup, sometimes much later when userspace has started.
Does this ring a bell?
[2.298447] =
[2.298971] [ BUG: Invalid wait context ]
[2.298971] 5.10.0-rc6+ #388 Not tainted
[2.298971] -
[2.298971] ksoftirqd/1/15 is trying to lock:
[2.298971] 888100b94598 (>list_lock){}-{3:3}, at:
free_debug_processing+0x3d/0x210
[2.298971] other info that might help us debug this:
[2.298971] context-{2:2}
[2.298971] 1 lock held by ksoftirqd/1/15:
[2.298971] #0: 835f4140 (rcu_callback){}-{0:0}, at:
rcu_core+0x408/0x1040
[2.298971] stack backtrace:
[2.298971] CPU: 1 PID: 15 Comm: ksoftirqd/1 Not tainted 5.10.0-rc6+ #388
[2.298971] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.12.0-0-ga698c89-rebuilt.opensuse.org 04/01/2014
[2.298971] Call Trace:
[2.298971]
[2.298971] dump_stack+0x9a/0xcc
[2.298971] __lock_acquire.cold+0xce/0x34b
[2.298971] ? lockdep_hardirqs_on_prepare+0x1f0/0x1f0
[2.298971] ? rcu_read_lock_sched_held+0x9c/0xd0
[2.298971] lock_acquire+0x153/0x4c0
[2.298971] ? free_debug_processing+0x3d/0x210
[2.298971] ? lock_release+0x690/0x690
[2.298971] ? rcu_read_lock_bh_held+0xb0/0xb0
[2.298971] ? pvclock_clocksource_read+0xd9/0x1a0
[2.298971] _raw_spin_lock_irqsave+0x3b/0x80
[2.298971] ? free_debug_processing+0x3d/0x210
[2.298971] ? qlist_free_all+0x35/0xd0
[2.298971] free_debug_processing+0x3d/0x210
[2.298971] __slab_free+0x286/0x490
[2.298971] ? lockdep_enabled+0x39/0x50
[2.298971] ? rcu_read_lock_sched_held+0x9c/0xd0
[2.298971] ? run_posix_cpu_timers+0x256/0x2c0
[2.298971] ? rcu_read_lock_bh_held+0xb0/0xb0
[2.298971] ? posix_cpu_timers_exit_group+0x30/0x30
[2.298971] qlist_free_all+0x59/0xd0
[2.298971] ? qlist_free_all+0xd0/0xd0
[2.298971] per_cpu_remove_cache+0x47/0x50
[2.298971] flush_smp_call_function_queue+0xea/0x2b0
[2.298971] __sysvec_call_function+0x6c/0x250
[2.298971] asm_call_irq_on_stack+0x12/0x20
[2.298971]
[2.298971] sysvec_call_function+0x84/0xa0
[2.298971] asm_sysvec_call_function+0x12/0x20
[2.298971] RIP: 0010:__asan_load4+0x1d/0x80
[2.298971] Code: 10 00 75 ee c3 0f 1f 84 00 00 00 00 00 4c 8b 04
24 48 83 ff fb 77 4d 48 b8 ff ff ff ff ff 7f ff ff 48 39 c7 76 3e 48
8d 47 03 <48> 89 c2 83 e2 07 48 83 fa 02 76 17 48 b9 00 00 00 00 00 fc
ff df
[2.298971] RSP: :888100e4f858 EFLAGS: 0216
[2.298971] RAX: 83c55773 RBX: 81002431 RCX: dc00
[2.298971] RDX: 0001 RSI: 83ee8d78 RDI: 83c55770
[2.298971] RBP: 83c5576c R08: 81083433 R09: fbfff07e333d
[2.298971] R10: 0001803d R11: fbfff07e333c R12: 83c5575c
[2.298971] R13: 83c55774 R14: 83c55770 R15: 83c55770
[2.298971] ? ret_from_fork+0x21/0x30
[2.298971] ? __orc_find+0x63/0xc0
[2.298971] ? stack_access_ok+0x35/0x90
[2.298971] __orc_find+0x63/0xc0
[2.298971] unwind_next_frame+0x1ee/0xbd0
[2.298971] ? ret_from_fork+0x22/0x30
[2.298971] ? ret_from_fork+0x21/0x30
[2.298971] ? deref_stack_reg+0x40/0x40
[2.298971] ? __unwind_start+0x2e8/0x370
[2.298971] ? create_prof_cpu_mask+0x20/0x20
[2.298971] arch_stack_walk+0x83/0xf0
[2.298971] ? ret_from_fork+0x22/0x30
[2.298971] ? rcu_core+0x488/0x1040
[2.298971] stack_trace_save+0x8c/0xc0
[2.298971] ? stack_trace_consume_entry+0x80/0x80
[2.298971] ? sched_clock_local+0x99/0xc0
[2.298971] kasan_save_stack+0x1b/0x40
[2.298971] ? kasan_save_stack+0x1b/0x40
[2.298971] ? kasan_set_track+0x1c/0x30
[2.298971] ? kasan_set_free_info+0x1b/0x30
[2.298971] ? __kasan_slab_free+0x10f/0x150
[2.298971] ? kmem_cache_free+0xa8/0x350
[2.298971] ? rcu_core+0x488/0x1040
[2.298971] ? __do_softirq+0x101/0x573
[2.298971] ? run_ksoftirqd+0x21/0x50
[2.298971] ? smpboot_thread_fn+0x1fc/0x380
[2.298971] ? kthread+0x1c7/0x220
[2.298971] ? ret_from_fork+0x22/0x30
[2.298971] ? lockdep_hardirqs_on_prepare+0x1f0/0x1f0
[2.298971] ? rcu_read_lock_sched_held+0x9c/0xd0
[2.298971] ? lock_acquire+0x153/0x4c0
[2.298971] ? rcu_core+0x408/0x1040
[2.298971] ? lock_release+0x690/0x690
[2.298971] ? lockdep_enabled+0x39/0x50
[2.298971] ? mark_held_locks+0x49/0x90
[2.298971] kasan_set_track+0x1c/0x30
[2.298971] kasan_set_free_info+0x1b/0x30
[2.298971] __kasan_slab_free+0x10f/0x150
[2.298971] ? rcu_core+0x488/0x1040
[2.298971] kmem_cache_free+0xa8/0x350
[2.298971] ? __ia32_compat_sys_move_pages+0x130/0x130
[2.298971] rcu_core+0x488/0x1040
[2.298971] ?
[PATCH] mtd: core: Fix refcounting for unpartitioned MTDs
Apply changes to usecount also the the master partition.
Otherwise we have no refcounting at all if an MTD has no partitions.
Cc: sta...@vger.kernel.org
Fixes: 46b5889cc2c5 ("mtd: implement proper partition handling")
Signed-off-by: Richard Weinberger
---
drivers/mtd/mtdcore.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index e9e163ae9d86..b07cbb0661fb 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -993,6 +993,8 @@ int __get_mtd_device(struct mtd_info *mtd)
}
}
+ master->usecount++;
+
while (mtd->parent) {
mtd->usecount++;
mtd = mtd->parent;
@@ -1059,6 +1061,8 @@ void __put_mtd_device(struct mtd_info *mtd)
mtd = mtd->parent;
}
+ master->usecount--;
+
if (master->_put_device)
master->_put_device(master);
--
2.26.2
Re: [PATCH v2] phram: Allow the user to set the erase page size.
On Wed, Nov 25, 2020 at 8:14 AM Guohua Zhong wrote: > > Permit the user to specify the erase page size as a parameter. > This solves two problems: > > - phram can access images made by mkfs.jffs2. mkfs.jffs2 won't > create images with erase sizes less than 8KiB; many architectures > define PAGE_SIZE as 4KiB. > > - Allows more effective use of small capacity devices. JFFS2 > needs somewhere between 2 and 5 empty pages for garbage collection; > and for an NVRAM part with only 32KiB of space, a smaller erase page > allows much better utilization in applications where garbage collection > is important. > > Signed-off-by: Patrick O'Grady > Reviewed-by: Joern Engel > Link: > https://lore.kernel.org/lkml/CAJ7m5OqYv_=JB9NhHsqBsa8YU0DFRoP7C+W10PY22wonAGJK=a...@mail.gmail.com/ > [Guohua Zhong: fix token array index out of bounds and update patch for > kernel master branch] > Signed-off-by: Guohua Zhong > Reported-by: kernel test robot Looks good to me, except the authorship. If I understand correctly, you took this old patch and resend it. Please make sure that the "From:"-Line contains the original author. You can fix this up using git commit --amend --author=. The git format-patch will create a correct patch. -- Thanks, //richard
[PATCH] ext4: Don't leak old mountpoint samples
As soon the first file is opened, ext4 samples the mountpoint of the filesystem in 64 bytes of the super block. It does so using strlcpy(), this means that the remaining bytes in the super block string buffer are untouched. If the mount point before had a longer path than the current one, it can be reconstructed. Consider the case where the fs was mounted to "/media/johnjdeveloper" and later to "/". The the super block buffer then contains "/\x00edia/johnjdeveloper". This case was seen in the wild and caused confusion how the name of a developer ands up on the super block of a filesystem used in production... Fix this by clearing the string buffer before writing to it, Signed-off-by: Richard Weinberger --- fs/ext4/file.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/ext4/file.c b/fs/ext4/file.c index 3ed8c048fb12..dba521250d01 100644 --- a/fs/ext4/file.c +++ b/fs/ext4/file.c @@ -809,6 +809,7 @@ static int ext4_sample_last_mounted(struct super_block *sb, err = ext4_journal_get_write_access(handle, sbi->s_sbh); if (err) goto out_journal; + memset(sbi->s_es->s_last_mounted, 0x00, sizeof(sbi->s_es->s_last_mounted)); strlcpy(sbi->s_es->s_last_mounted, cp, sizeof(sbi->s_es->s_last_mounted)); ext4_handle_dirty_super(handle, sb); -- 2.26.2
Re: [PATCH v2 0/3] mtd: Make sure UBIFS does not do multi-pass page programming on flashes that don't support it
On Tue, Nov 24, 2020 at 2:58 PM Pratyush Yadav wrote: > > Hi, > > On 18/11/20 11:54PM, Pratyush Yadav wrote: > > Hi, > > > > The Cypress Semper S28 flash family uses 2-bit ECC by default. Under > > this ECC scheme, multi-pass page programs result in a program error. > > This means that unlike many other SPI NOR flashes, bit-walking cannot be > > done. In other words, once a page is programmed, its bits cannot then be > > flipped to 0 without an erase in between. > > > > This causes problems with UBIFS because it uses bit-walking to clear EC > > and VID magic numbers from a PEB before issuing an erase to preserve the > > file system correctness in case of power cuts. > > > > This series fixes that by setting mtd->writesize to the ECC block size > > (16) and making sure UBIFS does not try to do a multi-pass write on > > flashes with writesize > 1. > > > > It is based on the xSPI/8D series that adds support for Cypress S28 > > flash [0] (it is in next now). The patches themselves are independent of > > that series in the sense that they don't rely on 8D support. But since > > S28 flash is not supported without that series, these patches don't make > > much sense without it. > > > > Tested on Cypress S28HS512T and MT35XU512ABA on J7200 and J721E > > respectively. > > > > [0] https://lore.kernel.org/linux-mtd/20201005153138.6437-1-p.ya...@ti.com/ > > Any comments on the series? If not, can it be picked up? > > > Pratyush Yadav (3): > > UBI: Do not zero out EC and VID on ECC-ed NOR flashes > > mtd: spi-nor: core: Allow flashes to specify MTD writesize > > mtd: spi-nor: spansion: Set ECC block size > > > > drivers/mtd/spi-nor/core.c | 4 +++- > > drivers/mtd/spi-nor/core.h | 3 +++ > > drivers/mtd/spi-nor/spansion.c | 1 + > > drivers/mtd/ubi/build.c| 4 +--- > > drivers/mtd/ubi/io.c | 9 - > > 5 files changed, 16 insertions(+), 5 deletions(-) Can we please have am ACK from NOR folks? :-) -- Thanks, //richard
[PATCH 4/7] mtd: Add MTD_MUSE flag
This flag will get set if an MTD is implemeted in userspace
using MUSE.
Signed-off-by: Richard Weinberger
---
include/uapi/mtd/mtd-abi.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/mtd/mtd-abi.h b/include/uapi/mtd/mtd-abi.h
index 65b9db936557..2ad2217e3a96 100644
--- a/include/uapi/mtd/mtd-abi.h
+++ b/include/uapi/mtd/mtd-abi.h
@@ -105,6 +105,7 @@ struct mtd_write_req {
#define MTD_NO_ERASE 0x1000 /* No erase necessary */
#define MTD_POWERUP_LOCK 0x2000 /* Always locked after reset */
#define MTD_SLC_ON_MLC_EMULATION 0x4000/* Emulate SLC behavior on MLC
NANDs */
+#define MTD_MUSE 0x8000 /* This MTD is implemented in userspace
*/
/* Some common devices / combinations of capabilities */
#define MTD_CAP_ROM0
--
2.26.2
[PATCH 1/7] fuse: Export fuse_simple_request
MUSE will use this function to issue requests,
so export it.
Signed-off-by: Richard Weinberger
---
fs/fuse/dev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index 588f8d1240aa..8b7209537683 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -522,6 +522,7 @@ ssize_t fuse_simple_request(struct fuse_mount *fm, struct
fuse_args *args)
return ret;
}
+EXPORT_SYMBOL_GPL(fuse_simple_request);
static bool fuse_request_queue_background(struct fuse_req *req)
{
--
2.26.2
[PATCH 2/7] fuse: Export IO helpers
MUSE will use this functions in its IO path,
so export them.
Signed-off-by: Richard Weinberger
---
fs/fuse/file.c | 16 +++-
fs/fuse/fuse_i.h | 16
2 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index c03034e8c152..ed91ca8b1203 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -20,8 +20,8 @@
#include
#include
-static struct page **fuse_pages_alloc(unsigned int npages, gfp_t flags,
- struct fuse_page_desc **desc)
+struct page **fuse_pages_alloc(unsigned int npages, gfp_t flags,
+ struct fuse_page_desc **desc)
{
struct page **pages;
@@ -31,6 +31,7 @@ static struct page **fuse_pages_alloc(unsigned int npages,
gfp_t flags,
return pages;
}
+EXPORT_SYMBOL_GPL(fuse_pages_alloc);
static int fuse_send_open(struct fuse_mount *fm, u64 nodeid, struct file *file,
int opcode, struct fuse_open_out *outargp)
@@ -1338,17 +1339,6 @@ static inline void fuse_page_descs_length_init(struct
fuse_page_desc *descs,
descs[i].length = PAGE_SIZE - descs[i].offset;
}
-static inline unsigned long fuse_get_user_addr(const struct iov_iter *ii)
-{
- return (unsigned long)ii->iov->iov_base + ii->iov_offset;
-}
-
-static inline size_t fuse_get_frag_size(const struct iov_iter *ii,
- size_t max_size)
-{
- return min(iov_iter_single_seg_count(ii), max_size);
-}
-
static int fuse_get_user_pages(struct fuse_args_pages *ap, struct iov_iter *ii,
size_t *nbytesp, int write,
unsigned int max_pages)
diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h
index d51598017d13..d23954908610 100644
--- a/fs/fuse/fuse_i.h
+++ b/fs/fuse/fuse_i.h
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
/** Default max number of pages that can be used in a single read request */
#define FUSE_DEFAULT_MAX_PAGES_PER_REQ 32
@@ -858,6 +859,17 @@ static inline u64 fuse_get_attr_version(struct fuse_conn
*fc)
return atomic64_read(>attr_version);
}
+static inline unsigned long fuse_get_user_addr(const struct iov_iter *ii)
+{
+ return (unsigned long)ii->iov->iov_base + ii->iov_offset;
+}
+
+static inline size_t fuse_get_frag_size(const struct iov_iter *ii,
+ size_t max_size)
+{
+ return min(iov_iter_single_seg_count(ii), max_size);
+}
+
/** Device operations */
extern const struct file_operations fuse_dev_operations;
@@ -1210,4 +1222,8 @@ void fuse_dax_inode_cleanup(struct inode *inode);
bool fuse_dax_check_alignment(struct fuse_conn *fc, unsigned int
map_alignment);
void fuse_dax_cancel_work(struct fuse_conn *fc);
+/* file.c */
+struct page **fuse_pages_alloc(unsigned int npages, gfp_t flags,
+ struct fuse_page_desc **desc);
+
#endif /* _FS_FUSE_I_H */
--
2.26.2
[PATCH 0/7] [RFC] MUSE: Userspace backed MTD v2
First of all, sorry for sending v2 before getting a review. I found a much better way to process IO and to get rid of all hacks from v1. When working with flash devices a common task is emulating them to run various tests or inspect dumps from real hardware. To achieve that we have plenty of emulators in the mtd subsystem: mtdram, block2mtd, nandsim. Each of them implements a adhoc MTD and have various drawbacks. Over the last years some developers tried to extend them but these attempts often got rejected because they added just more adhoc feature instead of addressing overall problems. MUSE is a novel approach to address the need of advanced MTD emulators. Advanced means in this context supporting different (vendor specific) image formats, different ways for fault injection (fuzzing) and recoding/replaying IOs to emulate power cuts. The core goal of MUSE is having the complexity on the userspace side and only a small MTD driver in kernelspace. While playing with different approaches I realized that FUSE offers everything we need. So MUSE is a little like CUSE except that it does not implement a bare character device but an MTD. To get early feedback I'm sending this series as RFC, so don't consider it as ready to merge yet. Open issues are: 1. Init parameter passing Currently parameter passing borrowed the logic from CUSE and parameters are passed as stringy key value pairs. Most MTD paramerters are numbers (erase size, etc..) so passing them via struct muse_init_out seems more natural. But I plan to pass also pure string parameters such as an mtdparts command line. What is the perffered way these days in FUSE? Am I allowed to embed structs such as struct mtd_info_user (mtd-abi.h) in muse_init_out? 2. OOB (out of band) handling So far OOB support is not implemented. I plan to do so. Mabye just the bare minimum to make jffs2 happy. I'm still digging into FUSE to find a nice way how to implement it. Changes since v1: - Rewrote IO path, fuse_direct_io() is no longer used. Instead of cheating fuse_direct_io() use custom ops to implement reading and writing. That way MUSE no longer needs a dummy file object nor a fuse file object. In MTD all IO is synchronous and operations on kernel buffers, this makes IO processing simple for MUSE. - Support for bad blocks. - No more (ab)use of FUSE ops such as FUSE_FSYNC. - Major code cleanup. This series can also be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rw/misc.git muse_v2 Richard Weinberger (7): fuse: Export fuse_simple_request fuse: Export IO helpers fuse: Make cuse_parse_one a common helper mtd: Add MTD_MUSE flag fuse: Add MUSE specific defines FUSE interface fuse: Implement MUSE: MTD in userspace MAINTAINERS: Add entry for MUSE MAINTAINERS| 7 + fs/fuse/Kconfig| 15 + fs/fuse/Makefile | 2 + fs/fuse/cuse.c | 58 +-- fs/fuse/dev.c | 1 + fs/fuse/file.c | 16 +- fs/fuse/fuse_i.h | 18 + fs/fuse/helper.c | 70 fs/fuse/muse.c | 730 + include/uapi/linux/fuse.h | 73 +++- include/uapi/mtd/mtd-abi.h | 1 + 11 files changed, 920 insertions(+), 71 deletions(-) create mode 100644 fs/fuse/helper.c create mode 100644 fs/fuse/muse.c -- 2.26.2
[PATCH 5/7] fuse: Add MUSE specific defines FUSE interface
Raise the FUSE API minor version to 33 and add all
MUSE specific operations and data structures.
MUSE_INIT: Initialize a new connection and install the MTD
MUSE_ERASE: Erase a block
MUSE_READ: Read a page
MUSE_WRITE: Write a page
MUSE_MARKBAD: Mark a block as bad
MUSE_ISBAD: Check whether a block is bad
MUSE_SYNC: Flush all cached data
Signed-off-by: Richard Weinberger
---
include/uapi/linux/fuse.h | 73 ++-
1 file changed, 72 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/fuse.h b/include/uapi/linux/fuse.h
index 7233502ea991..2f7cbe5ce434 100644
--- a/include/uapi/linux/fuse.h
+++ b/include/uapi/linux/fuse.h
@@ -175,6 +175,10 @@
*
* 7.32
* - add flags to fuse_attr, add FUSE_ATTR_SUBMOUNT, add FUSE_SUBMOUNTS
+ *
+ * 7.33
+ * - add support for MUSE: MUSE_INIT, MUSE_ERASE, MUSE_READ, MUSE_WRITE,
+ *MUSE_MARKBAD, MUSE_ISBAD and MUSE_SYNC
*/
#ifndef _LINUX_FUSE_H
@@ -210,7 +214,7 @@
#define FUSE_KERNEL_VERSION 7
/** Minor version number of this interface */
-#define FUSE_KERNEL_MINOR_VERSION 32
+#define FUSE_KERNEL_MINOR_VERSION 33
/** The node ID of the root inode */
#define FUSE_ROOT_ID 1
@@ -483,6 +487,15 @@ enum fuse_opcode {
/* CUSE specific operations */
CUSE_INIT = 4096,
+ /* MUSE specific operations */
+ MUSE_INIT = 8192,
+ MUSE_ERASE = 8193,
+ MUSE_READ = 8194,
+ MUSE_WRITE = 8195,
+ MUSE_MARKBAD= 8196,
+ MUSE_ISBAD = 8197,
+ MUSE_SYNC = 8198,
+
/* Reserved opcodes: helpful to detect structure endian-ness */
CUSE_INIT_BSWAP_RESERVED= 1048576, /* CUSE_INIT << 8 */
FUSE_INIT_BSWAP_RESERVED= 436207616,/* FUSE_INIT << 24 */
@@ -936,4 +949,62 @@ struct fuse_removemapping_one {
#define FUSE_REMOVEMAPPING_MAX_ENTRY \
(PAGE_SIZE / sizeof(struct fuse_removemapping_one))
+#define MUSE_INIT_INFO_MAX 4096
+
+struct muse_init_in {
+ uint32_tfuse_major;
+ uint32_tfuse_minor;
+};
+
+struct muse_init_out {
+ uint32_tfuse_major;
+ uint32_tfuse_minor;
+ uint32_tmax_read;
+ uint32_tmax_write;
+};
+
+struct muse_erase_in {
+ uint64_taddr;
+ uint64_tlen;
+};
+
+struct muse_read_in {
+ uint64_tdataaddr;
+ uint64_tdatalen;
+ uint32_tflags;
+ uint32_tpadding;
+};
+
+struct muse_read_out {
+ uint64_tdatalen;
+ uint32_tsoft_error;
+ uint32_tpadding;
+};
+
+struct muse_write_in {
+ uint64_tdataaddr;
+ uint64_tdatalen;
+ uint32_tflags;
+ uint32_tpadding;
+};
+
+struct muse_write_out {
+ uint64_tdatalen;
+ uint32_tsoft_error;
+ uint32_tpadding;
+};
+
+struct muse_markbad_in {
+ uint64_taddr;
+};
+
+struct muse_isbad_in {
+ uint64_taddr;
+};
+
+struct muse_isbad_out {
+ uint32_tresult;
+ uint32_tpadding;
+};
+
#endif /* _LINUX_FUSE_H */
--
2.26.2
[PATCH 6/7] fuse: Implement MUSE: MTD in userspace
MUSE allows implementing a MTD in userspace.
So far userspace has control over mtd_read, mtd_write, mtd_erase,
mtd_block_isbad, mtd_block_markbad, and mtd_sync.
It can also set the following MTD parameters:
name, flags, site, writesize and erasesize.
That way advanced simulators for many type of flashes
can be implemented in userspace.
Signed-off-by: Richard Weinberger
---
fs/fuse/Kconfig | 11 +
fs/fuse/Makefile | 1 +
fs/fuse/muse.c | 730 +++
3 files changed, 742 insertions(+)
create mode 100644 fs/fuse/muse.c
diff --git a/fs/fuse/Kconfig b/fs/fuse/Kconfig
index 9c8cc1e7b3a5..2fc63dc18a53 100644
--- a/fs/fuse/Kconfig
+++ b/fs/fuse/Kconfig
@@ -56,3 +56,14 @@ config FUSE_DAX
If you want to allow mounting a Virtio Filesystem with the "dax"
option, answer Y.
+
+config MUSE
+ tristate "Memory Technology Device (MTD) in Userspace support"
+ depends on FUSE_FS
+ select FUSE_HELPER
+ select MTD
+ help
+ This FUSE extension allows an MTD to be implemented in userspace.
+
+ If you want to develop or use a userspace MTD based on MUSE,
+ answer Y or M.
diff --git a/fs/fuse/Makefile b/fs/fuse/Makefile
index 7a5768cce6be..67a7af3fb047 100644
--- a/fs/fuse/Makefile
+++ b/fs/fuse/Makefile
@@ -6,6 +6,7 @@
obj-$(CONFIG_FUSE_FS) += fuse.o
obj-$(CONFIG_CUSE) += cuse.o
obj-$(CONFIG_VIRTIO_FS) += virtiofs.o
+obj-$(CONFIG_MUSE) += muse.o
fuse-y := dev.o dir.o file.o inode.o control.o xattr.o acl.o readdir.o
fuse-$(CONFIG_FUSE_DAX) += dax.o
diff --git a/fs/fuse/muse.c b/fs/fuse/muse.c
new file mode 100644
index ..b947f5aa2e1c
--- /dev/null
+++ b/fs/fuse/muse.c
@@ -0,0 +1,730 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MUSE: MTD in userspace
+ * Copyright (C) 2020 sigma star gmbh
+ * Author: Richard Weinberger
+ */
+
+#define pr_fmt(fmt) "MUSE: " fmt
+
+#include
+#include
+#include
+#include
+#include
+
+#include "fuse_i.h"
+
+static struct file_operations muse_ctrl_fops;
+
+/*
+ * struct muse_conn - MUSE connection object.
+ *
+ * @fm: FUSE mount object.
+ * @fc: FUSE connection object.
+ * @mtd: MTD object.
+ * @init_done: true when the MTD was registered.
+ *
+ * Describes a connection to a userspace server.
+ * Each connection implements a single MTD.
+ */
+struct muse_conn {
+ struct fuse_mount fm;
+ struct fuse_conn fc;
+ struct mtd_info mtd;
+ bool init_done;
+};
+
+struct muse_init_args {
+ struct fuse_args_pages ap;
+ struct muse_init_in in;
+ struct muse_init_out out;
+ struct page *page;
+ struct fuse_page_desc desc;
+};
+
+static void muse_fc_release(struct fuse_conn *fc)
+{
+ struct muse_conn *mc = container_of(fc, struct muse_conn, fc);
+
+ kfree_rcu(mc, fc.rcu);
+}
+
+static int muse_mtd_erase(struct mtd_info *mtd, struct erase_info *instr)
+{
+ struct muse_conn *mc = mtd->priv;
+ struct fuse_mount *fm = >fm;
+ struct muse_erase_in inarg;
+ FUSE_ARGS(args);
+ ssize_t ret;
+
+ inarg.addr = instr->addr;
+ inarg.len = instr->len;
+
+ args.opcode = MUSE_ERASE;
+ args.nodeid = FUSE_ROOT_ID;
+ args.in_numargs = 1;
+ args.in_args[0].size = sizeof(inarg);
+ args.in_args[0].value =
+
+ ret = fuse_simple_request(fm, );
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+static int muse_mtd_markbad(struct mtd_info *mtd, loff_t addr)
+{
+ struct muse_conn *mc = mtd->priv;
+ struct fuse_mount *fm = >fm;
+ struct muse_markbad_in inarg;
+ FUSE_ARGS(args);
+ ssize_t ret;
+
+ inarg.addr = addr;
+
+ args.opcode = MUSE_MARKBAD;
+ args.nodeid = FUSE_ROOT_ID;
+ args.in_numargs = 1;
+ args.in_args[0].size = sizeof(inarg);
+ args.in_args[0].value =
+
+ ret = fuse_simple_request(fm, );
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+static int muse_mtd_isbad(struct mtd_info *mtd, loff_t addr)
+{
+ struct muse_conn *mc = mtd->priv;
+ struct fuse_mount *fm = >fm;
+ struct muse_isbad_in inarg;
+ struct muse_isbad_out outarg;
+ FUSE_ARGS(args);
+ ssize_t ret;
+
+ inarg.addr = addr;
+
+ args.opcode = MUSE_ISBAD;
+ args.nodeid = FUSE_ROOT_ID;
+ args.in_numargs = 1;
+ args.in_args[0].size = sizeof(inarg);
+ args.in_args[0].value =
+ args.out_numargs = 1;
+ args.out_args[0].size = sizeof(outarg);
+ args.out_args[0].value =
+
+ ret = fuse_simple_request(fm, );
+ if (ret < 0)
+ return ret;
+
+ return outarg.result;
+}
+
+static void muse_mtd_sync(struct mtd_info *mtd)
+{
+ struct muse_conn *mc = mtd->priv;
+ struct fuse_mount *fm = >fm;
+ FUSE_ARGS(args);
+
+ args.opcode = MUSE_SYNC;
+ args.nodei
