From: Eric Biggers
qcom_ice_program_key() currently accepts the key as an array of bytes,
algorithm ID, key size enum, and data unit size. However both callers
have a struct blk_crypto_key which contains all that information. Thus
they both have similar code that converts the blk_crypto_key
From: Eric Biggers
Add support for hardware-wrapped keys to fscrypt. Such keys are
protected from certain attacks, such as cold boot attacks. For more
information, see the "Hardware-wrapped keys" section of
Documentation/block/inline-encryption.rst.
To support hardware-wrapped keys
From: Eric Biggers
Wire up the wrapped key support for ufs-qcom by implementing the needed
methods in struct blk_crypto_ll_ops and setting the appropriate flag in
blk_crypto_profile::key_types_supported.
For more information about this feature and how to use it, refer to
the sections about
work
correctly; dropped unnecessary support for HWKM v1; fixed error
handling; improved log messages, comments, and commit message;
fixed naming; merged enable and init functions; and other cleanups]
Co-developed-by: Eric Biggers
Signed-off-by: Eric Biggers
---
drivers/mmc/host/sdhci-
o HW-wrapped keys could in
principle be standardized.
- I've reordered the patchset to place preparatory patches that don't
depend on the actual HW-wrapped key support first.
For older changelogs, see
https://lore.kernel.org/r/20241202-wrapped-keys-v7-0-67c3ca3f3...@linaro.org
Hi Jens,
On Mon, Feb 03, 2025 at 10:00:34PM -0800, Eric Biggers wrote:
> This is targeting 6.15. As per the suggestion from Jens
> (https://lore.kernel.org/linux-block/c3407d1c-6c5c-42ee-b446-ccbab1643...@kernel.dk/),
> I'd like patches 1-3 to be queued up into a branch that ge
On Mon, Feb 10, 2025 at 10:14:45AM +0530, Manivannan Sadhasivam wrote:
> On Mon, Feb 03, 2025 at 10:00:41PM -0800, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > Wire up the wrapped key support for ufs-qcom by implementing the needed
> > methods in struct blk_cr
From: Eric Biggers
Wire up the wrapped key support for ufs-qcom by implementing the needed
methods in struct blk_crypto_ll_ops and setting the appropriate flag in
blk_crypto_profile::key_types_supported.
For more information about this feature and how to use it, refer to
the sections about
work
correctly; dropped unnecessary support for HWKM v1; fixed error
handling; improved log messages, comments, and commit message;
fixed naming; merged enable and init functions; and other cleanups]
Co-developed-by: Eric Biggers
Signed-off-by: Eric Biggers
---
drivers/mmc/host/sdhci-
From: Eric Biggers
qcom_ice_program_key() currently accepts the key as an array of bytes,
algorithm ID, key size enum, and data unit size. However both callers
have a struct blk_crypto_key which contains all that information. Thus
they both have similar code that converts the blk_crypto_key
From: Eric Biggers
Until this point, the kernel can use hardware-wrapped keys to do
encryption if userspace provides one -- specifically a key in
ephemerally-wrapped form. However, no generic way has been provided for
userspace to get such a key in the first place.
Getting such a key is a two
From: Eric Biggers
Add support for hardware-wrapped keys to fscrypt. Such keys are
protected from certain attacks, such as cold boot attacks. For more
information, see the "Hardware-wrapped keys" section of
Documentation/block/inline-encryption.rst.
To support hardware-wrapped keys
From: Eric Biggers
Add sysfs files that indicate which type(s) of keys are supported by the
inline encryption hardware associated with a particular request queue:
/sys/block/$disk/queue/crypto/hw_wrapped_keys
/sys/block/$disk/queue/crypto/raw_keys
Userspace can use the presence
From: Eric Biggers
To prevent keys from being compromised if an attacker acquires read
access to kernel memory, some inline encryption hardware can accept keys
which are wrapped by a per-boot hardware-internal key. This avoids
needing to keep the raw keys in kernel memory, without limiting the
- I've reordered the patchset to place preparatory patches that don't
depend on the actual HW-wrapped key support first.
For older changelogs, see
https://lore.kernel.org/r/20241202-wrapped-keys-v7-0-67c3ca3f3...@linaro.org and
https://lore.kernel.org/r/20231104211259.17448-1-ebig
On Fri, Jan 10, 2025 at 09:44:07AM +0100, Bartosz Golaszewski wrote:
> On Fri, Dec 13, 2024 at 5:20 AM Eric Biggers wrote:
> >
> > This patchset is based on next-20241212 and is also available in git via:
> >
> > git fetch https://git.kernel.org/pub/scm/fs/fscrypt/
On Thu, Jan 02, 2025 at 01:40:48PM -0500, Martin K. Petersen wrote:
>
> Eric,
>
> > This patchset adds support for hardware-wrapped inline encryption
> > keys, a security feature supported by some SoCs. It adds the block and
> > fscrypt framework for the feature as well as support for it with UFS
On Thu, Dec 12, 2024 at 08:19:43PM -0800, Eric Biggers wrote:
> Maintainers, please consider merging the following preparatory patches for
> 6.14:
>
> - UFS / SCSI tree: patches 1-4
> - MMC tree: patches 5-7
> - Qualcomm / MSM tree: patch 8
Happy new year everyone.
We
From: Eric Biggers
Wire up the wrapped key support for ufs-qcom by implementing the needed
methods in struct blk_crypto_ll_ops and setting the appropriate flags in
blk_crypto_profile::key_types_supported.
For more information about this feature and how to use it, refer to
the sections about
From: Eric Biggers
Add sysfs files that indicate which type(s) of keys are supported by the
inline encryption hardware associated with a particular request queue:
/sys/block/$disk/queue/crypto/hw_wrapped_keys
/sys/block/$disk/queue/crypto/raw_keys
Userspace can use the presence
[EB: merged related patches, fixed the module parameter to work
correctly, fixed error handling, improved log messages, improved
comments, improved commit message, fixed various names.]
Signed-off-by: Eric Biggers
---
drivers/mmc/host/sdhci-msm.c | 5 +
drivers/soc/qcom/ice.c
From: Eric Biggers
Add support for hardware-wrapped keys to fscrypt. Such keys are
protected from certain attacks, such as cold boot attacks. For more
information, see the "Hardware-wrapped keys" section of
Documentation/block/inline-encryption.rst.
To support hardware-wrapped keys
From: Eric Biggers
Until this point, the kernel can use hardware-wrapped keys to do
encryption if userspace provides one -- specifically a key in
ephemerally-wrapped form. However, no generic way has been provided for
userspace to get such a key in the first place.
Getting such a key is a two
ze parameters, fixed qcom_scm_has_wrapped_key_support(),
improved comments, improved commit message.]
Signed-off-by: Eric Biggers
---
drivers/firmware/qcom/qcom_scm.c | 214 +
drivers/firmware/qcom/qcom_scm.h | 4 +
include/linux/firmware/qcom/qcom_scm.h | 8 +
From: Eric Biggers
To prevent keys from being compromised if an attacker acquires read
access to kernel memory, some inline encryption hardware can accept keys
which are wrapped by a per-boot hardware-internal key. This avoids
needing to keep the raw keys in kernel memory, without limiting the
From: Eric Biggers
As is being done in ufs-qcom, make the sdhci-msm driver override the
full crypto profile rather than "just" key programming and eviction.
This makes it much more straightforward to add support for
hardware-wrapped inline encryption keys. It also makes it easy t
From: Eric Biggers
qcom_ice_program_key() currently accepts the key as an array of bytes,
algorithm ID, key size enum, and data unit size. However both callers
have a struct blk_crypto_key which contains all that information. Thus
they both have similar code that converts the blk_crypto_key
From: Eric Biggers
There are no longer any implementations of
ufs_hba_variant_ops::program_key, so remove it.
As a result, ufshcd_program_key() no longer can return an error, so also
clean it up to return void.
Signed-off-by: Eric Biggers
---
drivers/ufs/core/ufshcd-crypto.c | 20
From: Eric Biggers
Add a helper function that encapsulates a container_of expression. For
now there is just one user but soon there will be more.
Signed-off-by: Eric Biggers
---
drivers/mmc/host/cqhci-crypto.c | 5 +
include/linux/mmc/host.h| 8
2 files changed, 9
From: Eric Biggers
Commit c7eed31e235c ("mmc: sdhci-msm: Switch to the new ICE API")
introduced an incorrect check of the algorithm ID into the key eviction
path, and thus qcom_ice_evict_key() is no longer ever called. Fix it.
Fixes: c7eed31e235c ("mmc: sdhci-msm: Switch to
From: Eric Biggers
By default the UFS core is responsible for initializing the
blk_crypto_profile, but Qualcomm platforms have their own way of
programming and evicting crypto keys. So currently
ufs_hba_variant_ops::program_key is used to redirect control flow from
ufshcd_program_key(). This
From: Eric Biggers
Add a helper function that encapsulates a container_of expression. For
now there are two users but soon there will be more.
Tested-by: Bartosz Golaszewski # sm8650
Signed-off-by: Eric Biggers
---
drivers/ufs/core/ufshcd-crypto.c | 6 ++
include/ufs/ufshcd.h
From: Eric Biggers
Commit 56541c7c4468 ("scsi: ufs: ufs-qcom: Switch to the new ICE API")
introduced an incorrect check of the algorithm ID into the key eviction
path, and thus qcom_ice_evict_key() is no longer ever called. Fix it.
Fixes: 56541c7c4468 ("scsi: ufs: ufs-qcom: Sw
on the actual HW-wrapped key support first.
For older changelogs, see
https://lore.kernel.org/r/20241202-wrapped-keys-v7-0-67c3ca3f3...@linaro.org and
https://lore.kernel.org/r/20231104211259.17448-1-ebigg...@kernel.org
Eric Biggers (13):
ufs: qcom: fix crypto key eviction
ufs: crypto: add ufs_hba_from
On Mon, Dec 09, 2024 at 02:35:29PM -0600, Bartosz Golaszewski wrote:
> On Mon, 9 Dec 2024 21:15:16 +0100, Eric Biggers said:
> > On Mon, Dec 09, 2024 at 04:00:18PM +0100, Bartosz Golaszewski wrote:
> >>
> >> I haven't gotten to the bottom of this yet but the
>
On Mon, Dec 09, 2024 at 04:00:18PM +0100, Bartosz Golaszewski wrote:
>
> I haven't gotten to the bottom of this yet but the
> FS_IOC_ADD_ENCRYPTION_KEY ioctl doesn't work due to the SCM call
> returning EINVAL. Just FYI. I'm still figuring out what's wrong.
>
> Bart
>
Can you try the following?
[EB: merged related patches, fixed the module parameter to work
correctly, fixed error handling, improved log messages, improved
comments, improved commit message, fixed various names.]
Signed-off-by: Eric Biggers
---
drivers/mmc/host/sdhci-msm.c | 5 +
drivers/soc/qcom/ice.c
From: Eric Biggers
Wire up the wrapped key support for ufs-qcom by implementing the needed
methods in struct blk_crypto_ll_ops and setting the appropriate flags in
blk_crypto_profile::key_types_supported.
For more information about this feature and how to use it, refer to
the sections about
From: Eric Biggers
Add support for hardware-wrapped keys to fscrypt. Such keys are
protected from certain attacks, such as cold boot attacks. For more
information, see the "Hardware-wrapped keys" section of
Documentation/block/inline-encryption.rst.
To support hardware-wrapped keys
From: Eric Biggers
Until this point, the kernel can use hardware-wrapped keys to do
encryption if userspace provides one -- specifically a key in
ephemerally-wrapped form. However, no generic way has been provided for
userspace to get such a key in the first place.
Getting such a key is a two
From: Eric Biggers
Add sysfs files that indicate which type(s) of keys are supported by the
inline encryption hardware associated with a particular request queue:
/sys/block/$disk/queue/crypto/hw_wrapped_keys
/sys/block/$disk/queue/crypto/raw_keys
Userspace can use the presence
From: Eric Biggers
To prevent keys from being compromised if an attacker acquires read
access to kernel memory, some inline encryption hardware can accept keys
which are wrapped by a per-boot hardware-internal key. This avoids
needing to keep the raw keys in kernel memory, without limiting the
From: Eric Biggers
qcom_ice_program_key() currently accepts the key as an array of bytes,
algorithm ID, key size enum, and data unit size. However both callers
have a struct blk_crypto_key which contains all that information. Thus
they both have similar code that converts the blk_crypto_key
ze parameters, fixed qcom_scm_has_wrapped_key_support(),
improved comments, improved commit message.]
Signed-off-by: Eric Biggers
---
drivers/firmware/qcom/qcom_scm.c | 214 +
drivers/firmware/qcom/qcom_scm.h | 4 +
include/linux/firmware/qcom/qcom_scm.h | 8 +
From: Eric Biggers
As is being done in ufs-qcom, make the sdhci-msm driver override the
full crypto profile rather than "just" key programming and eviction.
This makes it much more straightforward to add support for
hardware-wrapped inline encryption keys. It also makes it easy t
From: Eric Biggers
By default the UFS core is responsible for initializing the
blk_crypto_profile, but Qualcomm platforms have their own way of
programming and evicting crypto keys. So currently
ufs_hba_variant_ops::program_key is used to redirect control flow from
ufshcd_program_key(). This
From: Eric Biggers
Add a helper function that encapsulates a container_of expression. For
now there is just one user but soon there will be more.
Signed-off-by: Eric Biggers
---
drivers/mmc/host/cqhci-crypto.c | 5 +
include/linux/mmc/host.h| 8
2 files changed, 9
From: Eric Biggers
Add a helper function that encapsulates a container_of expression. For
now there are two users but soon there will be more.
Signed-off-by: Eric Biggers
---
drivers/ufs/core/ufshcd-crypto.c | 6 ++
include/ufs/ufshcd.h | 8
2 files changed, 10
tl and
tests via xfstests (I have some old patches for this that need to be updated).
Eric Biggers (10):
ufs: crypto: add ufs_hba_from_crypto_profile()
ufs: qcom: convert to use UFSHCD_QUIRK_CUSTOM_CRYPTO_PROFILE
mmc: crypto: add mmc_from_crypto_profile()
mmc: sdhci-msm: convert to use cust
From: Eric Biggers
Add sysfs files that indicate which type(s) of keys are supported by the
inline encryption hardware associated with a particular request queue:
/sys/block/$disk/queue/crypto/hw_wrapped_keys
/sys/block/$disk/queue/crypto/standard_keys
Userspace can use the
From: Eric Biggers
Add support for hardware-wrapped keys to fscrypt. Such keys are
protected from certain attacks, such as cold boot attacks. For more
information, see the "Hardware-wrapped keys" section of
Documentation/block/inline-encryption.rst.
To support hardware-wrapped keys
From: Eric Biggers
To prevent keys from being compromised if an attacker acquires read
access to kernel memory, some inline encryption hardware can accept keys
which are wrapped by a per-boot hardware-internal key. This avoids
needing to keep the raw keys in kernel memory, without limiting the
From: Eric Biggers
Until this point, the kernel can use hardware-wrapped keys to do
encryption if userspace provides one -- specifically a key in
ephemerally-wrapped form. However, no generic way has been provided for
userspace to get such a key in the first place.
Getting such a key is a two
and fscrypt branches.
- Minor cleanups.
Changes in v2:
- Added new ioctls for creating and preparing hardware-wrapped keys.
- Rebased onto my patchset which renames blk_keyslot_manager to
blk_crypto_profile.
Eric Biggers (4):
blk-crypto: add basic hardware-wrapped key support
On Thu, Oct 17, 2019 at 05:28:29PM +0100, Richard W.M. Jones wrote:
> On Thu, Oct 17, 2019 at 10:47:59AM -0500, Mike Christie wrote:
> > On 10/17/2019 09:03 AM, Richard W.M. Jones wrote:
> > > On Tue, Oct 01, 2019 at 04:19:25PM -0500, Mike Christie wrote:
> > >> Hey Josef and nbd list,
> > >>
> > >
On Wed, Sep 25, 2019 at 10:13:30PM +, Damien Le Moal wrote:
> On 2019/09/25 10:56, Damien Le Moal wrote:
> > On 2019/09/25 9:56, syzbot wrote:
> >> Hello,
> >>
> >> syzbot found the following crash on:
> >>
> >> HEAD commit:f7c3bf8f Merge tag 'gfs2-for-5.4' of
> >> git://git.kernel.org/..
On Wed, Aug 21, 2019 at 12:57:13AM -0700, Satya Tangirala wrote:
> Introduce fscrypt_set_bio_crypt_ctx for filesystems to call to set up
> encryption contexts in bios, and fscrypt_evict_crypt_key to evict
> the encryption context associated with an inode.
>
> Inline encryption is controlled by a p
On Wed, Aug 21, 2019 at 12:57:11AM -0700, Satya Tangirala wrote:
> +static int ufshcd_crypto_cap_find(void *hba_p,
> +enum blk_crypto_mode_num crypto_mode,
> +unsigned int data_unit_size)
> +{
> + struct ufs_hba *hba = hba_p;
> + enum ufs_cryp
On Wed, Aug 21, 2019 at 12:57:09AM -0700, Satya Tangirala wrote:
> diff --git a/block/blk-crypto.c b/block/blk-crypto.c
> new file mode 100644
> index ..c8f06264a0f5
> --- /dev/null
> +++ b/block/blk-crypto.c
> @@ -0,0 +1,737 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyrig
Hi Satya, a few more minor comments:
On Wed, Aug 21, 2019 at 12:57:07AM -0700, Satya Tangirala wrote:
> +/**
> + * keyslot_manager_create() - Create a keyslot manager
> + * @num_slots: The number of key slots to manage.
> + * @ksm_ll_ops: The struct keyslot_mgmt_ll_ops for the device that this
>
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 11 of them as possibly being bugs in the block subsystem
Hi Satya, here's yet another round of comments. I'd really like for
people who are experts in the block layer to review this too, though.
The integration into the block layer needs more review.
On Wed, Jul 10, 2019 at 03:56:04PM -0700, Satya Tangirala wrote:
> We introduce blk-crypto, which manag
Hi Satya,
On Wed, Jul 10, 2019 at 03:56:08PM -0700, Satya Tangirala wrote:
> Introduce fscrypt_set_bio_crypt_ctx for filesystems to call to set up
> encryption contexts in bios, and fscrypt_evict_crypt_key to evict
> the encryption context associated with an inode.
>
> Inline encryption is contro
Jens, any idea about this?
On Mon, Jun 24, 2019 at 01:21:06AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:bed3c0d8 Merge tag 'for-5.2-rc5-tag' of git://git.kernel.o..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.t
[This email was generated by a script. Let me know if you have any suggestions
to make it better.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 11 of them as possibly being bugs in the block subsystem. I've listed
these reports below, sorted by an algori
Hi Satya,
On Wed, Jun 05, 2019 at 04:28:36PM -0700, Satya Tangirala wrote:
> Introduce fscrypt_set_bio_crypt_ctx for filesystems to call to set up
> encryption contexts in bios, and fscrypt_evict_crypt_key to evict
> the encryption context associated with an inode.
>
> Inline encryption is contro
On Wed, Jun 05, 2019 at 04:28:35PM -0700, Satya Tangirala wrote:
> +static inline int ufshcd_prepare_lrbp_crypto(struct ufs_hba *hba,
> + struct scsi_cmnd *cmd,
> + struct ufshcd_lrb *lrbp)
> +{
> + int key_slot;
From: Eric Biggers
Opening and closing an io_uring instance leaks a UNIX domain socket
inode. This is because the ->file of the io_uring instance's internal
UNIX domain socket is set to point to the io_uring file, but then
sock_release() sees the non-NULL ->file and assumes the inod
Hi Satya,
On Wed, Jun 05, 2019 at 04:28:34PM -0700, Satya Tangirala wrote:
> Introduce functions to manipulate UFS inline encryption hardware
> in line with the JEDEC UFSHCI v2.1 specification and to work with the
> block keyslot manager.
>
> Signed-off-by: Satya Tangirala
> ---
> drivers/scsi/
On Wed, Jun 05, 2019 at 04:28:32PM -0700, Satya Tangirala wrote:
> We introduce blk-crypto, which manages programming keyslots for struct
> bios. With blk-crypto, filesystems only need to call bio_crypt_set_ctx with
> the encryption key, algorithm and data_unit_num; they don't have to worry
> about
On Wed, Jun 05, 2019 at 04:28:30PM -0700, Satya Tangirala wrote:
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index 592669bcc536..f76d5dff27fe 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -385,6 +385,10 @@ static inline int blkdev_reset_zones_ioctl(s
Hi Satya,
On Wed, Jun 05, 2019 at 04:28:31PM -0700, Satya Tangirala wrote:
> We must have some way of letting a storage device driver know what
> encryption context it should use for en/decrypting a request. However,
> it's the filesystem/fscrypt that knows about and manages encryption
> contexts.
Hi Satya,
On Wed, Jun 05, 2019 at 04:28:30PM -0700, Satya Tangirala wrote:
>
> Known issues:
> 1) Keyslot Manager has a performance bug where the same encryption
>context may be programmed into multiple keyslots at the same time in
>certain situations when all keyslots are being used.
Th
Hi Jens,
On Thu, Feb 21, 2019 at 10:45:27AM -0700, Jens Axboe wrote:
> On 2/20/19 3:58 PM, Ming Lei wrote:
> > On Mon, Feb 11, 2019 at 12:00:41PM -0700, Jens Axboe wrote:
> >> For an ITER_BVEC, we can just iterate the iov and add the pages
> >> to the bio directly. This requires that the caller do
[+Cc other people who have been working on this]
Hi Parshuram,
On Tue, Dec 11, 2018 at 09:50:27AM +, Parshuram Thombare wrote:
> Add real time crypto support to UFS HCD using new device
> mapper 'crypto-ufs'. dmsetup tool can be used to enable
> real time / inline crypto support using device
From: Eric Biggers
blk_try_req_merge() is only used in block/blk-merge.c, so make it
static.
This addresses a gcc warning when -Wmissing-prototypes is enabled.
Signed-off-by: Eric Biggers
---
block/blk-merge.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/block/blk
On Mon, 30 Oct 2017 12:32:58 -0700, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 36ef71cae353f88fd6e095e2aaa3e5953af1685d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console outpu
On Fri, Jan 26, 2018 at 04:58:06PM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> 'struct blk_user_trace_setup' is passed to BLKTRACESETUP, not
> BLKTRACESTART.
>
> Signed-off-by: Eric Biggers
> ---
> include/uapi/linux/blktrace_api.h | 2 +-
> 1 fil
On Thu, Jan 11, 2018 at 06:00:08PM +0100, Jan Kara wrote:
> On Thu 11-01-18 19:22:39, Hou Tao wrote:
> > Hi,
> >
> > On 2018/1/11 16:24, Dan Carpenter wrote:
> > > Thanks for your report and the patch. I am sending it to the
> > > linux-block devs since it's already public.
> > >
> > > regards,
On Tue, Dec 19, 2017 at 06:42:00AM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console o
From: Eric Biggers
'struct blk_user_trace_setup' is passed to BLKTRACESETUP, not
BLKTRACESTART.
Signed-off-by: Eric Biggers
---
include/uapi/linux/blktrace_api.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/blktrace_api.h
b/include/
From: Eric Biggers
This reverts commit ba62bafe942b159a6109cbec780d36496e06b6c5.
This commit introduced a double free bug, because 'chan' is already
freed by the line:
kref_put(&chan->kref, relay_destroy_channel);
This bug was found by syzkaller, using the BLKTRACESE
On Mon, Dec 04, 2017 at 12:26:32PM +0300, Dan Carpenter wrote:
> On Mon, Dec 04, 2017 at 09:18:05AM +0100, Dmitry Vyukov wrote:
> > On Mon, Dec 4, 2017 at 9:14 AM, Dan Carpenter
> > wrote:
> > > On Sun, Dec 03, 2017 at 12:16:08PM -0800, Eric Biggers wrote:
> > >&
On Sun, Dec 03, 2017 at 05:24:32PM -0700, Jens Axboe wrote:
> On 12/03/2017 01:24 PM, Eric Biggers wrote:
> > On Sun, Nov 19, 2017 at 02:36:01AM -0800, syzbot wrote:
> >> Hello,
> >>
> >> syzkaller hit the following crash on
> >> d9e0e63d9a6f88440eb20
On Sun, Nov 19, 2017 at 02:36:01AM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> d9e0e63d9a6f88440eb201e1491fcf730272c706
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console o
+Cc linux-block
On Sun, Dec 03, 2017 at 06:25:01AM -0800, syzbot wrote:
> WARNING: CPU: 0 PID: 3081 at mm/slab_common.c:971 kmalloc_slab+0x5d/0x70
> mm/slab_common.c:971
> Kernel panic - not syncing: panic_on_warn set ...
>
[...]
> __do_kmalloc mm/slab.c:3706 [inline]
> __kmalloc+0x25/0x760 mm/
On Wed, Nov 01, 2017 at 10:02:44PM +0300, 'Dmitry Vyukov' via syzkaller-bugs
wrote:
>
> Still happens on linux-next 36ef71cae353f88fd6e095e2aaa3e5953af1685d (Oct 20).
> Note repro needs to be compiled with -m32
>
> [ 243.819514] ==
> [ 243.82
From: Eric Biggers
gcc 7.1 reports the following warning:
block/elevator.c: In function ‘elv_register’:
block/elevator.c:898:5: warning: ‘snprintf’ output may be truncated before
the last format character [-Wformat-truncation=]
"%s_io_cq", e->
Hi Elena,
On Fri, Apr 21, 2017 at 10:55:29AM +, Reshetova, Elena wrote:
> >
> > At the very least, what is there now could probably be made about twice as
> > fast
> > by removing the checks that don't actually help mitigate refcount overflow
> > bugs,
> > specifically all the checks in ref
Hi Elena,
On Thu, Apr 20, 2017 at 04:10:16PM +, Reshetova, Elena wrote:
>
> > All the objections from DaveM on the amount of cycles spent on the
> > new refcount_t apply to the block layer fast path operations as well.
>
> Ok, could you please indicate the correct way to measure the impact f
From: Eric Biggers
Constify all instances of blk_mq_ops, as they are never modified.
Signed-off-by: Eric Biggers
---
drivers/block/loop.c | 2 +-
drivers/block/mtip32xx/mtip32xx.c | 2 +-
drivers/block/nbd.c | 2 +-
drivers/block/null_blk.c | 2 +-
drivers
From: Eric Biggers
_submit_bh() allowed submitting a buffer_head for I/O using custom
bio_flags. It used to be used by jbd to set BIO_SNAP_STABLE, introduced
by commit 713685111774 ("mm: make snapshotting pages for stable writes a
per-bio operation"). However, the code and flag has
From: Eric Biggers
blk_integrity_profile's are never modified, so mark them 'const' so that
they are placed in .rodata and benefit from memory protection.
Signed-off-by: Eric Biggers
---
block/blk-integrity.c | 2 +-
block/t10-pi.c | 8
include/linu
On Mon, Jan 23, 2017 at 11:43:21AM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> blkdev_issue_flush() is now always synchronous, and it no longer has a
> flags argument. So remove the part of the comment about the WAIT flag.
>
> Signed-off-by: Eric Biggers
> ---
>
On Mon, Jan 23, 2017 at 11:41:39AM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> BLKDEV_IFL_* flags no longer exist; blkdev_issue_discard() now actually
> takes BLKDEV_DISCARD_* flags.
>
> Signed-off-by: Eric Biggers
> ---
> block/blk-lib.c | 2 +-
> 1 file
From: Eric Biggers
blkdev_issue_flush() is now always synchronous, and it no longer has a
flags argument. So remove the part of the comment about the WAIT flag.
Signed-off-by: Eric Biggers
---
block/blk-flush.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/block/blk
From: Eric Biggers
BLKDEV_IFL_* flags no longer exist; blkdev_issue_discard() now actually
takes BLKDEV_DISCARD_* flags.
Signed-off-by: Eric Biggers
---
block/blk-lib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/blk-lib.c b/block/blk-lib.c
index ed89c8f4b2a0
97 matches
Mail list logo
