lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 18 Apr 2022 07:34:52 +0000
From:   常凤楠 <>
To:     Eric Biggers <>
CC:     "" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
Subject: RE: [PATCH 2/3] f2fs: notify when device not supprt inlinecrypt

> -----Original Message-----
> From: Eric Biggers <>
> Sent: Monday, April 18, 2022 3:22 PM
> To: 常凤楠 <>
> Cc:;;;
> Subject: Re: [PATCH 2/3] f2fs: notify when device not supprt inlinecrypt
> On Mon, Apr 18, 2022 at 02:33:11PM +0800, Fengnan Chang via
> Linux-f2fs-devel wrote:
> > Notify when mount filesystem with -o inlinecrypt option, but the
> > device not support inlinecrypt.
> >
> > Signed-off-by: Fengnan Chang <>
> You didn't include a cover letter in this patchset.  Can you explain what
> problem this patchset is meant to solve?

What I'm try to make is when devices not support inlinecrypt, do not show inlinecrypt in mount option. 
When I test fscrypt first, it make me confused. Not a real problem, just make this logical more reasonable.
Do you think this needs to be revised?

> Note that there are multiple factors that affect whether inline encryption can
> be used with a particular file, such as whether the device supports the
> required encryption mode, data unit size, and data unit number size.  So
> your warning might not trigger even if inline encryption can't be used.  Also,
> your warning will never trigger if the kernel has

I get it.

> I recently sent out a patch that makes fs/crypto/ consistently log a message
> when starting to use an encryption implementation for the first time:
> It already did this for the crypto API, but not blk-crypto.  Being silent for
> blk-crypto was somewhat of an oversight.  These log messages make it clear
> which encryption implementations are in use.
> Does that patch solve the problem you are trying to solve?

I think it's a different point.


> - Eric

Powered by blists - more mailing lists