Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1593407 > unrolled thread
| Started by | Elena Reshetova <elena.reshetova@intel.com> |
|---|---|
| First post | 2017-03-06 15:30 +0100 |
| Last post | 2017-03-06 16:30 +0100 |
| Articles | 20 on this page of 57 — 14 participants |
Back to article view | Back to linux.kernel
[PATCH 00/29] drivers, mics refcount conversions Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:30 +0100
[PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:30 +0100
Re: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t Shaohua Li <shli@kernel.org> - 2017-03-07 20:20 +0100
RE: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t "Reshetova, Elena" <elena.reshetova@intel.com> - 2017-03-08 10:50 +0100
Re: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org> - 2017-03-08 11:30 +0100
Re: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t Michael Ellerman <mpe@ellerman.id.au> - 2017-03-14 13:20 +0100
RE: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t "Reshetova, Elena" <elena.reshetova@intel.com> - 2017-03-14 13:40 +0100
Re: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-03-14 16:00 +0100
RE: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t "Reshetova, Elena" <elena.reshetova@intel.com> - 2017-03-16 19:10 +0100
[PATCH 10/29] drivers, md: convert stripe_head.count from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:30 +0100
Re: [PATCH 10/29] drivers, md: convert stripe_head.count from atomic_t to refcount_t Shaohua Li <shli@kernel.org> - 2017-03-07 20:20 +0100
RE: [PATCH 10/29] drivers, md: convert stripe_head.count from atomic_t to refcount_t "Reshetova, Elena" <elena.reshetova@intel.com> - 2017-03-08 10:50 +0100
[PATCH 26/29] drivers, usb: convert dev_data.count from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:30 +0100
[PATCH 06/29] drivers, md: convert dm_cache_metadata.ref_count from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:30 +0100
[PATCH 24/29] drivers: convert iblock_req.pending from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:30 +0100
Re: [PATCH 24/29] drivers: convert iblock_req.pending from atomic_t to refcount_t "Nicholas A. Bellinger" <nab@linux-iscsi.org> - 2017-03-08 08:50 +0100
Re: [PATCH 24/29] drivers: convert iblock_req.pending from atomic_t to refcount_t "Nicholas A. Bellinger" <nab@linux-iscsi.org> - 2017-03-21 08:20 +0100
[PATCH 02/29] drivers, firewire: convert fw_node.ref_count from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:30 +0100
[PATCH 13/29] drivers, media: convert vb2_vmarea_handler.refcount from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:40 +0100
Re: [PATCH 13/29] drivers, media: convert vb2_vmarea_handler.refcount from atomic_t to refcount_t Sakari Ailus <sakari.ailus@iki.fi> - 2017-03-07 10:00 +0100
RE: [PATCH 13/29] drivers, media: convert vb2_vmarea_handler.refcount from atomic_t to refcount_t "Reshetova, Elena" <elena.reshetova@intel.com> - 2017-03-07 16:00 +0100
[PATCH 16/29] drivers, media: convert vb2_vmalloc_buf.refcount from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:40 +0100
[PATCH 15/29] drivers, media: convert vb2_dma_sg_buf.refcount from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:40 +0100
[PATCH 22/29] drivers, scsi: convert iscsi_task.refcount from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:40 +0100
Re: [PATCH 22/29] drivers, scsi: convert iscsi_task.refcount from atomic_t to refcount_t Chris Leech <cleech@redhat.com> - 2017-03-08 19:50 +0100
RE: [PATCH 22/29] drivers, scsi: convert iscsi_task.refcount from atomic_t to refcount_t "Reshetova, Elena" <elena.reshetova@intel.com> - 2017-03-09 08:30 +0100
Re: [PATCH 22/29] drivers, scsi: convert iscsi_task.refcount from atomic_t to refcount_t Johannes Thumshirn <jthumshirn@suse.de> - 2017-03-09 09:50 +0100
RE: [PATCH 22/29] drivers, scsi: convert iscsi_task.refcount from atomic_t to refcount_t "Reshetova, Elena" <elena.reshetova@intel.com> - 2017-03-09 10:30 +0100
Re: [PATCH 22/29] drivers, scsi: convert iscsi_task.refcount from atomic_t to refcount_t Johannes Thumshirn <jthumshirn@suse.de> - 2017-03-09 10:40 +0100
[PATCH 27/29] drivers, usb: convert ep_data.count from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:40 +0100
[PATCH 19/29] drivers, s390: convert lcs_reply.refcnt from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:40 +0100
[PATCH 21/29] drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:40 +0100
Re: [PATCH 21/29] drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t Johannes Thumshirn <jthumshirn@suse.de> - 2017-03-06 16:30 +0100
Re: [PATCH 21/29] drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t Benjamin Block <bblock@linux.vnet.ibm.com> - 2017-03-06 20:50 +0100
RE: [PATCH 21/29] drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t "Reshetova, Elena" <elena.reshetova@intel.com> - 2017-03-07 12:20 +0100
RE: [PATCH 21/29] drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t "Reshetova, Elena" <elena.reshetova@intel.com> - 2017-03-08 15:00 +0100
Re: [PATCH 21/29] drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t Johannes Thumshirn <jthumshirn@suse.de> - 2017-03-08 16:30 +0100
[PATCH 23/29] drivers: convert vme_user_vma_priv.refcnt from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:40 +0100
[PATCH 14/29] drivers, media: convert vb2_dc_buf.refcount from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:40 +0100
[PATCH 04/29] drivers, connector: convert cn_callback_entry.refcnt from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:40 +0100
[PATCH 05/29] drivers, md, bcache: convert cached_dev.count from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:40 +0100
[PATCH 17/29] drivers, pci: convert hv_pci_dev.refs from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:40 +0100
Re: [PATCH 17/29] drivers, pci: convert hv_pci_dev.refs from atomic_t to refcount_t Bjorn Helgaas <helgaas@kernel.org> - 2017-03-06 23:30 +0100
Re: [PATCH 17/29] drivers, pci: convert hv_pci_dev.refs from atomic_t to refcount_t Stephen Hemminger <stephen@networkplumber.org> - 2017-03-07 21:00 +0100
[PATCH 20/29] drivers, s390: convert qeth_reply.refcnt from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:40 +0100
[PATCH 07/29] drivers, md: convert dm_dev_internal.count from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:40 +0100
[PATCH 29/29] drivers, xen: convert grant_map.users from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:40 +0100
Re: [Xen-devel] [PATCH 29/29] drivers, xen: convert grant_map.users from atomic_t to refcount_t Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-03-06 19:50 +0100
RE: [Xen-devel] [PATCH 29/29] drivers, xen: convert grant_map.users from atomic_t to refcount_t "Reshetova, Elena" <elena.reshetova@intel.com> - 2017-03-08 15:10 +0100
Re: [Xen-devel] [PATCH 29/29] drivers, xen: convert grant_map.users from atomic_t to refcount_t Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-03-08 18:50 +0100
RE: [Xen-devel] [PATCH 29/29] drivers, xen: convert grant_map.users from atomic_t to refcount_t "Reshetova, Elena" <elena.reshetova@intel.com> - 2017-03-09 08:30 +0100
[PATCH 25/29] drivers, usb: convert ffs_data.ref from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:40 +0100
[PATCH 28/29] drivers: convert sbd_duart.map_guard from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:40 +0100
[PATCH 09/29] drivers, md: convert table_device.count from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:50 +0100
[PATCH 01/29] drivers, block: convert xen_blkif.refcnt from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:50 +0100
[PATCH 18/29] drivers, s390: convert urdev.ref_count from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 15:50 +0100
[PATCH 03/29] drivers, char: convert vma_data.refcnt from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-06 16:30 +0100
Page 1 of 3 [1] 2 3 Next page →
| From | Elena Reshetova <elena.reshetova@intel.com> |
|---|---|
| Date | 2017-03-06 15:30 +0100 |
| Subject | [PATCH 00/29] drivers, mics refcount conversions |
| Message-ID | <ti1O9-Yn-3@gated-at.bofh.it> |
This series, for various different drivers, replaces atomic_t reference
counters with the new refcount_t type and API (see include/linux/refcount.h).
By doing this we prevent intentional or accidental
underflows or overflows that can led to use-after-free vulnerabilities.
The below patches are fully independent and can be cherry-picked separately*.
Since we convert all kernel subsystems in the same fashion, resulting
in about 300 patches, we have to group them for sending at least in some
fashion to be manageable. Please excuse the long cc list.
*with the exception of the media/vb2-related patches that depend on
vb2_vmarea_handler.refcount conversions.
Not run-time tested beyond booting and using kernel with refcount conversions
for my daily work.
If there are no objections to these patches,
I think they can go via Greg's drivers tree, as he suggested before.
Elena Reshetova (29):
drivers, block: convert xen_blkif.refcnt from atomic_t to refcount_t
drivers, firewire: convert fw_node.ref_count from atomic_t to
refcount_t
drivers, char: convert vma_data.refcnt from atomic_t to refcount_t
drivers, connector: convert cn_callback_entry.refcnt from atomic_t to
refcount_t
drivers, md, bcache: convert cached_dev.count from atomic_t to
refcount_t
drivers, md: convert dm_cache_metadata.ref_count from atomic_t to
refcount_t
drivers, md: convert dm_dev_internal.count from atomic_t to refcount_t
drivers, md: convert mddev.active from atomic_t to refcount_t
drivers, md: convert table_device.count from atomic_t to refcount_t
drivers, md: convert stripe_head.count from atomic_t to refcount_t
drivers, media: convert cx88_core.refcount from atomic_t to refcount_t
drivers, media: convert s2255_dev.num_channels from atomic_t to
refcount_t
drivers, media: convert vb2_vmarea_handler.refcount from atomic_t to
refcount_t
drivers, media: convert vb2_dc_buf.refcount from atomic_t to
refcount_t
drivers, media: convert vb2_dma_sg_buf.refcount from atomic_t to
refcount_t
drivers, media: convert vb2_vmalloc_buf.refcount from atomic_t to
refcount_t
drivers, pci: convert hv_pci_dev.refs from atomic_t to refcount_t
drivers, s390: convert urdev.ref_count from atomic_t to refcount_t
drivers, s390: convert lcs_reply.refcnt from atomic_t to refcount_t
drivers, s390: convert qeth_reply.refcnt from atomic_t to refcount_t
drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t
drivers, scsi: convert iscsi_task.refcount from atomic_t to refcount_t
drivers: convert vme_user_vma_priv.refcnt from atomic_t to refcount_t
drivers: convert iblock_req.pending from atomic_t to refcount_t
drivers, usb: convert ffs_data.ref from atomic_t to refcount_t
drivers, usb: convert dev_data.count from atomic_t to refcount_t
drivers, usb: convert ep_data.count from atomic_t to refcount_t
drivers: convert sbd_duart.map_guard from atomic_t to refcount_t
drivers, xen: convert grant_map.users from atomic_t to refcount_t
drivers/block/xen-blkback/common.h | 7 +--
drivers/block/xen-blkback/xenbus.c | 2 +-
drivers/char/mspec.c | 9 ++--
drivers/connector/cn_queue.c | 4 +-
drivers/connector/connector.c | 2 +-
drivers/firewire/core-topology.c | 2 +-
drivers/firewire/core.h | 8 ++--
drivers/md/bcache/bcache.h | 7 +--
drivers/md/bcache/super.c | 6 +--
drivers/md/bcache/writeback.h | 2 +-
drivers/md/dm-cache-metadata.c | 9 ++--
drivers/md/dm-table.c | 6 +--
drivers/md/dm.c | 12 +++--
drivers/md/dm.h | 3 +-
drivers/md/md.c | 6 +--
drivers/md/md.h | 3 +-
drivers/md/raid5-cache.c | 8 ++--
drivers/md/raid5.c | 66 +++++++++++++-------------
drivers/md/raid5.h | 3 +-
drivers/media/pci/cx88/cx88-cards.c | 2 +-
drivers/media/pci/cx88/cx88-core.c | 4 +-
drivers/media/pci/cx88/cx88.h | 3 +-
drivers/media/usb/s2255/s2255drv.c | 21 ++++----
drivers/media/v4l2-core/videobuf2-dma-contig.c | 11 +++--
drivers/media/v4l2-core/videobuf2-dma-sg.c | 11 +++--
drivers/media/v4l2-core/videobuf2-memops.c | 6 +--
drivers/media/v4l2-core/videobuf2-vmalloc.c | 11 +++--
drivers/pci/host/pci-hyperv.c | 9 ++--
drivers/s390/char/vmur.c | 8 ++--
drivers/s390/char/vmur.h | 4 +-
drivers/s390/net/lcs.c | 8 ++--
drivers/s390/net/lcs.h | 3 +-
drivers/s390/net/qeth_core.h | 3 +-
drivers/s390/net/qeth_core_main.c | 8 ++--
drivers/scsi/libfc/fc_fcp.c | 6 +--
drivers/scsi/libiscsi.c | 8 ++--
drivers/scsi/qedi/qedi_iscsi.c | 2 +-
drivers/staging/vme/devices/vme_user.c | 10 ++--
drivers/target/target_core_iblock.c | 12 ++---
drivers/target/target_core_iblock.h | 3 +-
drivers/tty/serial/sb1250-duart.c | 18 +++----
drivers/usb/gadget/function/f_fs.c | 8 ++--
drivers/usb/gadget/function/u_fs.h | 3 +-
drivers/usb/gadget/legacy/inode.c | 17 +++----
drivers/xen/gntdev.c | 11 +++--
include/linux/connector.h | 4 +-
include/media/videobuf2-memops.h | 3 +-
include/scsi/libfc.h | 3 +-
include/scsi/libiscsi.h | 3 +-
49 files changed, 203 insertions(+), 185 deletions(-)
--
2.7.4
[toc] | [next] | [standalone]
| From | Elena Reshetova <elena.reshetova@intel.com> |
|---|---|
| Date | 2017-03-06 15:30 +0100 |
| Subject | [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t |
| Message-ID | <ti1O9-Yn-7@gated-at.bofh.it> |
| In reply to | #1593407 |
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: David Windsor <dwindsor@gmail.com>
---
drivers/md/md.c | 6 +++---
drivers/md/md.h | 3 ++-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 985374f..94c8ebf 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -449,7 +449,7 @@ EXPORT_SYMBOL(md_unplug);
static inline struct mddev *mddev_get(struct mddev *mddev)
{
- atomic_inc(&mddev->active);
+ refcount_inc(&mddev->active);
return mddev;
}
@@ -459,7 +459,7 @@ static void mddev_put(struct mddev *mddev)
{
struct bio_set *bs = NULL;
- if (!atomic_dec_and_lock(&mddev->active, &all_mddevs_lock))
+ if (!refcount_dec_and_lock(&mddev->active, &all_mddevs_lock))
return;
if (!mddev->raid_disks && list_empty(&mddev->disks) &&
mddev->ctime == 0 && !mddev->hold_active) {
@@ -495,7 +495,7 @@ void mddev_init(struct mddev *mddev)
INIT_LIST_HEAD(&mddev->all_mddevs);
setup_timer(&mddev->safemode_timer, md_safemode_timeout,
(unsigned long) mddev);
- atomic_set(&mddev->active, 1);
+ refcount_set(&mddev->active, 1);
atomic_set(&mddev->openers, 0);
atomic_set(&mddev->active_io, 0);
spin_lock_init(&mddev->lock);
diff --git a/drivers/md/md.h b/drivers/md/md.h
index b8859cb..4811663 100644
--- a/drivers/md/md.h
+++ b/drivers/md/md.h
@@ -22,6 +22,7 @@
#include <linux/list.h>
#include <linux/mm.h>
#include <linux/mutex.h>
+#include <linux/refcount.h>
#include <linux/timer.h>
#include <linux/wait.h>
#include <linux/workqueue.h>
@@ -360,7 +361,7 @@ struct mddev {
*/
struct mutex open_mutex;
struct mutex reconfig_mutex;
- atomic_t active; /* general refcount */
+ refcount_t active; /* general refcount */
atomic_t openers; /* number of active opens */
int changed; /* True if we might need to
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Shaohua Li <shli@kernel.org> |
|---|---|
| Date | 2017-03-07 20:20 +0100 |
| Subject | Re: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t |
| Message-ID | <tisOl-3ze-1@gated-at.bofh.it> |
| In reply to | #1593408 |
On Mon, Mar 06, 2017 at 04:20:55PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
Looks good. Let me know how do you want to route the patch to upstream.
> Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
> Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: David Windsor <dwindsor@gmail.com>
> ---
> drivers/md/md.c | 6 +++---
> drivers/md/md.h | 3 ++-
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 985374f..94c8ebf 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -449,7 +449,7 @@ EXPORT_SYMBOL(md_unplug);
>
> static inline struct mddev *mddev_get(struct mddev *mddev)
> {
> - atomic_inc(&mddev->active);
> + refcount_inc(&mddev->active);
> return mddev;
> }
>
> @@ -459,7 +459,7 @@ static void mddev_put(struct mddev *mddev)
> {
> struct bio_set *bs = NULL;
>
> - if (!atomic_dec_and_lock(&mddev->active, &all_mddevs_lock))
> + if (!refcount_dec_and_lock(&mddev->active, &all_mddevs_lock))
> return;
> if (!mddev->raid_disks && list_empty(&mddev->disks) &&
> mddev->ctime == 0 && !mddev->hold_active) {
> @@ -495,7 +495,7 @@ void mddev_init(struct mddev *mddev)
> INIT_LIST_HEAD(&mddev->all_mddevs);
> setup_timer(&mddev->safemode_timer, md_safemode_timeout,
> (unsigned long) mddev);
> - atomic_set(&mddev->active, 1);
> + refcount_set(&mddev->active, 1);
> atomic_set(&mddev->openers, 0);
> atomic_set(&mddev->active_io, 0);
> spin_lock_init(&mddev->lock);
> diff --git a/drivers/md/md.h b/drivers/md/md.h
> index b8859cb..4811663 100644
> --- a/drivers/md/md.h
> +++ b/drivers/md/md.h
> @@ -22,6 +22,7 @@
> #include <linux/list.h>
> #include <linux/mm.h>
> #include <linux/mutex.h>
> +#include <linux/refcount.h>
> #include <linux/timer.h>
> #include <linux/wait.h>
> #include <linux/workqueue.h>
> @@ -360,7 +361,7 @@ struct mddev {
> */
> struct mutex open_mutex;
> struct mutex reconfig_mutex;
> - atomic_t active; /* general refcount */
> + refcount_t active; /* general refcount */
> atomic_t openers; /* number of active opens */
>
> int changed; /* True if we might need to
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[toc] | [prev] | [next] | [standalone]
| From | "Reshetova, Elena" <elena.reshetova@intel.com> |
|---|---|
| Date | 2017-03-08 10:50 +0100 |
| Subject | RE: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t |
| Message-ID | <tiGoi-4Ft-23@gated-at.bofh.it> |
| In reply to | #1594551 |
> On Mon, Mar 06, 2017 at 04:20:55PM +0200, Elena Reshetova wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
>
> Looks good. Let me know how do you want to route the patch to upstream.
Greg, you previously mentioned that driver's conversions can go via your tree. Does this still apply?
Or should I be asking maintainers to merge these patches via their trees?
I am not sure about the correct (and easier for everyone) way, please suggest.
Best Regards,
Elena.
>
> > Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
> > Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com>
> > Signed-off-by: Kees Cook <keescook@chromium.org>
> > Signed-off-by: David Windsor <dwindsor@gmail.com>
> > ---
> > drivers/md/md.c | 6 +++---
> > drivers/md/md.h | 3 ++-
> > 2 files changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/md/md.c b/drivers/md/md.c
> > index 985374f..94c8ebf 100644
> > --- a/drivers/md/md.c
> > +++ b/drivers/md/md.c
> > @@ -449,7 +449,7 @@ EXPORT_SYMBOL(md_unplug);
> >
> > static inline struct mddev *mddev_get(struct mddev *mddev)
> > {
> > - atomic_inc(&mddev->active);
> > + refcount_inc(&mddev->active);
> > return mddev;
> > }
> >
> > @@ -459,7 +459,7 @@ static void mddev_put(struct mddev *mddev)
> > {
> > struct bio_set *bs = NULL;
> >
> > - if (!atomic_dec_and_lock(&mddev->active, &all_mddevs_lock))
> > + if (!refcount_dec_and_lock(&mddev->active, &all_mddevs_lock))
> > return;
> > if (!mddev->raid_disks && list_empty(&mddev->disks) &&
> > mddev->ctime == 0 && !mddev->hold_active) {
> > @@ -495,7 +495,7 @@ void mddev_init(struct mddev *mddev)
> > INIT_LIST_HEAD(&mddev->all_mddevs);
> > setup_timer(&mddev->safemode_timer, md_safemode_timeout,
> > (unsigned long) mddev);
> > - atomic_set(&mddev->active, 1);
> > + refcount_set(&mddev->active, 1);
> > atomic_set(&mddev->openers, 0);
> > atomic_set(&mddev->active_io, 0);
> > spin_lock_init(&mddev->lock);
> > diff --git a/drivers/md/md.h b/drivers/md/md.h
> > index b8859cb..4811663 100644
> > --- a/drivers/md/md.h
> > +++ b/drivers/md/md.h
> > @@ -22,6 +22,7 @@
> > #include <linux/list.h>
> > #include <linux/mm.h>
> > #include <linux/mutex.h>
> > +#include <linux/refcount.h>
> > #include <linux/timer.h>
> > #include <linux/wait.h>
> > #include <linux/workqueue.h>
> > @@ -360,7 +361,7 @@ struct mddev {
> > */
> > struct mutex open_mutex;
> > struct mutex reconfig_mutex;
> > - atomic_t active;
> /* general refcount */
> > + refcount_t active;
> /* general refcount */
> > atomic_t openers; /*
> number of active opens */
> >
> > int
> changed; /* True if we might need to
> > --
> > 2.7.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
[toc] | [prev] | [next] | [standalone]
| From | "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2017-03-08 11:30 +0100 |
| Subject | Re: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t |
| Message-ID | <tiH10-5e8-21@gated-at.bofh.it> |
| In reply to | #1594990 |
On Wed, Mar 08, 2017 at 09:42:09AM +0000, Reshetova, Elena wrote: > > On Mon, Mar 06, 2017 at 04:20:55PM +0200, Elena Reshetova wrote: > > > refcount_t type and corresponding API should be > > > used instead of atomic_t when the variable is used as > > > a reference counter. This allows to avoid accidental > > > refcounter overflows that might lead to use-after-free > > > situations. > > > > Looks good. Let me know how do you want to route the patch to upstream. > > Greg, you previously mentioned that driver's conversions can go via your tree. Does this still apply? > Or should I be asking maintainers to merge these patches via their trees? You should ask them to take them through their trees, if they have them. I'll be glad to scoop up all of the remaining ones that get missed, or for subsystems that do not have trees. thanks, greg k-h
[toc] | [prev] | [next] | [standalone]
| From | Michael Ellerman <mpe@ellerman.id.au> |
|---|---|
| Date | 2017-03-14 13:20 +0100 |
| Subject | Re: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t |
| Message-ID | <tkTAK-8qq-23@gated-at.bofh.it> |
| In reply to | #1593408 |
Elena Reshetova <elena.reshetova@intel.com> writes: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. > > Signed-off-by: Elena Reshetova <elena.reshetova@intel.com> > Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com> > Signed-off-by: Kees Cook <keescook@chromium.org> > Signed-off-by: David Windsor <dwindsor@gmail.com> > --- > drivers/md/md.c | 6 +++--- > drivers/md/md.h | 3 ++- > 2 files changed, 5 insertions(+), 4 deletions(-) When booting linux-next (specifically 5be4921c9958ec) I'm seeing the backtrace below. I suspect this patch is just exposing an existing issue? cheers [ 0.230738] md: Waiting for all devices to be available before autodetect [ 0.230742] md: If you don't use raid, use raid=noautodetect [ 0.230962] refcount_t: increment on 0; use-after-free. [ 0.230988] ------------[ cut here ]------------ [ 0.230996] WARNING: CPU: 0 PID: 1 at lib/refcount.c:114 .refcount_inc+0x5c/0x70 [ 0.231001] Modules linked in: [ 0.231006] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc1-gccN-next-20170310-g5be4921 #1 [ 0.231012] task: c000000049400000 task.stack: c000000049440000 [ 0.231016] NIP: c0000000005ac6bc LR: c0000000005ac6b8 CTR: c000000000743390 [ 0.231021] REGS: c000000049443160 TRAP: 0700 Not tainted (4.11.0-rc1-gccN-next-20170310-g5be4921) [ 0.231026] MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> [ 0.231033] CR: 24024422 XER: 0000000c [ 0.231038] CFAR: c000000000a5356c SOFTE: 1 [ 0.231038] GPR00: c0000000005ac6b8 c0000000494433e0 c000000001079d00 000000000000002b [ 0.231038] GPR04: 0000000000000000 00000000000000ef 0000000000000000 c0000000010418a0 [ 0.231038] GPR08: 000000004af80000 c000000000ecc9a8 c000000000ecc9a8 0000000000000000 [ 0.231038] GPR12: 0000000028024824 c000000006bb0000 0000000000000000 c000000049443a00 [ 0.231038] GPR16: 0000000000000000 c000000049443a10 0000000000000000 0000000000000000 [ 0.231038] GPR20: 0000000000000000 0000000000000000 c000000000f7dd20 0000000000000000 [ 0.231038] GPR24: 00000000014080c0 c0000000012060b8 c000000001206080 0000000000000009 [ 0.231038] GPR28: c000000000f7dde0 0000000000900000 0000000000000000 c0000000461ae800 [ 0.231100] NIP [c0000000005ac6bc] .refcount_inc+0x5c/0x70 [ 0.231104] LR [c0000000005ac6b8] .refcount_inc+0x58/0x70 [ 0.231108] Call Trace: [ 0.231112] [c0000000494433e0] [c0000000005ac6b8] .refcount_inc+0x58/0x70 (unreliable) [ 0.231120] [c000000049443450] [c00000000086c008] .mddev_find+0x1e8/0x430 [ 0.231125] [c000000049443530] [c000000000872b6c] .md_open+0x2c/0x140 [ 0.231132] [c0000000494435c0] [c0000000003962a4] .__blkdev_get+0xd4/0x520 [ 0.231138] [c000000049443690] [c000000000396cc0] .blkdev_get+0x1c0/0x4f0 [ 0.231145] [c000000049443790] [c000000000336d64] .do_dentry_open.isra.1+0x2a4/0x410 [ 0.231152] [c000000049443830] [c0000000003523f4] .path_openat+0x624/0x1580 [ 0.231157] [c000000049443990] [c000000000354ce4] .do_filp_open+0x84/0x120 [ 0.231163] [c000000049443b10] [c000000000338d74] .do_sys_open+0x214/0x300 [ 0.231170] [c000000049443be0] [c000000000da69ac] .md_run_setup+0xa0/0xec [ 0.231176] [c000000049443c60] [c000000000da4fbc] .prepare_namespace+0x60/0x240 [ 0.231182] [c000000049443ce0] [c000000000da47a8] .kernel_init_freeable+0x330/0x36c [ 0.231190] [c000000049443db0] [c00000000000dc44] .kernel_init+0x24/0x160 [ 0.231197] [c000000049443e30] [c00000000000badc] .ret_from_kernel_thread+0x58/0x7c [ 0.231202] Instruction dump: [ 0.231206] 60000000 3d22ffee 89296bfb 2f890000 409effdc 3c62ffc6 39200001 3d42ffee [ 0.231216] 38630928 992a6bfb 484a6e79 60000000 <0fe00000> 4bffffb8 60000000 60000000 [ 0.231226] ---[ end trace 8c51f269ad91ffc2 ]--- [ 0.231233] md: Autodetecting RAID arrays. [ 0.231236] md: autorun ... [ 0.231239] md: ... autorun DONE. [ 0.234188] EXT4-fs (sda4): mounting ext3 file system using the ext4 subsystem [ 0.250506] refcount_t: underflow; use-after-free. [ 0.250531] ------------[ cut here ]------------ [ 0.250537] WARNING: CPU: 0 PID: 3 at lib/refcount.c:207 .refcount_dec_not_one+0x104/0x120 [ 0.250542] Modules linked in: [ 0.250546] CPU: 0 PID: 3 Comm: kworker/0:0 Tainted: G W 4.11.0-rc1-gccN-next-20170310-g5be4921 #1 [ 0.250553] Workqueue: events .delayed_fput [ 0.250557] task: c000000049404900 task.stack: c000000049448000 [ 0.250562] NIP: c0000000005ac964 LR: c0000000005ac960 CTR: c000000000743390 [ 0.250567] REGS: c00000004944b530 TRAP: 0700 Tainted: G W (4.11.0-rc1-gccN-next-20170310-g5be4921) [ 0.250572] MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> [ 0.250578] CR: 24002422 XER: 00000007 [ 0.250584] CFAR: c000000000a5356c SOFTE: 1 [ 0.250584] GPR00: c0000000005ac960 c00000004944b7b0 c000000001079d00 0000000000000026 [ 0.250584] GPR04: 0000000000000000 0000000000000113 0000000000000000 c0000000010418a0 [ 0.250584] GPR08: 000000004af80000 c000000000ecc9a8 c000000000ecc9a8 0000000000000000 [ 0.250584] GPR12: 0000000022002824 c000000006bb0000 c0000000001116d0 c000000049050200 [ 0.250584] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.250584] GPR20: 0000000000000001 0000000000000000 c000000048030a98 0000000000000001 [ 0.250584] GPR24: 000000000002001d 0000000000000000 0000000000000000 c0000000461af000 [ 0.250584] GPR28: 0000000000000000 c000000048030bd8 c0000000461aea08 c0000000012060b8 [ 0.250645] NIP [c0000000005ac964] .refcount_dec_not_one+0x104/0x120 [ 0.250650] LR [c0000000005ac960] .refcount_dec_not_one+0x100/0x120 [ 0.250654] Call Trace: [ 0.250658] [c00000004944b7b0] [c0000000005ac960] .refcount_dec_not_one+0x100/0x120 (unreliable) [ 0.250665] [c00000004944b820] [c0000000005ac9a0] .refcount_dec_and_lock+0x20/0xc0 [ 0.250671] [c00000004944b8a0] [c000000000870fa4] .mddev_put+0x34/0x180 [ 0.250677] [c00000004944b930] [c000000000396108] .__blkdev_put+0x288/0x350 [ 0.250683] [c00000004944ba30] [c0000000003968f0] .blkdev_close+0x30/0x50 [ 0.250689] [c00000004944bab0] [c00000000033e7d8] .__fput+0xc8/0x2a0 [ 0.250695] [c00000004944bb60] [c00000000033ea08] .delayed_fput+0x58/0x80 [ 0.250701] [c00000004944bbe0] [c000000000107ea0] .process_one_work+0x2a0/0x630 [ 0.250707] [c00000004944bc80] [c0000000001082c8] .worker_thread+0x98/0x6a0 [ 0.250713] [c00000004944bd70] [c000000000111868] .kthread+0x198/0x1a0 [ 0.250719] [c00000004944be30] [c00000000000badc] .ret_from_kernel_thread+0x58/0x7c [ 0.250724] Instruction dump: [ 0.250728] 419e000c 38210070 4e800020 7c0802a6 3c62ffc6 39200001 3d42ffee 38630958 [ 0.250738] 992a6bfe f8010080 484a6bd1 60000000 <0fe00000> e8010080 38600001 7c0803a6 [ 0.250748] ---[ end trace 8c51f269ad91ffc3 ]--- [ 0.262454] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null)
[toc] | [prev] | [next] | [standalone]
| From | "Reshetova, Elena" <elena.reshetova@intel.com> |
|---|---|
| Date | 2017-03-14 13:40 +0100 |
| Subject | RE: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t |
| Message-ID | <tkTU6-5w-37@gated-at.bofh.it> |
| In reply to | #1600281 |
> Elena Reshetova <elena.reshetova@intel.com> writes: > > > refcount_t type and corresponding API should be > > used instead of atomic_t when the variable is used as > > a reference counter. This allows to avoid accidental > > refcounter overflows that might lead to use-after-free > > situations. > > > > Signed-off-by: Elena Reshetova <elena.reshetova@intel.com> > > Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com> > > Signed-off-by: Kees Cook <keescook@chromium.org> > > Signed-off-by: David Windsor <dwindsor@gmail.com> > > --- > > drivers/md/md.c | 6 +++--- > > drivers/md/md.h | 3 ++- > > 2 files changed, 5 insertions(+), 4 deletions(-) > > When booting linux-next (specifically 5be4921c9958ec) I'm seeing the > backtrace below. I suspect this patch is just exposing an existing > issue? Yes, we have actually been following this issue in the another thread. It looks like the object is re-used somehow, but I can't quite understand how just by reading the code. This was what I put into the previous thread: "The log below indicates that you are using your refcounter in a bit weird way in mddev_find(). However, I can't find the place (just by reading the code) where you would increment refcounter from zero (vs. setting it to one). It looks like you either iterate over existing nodes (and increment their counters, which should be >= 1 at the time of increment) or create a new node, but then mddev_init() sets the counter to 1. " If you can help to understand what is going on with the object creation/destruction, would be appreciated! Also Shaohua Li stopped this patch coming from his tree since the issue was caught at that time, so we are not going to merge this until we figure it out. Best Regards, Elena. > > cheers > > > [ 0.230738] md: Waiting for all devices to be available before autodetect > [ 0.230742] md: If you don't use raid, use raid=noautodetect > [ 0.230962] refcount_t: increment on 0; use-after-free. > [ 0.230988] ------------[ cut here ]------------ > [ 0.230996] WARNING: CPU: 0 PID: 1 at lib/refcount.c:114 > .refcount_inc+0x5c/0x70 > [ 0.231001] Modules linked in: > [ 0.231006] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc1-gccN-next- > 20170310-g5be4921 #1 > [ 0.231012] task: c000000049400000 task.stack: c000000049440000 > [ 0.231016] NIP: c0000000005ac6bc LR: c0000000005ac6b8 CTR: > c000000000743390 > [ 0.231021] REGS: c000000049443160 TRAP: 0700 Not tainted (4.11.0-rc1- > gccN-next-20170310-g5be4921) > [ 0.231026] MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> > [ 0.231033] CR: 24024422 XER: 0000000c > [ 0.231038] CFAR: c000000000a5356c SOFTE: 1 > [ 0.231038] GPR00: c0000000005ac6b8 c0000000494433e0 c000000001079d00 > 000000000000002b > [ 0.231038] GPR04: 0000000000000000 00000000000000ef 0000000000000000 > c0000000010418a0 > [ 0.231038] GPR08: 000000004af80000 c000000000ecc9a8 c000000000ecc9a8 > 0000000000000000 > [ 0.231038] GPR12: 0000000028024824 c000000006bb0000 0000000000000000 > c000000049443a00 > [ 0.231038] GPR16: 0000000000000000 c000000049443a10 0000000000000000 > 0000000000000000 > [ 0.231038] GPR20: 0000000000000000 0000000000000000 c000000000f7dd20 > 0000000000000000 > [ 0.231038] GPR24: 00000000014080c0 c0000000012060b8 c000000001206080 > 0000000000000009 > [ 0.231038] GPR28: c000000000f7dde0 0000000000900000 0000000000000000 > c0000000461ae800 > [ 0.231100] NIP [c0000000005ac6bc] .refcount_inc+0x5c/0x70 > [ 0.231104] LR [c0000000005ac6b8] .refcount_inc+0x58/0x70 > [ 0.231108] Call Trace: > [ 0.231112] [c0000000494433e0] [c0000000005ac6b8] .refcount_inc+0x58/0x70 > (unreliable) > [ 0.231120] [c000000049443450] [c00000000086c008] > .mddev_find+0x1e8/0x430 > [ 0.231125] [c000000049443530] [c000000000872b6c] .md_open+0x2c/0x140 > [ 0.231132] [c0000000494435c0] [c0000000003962a4] > .__blkdev_get+0xd4/0x520 > [ 0.231138] [c000000049443690] [c000000000396cc0] .blkdev_get+0x1c0/0x4f0 > [ 0.231145] [c000000049443790] [c000000000336d64] > .do_dentry_open.isra.1+0x2a4/0x410 > [ 0.231152] [c000000049443830] [c0000000003523f4] > .path_openat+0x624/0x1580 > [ 0.231157] [c000000049443990] [c000000000354ce4] > .do_filp_open+0x84/0x120 > [ 0.231163] [c000000049443b10] [c000000000338d74] > .do_sys_open+0x214/0x300 > [ 0.231170] [c000000049443be0] [c000000000da69ac] > .md_run_setup+0xa0/0xec > [ 0.231176] [c000000049443c60] [c000000000da4fbc] > .prepare_namespace+0x60/0x240 > [ 0.231182] [c000000049443ce0] [c000000000da47a8] > .kernel_init_freeable+0x330/0x36c > [ 0.231190] [c000000049443db0] [c00000000000dc44] .kernel_init+0x24/0x160 > [ 0.231197] [c000000049443e30] [c00000000000badc] > .ret_from_kernel_thread+0x58/0x7c > [ 0.231202] Instruction dump: > [ 0.231206] 60000000 3d22ffee 89296bfb 2f890000 409effdc 3c62ffc6 39200001 > 3d42ffee > [ 0.231216] 38630928 992a6bfb 484a6e79 60000000 <0fe00000> 4bffffb8 > 60000000 60000000 > [ 0.231226] ---[ end trace 8c51f269ad91ffc2 ]--- > [ 0.231233] md: Autodetecting RAID arrays. > [ 0.231236] md: autorun ... > [ 0.231239] md: ... autorun DONE. > [ 0.234188] EXT4-fs (sda4): mounting ext3 file system using the ext4 subsystem > [ 0.250506] refcount_t: underflow; use-after-free. > [ 0.250531] ------------[ cut here ]------------ > [ 0.250537] WARNING: CPU: 0 PID: 3 at lib/refcount.c:207 > .refcount_dec_not_one+0x104/0x120 > [ 0.250542] Modules linked in: > [ 0.250546] CPU: 0 PID: 3 Comm: kworker/0:0 Tainted: G W 4.11.0-rc1- > gccN-next-20170310-g5be4921 #1 > [ 0.250553] Workqueue: events .delayed_fput > [ 0.250557] task: c000000049404900 task.stack: c000000049448000 > [ 0.250562] NIP: c0000000005ac964 LR: c0000000005ac960 CTR: > c000000000743390 > [ 0.250567] REGS: c00000004944b530 TRAP: 0700 Tainted: G W (4.11.0- > rc1-gccN-next-20170310-g5be4921) > [ 0.250572] MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> > [ 0.250578] CR: 24002422 XER: 00000007 > [ 0.250584] CFAR: c000000000a5356c SOFTE: 1 > [ 0.250584] GPR00: c0000000005ac960 c00000004944b7b0 c000000001079d00 > 0000000000000026 > [ 0.250584] GPR04: 0000000000000000 0000000000000113 0000000000000000 > c0000000010418a0 > [ 0.250584] GPR08: 000000004af80000 c000000000ecc9a8 c000000000ecc9a8 > 0000000000000000 > [ 0.250584] GPR12: 0000000022002824 c000000006bb0000 c0000000001116d0 > c000000049050200 > [ 0.250584] GPR16: 0000000000000000 0000000000000000 0000000000000000 > 0000000000000000 > [ 0.250584] GPR20: 0000000000000001 0000000000000000 c000000048030a98 > 0000000000000001 > [ 0.250584] GPR24: 000000000002001d 0000000000000000 0000000000000000 > c0000000461af000 > [ 0.250584] GPR28: 0000000000000000 c000000048030bd8 c0000000461aea08 > c0000000012060b8 > [ 0.250645] NIP [c0000000005ac964] .refcount_dec_not_one+0x104/0x120 > [ 0.250650] LR [c0000000005ac960] .refcount_dec_not_one+0x100/0x120 > [ 0.250654] Call Trace: > [ 0.250658] [c00000004944b7b0] [c0000000005ac960] > .refcount_dec_not_one+0x100/0x120 (unreliable) > [ 0.250665] [c00000004944b820] [c0000000005ac9a0] > .refcount_dec_and_lock+0x20/0xc0 > [ 0.250671] [c00000004944b8a0] [c000000000870fa4] .mddev_put+0x34/0x18 0 > [ 0.250677] [c00000004944b930] [c000000000396108] > .__blkdev_put+0x288/0x350 > [ 0.250683] [c00000004944ba30] [c0000000003968f0] .blkdev_close+0x30/0x50 > [ 0.250689] [c00000004944bab0] [c00000000033e7d8] .__fput+0xc8/0x2a0 > [ 0.250695] [c00000004944bb60] [c00000000033ea08] > .delayed_fput+0x58/0x80 > [ 0.250701] [c00000004944bbe0] [c000000000107ea0] > .process_one_work+0x2a0/0x630 > [ 0.250707] [c00000004944bc80] [c0000000001082c8] > .worker_thread+0x98/0x6a0 > [ 0.250713] [c00000004944bd70] [c000000000111868] .kthread+0x198/0x1a0 > [ 0.250719] [c00000004944be30] [c00000000000badc] > .ret_from_kernel_thread+0x58/0x7c > [ 0.250724] Instruction dump: > [ 0.250728] 419e000c 38210070 4e800020 7c0802a6 3c62ffc6 39200001 > 3d42ffee 38630958 > [ 0.250738] 992a6bfe f8010080 484a6bd1 60000000 <0fe00000> e8010080 > 38600001 7c0803a6 > [ 0.250748] ---[ end trace 8c51f269ad91ffc3 ]--- > [ 0.262454] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: > (null)
[toc] | [prev] | [next] | [standalone]
| From | James Bottomley <James.Bottomley@HansenPartnership.com> |
|---|---|
| Date | 2017-03-14 16:00 +0100 |
| Subject | Re: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t |
| Message-ID | <tkW5B-1Ad-53@gated-at.bofh.it> |
| In reply to | #1600289 |
On Tue, 2017-03-14 at 12:29 +0000, Reshetova, Elena wrote: > > Elena Reshetova <elena.reshetova@intel.com> writes: > > > > > refcount_t type and corresponding API should be > > > used instead of atomic_t when the variable is used as > > > a reference counter. This allows to avoid accidental > > > refcounter overflows that might lead to use-after-free > > > situations. > > > > > > Signed-off-by: Elena Reshetova <elena.reshetova@intel.com> > > > Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com> > > > Signed-off-by: Kees Cook <keescook@chromium.org> > > > Signed-off-by: David Windsor <dwindsor@gmail.com> > > > --- > > > drivers/md/md.c | 6 +++--- > > > drivers/md/md.h | 3 ++- > > > 2 files changed, 5 insertions(+), 4 deletions(-) > > > > When booting linux-next (specifically 5be4921c9958ec) I'm seeing > > the > > backtrace below. I suspect this patch is just exposing an existing > > issue? > > Yes, we have actually been following this issue in the another > thread. > It looks like the object is re-used somehow, but I can't quite > understand how just by reading the code. > This was what I put into the previous thread: > > "The log below indicates that you are using your refcounter in a bit > weird way in mddev_find(). > However, I can't find the place (just by reading the code) where you > would increment refcounter from zero (vs. setting it to one). > It looks like you either iterate over existing nodes (and increment > their counters, which should be >= 1 at the time of increment) or > create a new node, but then mddev_init() sets the counter to 1. " > > If you can help to understand what is going on with the object > creation/destruction, would be appreciated! > > Also Shaohua Li stopped this patch coming from his tree since the > issue was caught at that time, so we are not going to merge this > until we figure it out. Asking on the correct list (dm-devel) would have got you the easy answer: The refcount behind mddev->active is a genuine atomic. It has refcount properties but only if the array fails to initialise (in that case, final put kills it). Once it's added to the system as a gendisk, it cannot be freed until md_free(). Thus its ->active count can go to zero (when it becomes inactive; usually because of an unmount). On a simple allocation regardless of outcome, the last executed statement in md_alloc is mddev_put(): that destroys the device if we didn't manage to create it or returns 0 and adds an inactive device to the system which the user can get with mddev_find(). James
[toc] | [prev] | [next] | [standalone]
| From | "Reshetova, Elena" <elena.reshetova@intel.com> |
|---|---|
| Date | 2017-03-16 19:10 +0100 |
| Subject | RE: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t |
| Message-ID | <tlI0y-25v-13@gated-at.bofh.it> |
| In reply to | #1600539 |
> On Tue, 2017-03-14 at 12:29 +0000, Reshetova, Elena wrote: > > > Elena Reshetova <elena.reshetova@intel.com> writes: > > > > > > > refcount_t type and corresponding API should be > > > > used instead of atomic_t when the variable is used as > > > > a reference counter. This allows to avoid accidental > > > > refcounter overflows that might lead to use-after-free > > > > situations. > > > > > > > > Signed-off-by: Elena Reshetova <elena.reshetova@intel.com> > > > > Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com> > > > > Signed-off-by: Kees Cook <keescook@chromium.org> > > > > Signed-off-by: David Windsor <dwindsor@gmail.com> > > > > --- > > > > drivers/md/md.c | 6 +++--- > > > > drivers/md/md.h | 3 ++- > > > > 2 files changed, 5 insertions(+), 4 deletions(-) > > > > > > When booting linux-next (specifically 5be4921c9958ec) I'm seeing > > > the > > > backtrace below. I suspect this patch is just exposing an existing > > > issue? > > > > Yes, we have actually been following this issue in the another > > thread. > > It looks like the object is re-used somehow, but I can't quite > > understand how just by reading the code. > > This was what I put into the previous thread: > > > > "The log below indicates that you are using your refcounter in a bit > > weird way in mddev_find(). > > However, I can't find the place (just by reading the code) where you > > would increment refcounter from zero (vs. setting it to one). > > It looks like you either iterate over existing nodes (and increment > > their counters, which should be >= 1 at the time of increment) or > > create a new node, but then mddev_init() sets the counter to 1. " > > > > If you can help to understand what is going on with the object > > creation/destruction, would be appreciated! > > > > Also Shaohua Li stopped this patch coming from his tree since the > > issue was caught at that time, so we are not going to merge this > > until we figure it out. > > Asking on the correct list (dm-devel) would have got you the easy > answer: The refcount behind mddev->active is a genuine atomic. It has > refcount properties but only if the array fails to initialise (in that > case, final put kills it). Once it's added to the system as a gendisk, > it cannot be freed until md_free(). Thus its ->active count can go to > zero (when it becomes inactive; usually because of an unmount). On a > simple allocation regardless of outcome, the last executed statement in > md_alloc is mddev_put(): that destroys the device if we didn't manage > to create it or returns 0 and adds an inactive device to the system > which the user can get with mddev_find(). Thank you James for explaining this! I guess in this case, the conversion doesn't make sense. And sorry about not asking in a correct place: we are handling many similar patches now and while I try to reach the right audience using get_maintainer script, it doesn't always succeeds. Best Regards, Elena. > > James >
[toc] | [prev] | [next] | [standalone]
| From | Elena Reshetova <elena.reshetova@intel.com> |
|---|---|
| Date | 2017-03-06 15:30 +0100 |
| Subject | [PATCH 10/29] drivers, md: convert stripe_head.count from atomic_t to refcount_t |
| Message-ID | <ti1O9-Yn-13@gated-at.bofh.it> |
| In reply to | #1593407 |
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: David Windsor <dwindsor@gmail.com>
---
drivers/md/raid5-cache.c | 8 +++---
drivers/md/raid5.c | 66 ++++++++++++++++++++++++------------------------
drivers/md/raid5.h | 3 ++-
3 files changed, 39 insertions(+), 38 deletions(-)
diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
index 3f307be..6c05e12 100644
--- a/drivers/md/raid5-cache.c
+++ b/drivers/md/raid5-cache.c
@@ -979,7 +979,7 @@ int r5l_write_stripe(struct r5l_log *log, struct stripe_head *sh)
* don't delay.
*/
clear_bit(STRIPE_DELAYED, &sh->state);
- atomic_inc(&sh->count);
+ refcount_inc(&sh->count);
mutex_lock(&log->io_mutex);
/* meta + data */
@@ -1321,7 +1321,7 @@ static void r5c_flush_stripe(struct r5conf *conf, struct stripe_head *sh)
assert_spin_locked(&conf->device_lock);
list_del_init(&sh->lru);
- atomic_inc(&sh->count);
+ refcount_inc(&sh->count);
set_bit(STRIPE_HANDLE, &sh->state);
atomic_inc(&conf->active_stripes);
@@ -1424,7 +1424,7 @@ static void r5c_do_reclaim(struct r5conf *conf)
*/
if (!list_empty(&sh->lru) &&
!test_bit(STRIPE_HANDLE, &sh->state) &&
- atomic_read(&sh->count) == 0) {
+ refcount_read(&sh->count) == 0) {
r5c_flush_stripe(conf, sh);
if (count++ >= R5C_RECLAIM_STRIPE_GROUP)
break;
@@ -2650,7 +2650,7 @@ r5c_cache_data(struct r5l_log *log, struct stripe_head *sh,
* don't delay.
*/
clear_bit(STRIPE_DELAYED, &sh->state);
- atomic_inc(&sh->count);
+ refcount_inc(&sh->count);
mutex_lock(&log->io_mutex);
/* meta + data */
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 2ce23b0..30c96a8 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -296,7 +296,7 @@ static void do_release_stripe(struct r5conf *conf, struct stripe_head *sh,
static void __release_stripe(struct r5conf *conf, struct stripe_head *sh,
struct list_head *temp_inactive_list)
{
- if (atomic_dec_and_test(&sh->count))
+ if (refcount_dec_and_test(&sh->count))
do_release_stripe(conf, sh, temp_inactive_list);
}
@@ -388,7 +388,7 @@ void raid5_release_stripe(struct stripe_head *sh)
/* Avoid release_list until the last reference.
*/
- if (atomic_add_unless(&sh->count, -1, 1))
+ if (refcount_dec_not_one(&sh->count))
return;
if (unlikely(!conf->mddev->thread) ||
@@ -401,7 +401,7 @@ void raid5_release_stripe(struct stripe_head *sh)
slow_path:
local_irq_save(flags);
/* we are ok here if STRIPE_ON_RELEASE_LIST is set or not */
- if (atomic_dec_and_lock(&sh->count, &conf->device_lock)) {
+ if (refcount_dec_and_lock(&sh->count, &conf->device_lock)) {
INIT_LIST_HEAD(&list);
hash = sh->hash_lock_index;
do_release_stripe(conf, sh, &list);
@@ -491,7 +491,7 @@ static void init_stripe(struct stripe_head *sh, sector_t sector, int previous)
struct r5conf *conf = sh->raid_conf;
int i, seq;
- BUG_ON(atomic_read(&sh->count) != 0);
+ BUG_ON(refcount_read(&sh->count) != 0);
BUG_ON(test_bit(STRIPE_HANDLE, &sh->state));
BUG_ON(stripe_operations_active(sh));
BUG_ON(sh->batch_head);
@@ -668,11 +668,11 @@ raid5_get_active_stripe(struct r5conf *conf, sector_t sector,
&conf->cache_state);
} else {
init_stripe(sh, sector, previous);
- atomic_inc(&sh->count);
+ refcount_inc(&sh->count);
}
- } else if (!atomic_inc_not_zero(&sh->count)) {
+ } else if (!refcount_inc_not_zero(&sh->count)) {
spin_lock(&conf->device_lock);
- if (!atomic_read(&sh->count)) {
+ if (!refcount_read(&sh->count)) {
if (!test_bit(STRIPE_HANDLE, &sh->state))
atomic_inc(&conf->active_stripes);
BUG_ON(list_empty(&sh->lru) &&
@@ -688,7 +688,7 @@ raid5_get_active_stripe(struct r5conf *conf, sector_t sector,
sh->group = NULL;
}
}
- atomic_inc(&sh->count);
+ refcount_inc(&sh->count);
spin_unlock(&conf->device_lock);
}
} while (sh == NULL);
@@ -752,9 +752,9 @@ static void stripe_add_to_batch_list(struct r5conf *conf, struct stripe_head *sh
hash = stripe_hash_locks_hash(head_sector);
spin_lock_irq(conf->hash_locks + hash);
head = __find_stripe(conf, head_sector, conf->generation);
- if (head && !atomic_inc_not_zero(&head->count)) {
+ if (head && !refcount_inc_not_zero(&head->count)) {
spin_lock(&conf->device_lock);
- if (!atomic_read(&head->count)) {
+ if (!refcount_read(&head->count)) {
if (!test_bit(STRIPE_HANDLE, &head->state))
atomic_inc(&conf->active_stripes);
BUG_ON(list_empty(&head->lru) &&
@@ -770,7 +770,7 @@ static void stripe_add_to_batch_list(struct r5conf *conf, struct stripe_head *sh
head->group = NULL;
}
}
- atomic_inc(&head->count);
+ refcount_inc(&head->count);
spin_unlock(&conf->device_lock);
}
spin_unlock_irq(conf->hash_locks + hash);
@@ -833,7 +833,7 @@ static void stripe_add_to_batch_list(struct r5conf *conf, struct stripe_head *sh
sh->batch_head->bm_seq = seq;
}
- atomic_inc(&sh->count);
+ refcount_inc(&sh->count);
unlock_out:
unlock_two_stripes(head, sh);
out:
@@ -1036,9 +1036,9 @@ static void ops_run_io(struct stripe_head *sh, struct stripe_head_state *s)
pr_debug("%s: for %llu schedule op %d on disc %d\n",
__func__, (unsigned long long)sh->sector,
bi->bi_opf, i);
- atomic_inc(&sh->count);
+ refcount_inc(&sh->count);
if (sh != head_sh)
- atomic_inc(&head_sh->count);
+ refcount_inc(&head_sh->count);
if (use_new_offset(conf, sh))
bi->bi_iter.bi_sector = (sh->sector
+ rdev->new_data_offset);
@@ -1097,9 +1097,9 @@ static void ops_run_io(struct stripe_head *sh, struct stripe_head_state *s)
"replacement disc %d\n",
__func__, (unsigned long long)sh->sector,
rbi->bi_opf, i);
- atomic_inc(&sh->count);
+ refcount_inc(&sh->count);
if (sh != head_sh)
- atomic_inc(&head_sh->count);
+ refcount_inc(&head_sh->count);
if (use_new_offset(conf, sh))
rbi->bi_iter.bi_sector = (sh->sector
+ rrdev->new_data_offset);
@@ -1275,7 +1275,7 @@ static void ops_run_biofill(struct stripe_head *sh)
}
}
- atomic_inc(&sh->count);
+ refcount_inc(&sh->count);
init_async_submit(&submit, ASYNC_TX_ACK, tx, ops_complete_biofill, sh, NULL);
async_trigger_callback(&submit);
}
@@ -1353,7 +1353,7 @@ ops_run_compute5(struct stripe_head *sh, struct raid5_percpu *percpu)
if (i != target)
xor_srcs[count++] = sh->dev[i].page;
- atomic_inc(&sh->count);
+ refcount_inc(&sh->count);
init_async_submit(&submit, ASYNC_TX_FENCE|ASYNC_TX_XOR_ZERO_DST, NULL,
ops_complete_compute, sh, to_addr_conv(sh, percpu, 0));
@@ -1441,7 +1441,7 @@ ops_run_compute6_1(struct stripe_head *sh, struct raid5_percpu *percpu)
BUG_ON(!test_bit(R5_Wantcompute, &tgt->flags));
dest = tgt->page;
- atomic_inc(&sh->count);
+ refcount_inc(&sh->count);
if (target == qd_idx) {
count = set_syndrome_sources(blocks, sh, SYNDROME_SRC_ALL);
@@ -1516,7 +1516,7 @@ ops_run_compute6_2(struct stripe_head *sh, struct raid5_percpu *percpu)
pr_debug("%s: stripe: %llu faila: %d failb: %d\n",
__func__, (unsigned long long)sh->sector, faila, failb);
- atomic_inc(&sh->count);
+ refcount_inc(&sh->count);
if (failb == syndrome_disks+1) {
/* Q disk is one of the missing disks */
@@ -1784,7 +1784,7 @@ ops_run_reconstruct5(struct stripe_head *sh, struct raid5_percpu *percpu,
break;
}
if (i >= sh->disks) {
- atomic_inc(&sh->count);
+ refcount_inc(&sh->count);
set_bit(R5_Discard, &sh->dev[pd_idx].flags);
ops_complete_reconstruct(sh);
return;
@@ -1825,7 +1825,7 @@ ops_run_reconstruct5(struct stripe_head *sh, struct raid5_percpu *percpu,
flags = ASYNC_TX_ACK |
(prexor ? ASYNC_TX_XOR_DROP_DST : ASYNC_TX_XOR_ZERO_DST);
- atomic_inc(&head_sh->count);
+ refcount_inc(&head_sh->count);
init_async_submit(&submit, flags, tx, ops_complete_reconstruct, head_sh,
to_addr_conv(sh, percpu, j));
} else {
@@ -1867,7 +1867,7 @@ ops_run_reconstruct6(struct stripe_head *sh, struct raid5_percpu *percpu,
break;
}
if (i >= sh->disks) {
- atomic_inc(&sh->count);
+ refcount_inc(&sh->count);
set_bit(R5_Discard, &sh->dev[sh->pd_idx].flags);
set_bit(R5_Discard, &sh->dev[sh->qd_idx].flags);
ops_complete_reconstruct(sh);
@@ -1891,7 +1891,7 @@ ops_run_reconstruct6(struct stripe_head *sh, struct raid5_percpu *percpu,
struct stripe_head, batch_list) == head_sh;
if (last_stripe) {
- atomic_inc(&head_sh->count);
+ refcount_inc(&head_sh->count);
init_async_submit(&submit, txflags, tx, ops_complete_reconstruct,
head_sh, to_addr_conv(sh, percpu, j));
} else
@@ -1948,7 +1948,7 @@ static void ops_run_check_p(struct stripe_head *sh, struct raid5_percpu *percpu)
tx = async_xor_val(xor_dest, xor_srcs, 0, count, STRIPE_SIZE,
&sh->ops.zero_sum_result, &submit);
- atomic_inc(&sh->count);
+ refcount_inc(&sh->count);
init_async_submit(&submit, ASYNC_TX_ACK, tx, ops_complete_check, sh, NULL);
tx = async_trigger_callback(&submit);
}
@@ -1967,7 +1967,7 @@ static void ops_run_check_pq(struct stripe_head *sh, struct raid5_percpu *percpu
if (!checkp)
srcs[count] = NULL;
- atomic_inc(&sh->count);
+ refcount_inc(&sh->count);
init_async_submit(&submit, ASYNC_TX_ACK, NULL, ops_complete_check,
sh, to_addr_conv(sh, percpu, 0));
async_syndrome_val(srcs, 0, count+2, STRIPE_SIZE,
@@ -2057,7 +2057,7 @@ static struct stripe_head *alloc_stripe(struct kmem_cache *sc, gfp_t gfp,
INIT_LIST_HEAD(&sh->lru);
INIT_LIST_HEAD(&sh->r5c);
INIT_LIST_HEAD(&sh->log_list);
- atomic_set(&sh->count, 1);
+ refcount_set(&sh->count, 1);
sh->log_start = MaxSector;
for (i = 0; i < disks; i++) {
struct r5dev *dev = &sh->dev[i];
@@ -2354,7 +2354,7 @@ static int drop_one_stripe(struct r5conf *conf)
spin_unlock_irq(conf->hash_locks + hash);
if (!sh)
return 0;
- BUG_ON(atomic_read(&sh->count));
+ BUG_ON(refcount_read(&sh->count));
shrink_buffers(sh);
kmem_cache_free(conf->slab_cache, sh);
atomic_dec(&conf->active_stripes);
@@ -2386,7 +2386,7 @@ static void raid5_end_read_request(struct bio * bi)
break;
pr_debug("end_read_request %llu/%d, count: %d, error %d.\n",
- (unsigned long long)sh->sector, i, atomic_read(&sh->count),
+ (unsigned long long)sh->sector, i, refcount_read(&sh->count),
bi->bi_error);
if (i == disks) {
bio_reset(bi);
@@ -2523,7 +2523,7 @@ static void raid5_end_write_request(struct bio *bi)
}
}
pr_debug("end_write_request %llu/%d, count %d, error: %d.\n",
- (unsigned long long)sh->sector, i, atomic_read(&sh->count),
+ (unsigned long long)sh->sector, i, refcount_read(&sh->count),
bi->bi_error);
if (i == disks) {
bio_reset(bi);
@@ -4545,7 +4545,7 @@ static void handle_stripe(struct stripe_head *sh)
pr_debug("handling stripe %llu, state=%#lx cnt=%d, "
"pd_idx=%d, qd_idx=%d\n, check:%d, reconstruct:%d\n",
(unsigned long long)sh->sector, sh->state,
- atomic_read(&sh->count), sh->pd_idx, sh->qd_idx,
+ refcount_read(&sh->count), sh->pd_idx, sh->qd_idx,
sh->check_state, sh->reconstruct_state);
analyse_stripe(sh, &s);
@@ -4924,7 +4924,7 @@ static void activate_bit_delay(struct r5conf *conf,
struct stripe_head *sh = list_entry(head.next, struct stripe_head, lru);
int hash;
list_del_init(&sh->lru);
- atomic_inc(&sh->count);
+ refcount_inc(&sh->count);
hash = sh->hash_lock_index;
__release_stripe(conf, sh, &temp_inactive_list[hash]);
}
@@ -5240,7 +5240,7 @@ static struct stripe_head *__get_priority_stripe(struct r5conf *conf, int group)
sh->group = NULL;
}
list_del_init(&sh->lru);
- BUG_ON(atomic_inc_return(&sh->count) != 1);
+ BUG_ON(refcount_inc_not_zero(&sh->count));
return sh;
}
diff --git a/drivers/md/raid5.h b/drivers/md/raid5.h
index 4bb27b9..a1ed351 100644
--- a/drivers/md/raid5.h
+++ b/drivers/md/raid5.h
@@ -3,6 +3,7 @@
#include <linux/raid/xor.h>
#include <linux/dmaengine.h>
+#include <linux/refcount.h>
/*
*
@@ -207,7 +208,7 @@ struct stripe_head {
short ddf_layout;/* use DDF ordering to calculate Q */
short hash_lock_index;
unsigned long state; /* state flags */
- atomic_t count; /* nr of active thread/requests */
+ refcount_t count; /* nr of active thread/requests */
int bm_seq; /* sequence number for bitmap flushes */
int disks; /* disks in stripe */
int overwrite_disks; /* total overwrite disks in stripe,
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Shaohua Li <shli@kernel.org> |
|---|---|
| Date | 2017-03-07 20:20 +0100 |
| Subject | Re: [PATCH 10/29] drivers, md: convert stripe_head.count from atomic_t to refcount_t |
| Message-ID | <tisOm-3ze-29@gated-at.bofh.it> |
| In reply to | #1593410 |
On Mon, Mar 06, 2017 at 04:20:57PM +0200, Elena Reshetova wrote: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. > > Signed-off-by: Elena Reshetova <elena.reshetova@intel.com> > Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com> > Signed-off-by: Kees Cook <keescook@chromium.org> > Signed-off-by: David Windsor <dwindsor@gmail.com> > --- > drivers/md/raid5-cache.c | 8 +++--- > drivers/md/raid5.c | 66 ++++++++++++++++++++++++------------------------ > drivers/md/raid5.h | 3 ++- > 3 files changed, 39 insertions(+), 38 deletions(-) > > diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c > index 3f307be..6c05e12 100644 > --- a/drivers/md/raid5-cache.c > +++ b/drivers/md/raid5-cache.c snip > sh->check_state, sh->reconstruct_state); > > analyse_stripe(sh, &s); > @@ -4924,7 +4924,7 @@ static void activate_bit_delay(struct r5conf *conf, > struct stripe_head *sh = list_entry(head.next, struct stripe_head, lru); > int hash; > list_del_init(&sh->lru); > - atomic_inc(&sh->count); > + refcount_inc(&sh->count); > hash = sh->hash_lock_index; > __release_stripe(conf, sh, &temp_inactive_list[hash]); > } > @@ -5240,7 +5240,7 @@ static struct stripe_head *__get_priority_stripe(struct r5conf *conf, int group) > sh->group = NULL; > } > list_del_init(&sh->lru); > - BUG_ON(atomic_inc_return(&sh->count) != 1); > + BUG_ON(refcount_inc_not_zero(&sh->count)); This changes the behavior. refcount_inc_not_zero doesn't inc if original value is 0 Thanks, Shaohua
[toc] | [prev] | [next] | [standalone]
| From | "Reshetova, Elena" <elena.reshetova@intel.com> |
|---|---|
| Date | 2017-03-08 10:50 +0100 |
| Subject | RE: [PATCH 10/29] drivers, md: convert stripe_head.count from atomic_t to refcount_t |
| Message-ID | <tiGoi-4Ft-5@gated-at.bofh.it> |
| In reply to | #1594562 |
> On Mon, Mar 06, 2017 at 04:20:57PM +0200, Elena Reshetova wrote: > > refcount_t type and corresponding API should be > > used instead of atomic_t when the variable is used as > > a reference counter. This allows to avoid accidental > > refcounter overflows that might lead to use-after-free > > situations. > > > > Signed-off-by: Elena Reshetova <elena.reshetova@intel.com> > > Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com> > > Signed-off-by: Kees Cook <keescook@chromium.org> > > Signed-off-by: David Windsor <dwindsor@gmail.com> > > --- > > drivers/md/raid5-cache.c | 8 +++--- > > drivers/md/raid5.c | 66 ++++++++++++++++++++++++------------------------ > > drivers/md/raid5.h | 3 ++- > > 3 files changed, 39 insertions(+), 38 deletions(-) > > > > diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c > > index 3f307be..6c05e12 100644 > > --- a/drivers/md/raid5-cache.c > > +++ b/drivers/md/raid5-cache.c > > snip > > sh->check_state, sh->reconstruct_state); > > > > analyse_stripe(sh, &s); > > @@ -4924,7 +4924,7 @@ static void activate_bit_delay(struct r5conf *conf, > > struct stripe_head *sh = list_entry(head.next, struct > stripe_head, lru); > > int hash; > > list_del_init(&sh->lru); > > - atomic_inc(&sh->count); > > + refcount_inc(&sh->count); > > hash = sh->hash_lock_index; > > __release_stripe(conf, sh, > &temp_inactive_list[hash]); > > } > > @@ -5240,7 +5240,7 @@ static struct stripe_head *__get_priority_stripe(struct > r5conf *conf, int group) > > sh->group = NULL; > > } > > list_del_init(&sh->lru); > > - BUG_ON(atomic_inc_return(&sh->count) != 1); > > + BUG_ON(refcount_inc_not_zero(&sh->count)); > > This changes the behavior. refcount_inc_not_zero doesn't inc if original value is 0 Hm.. So, you want to inc here in any case and BUG if the end result differs from 1. So essentially you want to only increment here from zero to one under normal conditions... This is a challenge for refcount_t and against the design. Is it ok just to maybe do this here: - BUG_ON(atomic_inc_return(&sh->count) != 1); + BUG_ON(refcount_read(&sh->count) != 0); + refcount_set((&sh->count, 1); Do we have an issue with locking in this case? Or maybe it is then better to leave this one to be atomic_t without protection since it isn't a real refcounter as it turns out. Best Regards, Elena. > > Thanks, > Shaohua
[toc] | [prev] | [next] | [standalone]
| From | Elena Reshetova <elena.reshetova@intel.com> |
|---|---|
| Date | 2017-03-06 15:30 +0100 |
| Subject | [PATCH 26/29] drivers, usb: convert dev_data.count from atomic_t to refcount_t |
| Message-ID | <ti1O9-Yn-19@gated-at.bofh.it> |
| In reply to | #1593407 |
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: David Windsor <dwindsor@gmail.com>
---
drivers/usb/gadget/legacy/inode.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/legacy/inode.c b/drivers/usb/gadget/legacy/inode.c
index 79a2d8f..81d76f3 100644
--- a/drivers/usb/gadget/legacy/inode.c
+++ b/drivers/usb/gadget/legacy/inode.c
@@ -27,6 +27,7 @@
#include <linux/mmu_context.h>
#include <linux/aio.h>
#include <linux/uio.h>
+#include <linux/refcount.h>
#include <linux/device.h>
#include <linux/moduleparam.h>
@@ -114,7 +115,7 @@ enum ep0_state {
struct dev_data {
spinlock_t lock;
- atomic_t count;
+ refcount_t count;
enum ep0_state state; /* P: lock */
struct usb_gadgetfs_event event [N_EVENT];
unsigned ev_next;
@@ -150,12 +151,12 @@ struct dev_data {
static inline void get_dev (struct dev_data *data)
{
- atomic_inc (&data->count);
+ refcount_inc (&data->count);
}
static void put_dev (struct dev_data *data)
{
- if (likely (!atomic_dec_and_test (&data->count)))
+ if (likely (!refcount_dec_and_test (&data->count)))
return;
/* needs no more cleanup */
BUG_ON (waitqueue_active (&data->wait));
@@ -170,7 +171,7 @@ static struct dev_data *dev_new (void)
if (!dev)
return NULL;
dev->state = STATE_DEV_DISABLED;
- atomic_set (&dev->count, 1);
+ refcount_set (&dev->count, 1);
spin_lock_init (&dev->lock);
INIT_LIST_HEAD (&dev->epfiles);
init_waitqueue_head (&dev->wait);
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Elena Reshetova <elena.reshetova@intel.com> |
|---|---|
| Date | 2017-03-06 15:30 +0100 |
| Subject | [PATCH 06/29] drivers, md: convert dm_cache_metadata.ref_count from atomic_t to refcount_t |
| Message-ID | <ti1Oa-Yn-23@gated-at.bofh.it> |
| In reply to | #1593407 |
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: David Windsor <dwindsor@gmail.com>
---
drivers/md/dm-cache-metadata.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/md/dm-cache-metadata.c b/drivers/md/dm-cache-metadata.c
index e4c2c1a..6d26e71 100644
--- a/drivers/md/dm-cache-metadata.c
+++ b/drivers/md/dm-cache-metadata.c
@@ -13,6 +13,7 @@
#include "persistent-data/dm-transaction-manager.h"
#include <linux/device-mapper.h>
+#include <linux/refcount.h>
/*----------------------------------------------------------------*/
@@ -102,7 +103,7 @@ struct cache_disk_superblock {
} __packed;
struct dm_cache_metadata {
- atomic_t ref_count;
+ refcount_t ref_count;
struct list_head list;
unsigned version;
@@ -756,7 +757,7 @@ static struct dm_cache_metadata *metadata_open(struct block_device *bdev,
}
cmd->version = metadata_version;
- atomic_set(&cmd->ref_count, 1);
+ refcount_set(&cmd->ref_count, 1);
init_rwsem(&cmd->root_lock);
cmd->bdev = bdev;
cmd->data_block_size = data_block_size;
@@ -794,7 +795,7 @@ static struct dm_cache_metadata *lookup(struct block_device *bdev)
list_for_each_entry(cmd, &table, list)
if (cmd->bdev == bdev) {
- atomic_inc(&cmd->ref_count);
+ refcount_inc(&cmd->ref_count);
return cmd;
}
@@ -865,7 +866,7 @@ struct dm_cache_metadata *dm_cache_metadata_open(struct block_device *bdev,
void dm_cache_metadata_close(struct dm_cache_metadata *cmd)
{
- if (atomic_dec_and_test(&cmd->ref_count)) {
+ if (refcount_dec_and_test(&cmd->ref_count)) {
mutex_lock(&table_lock);
list_del(&cmd->list);
mutex_unlock(&table_lock);
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Elena Reshetova <elena.reshetova@intel.com> |
|---|---|
| Date | 2017-03-06 15:30 +0100 |
| Subject | [PATCH 24/29] drivers: convert iblock_req.pending from atomic_t to refcount_t |
| Message-ID | <ti1Oa-Yn-25@gated-at.bofh.it> |
| In reply to | #1593407 |
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: David Windsor <dwindsor@gmail.com>
---
drivers/target/target_core_iblock.c | 12 ++++++------
drivers/target/target_core_iblock.h | 3 ++-
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/target/target_core_iblock.c b/drivers/target/target_core_iblock.c
index d316ed5..bb069eb 100644
--- a/drivers/target/target_core_iblock.c
+++ b/drivers/target/target_core_iblock.c
@@ -279,7 +279,7 @@ static void iblock_complete_cmd(struct se_cmd *cmd)
struct iblock_req *ibr = cmd->priv;
u8 status;
- if (!atomic_dec_and_test(&ibr->pending))
+ if (!refcount_dec_and_test(&ibr->pending))
return;
if (atomic_read(&ibr->ib_bio_err_cnt))
@@ -487,7 +487,7 @@ iblock_execute_write_same(struct se_cmd *cmd)
bio_list_init(&list);
bio_list_add(&list, bio);
- atomic_set(&ibr->pending, 1);
+ refcount_set(&ibr->pending, 1);
while (sectors) {
while (bio_add_page(bio, sg_page(sg), sg->length, sg->offset)
@@ -498,7 +498,7 @@ iblock_execute_write_same(struct se_cmd *cmd)
if (!bio)
goto fail_put_bios;
- atomic_inc(&ibr->pending);
+ refcount_inc(&ibr->pending);
bio_list_add(&list, bio);
}
@@ -706,7 +706,7 @@ iblock_execute_rw(struct se_cmd *cmd, struct scatterlist *sgl, u32 sgl_nents,
cmd->priv = ibr;
if (!sgl_nents) {
- atomic_set(&ibr->pending, 1);
+ refcount_set(&ibr->pending, 1);
iblock_complete_cmd(cmd);
return 0;
}
@@ -719,7 +719,7 @@ iblock_execute_rw(struct se_cmd *cmd, struct scatterlist *sgl, u32 sgl_nents,
bio_list_init(&list);
bio_list_add(&list, bio);
- atomic_set(&ibr->pending, 2);
+ refcount_set(&ibr->pending, 2);
bio_cnt = 1;
for_each_sg(sgl, sg, sgl_nents, i) {
@@ -740,7 +740,7 @@ iblock_execute_rw(struct se_cmd *cmd, struct scatterlist *sgl, u32 sgl_nents,
if (!bio)
goto fail_put_bios;
- atomic_inc(&ibr->pending);
+ refcount_inc(&ibr->pending);
bio_list_add(&list, bio);
bio_cnt++;
}
diff --git a/drivers/target/target_core_iblock.h b/drivers/target/target_core_iblock.h
index 718d3fc..f2a5797 100644
--- a/drivers/target/target_core_iblock.h
+++ b/drivers/target/target_core_iblock.h
@@ -2,6 +2,7 @@
#define TARGET_CORE_IBLOCK_H
#include <linux/atomic.h>
+#include <linux/refcount.h>
#include <target/target_core_base.h>
#define IBLOCK_VERSION "4.0"
@@ -10,7 +11,7 @@
#define IBLOCK_LBA_SHIFT 9
struct iblock_req {
- atomic_t pending;
+ refcount_t pending;
atomic_t ib_bio_err_cnt;
} ____cacheline_aligned;
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | "Nicholas A. Bellinger" <nab@linux-iscsi.org> |
|---|---|
| Date | 2017-03-08 08:50 +0100 |
| Subject | Re: [PATCH 24/29] drivers: convert iblock_req.pending from atomic_t to refcount_t |
| Message-ID | <tiEw9-3fU-9@gated-at.bofh.it> |
| In reply to | #1593415 |
Hi Elena, On Mon, 2017-03-06 at 16:21 +0200, Elena Reshetova wrote: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. > > Signed-off-by: Elena Reshetova <elena.reshetova@intel.com> > Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com> > Signed-off-by: Kees Cook <keescook@chromium.org> > Signed-off-by: David Windsor <dwindsor@gmail.com> > --- > drivers/target/target_core_iblock.c | 12 ++++++------ > drivers/target/target_core_iblock.h | 3 ++- > 2 files changed, 8 insertions(+), 7 deletions(-) For the target_core_iblock part: Acked-by: Nicholas Bellinger <nab@linux-iscsi.org>
[toc] | [prev] | [next] | [standalone]
| From | "Nicholas A. Bellinger" <nab@linux-iscsi.org> |
|---|---|
| Date | 2017-03-21 08:20 +0100 |
| Subject | Re: [PATCH 24/29] drivers: convert iblock_req.pending from atomic_t to refcount_t |
| Message-ID | <tnmfg-8tT-15@gated-at.bofh.it> |
| In reply to | #1593415 |
Hi Elena, On Mon, 2017-03-06 at 16:21 +0200, Elena Reshetova wrote: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. > > Signed-off-by: Elena Reshetova <elena.reshetova@intel.com> > Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com> > Signed-off-by: Kees Cook <keescook@chromium.org> > Signed-off-by: David Windsor <dwindsor@gmail.com> > --- > drivers/target/target_core_iblock.c | 12 ++++++------ > drivers/target/target_core_iblock.h | 3 ++- > 2 files changed, 8 insertions(+), 7 deletions(-) After reading up on this thread, it looks like various subsystem maintainers are now picking these atomic_t -> refcount_t conversions.. That said, applied to target-pending/for-next and will plan to include for v4.12-rc1 merge window. Thanks!
[toc] | [prev] | [next] | [standalone]
| From | Elena Reshetova <elena.reshetova@intel.com> |
|---|---|
| Date | 2017-03-06 15:30 +0100 |
| Subject | [PATCH 02/29] drivers, firewire: convert fw_node.ref_count from atomic_t to refcount_t |
| Message-ID | <ti1Oa-Yn-33@gated-at.bofh.it> |
| In reply to | #1593407 |
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: David Windsor <dwindsor@gmail.com>
---
drivers/firewire/core-topology.c | 2 +-
drivers/firewire/core.h | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/firewire/core-topology.c b/drivers/firewire/core-topology.c
index 0de8350..939d259 100644
--- a/drivers/firewire/core-topology.c
+++ b/drivers/firewire/core-topology.c
@@ -124,7 +124,7 @@ static struct fw_node *fw_node_create(u32 sid, int port_count, int color)
node->initiated_reset = SELF_ID_PHY_INITIATOR(sid);
node->port_count = port_count;
- atomic_set(&node->ref_count, 1);
+ refcount_set(&node->ref_count, 1);
INIT_LIST_HEAD(&node->link);
return node;
diff --git a/drivers/firewire/core.h b/drivers/firewire/core.h
index e1480ff6..c07962e 100644
--- a/drivers/firewire/core.h
+++ b/drivers/firewire/core.h
@@ -12,7 +12,7 @@
#include <linux/slab.h>
#include <linux/types.h>
-#include <linux/atomic.h>
+#include <linux/refcount.h>
struct device;
struct fw_card;
@@ -184,7 +184,7 @@ struct fw_node {
* local node to this node. */
u8 max_depth:4; /* Maximum depth to any leaf node */
u8 max_hops:4; /* Max hops in this sub tree */
- atomic_t ref_count;
+ refcount_t ref_count;
/* For serializing node topology into a list. */
struct list_head link;
@@ -197,14 +197,14 @@ struct fw_node {
static inline struct fw_node *fw_node_get(struct fw_node *node)
{
- atomic_inc(&node->ref_count);
+ refcount_inc(&node->ref_count);
return node;
}
static inline void fw_node_put(struct fw_node *node)
{
- if (atomic_dec_and_test(&node->ref_count))
+ if (refcount_dec_and_test(&node->ref_count))
kfree(node);
}
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Elena Reshetova <elena.reshetova@intel.com> |
|---|---|
| Date | 2017-03-06 15:40 +0100 |
| Subject | [PATCH 13/29] drivers, media: convert vb2_vmarea_handler.refcount from atomic_t to refcount_t |
| Message-ID | <ti1XP-146-3@gated-at.bofh.it> |
| In reply to | #1593407 |
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: David Windsor <dwindsor@gmail.com>
---
drivers/media/v4l2-core/videobuf2-memops.c | 6 +++---
include/media/videobuf2-memops.h | 3 ++-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-memops.c b/drivers/media/v4l2-core/videobuf2-memops.c
index 1cd322e..4bb8424 100644
--- a/drivers/media/v4l2-core/videobuf2-memops.c
+++ b/drivers/media/v4l2-core/videobuf2-memops.c
@@ -96,10 +96,10 @@ static void vb2_common_vm_open(struct vm_area_struct *vma)
struct vb2_vmarea_handler *h = vma->vm_private_data;
pr_debug("%s: %p, refcount: %d, vma: %08lx-%08lx\n",
- __func__, h, atomic_read(h->refcount), vma->vm_start,
+ __func__, h, refcount_read(h->refcount), vma->vm_start,
vma->vm_end);
- atomic_inc(h->refcount);
+ refcount_inc(h->refcount);
}
/**
@@ -114,7 +114,7 @@ static void vb2_common_vm_close(struct vm_area_struct *vma)
struct vb2_vmarea_handler *h = vma->vm_private_data;
pr_debug("%s: %p, refcount: %d, vma: %08lx-%08lx\n",
- __func__, h, atomic_read(h->refcount), vma->vm_start,
+ __func__, h, refcount_read(h->refcount), vma->vm_start,
vma->vm_end);
h->put(h->arg);
diff --git a/include/media/videobuf2-memops.h b/include/media/videobuf2-memops.h
index 36565c7a..a6ed091 100644
--- a/include/media/videobuf2-memops.h
+++ b/include/media/videobuf2-memops.h
@@ -16,6 +16,7 @@
#include <media/videobuf2-v4l2.h>
#include <linux/mm.h>
+#include <linux/refcount.h>
/**
* struct vb2_vmarea_handler - common vma refcount tracking handler
@@ -25,7 +26,7 @@
* @arg: argument for @put callback
*/
struct vb2_vmarea_handler {
- atomic_t *refcount;
+ refcount_t *refcount;
void (*put)(void *arg);
void *arg;
};
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Sakari Ailus <sakari.ailus@iki.fi> |
|---|---|
| Date | 2017-03-07 10:00 +0100 |
| Subject | Re: [PATCH 13/29] drivers, media: convert vb2_vmarea_handler.refcount from atomic_t to refcount_t |
| Message-ID | <tij8m-4ZD-37@gated-at.bofh.it> |
| In reply to | #1593417 |
Hi Elena,
On Mon, Mar 06, 2017 at 04:21:00PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
>
> Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
> Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: David Windsor <dwindsor@gmail.com>
> ---
> drivers/media/v4l2-core/videobuf2-memops.c | 6 +++---
> include/media/videobuf2-memops.h | 3 ++-
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/videobuf2-memops.c b/drivers/media/v4l2-core/videobuf2-memops.c
> index 1cd322e..4bb8424 100644
> --- a/drivers/media/v4l2-core/videobuf2-memops.c
> +++ b/drivers/media/v4l2-core/videobuf2-memops.c
> @@ -96,10 +96,10 @@ static void vb2_common_vm_open(struct vm_area_struct *vma)
> struct vb2_vmarea_handler *h = vma->vm_private_data;
>
> pr_debug("%s: %p, refcount: %d, vma: %08lx-%08lx\n",
> - __func__, h, atomic_read(h->refcount), vma->vm_start,
> + __func__, h, refcount_read(h->refcount), vma->vm_start,
> vma->vm_end);
>
> - atomic_inc(h->refcount);
> + refcount_inc(h->refcount);
> }
>
> /**
> @@ -114,7 +114,7 @@ static void vb2_common_vm_close(struct vm_area_struct *vma)
> struct vb2_vmarea_handler *h = vma->vm_private_data;
>
> pr_debug("%s: %p, refcount: %d, vma: %08lx-%08lx\n",
> - __func__, h, atomic_read(h->refcount), vma->vm_start,
> + __func__, h, refcount_read(h->refcount), vma->vm_start,
> vma->vm_end);
>
> h->put(h->arg);
> diff --git a/include/media/videobuf2-memops.h b/include/media/videobuf2-memops.h
> index 36565c7a..a6ed091 100644
> --- a/include/media/videobuf2-memops.h
> +++ b/include/media/videobuf2-memops.h
> @@ -16,6 +16,7 @@
>
> #include <media/videobuf2-v4l2.h>
> #include <linux/mm.h>
> +#include <linux/refcount.h>
>
> /**
> * struct vb2_vmarea_handler - common vma refcount tracking handler
> @@ -25,7 +26,7 @@
> * @arg: argument for @put callback
> */
> struct vb2_vmarea_handler {
> - atomic_t *refcount;
> + refcount_t *refcount;
This is a pointer to refcount, not refcount itself. The refcount is part of
a memory type specific struct, the types that you change in the following
three patches. I guess it would still compile and work as separate patches
but you'd sure get warnings at least.
How about merging this and the three following patches that change the memop
refcount types?
> void (*put)(void *arg);
> void *arg;
> };
--
Kind regards,
Sakari Ailus
e-mail: sakari.ailus@iki.fi XMPP: sailus@retiisi.org.uk
[toc] | [prev] | [next] | [standalone]
Page 1 of 3 [1] 2 3 Next page →
Back to top | Article view | linux.kernel
csiph-web