Linux RAID subsystem development
 help / color / mirror / Atom feed
* Re: [PATCH] mdadm:fix typo in comment
From: jes.sorensen @ 2017-03-06 21:27 UTC (permalink / raw)
  To: Zhilong Liu; +Cc: linux-raid
In-Reply-To: <1488357873-19495-1-git-send-email-zlliu@suse.com>

Zhilong Liu <zlliu@suse.com> writes:
> Signed-off-by: Zhilong Liu <zlliu@suse.com>
>
> diff --git a/mdadm.c b/mdadm.c
> index b5d89e4..16fd49a 100644
> --- a/mdadm.c
> +++ b/mdadm.c
> @@ -1268,7 +1268,7 @@ int main(int argc, char *argv[])
>  	 * hopefully it's mostly right but there might be some stuff
>  	 * missing
>  	 *
> -	 * That is mosty checked in the per-mode stuff but...
> +	 * That is mostly checked in the per-mode stuff but...
>  	 *
>  	 * For @,B,C and A without -s, the first device listed must be
>  	 * an md device.  We check that here and open it.

Applied!

Thanks,
Jes

^ permalink raw reply

* Re: [MDADM PATCH 2/2] Specify suitable size when write to buffer
From: jes.sorensen @ 2017-03-06 21:21 UTC (permalink / raw)
  To: Xiao Ni; +Cc: linux-raid, ncroxon
In-Reply-To: <1488348766-31087-3-git-send-email-xni@redhat.com>

Xiao Ni <xni@redhat.com> writes:
> ---
>  Detail.c      | 2 +-
>  super-intel.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Detail.c b/Detail.c
> index 509b0d4..f4d4241 100644
> --- a/Detail.c
> +++ b/Detail.c
> @@ -575,7 +575,7 @@ This is pretty boring
>  			printf("  Member Arrays :");
>  
>  			while (dir && (de = readdir(dir)) != NULL) {
> -				char path[200];
> +				char path[320];
>  				char vbuf[1024];
>  				int nlen = strlen(sra->sys_name);
>  				dev_t devid;
> diff --git a/super-intel.c b/super-intel.c
> index d5e9517..ea50265 100644
> --- a/super-intel.c
> +++ b/super-intel.c
> @@ -1811,7 +1811,7 @@ static void examine_super_imsm(struct supertype *st, char *homehost)
>  	__u32 reserved = imsm_reserved_sectors(super, super->disks);
>  	struct dl *dl;
>  
> -	snprintf(str, MPB_SIG_LEN, "%s", mpb->sig);
> +	snprintf(str, MAX_SIGNATURE_LENGTH, "%s", mpb->sig);
>  	printf("          Magic : %s\n", str);
>  	snprintf(str, strlen(MPB_VERSION_RAID0), "%s", get_imsm_version(mpb));
>  	printf("        Version : %s\n", get_imsm_version(mpb));

Hi Xiao,

This is really two independent changes, so they should come in two
seperate patches. All the patches needs their own commit messages and
signed-off-by lines.

Thanks,
Jes

^ permalink raw reply

* Re: [MDADM PATCH 1/2] Add Wimplicit-fallthrough=0 in Makefile
From: jes.sorensen @ 2017-03-06 20:30 UTC (permalink / raw)
  To: Xiao Ni; +Cc: linux-raid, ncroxon
In-Reply-To: <1488348766-31087-2-git-send-email-xni@redhat.com>

Xiao Ni <xni@redhat.com> writes:
> There are many errors like 'error: this statement may fall through'. 
> But the logic is right. So add the flag Wimplicit-fallthrough=0 
> to disable the error messages. The method I use is from 
> https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
> #index-Wimplicit-fallthrough-375
> ---
>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index a6f464c..b9f52e0 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -43,7 +43,7 @@ KLIBC_GCC = gcc -nostdinc -iwithprefix include
> -I$(KLIBC)/klibc/include -I$(KLIB
>  
>  CC ?= $(CROSS_COMPILE)gcc
>  CXFLAGS ?= -ggdb
> -CWFLAGS = -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
> +CWFLAGS = -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter -Wimplicit-fallthrough=0

Hi Xiao,

I am not sure how long -Wimplicit-fallthrough has existed. I want to
make sure we allow for this to compile with older compilers as well.

Could you please make it a check so this flag is only set if the version
of gcc supports it?

Thanks,
Jes



^ permalink raw reply

* Re: [PATCH 1/2] md: add bad block flag to disk state
From: jes.sorensen @ 2017-03-06 20:23 UTC (permalink / raw)
  To: Shaohua Li; +Cc: Tomasz Majchrzak, linux-raid
In-Reply-To: <20170201181215.4d5nfyxmpsmgenks@kernel.org>

Shaohua Li <shli@kernel.org> writes:
> On Wed, Feb 01, 2017 at 10:53:52AM +0100, Tomasz Majchrzak wrote:
>> On Mon, Jan 30, 2017 at 03:33:41PM -0800, Shaohua Li wrote:
>> > On Tue, Jan 24, 2017 at 01:03:38PM +0100, Tomasz Majchrzak wrote:
>> > > Add a new flag to report that bad blocks are present on a disk. It will
>> > > allow userspace to notify the user of the problem.
>> > > 
>> > > Signed-off-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
>> > > ---
>> > >  drivers/md/md.c                | 2 ++
>> > >  include/uapi/linux/raid/md_p.h | 1 +
>> > >  2 files changed, 3 insertions(+)
>> > > 
>> > > diff --git a/drivers/md/md.c b/drivers/md/md.c
>> > > index 0abb147..1a807ec 100644
>> > > --- a/drivers/md/md.c
>> > > +++ b/drivers/md/md.c
>> > > @@ -6034,6 +6034,8 @@ static int get_disk_info(struct mddev *mddev, void __user * arg)
>> > >  			info.state |= (1<<MD_DISK_WRITEMOSTLY);
>> > >  		if (test_bit(FailFast, &rdev->flags))
>> > >  			info.state |= (1<<MD_DISK_FAILFAST);
>> > > +		if (rdev->badblocks.count)
>> > > +			info.state |= (1<<MD_DISK_BB_PRESENT);
>> > 
>> > Userspace can find if a disk has badblocks by reading the bad_blocks sysfs
>> > file. Why adds another interface?
>> > 
>> > Thanks,
>> > Shaohua
>> 
>> Yes, indeed, it can. I have chosen to do it this way to keep it consistent
>> with mdadm which uses GET_DISK_INFO ioctl to get disk information. All data
>> provided in this ioctl is also available in sysfs file (rdev state), however
>> ioctl is still used (legacy). The same applies for details subcommand of
>> mdadm. To answer your question - yes, I could avoid new flag but it would
>> make mdadm side of my improvement much more complicated.
>
> I intended to avoid adding new user interface if possible. Not sure about this
> case though. How complicated in the mdadm side if we use the bad_block sysfs
> file?
>
> Jes, how do you think from the mdadm side?

Hi,

Sorry for being so late getting back on this, I am just getting back to
this now.

I am really split on this - if we have spare flags available, I guess
it's not the end of the World. On the other hand there is something to
be said for not adding any more using the old interface.

Right now mdadm relies heavily on the ioctl interfaces. In order to
migrate away from that, we need to spend a fair amount of time to
rewriting the general interface first. Something I think we should
invest some time into doing, but having to handle both in parallel seems
a bad idea to me.

Cheers,
Jes

^ permalink raw reply

* Re: RAID Recovery
From: Phil Turmel @ 2017-03-06 20:10 UTC (permalink / raw)
  To: Adam Goryachev, linux-raid
In-Reply-To: <936e84af-f190-3541-bdf8-eaa0c42d2ddc@websitemanagers.com.au>

On 03/06/2017 10:07 AM, Adam Goryachev wrote:
> Hi all,
> 
> I'm trying to assist a friend to recover their RAID array, it consists
> of 4 drives, most likely in RAID10. It was a linux based NAS (AFAIK). I
> would really appreciate any tips or suggestions...
> 
> First, the bad news:
> 
> mdadm --misc --detail /dev/sd[abcd]
> mdadm: /dev/sda does not appear to be an md device

For future reference:  --detail is only applicable to the /dev/md*
*array* device.  --examine is only applicable to *member* devices,
and is required for valid results when an array is not running.

> mdadm --misc --examine /dev/sd[abcd]
> /dev/sda:
>    MBR Magic : aa55
> /dev/sdb:
>    MBR Magic : aa55
> /dev/sdc:
>    MBR Magic : aa55
> /dev/sdd:
>    MBR Magic : aa55
> 
> This really doesn't look promising.... but the disks themselves look
> "healthy"... at least mostly.

As Reindl said, this by itself is no surprise.  The NAS has to boot off
of *something*, so partitions for /boot, /swap, /, and /data, or some
combination, is common for such small systems.

The first partition is likely raid1 across all devices for /boot.
After that, all bets are off.

> Looking at the content of the drives, it might be possible that all four
> drives were in RAID1 ... at least, I can find identical data on all four
> of the drives:
> 
> Running this command for each drive:
> 
> strings /dev/sdd |cat -n |less
> 
> looking for some "text", and I find what looks like a log file snipped
> which is identical across all four drives. Thats 25 lines of output,
> that exists on the same output line number, matching across all 4
> drives. So perhaps I have a 4 drive RAID1, which I guess should make it
> easier to recover from.

Probably just a 4x raid1 mirror for the root partition.

> Disks are /dev/sda /dev/sdb /dev/sdc /dev/sdd, all identical
> "partitions" that don't seem to exist, but there is a MBR partition table
> 
> gdisk -l /dev/sda
> GPT fdisk (gdisk) version 1.0.1
> 
> Partition table scan:
>   MBR: MBR only
>   BSD: not present
>   APM: not present
>   GPT: not present
> 
> 
> ***************************************************************
> Found invalid GPT and valid MBR; converting MBR to GPT format
> in memory.
> ***************************************************************
> 
> Disk /dev/sda: 1953525168 sectors, 931.5 GiB
> Logical sector size: 512 bytes
> Disk identifier (GUID): 145F71F0-4D0B-4941-9F9E-2C5301BF518F
> Partition table holds up to 128 entries
> First usable sector is 34, last usable sector is 1953525134
> Partitions will be aligned on 2048-sector boundaries
> Total free space is 1953525101 sectors (931.5 GiB)

This is worrisome.  Please repost the complete output of fdisk -l
and gdisk -l for all of these devices.  But....

> The first two drives look like this (lots of read errors), the second
> two look perfectly clean...

Please remove the drives from the NAS box and connect to a known good
system.  Your smartctl reports include neither re-allocated sectors
nor pending relocations, which would be expected if there are many
read errors.  That means the read errors are likely due to controller,
cables, or power supply problems.

Note, timeout mismatch *does not* apply to sda, but you trimmed
too much to tell for the other devices.  Please submit complete output
from smartctl -iA -l scterc /dev/sdX for each of these devices.

Do the fdisk & gdisk reports from the known good system, and also,
if you can find any partitions, run --examine on each from the same
system.  Keep the --examine reports with the corresponding smartctl
report.

Phil

^ permalink raw reply

* Re: [RAID recovery] Unable to recover RAID5 array after disk failure
From: Phil Turmel @ 2017-03-06 19:50 UTC (permalink / raw)
  To: Olivier Swinkels; +Cc: linux-raid
In-Reply-To: <CAJ0QwkKuSKzE7_4h1aUA4XMyNAAdmFR4J6z+Z_vW5nsW3OcZtw@mail.gmail.com>

On 03/06/2017 04:17 AM, Olivier Swinkels wrote:

>> That sounds promising, as /etc was not on the array.
>> I found a backup in /etc/lvm/backup/lvm-raid (contents shown below).

Yay!  That's exactly what you need.

>> Unfortunatelly when I try to use it to restore the LVM I get the
>> following error:
>> vgcfgrestore -f /etc/lvm/backup/lvm-raid lvm-raid
>> Aborting vg_write: No metadata areas to write to!
>> Restore failed.

You're command doesn't specify the device name of your reconstructed
array.

>> So I guess I also need to recreate the physical volume using:
> 
> Correction: (Put the wrong ID in the pvcreate example):
> pvcreate --uuid "DWv51O-lg9s-Dl4w-EBp9-QeIF-Vv60-8wt2uS" --restorefile
> /etc/lvm/backup/lvm-raid
> 
>> Is this correct? (I'm a bit hesitant with another 'create' command as
>> you might understand.)

I haven't actually had to do this operation but once, and I don't
recall if the vgcfgrestore was sufficient.  But either way, you simply
didn't tell LVM where you are restoring TO.

Phil


^ permalink raw reply

* Re: [Xen-devel] [PATCH 29/29] drivers, xen: convert grant_map.users from atomic_t to refcount_t
From: Boris Ostrovsky @ 2017-03-06 16:58 UTC (permalink / raw)
  To: Elena Reshetova, gregkh
  Cc: peterz, linux-pci, target-devel, linux1394-devel, devel,
	linux-s390, linux-scsi, linux-serial, fcoe-devel,
	Hans Liljestrand, open-iscsi, linux-media, Kees Cook, linux-raid,
	linux-bcache, xen-devel, David Windsor, Juergen Gross, netdev,
	linux-usb, linux-kernel, devel
In-Reply-To: <1488810076-3754-30-git-send-email-elena.reshetova@intel.com>

On 03/06/2017 09:21 AM, 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/xen/gntdev.c | 11 ++++++-----
>  1 file changed, 6 insertions(+), 5 deletions(-)

Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

^ permalink raw reply

* Re: [PATCH 21/29] drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t
From: Benjamin Block @ 2017-03-06 16:54 UTC (permalink / raw)
  To: Johannes Thumshirn
  Cc: peterz, linux-pci, target-devel, linux1394-devel, Elena Reshetova,
	devel, linux-s390, linux-scsi, linux-serial, fcoe-devel,
	xen-devel, open-iscsi, linux-media, Kees Cook, linux-raid,
	linux-bcache, Hans Liljestrand, David Windsor, gregkh, linux-usb,
	linux-kernel, netdev, devel
In-Reply-To: <536a58ba-8896-5639-cab9-bd2f13bed325@suse.de>

On Mon, Mar 06, 2017 at 04:27:11PM +0100, Johannes Thumshirn wrote:
> On 03/06/2017 03:21 PM, 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.
> 
> The subject is wrong, should be something like "scsi: libfc convert
> fc_fcp_pkt.ref_cnt from atomic_t to refcount_t" but not s390.
> 

Yes please, I was extremely confused for a moment here.



                                                    Beste Grüße / Best regards,
                                                      - Benjamin Block
-- 
Linux on z Systems Development         /         IBM Systems & Technology Group
		  IBM Deutschland Research & Development GmbH 
Vorsitz. AufsR.: Martina Koederitz     /        Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: AmtsG Stuttgart, HRB 243294

^ permalink raw reply

* Re: [PATCH 11/29] drivers, media: convert cx88_core.refcount from atomic_t to refcount_t
From: Sergei Shtylyov @ 2017-03-06 16:26 UTC (permalink / raw)
  To: Elena Reshetova, gregkh
  Cc: devel, linux-s390, open-iscsi, Kees Cook, linux-scsi,
	David Windsor, peterz, netdev, linux-usb, linux-pci, linux-kernel,
	linux-raid, linux-bcache, target-devel, linux-serial, devel,
	fcoe-devel, xen-devel, linux1394-devel, Hans Liljestrand,
	linux-media
In-Reply-To: <1488810076-3754-12-git-send-email-elena.reshetova@intel.com>

Hello.

On 03/06/2017 05:20 PM, 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>
[...]
> diff --git a/drivers/media/pci/cx88/cx88.h b/drivers/media/pci/cx88/cx88.h
> index 115414c..16c1313 100644
> --- a/drivers/media/pci/cx88/cx88.h
> +++ b/drivers/media/pci/cx88/cx88.h
> @@ -24,6 +24,7 @@
>  #include <linux/i2c-algo-bit.h>
>  #include <linux/videodev2.h>
>  #include <linux/kdev_t.h>
> +#include <linux/refcount.h>
>
>  #include <media/v4l2-device.h>
>  #include <media/v4l2-fh.h>
> @@ -339,7 +340,7 @@ struct cx8802_dev;
>
>  struct cx88_core {
>  	struct list_head           devlist;
> -	atomic_t                   refcount;
> +	refcount_t                   refcount;

    Could you please keep the name aligned with above and below?

>
>  	/* board name */
>  	int                        nr;
>

MBR, Sergei

^ permalink raw reply

* Re: RAID Recovery
From: Reindl Harald @ 2017-03-06 15:36 UTC (permalink / raw)
  To: Adam Goryachev, linux-raid
In-Reply-To: <936e84af-f190-3541-bdf8-eaa0c42d2ddc@websitemanagers.com.au>



Am 06.03.2017 um 16:07 schrieb Adam Goryachev:
> Hi all,
>
> I'm trying to assist a friend to recover their RAID array, it consists
> of 4 drives, most likely in RAID10. It was a linux based NAS (AFAIK). I
> would really appreciate any tips or suggestions...
>
> First, the bad news:
>
> mdadm --misc --detail /dev/sd[abcd]
> mdadm: /dev/sda does not appear to be an md device
> mdadm: /dev/sdb does not appear to be an md device
> mdadm: /dev/sdc does not appear to be an md device
> mdadm: /dev/sdd does not appear to be an md device

it's not uncommon to use partitions instead of whole drives

that below are two RAID10 and one RAID1 on four 2 TB drives and so 
/dev/sd[-d] are not an md-device

[root@rh:~]$ cat /proc/mdstat
Personalities : [raid1] [raid10]
md1 : active raid10 sda2[0] sdd2[2] sdb2[3] sdc2[1]
       30716928 blocks super 1.1 512K chunks 2 near-copies [4/4] [UUUU]

md0 : active raid1 sda1[0] sdd1[2] sdb1[3] sdc1[1]
       511988 blocks super 1.0 [4/4] [UUUU]

md2 : active raid10 sda3[0] sdd3[2] sdb3[3] sdc3[1]
       3875222528 blocks super 1.1 512K chunks 2 near-copies [4/4] [UUUU]

^ permalink raw reply

* Re: [PATCH 21/29] drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t
From: Johannes Thumshirn @ 2017-03-06 15:27 UTC (permalink / raw)
  To: Elena Reshetova, gregkh
  Cc: linux-kernel, xen-devel, netdev, linux1394-devel, linux-bcache,
	linux-raid, linux-media, devel, linux-pci, linux-s390, fcoe-devel,
	linux-scsi, open-iscsi, devel, target-devel, linux-serial,
	linux-usb, peterz, Hans Liljestrand, Kees Cook, David Windsor
In-Reply-To: <1488810076-3754-22-git-send-email-elena.reshetova@intel.com>

On 03/06/2017 03:21 PM, 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.

The subject is wrong, should be something like "scsi: libfc convert
fc_fcp_pkt.ref_cnt from atomic_t to refcount_t" but not s390.

Other than that
Acked-by: Johannes Thumshirn <jth@kernel.org>

-- 
Johannes Thumshirn                                          Storage
jthumshirn@suse.de                                +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

^ permalink raw reply

* RAID Recovery
From: Adam Goryachev @ 2017-03-06 15:07 UTC (permalink / raw)
  To: linux-raid

Hi all,

I'm trying to assist a friend to recover their RAID array, it consists 
of 4 drives, most likely in RAID10. It was a linux based NAS (AFAIK). I 
would really appreciate any tips or suggestions...

First, the bad news:

mdadm --misc --detail /dev/sd[abcd]
mdadm: /dev/sda does not appear to be an md device
mdadm: /dev/sdb does not appear to be an md device
mdadm: /dev/sdc does not appear to be an md device
mdadm: /dev/sdd does not appear to be an md device

mdadm --misc --examine /dev/sd[abcd]
/dev/sda:
    MBR Magic : aa55
/dev/sdb:
    MBR Magic : aa55
/dev/sdc:
    MBR Magic : aa55
/dev/sdd:
    MBR Magic : aa55

This really doesn't look promising.... but the disks themselves look 
"healthy"... at least mostly.

Looking at the content of the drives, it might be possible that all four 
drives were in RAID1 ... at least, I can find identical data on all four 
of the drives:

Running this command for each drive:

strings /dev/sdd |cat -n |less

looking for some "text", and I find what looks like a log file snipped 
which is identical across all four drives. Thats 25 lines of output, 
that exists on the same output line number, matching across all 4 
drives. So perhaps I have a 4 drive RAID1, which I guess should make it 
easier to recover from.


Disks are /dev/sda /dev/sdb /dev/sdc /dev/sdd, all identical 
"partitions" that don't seem to exist, but there is a MBR partition table

gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
   MBR: MBR only
   BSD: not present
   APM: not present
   GPT: not present


***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.
***************************************************************

Disk /dev/sda: 1953525168 sectors, 931.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 145F71F0-4D0B-4941-9F9E-2C5301BF518F
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 2048-sector boundaries
Total free space is 1953525101 sectors (931.5 GiB)

The first two drives look like this (lots of read errors), the second 
two look perfectly clean...

/dev/sda

Number  Start (sector)    End (sector)  Size       Code  Name

=== START OF INFORMATION SECTION ===
Device Model:     ST1000NM0033         81Y9807 81Y3867IBM
Serial Number:    Z1W2ZG3M
LU WWN Device Id: 5 000c50 079c48262
Firmware Version: BB5A
User Capacity:    1,000,204,886,016 bytes [1.00 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-2 (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Mon Mar  6 14:44:32 2017 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
AAM feature is:   Unavailable
APM feature is:   Unavailable
Rd look-ahead is: Enabled
Write cache is:   Enabled
ATA Security is:  Disabled, NOT FROZEN [SEC1]
Wt Cache Reorder: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82) Offline data collection activity
                                         was completed without error.
                                         Auto Offline Data Collection: 
Enabled.
Self-test execution status:      (   0) The previous self-test routine 
completed
                                         without error or no self-test 
has ever
                                         been run.
Total time to complete Offline
data collection:                (  592) seconds.
Offline data collection
capabilities:                    (0x7b) SMART execute Offline immediate.
                                         Auto Offline data collection 
on/off support.
                                         Suspend Offline collection upon new
                                         command.
                                         Offline surface scan supported.
                                         Self-test supported.
                                         Conveyance Self-test supported.
                                         Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                         power-saving mode.
                                         Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                         General Purpose Logging supported.
Short self-test routine
recommended polling time:        (   1) minutes.
Extended self-test routine
recommended polling time:        ( 115) minutes.
Conveyance self-test routine
recommended polling time:        (   2) minutes.
SCT capabilities:              (0x50bd) SCT Status supported.
                                         SCT Error Recovery Control 
supported.
                                         SCT Feature Control supported.
                                         SCT Data Table supported.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAGS    VALUE WORST THRESH FAIL RAW_VALUE
   1 Raw_Read_Error_Rate     POSR--   081   063   044 -    120486603
   3 Spin_Up_Time            PO----   097   096   000 -    0
   4 Start_Stop_Count        -O--CK   100   100   020 -    80
   5 Reallocated_Sector_Ct   PO--CK   100   100   010 -    0
   7 Seek_Error_Rate         POSR--   082   060   030 -    181785851
   9 Power_On_Hours          -O--CK   087   087   000 -    11874
  10 Spin_Retry_Count        PO--C-   100   100   097 -    0
  12 Power_Cycle_Count       -O--CK   100   100   020 -    65
184 End-to-End_Error        -O--CK   100   100   099 -    0
187 Reported_Uncorrect      -O--CK   100   100   000 -    0
188 Command_Timeout         -O--CK   100   100   000 -    0
189 High_Fly_Writes         -O-RCK   100   100   000 -    0
190 Airflow_Temperature_Cel -O---K   060   051   045 -    40 (Min/Max 37/40)
191 G-Sense_Error_Rate      -O--CK   100   100   000 -    0
192 Power-Off_Retract_Count -O--CK   100   100   000 -    60
193 Load_Cycle_Count        -O--CK   100   100   000 -    559
194 Temperature_Celsius     -O---K   040   049   000 -    40 (0 21 0 0 0)
195 Hardware_ECC_Recovered  -O-RC-   021   007   000 -    120486603
197 Current_Pending_Sector  -O--C-   100   100   000 -    0
198 Offline_Uncorrectable   ----C-   100   100   000 -    0
199 UDMA_CRC_Error_Count    -OSRCK   200   200   000 -    0
                             ||||||_ K auto-keep
                             |||||__ C event count
                             ||||___ R error rate
                             |||____ S speed/performance
                             ||_____ O updated online
                             |______ P prefailure warning

General Purpose Log Directory Version 1
SMART           Log Directory Version 1 [multi-sector log support]
Address    Access  R/W   Size  Description
0x00       GPL,SL  R/O      1  Log Directory
0x01           SL  R/O      1  Summary SMART error log
0x02           SL  R/O      5  Comprehensive SMART error log
0x03       GPL     R/O      5  Ext. Comprehensive SMART error log
0x04       GPL,SL  R/O      8  Device Statistics log
0x06           SL  R/O      1  SMART self-test log
0x07       GPL     R/O      1  Extended self-test log
0x08       GPL,SL  R/O      2  Power Conditions log
0x09           SL  R/W      1  Selective self-test log
0x10       GPL     R/O      1  SATA NCQ Queued Error log
0x11       GPL     R/O      1  SATA Phy Event Counters log
0x21       GPL     R/O      1  Write stream error log
0x22       GPL     R/O      1  Read stream error log
0x24       GPL     R/O    512  Current Device Internal Status Data log
0x30       GPL,SL  R/O      9  IDENTIFY DEVICE data log
0x80-0x9f  GPL,SL  R/W     16  Host vendor specific log
0xa1       GPL,SL  VS      20  Device vendor specific log
0xa2       GPL     VS    4496  Device vendor specific log
0xa8       GPL,SL  VS     129  Device vendor specific log
0xa9       GPL,SL  VS       1  Device vendor specific log
0xb0       GPL,SL  VS       1  Device vendor specific log
0xbd       GPL     VS     512  Device vendor specific log
0xbe-0xbf  GPL     VS   65535  Device vendor specific log
0xc1       GPL,SL  VS      10  Device vendor specific log
0xc2       GPL,SL  VS      50  Device vendor specific log
0xc3       GPL,SL  VS       8  Device vendor specific log
0xc4       GPL,SL  VS       5  Device vendor specific log
0xd1       GPL,SL  VS       8  Device vendor specific log
0xe0       GPL,SL  R/W      1  SCT Command/Status
0xe1       GPL,SL  R/W      1  SCT Data Transfer

SMART Extended Comprehensive Error Log Version: 1 (5 sectors)
No Errors Logged

SMART Extended Self-test Log Version: 1 (1 sectors)
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

SMART Selective self-test log data structure revision number 1
  SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
     1        0        0  Not_testing
     2        0        0  Not_testing
     3        0        0  Not_testing
     4        0        0  Not_testing
     5        0        0  Not_testing
Selective self-test flags (0x0):
   After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

SCT Status Version:                  3
SCT Version (vendor specific):       522 (0x020a)
SCT Support Level:                   1
Device State:                        Active (0)
Current Temperature:                    40 Celsius
Power Cycle Min/Max Temperature:     37/40 Celsius
Lifetime    Min/Max Temperature:     21/49 Celsius
Under/Over Temperature Limit Count:   0/8

SCT Temperature History Version:     2
Temperature Sampling Period:         1 minute
Temperature Logging Interval:        10 minutes
Min/Max recommended Temperature:      0/ 0 Celsius
Min/Max Temperature Limit:            0/ 0 Celsius
Temperature History Size (Index):    128 (50)
[SNIP TEMPERATURE SECTION]

SCT Error Recovery Control:
            Read:     75 (7.5 seconds)
           Write:     75 (7.5 seconds)

Device Statistics (GP Log 0x04)
Page  Offset Size        Value Flags Description
0x01  =====  =               =  ===  == General Statistics (rev 2) ==
0x01  0x008  4              65  ---  Lifetime Power-On Resets
0x01  0x010  4           11874  ---  Power-on Hours
0x01  0x018  6      2728215464  ---  Logical Sectors Written
0x01  0x020  6        60447755  ---  Number of Write Commands
0x01  0x028  6     72441102919  ---  Logical Sectors Read
0x01  0x030  6        47955151  ---  Number of Read Commands
0x01  0x038  6               -  ---  Date and Time TimeStamp
0x03  =====  =               =  ===  == Rotating Media Statistics (rev 1) ==
0x03  0x008  4           11667  ---  Spindle Motor Power-on Hours
0x03  0x010  4             437  ---  Head Flying Hours
0x03  0x018  4             559  ---  Head Load Events
0x03  0x020  4               0  ---  Number of Reallocated Logical Sectors
0x03  0x028  4               0  ---  Read Recovery Attempts
0x03  0x030  4               0  ---  Number of Mechanical Start Failures
0x04  =====  =               =  ===  == General Errors Statistics (rev 1) ==
0x04  0x008  4               0  ---  Number of Reported Uncorrectable Errors
0x04  0x010  4               0  ---  Resets Between Cmd Acceptance and 
Completion
0x05  =====  =               =  ===  == Temperature Statistics (rev 1) ==
0x05  0x008  1              40  N--  Current Temperature
0x05  0x010  1              38  N--  Average Short Term Temperature
0x05  0x018  1              38  N--  Average Long Term Temperature
0x05  0x020  1              49  N--  Highest Temperature
0x05  0x028  1              21  N--  Lowest Temperature
0x05  0x030  1              41  N--  Highest Average Short Term Temperature
0x05  0x038  1               2  N--  Lowest Average Short Term Temperature
0x05  0x040  1              39  N--  Highest Average Long Term Temperature
0x05  0x050  4               0  ---  Time in Over-Temperature
0x05  0x058  1              55  ---  Specified Maximum Operating Temperature
0x05  0x060  4               0  ---  Time in Under-Temperature
0x05  0x068  1              13  ---  Specified Minimum Operating Temperature
                                 |||_ C monitored condition met
                                 ||__ D supports DSN
                                 |___ N normalized value

SATA Phy Event Counters (GP Log 0x11)
ID      Size     Value  Description
0x000a  2            3  Device-to-host register FISes sent due to a COMRESET
0x0001  2            0  Command failed due to ICRC error
0x0003  2            0  R_ERR response for device-to-host data FIS
0x0004  2            0  R_ERR response for host-to-device data FIS
0x0006  2            0  R_ERR response for device-to-host non-data FIS
0x0007  2            0  R_ERR response for host-to-device non-data FIS

/dev/sdb is similar:
=== START OF INFORMATION SECTION ===
Device Model:     ST1000NM0033         81Y9807 81Y3867IBM
Serial Number:    Z1W2ZKKD
LU WWN Device Id: 5 000c50 079c557df
Firmware Version: BB5A
User Capacity:    1,000,204,886,016 bytes [1.00 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-2 (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Mon Mar  6 14:47:49 2017 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
AAM feature is:   Unavailable
APM feature is:   Unavailable
Rd look-ahead is: Enabled
Write cache is:   Enabled
ATA Security is:  Disabled, NOT FROZEN [SEC1]
Wt Cache Reorder: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAGS    VALUE WORST THRESH FAIL RAW_VALUE
   1 Raw_Read_Error_Rate     POSR--   083   063   044 -    224696760
   3 Spin_Up_Time            PO----   097   096   000 -    0
   4 Start_Stop_Count        -O--CK   100   100   020 -    80
   5 Reallocated_Sector_Ct   PO--CK   100   100   010 -    0
   7 Seek_Error_Rate         POSR--   082   060   030 -    192122915
   9 Power_On_Hours          -O--CK   087   087   000 -    11874
  10 Spin_Retry_Count        PO--C-   100   100   097 -    0
  12 Power_Cycle_Count       -O--CK   100   100   020 -    66
184 End-to-End_Error        -O--CK   100   100   099 -    0
187 Reported_Uncorrect      -O--CK   100   100   000 -    0
188 Command_Timeout         -O--CK   100   100   000 -    0
189 High_Fly_Writes         -O-RCK   100   100   000 -    0
190 Airflow_Temperature_Cel -O---K   056   047   045 -    44 (Min/Max 41/44)
191 G-Sense_Error_Rate      -O--CK   100   100   000 -    0
192 Power-Off_Retract_Count -O--CK   100   100   000 -    58
193 Load_Cycle_Count        -O--CK   100   100   000 -    556
194 Temperature_Celsius     -O---K   044   053   000 -    44 (0 21 0 0 0)
195 Hardware_ECC_Recovered  -O-RC-   023   013   000 -    224696760
197 Current_Pending_Sector  -O--C-   100   100   000 -    0
198 Offline_Uncorrectable   ----C-   100   100   000 -    0
199 UDMA_CRC_Error_Count    -OSRCK   200   200   000 -    0
                             ||||||_ K auto-keep
                             |||||__ C event count
                             ||||___ R error rate
                             |||____ S speed/performance
                             ||_____ O updated online
                             |______ P prefailure warning


while /dev/sdc looks OK

=== START OF INFORMATION SECTION ===
Device Model:     WD1003FBYX-23        81Y9807 81Y3867IBM
Serial Number:    WD-WCAW37DULJLP
LU WWN Device Id: 5 0014ee 261450c09
Firmware Version: WB35
User Capacity:    1,000,204,886,016 bytes [1.00 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    7200 rpm
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ATA8-ACS (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Mon Mar  6 14:48:21 2017 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
AAM feature is:   Unavailable
APM level is:     254 (maximum performance)
Rd look-ahead is: Enabled
Write cache is:   Enabled
ATA Security is:  Disabled, NOT FROZEN [SEC1]
Wt Cache Reorder: Enabled

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAGS    VALUE WORST THRESH FAIL RAW_VALUE
   1 Raw_Read_Error_Rate     POSR-K   200   200   051 -    3
   3 Spin_Up_Time            POS--K   186   173   021 -    3691
   4 Start_Stop_Count        -O--CK   100   100   000 -    90
   5 Reallocated_Sector_Ct   PO--CK   200   200   140 -    0
   7 Seek_Error_Rate         -OSR-K   100   253   000 -    0
   9 Power_On_Hours          -O--CK   084   084   000 -    11759
  10 Spin_Retry_Count        -O--CK   100   253   000 -    0
  11 Calibration_Retry_Count -O--CK   100   253   000 -    0
  12 Power_Cycle_Count       -O--CK   100   100   000 -    76
192 Power-Off_Retract_Count -O--CK   200   200   000 -    69
193 Load_Cycle_Count        -O--CK   200   200   000 -    20
194 Temperature_Celsius     -O---K   102   092   000 -    45
196 Reallocated_Event_Count -O--CK   200   200   000 -    0
197 Current_Pending_Sector  -O--CK   200   200   000 -    0
198 Offline_Uncorrectable   ----CK   200   200   000 -    0
199 UDMA_CRC_Error_Count    -O--CK   200   200   000 -    0
200 Multi_Zone_Error_Rate   ---R--   200   200   000 -    0
                             ||||||_ K auto-keep
                             |||||__ C event count
                             ||||___ R error rate
                             |||____ S speed/performance
                             ||_____ O updated online
                             |______ P prefailure warning


Can anyone provide some hints or suggestions on how I should proceed?

Regards,
Adam



^ permalink raw reply

* Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt
From: Gilad Ben-Yossef @ 2017-03-06 14:38 UTC (permalink / raw)
  To: Milan Broz
  Cc: Binoy Jayan, Rajendra, Herbert Xu, Oded, Mike Snitzer,
	Linux kernel mailing list, Ondrej Mosnacek, linux-raid, dm-devel,
	Mark Brown, Arnd Bergmann, linux-crypto, Shaohua Li,
	David S. Miller, Alasdair Kergon, Ofir
In-Reply-To: <c835926e-c2bd-8a52-34db-6c605301bc2b@gmail.com>

On Wed, Mar 1, 2017 at 5:38 PM, Milan Broz <gmazyland@gmail.com> wrote:
>
> On 03/01/2017 02:04 PM, Milan Broz wrote:
>> On 03/01/2017 01:42 PM, Gilad Ben-Yossef wrote:
>> ...
>>
>>> I can certainly understand if you don't wont to take the patch until
>>> we have results with
>>> dm-crypt itself but the difference between 8 separate invocation of
>>> the engine for 512
>>> bytes of XTS and a single invocation for 4KB are pretty big.
>>
>> Yes, I know it. But the same can be achieved if we just implement
>> 4k sector encryption in dmcrypt. It is incompatible with LUKS1
>> (but next LUKS version will support it) but I think this is not
>> a problem for now.
>>
>> If the underlying device supports atomic write of 4k sectors, then
>> there should not be a problem.
>>
>> This is one of the speed-up I would like to compare with the IV approach,
>> because everyone should benefit from 4k sectors in the end.
>> And no crypto API changes are needed here.
>>
>> (I have an old patch for this, so I will try to revive it.)
>
> If anyone interested, simple experimental patch for larger sector size
> (up to the page size) for dmcrypt is in this branch:
>
> http://git.kernel.org/cgit/linux/kernel/git/mbroz/linux.git/log/?h=dm-crypt-4k-sector
>
> It would be nice to check what performance gain could be provided
> by this simple approach.


I gave it a spin on a x86_64 with 8 CPUs with AES-NI using cryptd and
on Arm  using CryptoCell hardware accelerator.

There was no difference in performance between 512 and 4096 bytes
cluster size on the x86_64 (800 MB loop file system)

There was an improvement in latency of 3.2% between 512 and 4096 bytes
cluster size on the Arm. I expect the performance benefits for this
test for Binoy's patch to be the same.

In both cases the very naive test was a simple dd with block size of
4096 bytes or the raw block device.

I do not know what effect having a bigger cluster size would have on
have on other more complex file system operations.
Is there any specific benchmark worth testing with?


Gilad


-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

^ permalink raw reply

* [PATCH 29/29] drivers, xen: convert grant_map.users from atomic_t to refcount_t
From: Elena Reshetova @ 2017-03-06 14:21 UTC (permalink / raw)
  To: gregkh
  Cc: peterz, linux-pci, target-devel, linux1394-devel, Elena Reshetova,
	devel, linux-s390, linux-scsi, linux-serial, fcoe-devel,
	xen-devel, open-iscsi, linux-media, Kees Cook, linux-raid,
	linux-bcache, Hans Liljestrand, David Windsor, netdev, linux-usb,
	linux-kernel, devel
In-Reply-To: <1488810076-3754-1-git-send-email-elena.reshetova@intel.com>

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/xen/gntdev.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 2ef2b61..b183cb2 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -35,6 +35,7 @@
 #include <linux/spinlock.h>
 #include <linux/slab.h>
 #include <linux/highmem.h>
+#include <linux/refcount.h>
 
 #include <xen/xen.h>
 #include <xen/grant_table.h>
@@ -85,7 +86,7 @@ struct grant_map {
 	int index;
 	int count;
 	int flags;
-	atomic_t users;
+	refcount_t users;
 	struct unmap_notify notify;
 	struct ioctl_gntdev_grant_ref *grants;
 	struct gnttab_map_grant_ref   *map_ops;
@@ -165,7 +166,7 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count)
 
 	add->index = 0;
 	add->count = count;
-	atomic_set(&add->users, 1);
+	refcount_set(&add->users, 1);
 
 	return add;
 
@@ -211,7 +212,7 @@ static void gntdev_put_map(struct gntdev_priv *priv, struct grant_map *map)
 	if (!map)
 		return;
 
-	if (!atomic_dec_and_test(&map->users))
+	if (!refcount_dec_and_test(&map->users))
 		return;
 
 	atomic_sub(map->count, &pages_mapped);
@@ -399,7 +400,7 @@ static void gntdev_vma_open(struct vm_area_struct *vma)
 	struct grant_map *map = vma->vm_private_data;
 
 	pr_debug("gntdev_vma_open %p\n", vma);
-	atomic_inc(&map->users);
+	refcount_inc(&map->users);
 }
 
 static void gntdev_vma_close(struct vm_area_struct *vma)
@@ -1003,7 +1004,7 @@ static int gntdev_mmap(struct file *flip, struct vm_area_struct *vma)
 		goto unlock_out;
 	}
 
-	atomic_inc(&map->users);
+	refcount_inc(&map->users);
 
 	vma->vm_ops = &gntdev_vmops;
 
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply related

* [PATCH 28/29] drivers: convert sbd_duart.map_guard from atomic_t to refcount_t
From: Elena Reshetova @ 2017-03-06 14:21 UTC (permalink / raw)
  To: gregkh
  Cc: peterz, linux-pci, target-devel, linux1394-devel, Elena Reshetova,
	devel, linux-s390, linux-scsi, linux-serial, fcoe-devel,
	xen-devel, open-iscsi, linux-media, Kees Cook, linux-raid,
	linux-bcache, Hans Liljestrand, David Windsor, netdev, linux-usb,
	linux-kernel, devel
In-Reply-To: <1488810076-3754-1-git-send-email-elena.reshetova@intel.com>

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/tty/serial/sb1250-duart.c | 18 +++++++-----------
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/tty/serial/sb1250-duart.c b/drivers/tty/serial/sb1250-duart.c
index 771f361..041625c 100644
--- a/drivers/tty/serial/sb1250-duart.c
+++ b/drivers/tty/serial/sb1250-duart.c
@@ -41,7 +41,7 @@
 #include <linux/tty_flip.h>
 #include <linux/types.h>
 
-#include <linux/atomic.h>
+#include <linux/refcount.h>
 #include <asm/io.h>
 #include <asm/war.h>
 
@@ -103,7 +103,7 @@ struct sbd_port {
 struct sbd_duart {
 	struct sbd_port		sport[2];
 	unsigned long		mapctrl;
-	atomic_t		map_guard;
+	refcount_t		map_guard;
 };
 
 #define to_sport(uport) container_of(uport, struct sbd_port, port)
@@ -654,15 +654,13 @@ static void sbd_release_port(struct uart_port *uport)
 {
 	struct sbd_port *sport = to_sport(uport);
 	struct sbd_duart *duart = sport->duart;
-	int map_guard;
 
 	iounmap(sport->memctrl);
 	sport->memctrl = NULL;
 	iounmap(uport->membase);
 	uport->membase = NULL;
 
-	map_guard = atomic_add_return(-1, &duart->map_guard);
-	if (!map_guard)
+	if(refcount_dec_and_test(&duart->map_guard))
 		release_mem_region(duart->mapctrl, DUART_CHANREG_SPACING);
 	release_mem_region(uport->mapbase, DUART_CHANREG_SPACING);
 }
@@ -698,7 +696,6 @@ static int sbd_request_port(struct uart_port *uport)
 {
 	const char *err = KERN_ERR "sbd: Unable to reserve MMIO resource\n";
 	struct sbd_duart *duart = to_sport(uport)->duart;
-	int map_guard;
 	int ret = 0;
 
 	if (!request_mem_region(uport->mapbase, DUART_CHANREG_SPACING,
@@ -706,11 +703,11 @@ static int sbd_request_port(struct uart_port *uport)
 		printk(err);
 		return -EBUSY;
 	}
-	map_guard = atomic_add_return(1, &duart->map_guard);
-	if (map_guard == 1) {
+	refcount_inc(&duart->map_guard);
+	if (refcount_read(&duart->map_guard) == 1) {
 		if (!request_mem_region(duart->mapctrl, DUART_CHANREG_SPACING,
 					"sb1250-duart")) {
-			atomic_add(-1, &duart->map_guard);
+			refcount_dec(&duart->map_guard);
 			printk(err);
 			ret = -EBUSY;
 		}
@@ -718,8 +715,7 @@ static int sbd_request_port(struct uart_port *uport)
 	if (!ret) {
 		ret = sbd_map_port(uport);
 		if (ret) {
-			map_guard = atomic_add_return(-1, &duart->map_guard);
-			if (!map_guard)
+			if (refcount_dec_and_test(&duart->map_guard))
 				release_mem_region(duart->mapctrl,
 						   DUART_CHANREG_SPACING);
 		}
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply related

* [PATCH 27/29] drivers, usb: convert ep_data.count from atomic_t to refcount_t
From: Elena Reshetova @ 2017-03-06 14:21 UTC (permalink / raw)
  To: gregkh
  Cc: peterz, linux-pci, target-devel, linux1394-devel, Elena Reshetova,
	devel, linux-s390, linux-scsi, linux-serial, fcoe-devel,
	xen-devel, open-iscsi, linux-media, Kees Cook, linux-raid,
	linux-bcache, Hans Liljestrand, David Windsor, netdev, linux-usb,
	linux-kernel, devel
In-Reply-To: <1488810076-3754-1-git-send-email-elena.reshetova@intel.com>

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 | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/legacy/inode.c b/drivers/usb/gadget/legacy/inode.c
index 81d76f3..d21a5f8 100644
--- a/drivers/usb/gadget/legacy/inode.c
+++ b/drivers/usb/gadget/legacy/inode.c
@@ -191,7 +191,7 @@ enum ep_state {
 struct ep_data {
 	struct mutex			lock;
 	enum ep_state			state;
-	atomic_t			count;
+	refcount_t			count;
 	struct dev_data			*dev;
 	/* must hold dev->lock before accessing ep or req */
 	struct usb_ep			*ep;
@@ -206,12 +206,12 @@ struct ep_data {
 
 static inline void get_ep (struct ep_data *data)
 {
-	atomic_inc (&data->count);
+	refcount_inc (&data->count);
 }
 
 static void put_ep (struct ep_data *data)
 {
-	if (likely (!atomic_dec_and_test (&data->count)))
+	if (likely (!refcount_dec_and_test (&data->count)))
 		return;
 	put_dev (data->dev);
 	/* needs no more cleanup */
@@ -1562,7 +1562,7 @@ static int activate_ep_files (struct dev_data *dev)
 		init_waitqueue_head (&data->wait);
 
 		strncpy (data->name, ep->name, sizeof (data->name) - 1);
-		atomic_set (&data->count, 1);
+		refcount_set (&data->count, 1);
 		data->dev = dev;
 		get_dev (dev);
 
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply related

* [PATCH 26/29] drivers, usb: convert dev_data.count from atomic_t to refcount_t
From: Elena Reshetova @ 2017-03-06 14:21 UTC (permalink / raw)
  To: gregkh
  Cc: peterz, linux-pci, target-devel, linux1394-devel, Elena Reshetova,
	devel, linux-s390, linux-scsi, linux-serial, fcoe-devel,
	xen-devel, open-iscsi, linux-media, Kees Cook, linux-raid,
	linux-bcache, Hans Liljestrand, David Windsor, netdev, linux-usb,
	linux-kernel, devel
In-Reply-To: <1488810076-3754-1-git-send-email-elena.reshetova@intel.com>

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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply related

* [PATCH 25/29] drivers, usb: convert ffs_data.ref from atomic_t to refcount_t
From: Elena Reshetova @ 2017-03-06 14:21 UTC (permalink / raw)
  To: gregkh
  Cc: peterz, linux-pci, target-devel, linux1394-devel, Elena Reshetova,
	devel, linux-s390, linux-scsi, linux-serial, fcoe-devel,
	xen-devel, open-iscsi, linux-media, Kees Cook, linux-raid,
	linux-bcache, Hans Liljestrand, David Windsor, netdev, linux-usb,
	linux-kernel, devel
In-Reply-To: <1488810076-3754-1-git-send-email-elena.reshetova@intel.com>

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/function/f_fs.c | 8 ++++----
 drivers/usb/gadget/function/u_fs.h | 3 ++-
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
index 87fccf6..3cdeb91 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1570,14 +1570,14 @@ static void ffs_data_get(struct ffs_data *ffs)
 {
 	ENTER();
 
-	atomic_inc(&ffs->ref);
+	refcount_inc(&ffs->ref);
 }
 
 static void ffs_data_opened(struct ffs_data *ffs)
 {
 	ENTER();
 
-	atomic_inc(&ffs->ref);
+	refcount_inc(&ffs->ref);
 	if (atomic_add_return(1, &ffs->opened) == 1 &&
 			ffs->state == FFS_DEACTIVATED) {
 		ffs->state = FFS_CLOSING;
@@ -1589,7 +1589,7 @@ static void ffs_data_put(struct ffs_data *ffs)
 {
 	ENTER();
 
-	if (unlikely(atomic_dec_and_test(&ffs->ref))) {
+	if (unlikely(refcount_dec_and_test(&ffs->ref))) {
 		pr_info("%s(): freeing\n", __func__);
 		ffs_data_clear(ffs);
 		BUG_ON(waitqueue_active(&ffs->ev.waitq) ||
@@ -1634,7 +1634,7 @@ static struct ffs_data *ffs_data_new(void)
 
 	ENTER();
 
-	atomic_set(&ffs->ref, 1);
+	refcount_set(&ffs->ref, 1);
 	atomic_set(&ffs->opened, 0);
 	ffs->state = FFS_READ_DESCRIPTORS;
 	mutex_init(&ffs->mutex);
diff --git a/drivers/usb/gadget/function/u_fs.h b/drivers/usb/gadget/function/u_fs.h
index 4b69694..abfca48 100644
--- a/drivers/usb/gadget/function/u_fs.h
+++ b/drivers/usb/gadget/function/u_fs.h
@@ -20,6 +20,7 @@
 #include <linux/list.h>
 #include <linux/mutex.h>
 #include <linux/workqueue.h>
+#include <linux/refcount.h>
 
 #ifdef VERBOSE_DEBUG
 #ifndef pr_vdebug
@@ -177,7 +178,7 @@ struct ffs_data {
 	struct completion		ep0req_completion;	/* P: mutex */
 
 	/* reference counter */
-	atomic_t			ref;
+	refcount_t			ref;
 	/* how many files are opened (EP0 and others) */
 	atomic_t			opened;
 
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply related

* [PATCH 24/29] drivers: convert iblock_req.pending from atomic_t to refcount_t
From: Elena Reshetova @ 2017-03-06 14:21 UTC (permalink / raw)
  To: gregkh
  Cc: peterz, linux-pci, target-devel, linux1394-devel, Elena Reshetova,
	devel, linux-s390, linux-scsi, linux-serial, fcoe-devel,
	xen-devel, open-iscsi, linux-media, Kees Cook, linux-raid,
	linux-bcache, Hans Liljestrand, David Windsor, netdev, linux-usb,
	linux-kernel, devel
In-Reply-To: <1488810076-3754-1-git-send-email-elena.reshetova@intel.com>

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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply related

* [PATCH 23/29] drivers: convert vme_user_vma_priv.refcnt from atomic_t to refcount_t
From: Elena Reshetova @ 2017-03-06 14:21 UTC (permalink / raw)
  To: gregkh
  Cc: peterz, linux-pci, target-devel, linux1394-devel, Elena Reshetova,
	devel, linux-s390, linux-scsi, linux-serial, fcoe-devel,
	xen-devel, open-iscsi, linux-media, Kees Cook, linux-raid,
	linux-bcache, Hans Liljestrand, David Windsor, netdev, linux-usb,
	linux-kernel, devel
In-Reply-To: <1488810076-3754-1-git-send-email-elena.reshetova@intel.com>

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/staging/vme/devices/vme_user.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/vme/devices/vme_user.c b/drivers/staging/vme/devices/vme_user.c
index 69e9a770..a3d4610 100644
--- a/drivers/staging/vme/devices/vme_user.c
+++ b/drivers/staging/vme/devices/vme_user.c
@@ -17,7 +17,7 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
-#include <linux/atomic.h>
+#include <linux/refcount.h>
 #include <linux/cdev.h>
 #include <linux/delay.h>
 #include <linux/device.h>
@@ -118,7 +118,7 @@ static const int type[VME_DEVS] = {	MASTER_MINOR,	MASTER_MINOR,
 
 struct vme_user_vma_priv {
 	unsigned int minor;
-	atomic_t refcnt;
+	refcount_t refcnt;
 };
 
 static ssize_t resource_to_user(int minor, char __user *buf, size_t count,
@@ -430,7 +430,7 @@ static void vme_user_vm_open(struct vm_area_struct *vma)
 {
 	struct vme_user_vma_priv *vma_priv = vma->vm_private_data;
 
-	atomic_inc(&vma_priv->refcnt);
+	refcount_inc(&vma_priv->refcnt);
 }
 
 static void vme_user_vm_close(struct vm_area_struct *vma)
@@ -438,7 +438,7 @@ static void vme_user_vm_close(struct vm_area_struct *vma)
 	struct vme_user_vma_priv *vma_priv = vma->vm_private_data;
 	unsigned int minor = vma_priv->minor;
 
-	if (!atomic_dec_and_test(&vma_priv->refcnt))
+	if (!refcount_dec_and_test(&vma_priv->refcnt))
 		return;
 
 	mutex_lock(&image[minor].mutex);
@@ -473,7 +473,7 @@ static int vme_user_master_mmap(unsigned int minor, struct vm_area_struct *vma)
 	}
 
 	vma_priv->minor = minor;
-	atomic_set(&vma_priv->refcnt, 1);
+	refcount_set(&vma_priv->refcnt, 1);
 	vma->vm_ops = &vme_user_vm_ops;
 	vma->vm_private_data = vma_priv;
 
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply related

* [PATCH 22/29] drivers, scsi: convert iscsi_task.refcount from atomic_t to refcount_t
From: Elena Reshetova @ 2017-03-06 14:21 UTC (permalink / raw)
  To: gregkh
  Cc: peterz, linux-pci, target-devel, linux1394-devel, Elena Reshetova,
	devel, linux-s390, linux-scsi, linux-serial, fcoe-devel,
	xen-devel, open-iscsi, linux-media, Kees Cook, linux-raid,
	linux-bcache, Hans Liljestrand, David Windsor, netdev, linux-usb,
	linux-kernel, devel
In-Reply-To: <1488810076-3754-1-git-send-email-elena.reshetova@intel.com>

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/scsi/libiscsi.c        | 8 ++++----
 drivers/scsi/qedi/qedi_iscsi.c | 2 +-
 include/scsi/libiscsi.h        | 3 ++-
 3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 834d121..7eb1d2c 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -516,13 +516,13 @@ static void iscsi_free_task(struct iscsi_task *task)
 
 void __iscsi_get_task(struct iscsi_task *task)
 {
-	atomic_inc(&task->refcount);
+	refcount_inc(&task->refcount);
 }
 EXPORT_SYMBOL_GPL(__iscsi_get_task);
 
 void __iscsi_put_task(struct iscsi_task *task)
 {
-	if (atomic_dec_and_test(&task->refcount))
+	if (refcount_dec_and_test(&task->refcount))
 		iscsi_free_task(task);
 }
 EXPORT_SYMBOL_GPL(__iscsi_put_task);
@@ -744,7 +744,7 @@ __iscsi_conn_send_pdu(struct iscsi_conn *conn, struct iscsi_hdr *hdr,
 	 * released by the lld when it has transmitted the task for
 	 * pdus we do not expect a response for.
 	 */
-	atomic_set(&task->refcount, 1);
+	refcount_set(&task->refcount, 1);
 	task->conn = conn;
 	task->sc = NULL;
 	INIT_LIST_HEAD(&task->running);
@@ -1616,7 +1616,7 @@ static inline struct iscsi_task *iscsi_alloc_task(struct iscsi_conn *conn,
 	sc->SCp.phase = conn->session->age;
 	sc->SCp.ptr = (char *) task;
 
-	atomic_set(&task->refcount, 1);
+	refcount_set(&task->refcount, 1);
 	task->state = ISCSI_TASK_PENDING;
 	task->conn = conn;
 	task->sc = sc;
diff --git a/drivers/scsi/qedi/qedi_iscsi.c b/drivers/scsi/qedi/qedi_iscsi.c
index b9f79d3..3895bd5 100644
--- a/drivers/scsi/qedi/qedi_iscsi.c
+++ b/drivers/scsi/qedi/qedi_iscsi.c
@@ -1372,7 +1372,7 @@ static void qedi_cleanup_task(struct iscsi_task *task)
 {
 	if (!task->sc || task->state == ISCSI_TASK_PENDING) {
 		QEDI_INFO(NULL, QEDI_LOG_IO, "Returning ref_cnt=%d\n",
-			  atomic_read(&task->refcount));
+			  refcount_read(&task->refcount));
 		return;
 	}
 
diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h
index b0e275d..24d74b5 100644
--- a/include/scsi/libiscsi.h
+++ b/include/scsi/libiscsi.h
@@ -29,6 +29,7 @@
 #include <linux/timer.h>
 #include <linux/workqueue.h>
 #include <linux/kfifo.h>
+#include <linux/refcount.h>
 #include <scsi/iscsi_proto.h>
 #include <scsi/iscsi_if.h>
 #include <scsi/scsi_transport_iscsi.h>
@@ -139,7 +140,7 @@ struct iscsi_task {
 
 	/* state set/tested under session->lock */
 	int			state;
-	atomic_t		refcount;
+	refcount_t		refcount;
 	struct list_head	running;	/* running cmd list */
 	void			*dd_data;	/* driver/transport data */
 };
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply related

* [PATCH 21/29] drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t
From: Elena Reshetova @ 2017-03-06 14:21 UTC (permalink / raw)
  To: gregkh
  Cc: peterz, linux-pci, target-devel, linux1394-devel, Elena Reshetova,
	devel, linux-s390, linux-scsi, linux-serial, fcoe-devel,
	xen-devel, open-iscsi, linux-media, Kees Cook, linux-raid,
	linux-bcache, Hans Liljestrand, David Windsor, netdev, linux-usb,
	linux-kernel, devel
In-Reply-To: <1488810076-3754-1-git-send-email-elena.reshetova@intel.com>

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/scsi/libfc/fc_fcp.c | 6 +++---
 include/scsi/libfc.h        | 3 ++-
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/libfc/fc_fcp.c b/drivers/scsi/libfc/fc_fcp.c
index 0e67621..a808e8e 100644
--- a/drivers/scsi/libfc/fc_fcp.c
+++ b/drivers/scsi/libfc/fc_fcp.c
@@ -154,7 +154,7 @@ static struct fc_fcp_pkt *fc_fcp_pkt_alloc(struct fc_lport *lport, gfp_t gfp)
 		memset(fsp, 0, sizeof(*fsp));
 		fsp->lp = lport;
 		fsp->xfer_ddp = FC_XID_UNKNOWN;
-		atomic_set(&fsp->ref_cnt, 1);
+		refcount_set(&fsp->ref_cnt, 1);
 		init_timer(&fsp->timer);
 		fsp->timer.data = (unsigned long)fsp;
 		INIT_LIST_HEAD(&fsp->list);
@@ -175,7 +175,7 @@ static struct fc_fcp_pkt *fc_fcp_pkt_alloc(struct fc_lport *lport, gfp_t gfp)
  */
 static void fc_fcp_pkt_release(struct fc_fcp_pkt *fsp)
 {
-	if (atomic_dec_and_test(&fsp->ref_cnt)) {
+	if (refcount_dec_and_test(&fsp->ref_cnt)) {
 		struct fc_fcp_internal *si = fc_get_scsi_internal(fsp->lp);
 
 		mempool_free(fsp, si->scsi_pkt_pool);
@@ -188,7 +188,7 @@ static void fc_fcp_pkt_release(struct fc_fcp_pkt *fsp)
  */
 static void fc_fcp_pkt_hold(struct fc_fcp_pkt *fsp)
 {
-	atomic_inc(&fsp->ref_cnt);
+	refcount_inc(&fsp->ref_cnt);
 }
 
 /**
diff --git a/include/scsi/libfc.h b/include/scsi/libfc.h
index da5033d..2109844 100644
--- a/include/scsi/libfc.h
+++ b/include/scsi/libfc.h
@@ -23,6 +23,7 @@
 #include <linux/timer.h>
 #include <linux/if.h>
 #include <linux/percpu.h>
+#include <linux/refcount.h>
 
 #include <scsi/scsi_transport.h>
 #include <scsi/scsi_transport_fc.h>
@@ -321,7 +322,7 @@ struct fc_seq_els_data {
  */
 struct fc_fcp_pkt {
 	spinlock_t	  scsi_pkt_lock;
-	atomic_t	  ref_cnt;
+	refcount_t	  ref_cnt;
 
 	/* SCSI command and data transfer information */
 	u32		  data_len;
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply related

* [PATCH 20/29] drivers, s390: convert qeth_reply.refcnt from atomic_t to refcount_t
From: Elena Reshetova @ 2017-03-06 14:21 UTC (permalink / raw)
  To: gregkh
  Cc: peterz, linux-pci, target-devel, linux1394-devel, Elena Reshetova,
	devel, linux-s390, linux-scsi, linux-serial, fcoe-devel,
	xen-devel, open-iscsi, linux-media, Kees Cook, linux-raid,
	linux-bcache, Hans Liljestrand, David Windsor, netdev, linux-usb,
	linux-kernel, devel
In-Reply-To: <1488810076-3754-1-git-send-email-elena.reshetova@intel.com>

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/s390/net/qeth_core.h      | 3 ++-
 drivers/s390/net/qeth_core_main.c | 8 +++-----
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/s390/net/qeth_core.h b/drivers/s390/net/qeth_core.h
index e7addea..e2c81d21 100644
--- a/drivers/s390/net/qeth_core.h
+++ b/drivers/s390/net/qeth_core.h
@@ -20,6 +20,7 @@
 #include <linux/ethtool.h>
 #include <linux/hashtable.h>
 #include <linux/ip.h>
+#include <linux/refcount.h>
 
 #include <net/ipv6.h>
 #include <net/if_inet6.h>
@@ -641,7 +642,7 @@ struct qeth_reply {
 	int rc;
 	void *param;
 	struct qeth_card *card;
-	atomic_t refcnt;
+	refcount_t refcnt;
 };
 
 
diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c
index 315d8a2..a2bf13f 100644
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -555,7 +555,7 @@ static struct qeth_reply *qeth_alloc_reply(struct qeth_card *card)
 
 	reply = kzalloc(sizeof(struct qeth_reply), GFP_ATOMIC);
 	if (reply) {
-		atomic_set(&reply->refcnt, 1);
+		refcount_set(&reply->refcnt, 1);
 		atomic_set(&reply->received, 0);
 		reply->card = card;
 	}
@@ -564,14 +564,12 @@ static struct qeth_reply *qeth_alloc_reply(struct qeth_card *card)
 
 static void qeth_get_reply(struct qeth_reply *reply)
 {
-	WARN_ON(atomic_read(&reply->refcnt) <= 0);
-	atomic_inc(&reply->refcnt);
+	refcount_inc(&reply->refcnt);
 }
 
 static void qeth_put_reply(struct qeth_reply *reply)
 {
-	WARN_ON(atomic_read(&reply->refcnt) <= 0);
-	if (atomic_dec_and_test(&reply->refcnt))
+	if (refcount_dec_and_test(&reply->refcnt))
 		kfree(reply);
 }
 
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply related

* [PATCH 19/29] drivers, s390: convert lcs_reply.refcnt from atomic_t to refcount_t
From: Elena Reshetova @ 2017-03-06 14:21 UTC (permalink / raw)
  To: gregkh
  Cc: peterz, linux-pci, target-devel, linux1394-devel, Elena Reshetova,
	devel, linux-s390, linux-scsi, linux-serial, fcoe-devel,
	xen-devel, open-iscsi, linux-media, Kees Cook, linux-raid,
	linux-bcache, Hans Liljestrand, David Windsor, netdev, linux-usb,
	linux-kernel, devel
In-Reply-To: <1488810076-3754-1-git-send-email-elena.reshetova@intel.com>

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/s390/net/lcs.c | 8 +++-----
 drivers/s390/net/lcs.h | 3 ++-
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/s390/net/lcs.c b/drivers/s390/net/lcs.c
index 211b31d..18dc787 100644
--- a/drivers/s390/net/lcs.c
+++ b/drivers/s390/net/lcs.c
@@ -774,15 +774,13 @@ lcs_get_lancmd(struct lcs_card *card, int count)
 static void
 lcs_get_reply(struct lcs_reply *reply)
 {
-	WARN_ON(atomic_read(&reply->refcnt) <= 0);
-	atomic_inc(&reply->refcnt);
+	refcount_inc(&reply->refcnt);
 }
 
 static void
 lcs_put_reply(struct lcs_reply *reply)
 {
-        WARN_ON(atomic_read(&reply->refcnt) <= 0);
-        if (atomic_dec_and_test(&reply->refcnt)) {
+        if (refcount_dec_and_test(&reply->refcnt)) {
 		kfree(reply);
 	}
 
@@ -798,7 +796,7 @@ lcs_alloc_reply(struct lcs_cmd *cmd)
 	reply = kzalloc(sizeof(struct lcs_reply), GFP_ATOMIC);
 	if (!reply)
 		return NULL;
-	atomic_set(&reply->refcnt,1);
+	refcount_set(&reply->refcnt,1);
 	reply->sequence_no = cmd->sequence_no;
 	reply->received = 0;
 	reply->rc = 0;
diff --git a/drivers/s390/net/lcs.h b/drivers/s390/net/lcs.h
index 150fcb4..3802f4f 100644
--- a/drivers/s390/net/lcs.h
+++ b/drivers/s390/net/lcs.h
@@ -4,6 +4,7 @@
 #include <linux/netdevice.h>
 #include <linux/skbuff.h>
 #include <linux/workqueue.h>
+#include <linux/refcount.h>
 #include <asm/ccwdev.h>
 
 #define LCS_DBF_TEXT(level, name, text) \
@@ -270,7 +271,7 @@ struct lcs_buffer {
 struct lcs_reply {
 	struct list_head list;
 	__u16 sequence_no;
-	atomic_t refcnt;
+	refcount_t refcnt;
 	/* Callback for completion notification. */
 	void (*callback)(struct lcs_card *, struct lcs_cmd *);
 	wait_queue_head_t wait_q;
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply related

* [PATCH 18/29] drivers, s390: convert urdev.ref_count from atomic_t to refcount_t
From: Elena Reshetova @ 2017-03-06 14:21 UTC (permalink / raw)
  To: gregkh
  Cc: peterz, linux-pci, target-devel, linux1394-devel, Elena Reshetova,
	devel, linux-s390, linux-scsi, linux-serial, fcoe-devel,
	xen-devel, open-iscsi, linux-media, Kees Cook, linux-raid,
	linux-bcache, Hans Liljestrand, David Windsor, netdev, linux-usb,
	linux-kernel, devel
In-Reply-To: <1488810076-3754-1-git-send-email-elena.reshetova@intel.com>

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/s390/char/vmur.c | 8 ++++----
 drivers/s390/char/vmur.h | 4 +++-
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/s390/char/vmur.c b/drivers/s390/char/vmur.c
index 04aceb6..ced8151 100644
--- a/drivers/s390/char/vmur.c
+++ b/drivers/s390/char/vmur.c
@@ -110,7 +110,7 @@ static struct urdev *urdev_alloc(struct ccw_device *cdev)
 	mutex_init(&urd->io_mutex);
 	init_waitqueue_head(&urd->wait);
 	spin_lock_init(&urd->open_lock);
-	atomic_set(&urd->ref_count,  1);
+	refcount_set(&urd->ref_count,  1);
 	urd->cdev = cdev;
 	get_device(&cdev->dev);
 	return urd;
@@ -126,7 +126,7 @@ static void urdev_free(struct urdev *urd)
 
 static void urdev_get(struct urdev *urd)
 {
-	atomic_inc(&urd->ref_count);
+	refcount_inc(&urd->ref_count);
 }
 
 static struct urdev *urdev_get_from_cdev(struct ccw_device *cdev)
@@ -159,7 +159,7 @@ static struct urdev *urdev_get_from_devno(u16 devno)
 
 static void urdev_put(struct urdev *urd)
 {
-	if (atomic_dec_and_test(&urd->ref_count))
+	if (refcount_dec_and_test(&urd->ref_count))
 		urdev_free(urd);
 }
 
@@ -946,7 +946,7 @@ static int ur_set_offline_force(struct ccw_device *cdev, int force)
 		rc = -EBUSY;
 		goto fail_urdev_put;
 	}
-	if (!force && (atomic_read(&urd->ref_count) > 2)) {
+	if (!force && (refcount_read(&urd->ref_count) > 2)) {
 		/* There is still a user of urd (e.g. ur_open) */
 		TRACE("ur_set_offline: BUSY\n");
 		rc = -EBUSY;
diff --git a/drivers/s390/char/vmur.h b/drivers/s390/char/vmur.h
index fa320ad..35ea9d1 100644
--- a/drivers/s390/char/vmur.h
+++ b/drivers/s390/char/vmur.h
@@ -11,6 +11,8 @@
 #ifndef _VMUR_H_
 #define _VMUR_H_
 
+#include <linux/refcount.h>
+
 #define DEV_CLASS_UR_I 0x20 /* diag210 unit record input device class */
 #define DEV_CLASS_UR_O 0x10 /* diag210 unit record output device class */
 /*
@@ -69,7 +71,7 @@ struct urdev {
 	size_t reclen;			/* Record length for *write* CCWs */
 	int class;			/* VM device class */
 	int io_request_rc;		/* return code from I/O request */
-	atomic_t ref_count;		/* reference counter */
+	refcount_t ref_count;		/* reference counter */
 	wait_queue_head_t wait;		/* wait queue to serialize open */
 	int open_flag;			/* "urdev is open" flag */
 	spinlock_t open_lock;		/* serialize critical sections */
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox