* Re: raid1 recoverable after system crash?
From: Roman Mamedov @ 2016-04-07 13:00 UTC (permalink / raw)
To: Brian J. Murrell; +Cc: linux-raid
In-Reply-To: <1460033086.27740.145.camel@interlinx.bc.ca>
[-- Attachment #1: Type: text/plain, Size: 1000 bytes --]
On Thu, 07 Apr 2016 08:44:46 -0400
"Brian J. Murrell" <brian@interlinx.bc.ca> wrote:
> # cat /proc/mdstat
> Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
> md0 : active raid1 sdd[0]
> 1953514496 blocks [2/1] [U_]
>
> md1 : active raid0 sdc[1] sdb[0]
> 1953524736 blocks super 1.2 512k chunks
...
> Is my only option here to fail/remove /dev/md1 from the array and re-
> add it that way or is there a more graceful recovery possible here?
You do not have a write intent bitmap at md0, so re-add will not work. Seems
like you should --add it now, then after it rebuilds use --grow to add a
bitmap, so that in the future you could use -re-add.
As to why the situation occured in the first place, you should ensure that md1
assembles before md0. Perhaps by listing both arrays in /etc/mdadm/mdadm.conf
in the order you need (and don't forget to re-generate initrd.img).
--
With respect,
Roman
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: raid1 recoverable after system crash?
From: Brian J. Murrell @ 2016-04-07 16:11 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <20160407180004.53615913@natsu>
[-- Attachment #1: Type: text/plain, Size: 2162 bytes --]
On Thu, 2016-04-07 at 18:00 +0500, Roman Mamedov wrote:
>
> You do not have a write intent bitmap at md0, so re-add will not
> work.
Ahhh. OK.
> Seems
> like you should --add it now,
Tried that. It started off and got this far:
# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 md1[2](F) sdd[0]
1953514496 blocks [2/1] [U_]
[================>....] recovery = 82.0% (1602507648/1953514496) finish=42613.2min speed=137K/sec
before hitting this:
2016 Apr 7 12:01:00 linux [16583.606363] md/raid1:md0: Disk failure on md1, disabling device.
2016 Apr 7 12:01:00 linux [16583.606366] md/raid1:md0: Operation continuing on 1 devices.
2016 Apr 7 12:01:00 linux FailSpare event detected on md device /dev/md0, component device /dev/md1
2016 Apr 7 12:01:01 linux [16583.907982] BUG: unable to handle kernel paging request at 0000000099b899b8
2016 Apr 7 12:01:01 linux [16583.908009] IP: [<ffffffffa0019227>] call_bio_endio+0x37/0xb0 [raid1]
2016 Apr 7 12:01:01 linux [16583.908009] Oops: 0000 [#1] SMP
2016 Apr 7 12:01:01 linux [16583.908009] Stack:
2016 Apr 7 12:01:01 linux [16583.908009] Call Trace:
2016 Apr 7 12:01:01 linux [16583.908009] Code: 4c 89 65 e0 4c 89 6d e8 4c 89 75 f0 4c 89 7d f8 66 66 66 66 90 4c 8b 67 28 48 8b 47 20 41 bf 01 00 00 00 48 89 fb 41 8b 54 24 2c <4c> 8b 28 85 d2 75 42 48 8b 43 18 a8 01 75 07 3e 41 80 64 24 18
2016 Apr 7 12:01:01 linux [16583.908009] RIP [<ffffffffa0019227>] call_bio_endio+0x37/0xb0 [raid1]
2016 Apr 7 12:01:01 linux [16583.908009] CR2: 0000000099b899b8
And it seems to be stuck there now.
dmesg contents at http://www.interlinx.bc.ca/~brian/raid-dmesg.txt
> then after it rebuilds use --grow to add a
> bitmap, so that in the future you could use -re-add.
Cool. Will do, when this finally gets fixed.
> As to why the situation occured in the first place, you should ensure
> that md1
> assembles before md0.
Yeah. Just noticed as of this incident that the order in mdadm.conf is
wrong. :-(
Cheers,
b.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: raid1 recoverable after system crash?
From: Roman Mamedov @ 2016-04-07 16:59 UTC (permalink / raw)
To: Brian J. Murrell; +Cc: linux-raid
In-Reply-To: <1460045497.27740.157.camel@interlinx.bc.ca>
[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]
On Thu, 07 Apr 2016 12:11:37 -0400
"Brian J. Murrell" <brian@interlinx.bc.ca> wrote:
> 2016 Apr 7 12:01:00 linux [16583.606363] md/raid1:md0: Disk failure on md1, disabling device.
> 2016 Apr 7 12:01:00 linux [16583.606366] md/raid1:md0: Operation continuing on 1 devices.
> 2016 Apr 7 12:01:00 linux FailSpare event detected on md device /dev/md0, component device /dev/md1
> 2016 Apr 7 12:01:01 linux [16583.907982] BUG: unable to handle kernel paging request at 0000000099b899b8
> 2016 Apr 7 12:01:01 linux [16583.908009] IP: [<ffffffffa0019227>] call_bio_endio+0x37/0xb0 [raid1]
> 2016 Apr 7 12:01:01 linux [16583.908009] Oops: 0000 [#1] SMP
> 2016 Apr 7 12:01:01 linux [16583.908009] Stack:
> 2016 Apr 7 12:01:01 linux [16583.908009] Call Trace:
> 2016 Apr 7 12:01:01 linux [16583.908009] Code: 4c 89 65 e0 4c 89 6d e8 4c 89 75 f0 4c 89 7d f8 66 66 66 66 90 4c 8b 67 28 48 8b 47 20 41 bf 01 00 00 00 48 89 fb 41 8b 54 24 2c <4c> 8b 28 85 d2 75 42 48 8b 43 18 a8 01 75 07 3e 41 80 64 24 18
> 2016 Apr 7 12:01:01 linux [16583.908009] RIP [<ffffffffa0019227>] call_bio_endio+0x37/0xb0 [raid1]
> 2016 Apr 7 12:01:01 linux [16583.908009] CR2: 0000000099b899b8
>
> And it seems to be stuck there now.
>
> dmesg contents at http://www.interlinx.bc.ca/~brian/raid-dmesg.txt
Don't know what's up with this bug, maybe someone else does.
How are the drives connected, plain SATA, not something unusual such as USB?
As something to try, upgrade to a newer kernel if you can: the 3.2 series is
very old, maybe the bug has been fixed in newer ones.
--
With respect,
Roman
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: raid1 recoverable after system crash?
From: Brian J. Murrell @ 2016-04-07 17:10 UTC (permalink / raw)
Cc: linux-raid
In-Reply-To: <20160407215927.2fc82680@natsu>
[-- Attachment #1: Type: text/plain, Size: 316 bytes --]
On Thu, 2016-04-07 at 21:59 +0500, Roman Mamedov wrote:
>
> How are the drives connected, plain SATA, not something unusual such
> as USB?
Yes, plain old SATA. This is all hardware and configuration that has
not changed and has been working for many many months until today's
"incident".
Cheers,
b.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Is mdadm.conf necessary? Is this the cause of my problems?
From: Anthonys Lists @ 2016-04-07 21:55 UTC (permalink / raw)
To: Linux-RAID
I've never managed to fix the problem I have where my running system has
root mounted on a "non-existent" partition. In other words, when I do a
"mount" it tells me /dev/md127 is mounted at "/". Except /dev/md127
doesn't actually exist ...
If I do an "ls -al" of /dev/md I get
drwx------ 2 root root 100 Apr 7 18:48 .
drwxr-xr-x 18 root root 4500 Apr 7 17:49 ..
lrwxrwxrwx 1 root root 10 Apr 7 18:48 126_0 -> /dev/md127
lrwxrwxrwx 1 root root 8 Apr 7 18:48 126_1 -> ../md126
lrwxrwxrwx 1 root root 10 Apr 7 18:48 slackware:2 -> /dev/md127
So dev knows about 126_0, and slackware:2, which are presumably pointing
at the initramfs /dev/md127 (which is why everything runs), but somehow
it hasn't translated to the current /dev.
Okay, so let's look at mdadm.conf (last modified in 2014, which is I
guess when I set the system up, and I've mucked about with it since, so
we could have an old mdadm.conf which doesn't actually reflect the
reality of the disks ...)
# mdadm configuration file
#
# mdadm will function properly without the use of a configuration file,
# but this file is useful for keeping track of arrays and member disks.
# In general, a mdadm.conf file is created, and updated, after arrays
# are created. This is the opposite behavior of /etc/raidtab which is
# created prior to array construction.
#
#
# the config file takes two types of lines:
#
# DEVICE lines specify a list of devices of where to look for
# potential member disks
#
# ARRAY lines specify information about how to identify arrays so
# so that they can be activated
#
# You can have more than one device line and use wild cards. The first
# example includes SCSI the first partition of SCSI disks /dev/sdb,
# /dev/sdc, /dev/sdd, /dev/sdj, /dev/sdk, and /dev/sdl. The second
# line looks for array slices on IDE disks.
#
#DEVICE /dev/sd[bcdjkl]1
#DEVICE /dev/hda1 /dev/hdb1
#
# If you mount devfs on /dev, then a suitable way to list all devices is:
#DEVICE /dev/discs/*/*
#
#
# The AUTO line can control which arrays get assembled by auto-assembly,
# meaing either "mdadm -As" when there are no 'ARRAY' lines in this file,
# or "mdadm --incremental" when the array found is not listed in this file.
# By default, all arrays that are found are assembled.
# If you want to ignore all DDF arrays (maybe they are managed by dmraid),
# and only assemble 1.x arrays if which are marked for 'this' homehost,
# but assemble all others, then use
#AUTO -ddf homehost -1.x +all
#
# ARRAY lines specify an array to assemble and a method of identification.
# Arrays can currently be identified by using a UUID, superblock minor
number,
# or a listing of devices.
#
# super-minor is usually the minor number of the metadevice
# UUID is the Universally Unique Identifier for the array
# Each can be obtained using
#
# mdadm -D <md>
#
#ARRAY /dev/md0 UUID=3aaa0122:29827cfa:5331ad66:ca767371
#ARRAY /dev/md1 super-minor=1
#ARRAY /dev/md2 devices=/dev/hda1,/dev/hdb1
#
# ARRAY lines can also specify a "spare-group" for each array. mdadm
--monitor
# will then move a spare between arrays in a spare-group if one array
has a failed
# drive but no spare
#ARRAY /dev/md4 uuid=b23f3c6d:aec43a9f:fd65db85:369432df spare-group=group1
#ARRAY /dev/md5 uuid=19464854:03f71b1b:e0df2edd:246cc977 spare-group=group1
#
# When used in --follow (aka --monitor) mode, mdadm needs a
# mail address and/or a program. This can be given with "mailaddr"
# and "program" lines to that monitoring can be started using
# mdadm --follow --scan & echo $! > /run/mdadm/mon.pid
# If the lines are not found, mdadm will exit quietly
#MAILADDR root@mydomain.tld
#PROGRAM /usr/sbin/handle-mdadm-events
ARRAY /dev/md/126_0 metadata=1.2 name=root
UUID=660afb13:150e817a:0cdd3647:6d5b2c51
ARRAY /dev/md/126_1 metadata=0.90 UUID=81f33aa2:c56b4118:14a75d6a:bbcc0774
Should I just delete mdadm.conf and the system will probably sort itself
out, or am I better off updating the ARRAY lines to match current
reality, namely changing 126_0 to 127, and 126_1 to plain 126?
Cheers,
Wol
^ permalink raw reply
* 我的个人主页是
From: 我的个人主页是 @ 2016-04-08 0:44 UTC (permalink / raw)
To: linux-raid
你的老朋友邀你来Q群:343257759 抢红包 抢秒杀 抢vip 什么都要抢。太刺激了。不靠手气只拼手速
--
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
^ permalink raw reply
* make_request bug: can't convert block across chunks or bigger than 512k 2554601336 124
From: Brian J. Murrell @ 2016-04-08 11:27 UTC (permalink / raw)
To: linux-raid
[-- Attachment #1: Type: text/plain, Size: 7564 bytes --]
So I've had this raid configuration set up and running for many many
months if not years:
/dev/md1:
Version : 1.2
Creation Time : Sat Dec 26 19:49:41 2015
Raid Level : raid0
Array Size : 1953524736 (1863.03 GiB 2000.41 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Sat Dec 26 19:49:41 2015
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Chunk Size : 512K
Name : linux.interlinx.bc.ca:1 (local to host linux.interlinx.bc.ca)
UUID : f27ae74d:e2997e50:9df158ee:c5ed3cbb
Events : 0
Number Major Minor RaidDevice State
0 8 16 0 active sync /dev/sdb
1 8 32 1 active sync /dev/sdc
/dev/md0:
Version : 0.90
Creation Time : Mon Jan 26 19:51:38 2009
Raid Level : raid1
Array Size : 1953514496 (1863.02 GiB 2000.40 GB)
Used Dev Size : 1953514496 (1863.02 GiB 2000.40 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Fri Apr 8 00:00:42 2016
State : active, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 1
Spare Devices : 0
UUID : 2f8fc5e0:a0eb646a:2303d005:33f25f21
Events : 0.5031387
Number Major Minor RaidDevice State
0 8 48 0 active sync /dev/sdd
1 0 0 1 removed
2 9 1 - faulty spare /dev/md1
Now out of the blue (or seemingly out of the blue, nothing really comes
out of the blue) I am starting to get the md0 array faulting with:
[37722.335880] md/raid0:md1: make_request bug: can't convert block across chunks or bigger than 512k 2554601336 124
[37722.335887] md/raid1:md0: md1: rescheduling sector 2554601336
[37722.376776] md/raid1:md0: redirecting sector 2554601336 to other mirror: md1
[37722.386455] md/raid0:md1: make_request bug: can't convert block across chunks or bigger than 512k 2554601336 124
[37722.386461] md/raid1:md0: md1: rescheduling sector 2554601336
[37722.412059] md/raid1:md0: redirecting sector 2554601336 to other mirror: sdd
[37722.735049] md/raid0:md1: make_request bug: can't convert block across chunks or bigger than 512k 2554608496 124
[37722.735056] md/raid1:md0: md1: rescheduling sector 2554608496
[37722.789926] md/raid1:md0: redirecting sector 2554608496 to other mirror: md1
[37722.798689] md/raid0:md1: make_request bug: can't convert block across chunks or bigger than 512k 2554608496 124
[37722.798696] md/raid1:md0: md1: rescheduling sector 2554608496
[37722.859314] md/raid1:md0: redirecting sector 2554608496 to other mirror: sdd
[37724.819090] md/raid0:md1: make_request bug: can't convert block across chunks or bigger than 512k 2554606584 12
[37724.819096] md/raid1:md0: md1: rescheduling sector 2554606584
[37727.455279] md/raid1:md0: redirecting sector 2554606584 to other mirror: sdd
[37752.406865] md/raid0:md1: make_request bug: can't convert block across chunks or bigger than 512k 1748150224 124
[37752.521219] md/raid1:md0: Disk failure on md1, disabling device.
[37752.521222] md/raid1:md0: Operation continuing on 1 devices.
[37752.580186] RAID1 conf printout:
[37752.580190] --- wd:1 rd:2
[37752.580194] disk 0, wo:0, o:1, dev:sdd
[37752.580197] disk 1, wo:1, o:0, dev:md1
[37752.580199] RAID1 conf printout:
[37752.580201] --- wd:1 rd:2
[37752.580203] disk 0, wo:0, o:1, dev:sdd
[37752.580228] BUG: unable to handle kernel paging request at 000000001dff2107
[37752.584011] IP: [<ffffffffa001909a>] close_write+0x6a/0xa0 [raid1]
[37752.584011] PGD 20f667067 PUD 20f669067 PMD 0
[37752.584011] Oops: 0000 [#1] SMP
[37752.584011] CPU 0
[37752.584011] Modules linked in: iptable_mangle iptable_filter ipt_MASQUERADE xt_tcpudp iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_tables autofs4 nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm radeon snd_seq_midi ttm drm_kms_helper snd_rawmidi ftdi_sio snd_seq_midi_event snd_seq snd_timer drm ppdev snd_seq_device pl2303 usbserial serio_raw i2c_algo_bit mac_hid asus_atk0110 snd parport_pc parport soundcore snd_page_alloc edac_core edac_mce_amd i2c_piix4 k8temp shpchp 8021q garp stp pata_atiixp r8169 raid10 raid456 async_pq async_xor xor async_memcpy async_raid6_recov raid6_pq async_tx raid1 raid0 multipath linear
[37752.584011]
[37752.584011] Pid: 267, comm: md0_raid1 Not tainted 3.2.0-101-generic #141-Ubuntu System manufacturer System Product Name/M2A-VM
[37752.584011] RIP: 0010:[<ffffffffa001909a>] [<ffffffffa001909a>] close_write+0x6a/0xa0 [raid1]
[37752.584011] RSP: 0018:ffff88020def9dc0 EFLAGS: 00010246
[37752.584011] RAX: 000000001dff1dff RBX: ffff88020e380108 RCX: 00000000e8e08784
[37752.584011] RDX: 00000000687249a8 RSI: 0000000000000002 RDI: ffff88020e380108
[37752.584011] RBP: ffff88020def9dd0 R08: 00000000e8e08784 R09: 000000000000036b
[37752.584011] R10: dead000000100100 R11: dead000000200200 R12: ffff88020e36b800
[37752.584011] R13: ffff88020e380100 R14: ffff88020e380130 R15: ffff88020e380108
[37752.584011] FS: 00007f8e0a353740(0000) GS:ffff88021fc00000(0000) knlGS:00000000f75586c0
[37752.584011] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[37752.584011] CR2: 000000001dff2107 CR3: 000000020f61e000 CR4: 00000000000006f0
[37752.584011] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[37752.584011] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[37752.584011] Process md0_raid1 (pid: 267, threadinfo ffff88020def8000, task ffff88020e2eae00)
[37752.584011] Stack:
[37752.584011] ffff88020def9e20 ffff88020e36b800 ffff88020def9e60 ffffffffa001cbe5
[37752.584011] ffff88020e380140 ffff880044dbd800 0000000091827364 ffff88020def9df8
[37752.584011] ffff88020def9df8 ffff88020def9e08 ffff88020def9e08 ffff880200000000
[37752.584011] Call Trace:
[37752.584011] [<ffffffffa001cbe5>] raid1d+0x2a5/0x2b0 [raid1]
[37752.584011] [<ffffffff814f0f9e>] md_thread+0x11e/0x170
[37752.584011] [<ffffffff8108c650>] ? add_wait_queue+0x60/0x60
[37752.584011] [<ffffffff814f0e80>] ? md_rdev_init+0x130/0x130
[37752.584011] [<ffffffff8108bbac>] kthread+0x8c/0xa0
[37752.584011] [<ffffffff816746b4>] kernel_thread_helper+0x4/0x10
[37752.584011] [<ffffffff8108bb20>] ? flush_kthread_worker+0xa0/0xa0
[37752.584011] [<ffffffff816746b0>] ? gs_change+0x13/0x13
[37752.584011] Code: e4 48 8b 53 48 75 de 48 89 d7 e8 e2 cd 14 e1 48 c7 43 48 00 00 00 00 4c 8b 43 18 48 8b 43 20 48 8b 4b 18 48 63 53 10 48 8b 73 08 <48> 8b b8 08 03 00 00 49 c1 e8 03 48 c1 e9 02 41 83 e0 01 83 e1
[37752.584011] RIP [<ffffffffa001909a>] close_write+0x6a/0xa0 [raid1]
[37752.584011] RSP <ffff88020def9dc0>
[37752.584011] CR2: 000000001dff2107
[37752.889674] ---[ end trace 276f024e11aa62ac ]---
Any ideas what is all of a sudden happening?
Cheers,
b.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Приглашаем Вас снять офис, Приглашаем Вас снять офис
From: Ирина Маринина (менеджер) @ 2016-04-08 14:09 UTC (permalink / raw)
To: lwljtbsu, lkuhsg, kompaspl, kolomoecva, kerilm0, kgxalgfsrc,
klub8igalliqnia, kaskad-tyre1, kiemunfw, l4058.html0.248699mail,
lryesz, kazan, lotte-plaza, l2202_b.html0.067575mail, magadan,
lauriewallop8075, linux-raid, kataisk45, lsjgegno, klmcomposer
Добрый день!
Предлагаем Вам открыть один из офисов в нашем здании рядом со станцией метро Багратионовская.
Данный бизнес-центр и его расположение идеально подходит для Вас, кроме этого - цены у нас реально низкие.
Если Вы еще ищите помещение - пожалуйста сообщите примерный метраж интересующего Вас помещения и я ответным письмом сообщу все свободные варианты со стоимостью аренды.
С уважением, Ирина Маринина.
^ permalink raw reply
* FROM: MR. OLIVER SENO!!
From: AKINWUMI @ 2016-04-08 18:53 UTC (permalink / raw)
To: Recipients
Dear Sir.
I bring you greetings. My name is Mr.Oliver Seno Lim, I am a staff of Abbey National Plc. London and heading our regional office in West Africa. Our late customer named Engr.Ben W.westland, made a fixed deposit amount of US$7Million.He did not declare any next of kin in any of his paper work, I want you as a foreigner to stand as the beneficiary to transfer this funds out of my bank into your account, after the successful transfer, we shall share in the ratio of 30% for you, 70%for me. Should you be interested please send me your information:
1,Full names.
2,current residential address.
3,Tele/Fax numbers./your work.
All I need from you is your readiness, trustworthiness and edication. Please email me directly on my private email address: officeosenol@yahoo.com) so we can begin arrangements and I would give you more information on how we would handle this venture and once i hear from you i will give you information of the bank for the transferring funds on your name.
Regards,
Mr.Oliver Seno Lim
^ permalink raw reply
* [GIT PULL] MD fix for 4.6-rc2
From: Shaohua Li @ 2016-04-08 21:34 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel, linux-raid, neilb
Hi Linus,
Could you please pull the MD fixes for 4.6-rc2? This update mainly fixes bugs.
- Fix error handling from Guoqing
- Fix a crash when a disk is hotremoved from me
- fix a dead loop from Wei Fang
Thanks,
Shaohua
The following changes since commit c05c2ec96bb8b7310da1055c7b9d786a3ec6dc0c:
Merge branch 'parisc-4.6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux (2016-03-31 07:55:14 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shli/md.git tags/md/4.6-rc2-fix
for you to fetch changes up to f9a67b1182e5abfcfcec24762ea95a77332f035e:
md/bitmap: clear bitmap if bitmap_create failed (2016-04-01 13:05:50 -0700)
----------------------------------------------------------------
Guoqing Jiang (1):
md/bitmap: clear bitmap if bitmap_create failed
Shaohua Li (1):
MD: add rdev reference for super write
Wei Fang (2):
md:raid1: fix a dead loop when read from a WriteMostly disk
md: fix a trivial typo in comments
drivers/md/bitmap.c | 19 +++++++++++--------
drivers/md/md.c | 5 ++++-
drivers/md/raid1.c | 2 +-
3 files changed, 16 insertions(+), 10 deletions(-)
^ permalink raw reply
* LOAN
From: darlehen @ 2016-04-08 22:02 UTC (permalink / raw)
To: Recipients
Brauchen Sie einen Kredit? Wir bieten Darlehen in 2% gelten heute Kontakt mit uns auf: legacyassetgrougp@hotmail.com
^ permalink raw reply
* Re: [BUG] NULL pointer in raid1_make_request passed to bio_trim when adding md as bcache caching dev
From: Sebastian Roesner @ 2016-04-10 18:01 UTC (permalink / raw)
To: Eric Wheeler, Shaohua Li
Cc: Ming Lei, linux-bcache, linux-raid, Ming Lin, Vlad-Cosmin Miu,
rjones, Kent Overstreet, jmoyer, axboe
In-Reply-To: <alpine.LRH.2.11.1604011812170.5949@mail.ewheeler.net>
Hello Eric, Shaohua,
Am 01.04.2016 um 20:14 schrieb Eric Wheeler:
> Hey Sebastian,
>
> Have you had a chance to test the patch below from Shaohua Li?
I just tried the patch and it did not crash anymore.
Sebastian
^ permalink raw reply
* [PATCH] dm thin: Remove return statement from void function
From: Amitoj Kaur Chawla @ 2016-04-11 6:07 UTC (permalink / raw)
To: agk, snitzer, dm-devel, shli, linux-raid, linux-kernel; +Cc: julia.lawall
Return statement at the end of a void function is useless.
The Coccinelle semantic patch used to make this change is as follows:
//<smpl>
@@
identifier f;
expression e;
@@
void f(...) {
<...
- return
e;
...>
}
//</smpl>
Signed-off-by: Amitoj Kaur Chawla <amitoj1606@gmail.com>
---
drivers/md/dm-thin.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-thin.c b/drivers/md/dm-thin.c
index 92237b6..04e7f3b 100644
--- a/drivers/md/dm-thin.c
+++ b/drivers/md/dm-thin.c
@@ -632,7 +632,7 @@ static void error_retry_list(struct pool *pool)
{
int error = get_pool_io_error_code(pool);
- return error_retry_list_with_code(pool, error);
+ error_retry_list_with_code(pool, error);
}
/*
--
1.9.1
^ permalink raw reply related
* Re: make_request bug: can't convert block across chunks or bigger than 512k 2554601336 124
From: Brian J. Murrell @ 2016-04-11 12:05 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <1460114831.27740.186.camel@interlinx.bc.ca>
[-- Attachment #1: Type: text/plain, Size: 8239 bytes --]
On Fri, 2016-04-08 at 07:27 -0400, Brian J. Murrell wrote:
> So I've had this raid configuration set up and running for many many
> months if not years:
My apologies if I come across as being impatient, but I wonder if
anyone can shed any light on this. My array is currently broken and
I'd like to get it back in order before I lose it completely. Murphy's
law and all.
> /dev/md1:
> Version : 1.2
> Creation Time : Sat Dec 26 19:49:41 2015
> Raid Level : raid0
> Array Size : 1953524736 (1863.03 GiB 2000.41 GB)
> Raid Devices : 2
> Total Devices : 2
> Persistence : Superblock is persistent
>
> Update Time : Sat Dec 26 19:49:41 2015
> State : clean
> Active Devices : 2
> Working Devices : 2
> Failed Devices : 0
> Spare Devices : 0
>
> Chunk Size : 512K
>
> Name : linux.interlinx.bc.ca:1 (local to host
> linux.interlinx.bc.ca)
> UUID : f27ae74d:e2997e50:9df158ee:c5ed3cbb
> Events : 0
>
> Number Major Minor RaidDevice State
> 0 8 16 0 active sync /dev/sdb
> 1 8 32 1 active sync /dev/sdc
>
> /dev/md0:
> Version : 0.90
> Creation Time : Mon Jan 26 19:51:38 2009
> Raid Level : raid1
> Array Size : 1953514496 (1863.02 GiB 2000.40 GB)
> Used Dev Size : 1953514496 (1863.02 GiB 2000.40 GB)
> Raid Devices : 2
> Total Devices : 2
> Preferred Minor : 0
> Persistence : Superblock is persistent
>
> Update Time : Fri Apr 8 00:00:42 2016
> State : active, degraded
> Active Devices : 1
> Working Devices : 1
> Failed Devices : 1
> Spare Devices : 0
>
> UUID : 2f8fc5e0:a0eb646a:2303d005:33f25f21
> Events : 0.5031387
>
> Number Major Minor RaidDevice State
> 0 8 48 0 active sync /dev/sdd
> 1 0 0 1 removed
>
> 2 9 1 - faulty spare /dev/md1
>
> Now out of the blue (or seemingly out of the blue, nothing really
> comes
> out of the blue) I am starting to get the md0 array faulting with:
>
> [37722.335880] md/raid0:md1: make_request bug: can't convert block
> across chunks or bigger than 512k 2554601336 124
> [37722.335887] md/raid1:md0: md1: rescheduling sector 2554601336
> [37722.376776] md/raid1:md0: redirecting sector 2554601336 to other
> mirror: md1
> [37722.386455] md/raid0:md1: make_request bug: can't convert block
> across chunks or bigger than 512k 2554601336 124
> [37722.386461] md/raid1:md0: md1: rescheduling sector 2554601336
> [37722.412059] md/raid1:md0: redirecting sector 2554601336 to other
> mirror: sdd
> [37722.735049] md/raid0:md1: make_request bug: can't convert block
> across chunks or bigger than 512k 2554608496 124
> [37722.735056] md/raid1:md0: md1: rescheduling sector 2554608496
> [37722.789926] md/raid1:md0: redirecting sector 2554608496 to other
> mirror: md1
> [37722.798689] md/raid0:md1: make_request bug: can't convert block
> across chunks or bigger than 512k 2554608496 124
> [37722.798696] md/raid1:md0: md1: rescheduling sector 2554608496
> [37722.859314] md/raid1:md0: redirecting sector 2554608496 to other
> mirror: sdd
> [37724.819090] md/raid0:md1: make_request bug: can't convert block
> across chunks or bigger than 512k 2554606584 12
> [37724.819096] md/raid1:md0: md1: rescheduling sector 2554606584
> [37727.455279] md/raid1:md0: redirecting sector 2554606584 to other
> mirror: sdd
> [37752.406865] md/raid0:md1: make_request bug: can't convert block
> across chunks or bigger than 512k 1748150224 124
> [37752.521219] md/raid1:md0: Disk failure on md1, disabling device.
> [37752.521222] md/raid1:md0: Operation continuing on 1 devices.
> [37752.580186] RAID1 conf printout:
> [37752.580190] --- wd:1 rd:2
> [37752.580194] disk 0, wo:0, o:1, dev:sdd
> [37752.580197] disk 1, wo:1, o:0, dev:md1
> [37752.580199] RAID1 conf printout:
> [37752.580201] --- wd:1 rd:2
> [37752.580203] disk 0, wo:0, o:1, dev:sdd
> [37752.580228] BUG: unable to handle kernel paging request at
> 000000001dff2107
> [37752.584011] IP: [<ffffffffa001909a>] close_write+0x6a/0xa0 [raid1]
> [37752.584011] PGD 20f667067 PUD 20f669067 PMD 0
> [37752.584011] Oops: 0000 [#1] SMP
> [37752.584011] CPU 0
> [37752.584011] Modules linked in: iptable_mangle iptable_filter
> ipt_MASQUERADE xt_tcpudp iptable_nat nf_nat nf_conntrack_ipv4
> nf_conntrack nf_defrag_ipv4 ip_tables x_tables autofs4 nfsd nfs lockd
> fscache auth_rpcgss nfs_acl sunrpc snd_hda_codec_realtek
> snd_hda_intel snd_hda_codec snd_hwdep snd_pcm radeon snd_seq_midi ttm
> drm_kms_helper snd_rawmidi ftdi_sio snd_seq_midi_event snd_seq
> snd_timer drm ppdev snd_seq_device pl2303 usbserial serio_raw
> i2c_algo_bit mac_hid asus_atk0110 snd parport_pc parport soundcore
> snd_page_alloc edac_core edac_mce_amd i2c_piix4 k8temp shpchp 8021q
> garp stp pata_atiixp r8169 raid10 raid456 async_pq async_xor xor
> async_memcpy async_raid6_recov raid6_pq async_tx raid1 raid0
> multipath linear
> [37752.584011]
> [37752.584011] Pid: 267, comm: md0_raid1 Not tainted 3.2.0-101-
> generic #141-Ubuntu System manufacturer System Product Name/M2A-VM
> [37752.584011] RIP: 0010:[<ffffffffa001909a>] [<ffffffffa001909a>]
> close_write+0x6a/0xa0 [raid1]
> [37752.584011] RSP: 0018:ffff88020def9dc0 EFLAGS: 00010246
> [37752.584011] RAX: 000000001dff1dff RBX: ffff88020e380108 RCX:
> 00000000e8e08784
> [37752.584011] RDX: 00000000687249a8 RSI: 0000000000000002 RDI:
> ffff88020e380108
> [37752.584011] RBP: ffff88020def9dd0 R08: 00000000e8e08784 R09:
> 000000000000036b
> [37752.584011] R10: dead000000100100 R11: dead000000200200 R12:
> ffff88020e36b800
> [37752.584011] R13: ffff88020e380100 R14: ffff88020e380130 R15:
> ffff88020e380108
> [37752.584011] FS: 00007f8e0a353740(0000) GS:ffff88021fc00000(0000)
> knlGS:00000000f75586c0
> [37752.584011] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [37752.584011] CR2: 000000001dff2107 CR3: 000000020f61e000 CR4:
> 00000000000006f0
> [37752.584011] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [37752.584011] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [37752.584011] Process md0_raid1 (pid: 267, threadinfo
> ffff88020def8000, task ffff88020e2eae00)
> [37752.584011] Stack:
> [37752.584011] ffff88020def9e20 ffff88020e36b800 ffff88020def9e60
> ffffffffa001cbe5
> [37752.584011] ffff88020e380140 ffff880044dbd800 0000000091827364
> ffff88020def9df8
> [37752.584011] ffff88020def9df8 ffff88020def9e08 ffff88020def9e08
> ffff880200000000
> [37752.584011] Call Trace:
> [37752.584011] [<ffffffffa001cbe5>] raid1d+0x2a5/0x2b0 [raid1]
> [37752.584011] [<ffffffff814f0f9e>] md_thread+0x11e/0x170
> [37752.584011] [<ffffffff8108c650>] ? add_wait_queue+0x60/0x60
> [37752.584011] [<ffffffff814f0e80>] ? md_rdev_init+0x130/0x130
> [37752.584011] [<ffffffff8108bbac>] kthread+0x8c/0xa0
> [37752.584011] [<ffffffff816746b4>] kernel_thread_helper+0x4/0x10
> [37752.584011] [<ffffffff8108bb20>] ? flush_kthread_worker+0xa0/0xa0
> [37752.584011] [<ffffffff816746b0>] ? gs_change+0x13/0x13
> [37752.584011] Code: e4 48 8b 53 48 75 de 48 89 d7 e8 e2 cd 14 e1 48
> c7 43 48 00 00 00 00 4c 8b 43 18 48 8b 43 20 48 8b 4b 18 48 63 53 10
> 48 8b 73 08 <48> 8b b8 08 03 00 00 49 c1 e8 03 48 c1 e9 02 41 83 e0
> 01 83 e1
> [37752.584011] RIP [<ffffffffa001909a>] close_write+0x6a/0xa0
> [raid1]
> [37752.584011] RSP <ffff88020def9dc0>
> [37752.584011] CR2: 000000001dff2107
> [37752.889674] ---[ end trace 276f024e11aa62ac ]---
>
> Any ideas what is all of a sudden happening?
>
> Cheers,
> b.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* [PATCH] dm: ioctl: use kvfree
From: Sudip Mukherjee @ 2016-04-11 15:14 UTC (permalink / raw)
To: Alasdair Kergon, Mike Snitzer, Shaohua Li
Cc: linux-kernel, dm-devel, linux-raid, Sudip Mukherjee
We can use kvfree() instead of calling kfree() and vfree() based on
if-else and param_flags. kvfree() will check the type of address and
will call the respective function to free it.
Additionally we can also remove the use of DM_PARAMS_KMALLOC and
DM_PARAMS_VMALLOC.
Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
---
drivers/md/dm-ioctl.c | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c
index 2adf81d..d5df3a5 100644
--- a/drivers/md/dm-ioctl.c
+++ b/drivers/md/dm-ioctl.c
@@ -1670,8 +1670,6 @@ static int check_version(unsigned int cmd, struct dm_ioctl __user *user)
return r;
}
-#define DM_PARAMS_KMALLOC 0x0001 /* Params alloced with kmalloc */
-#define DM_PARAMS_VMALLOC 0x0002 /* Params alloced with vmalloc */
#define DM_WIPE_BUFFER 0x0010 /* Wipe input buffer before returning from ioctl */
static void free_params(struct dm_ioctl *param, size_t param_size, int param_flags)
@@ -1679,10 +1677,7 @@ static void free_params(struct dm_ioctl *param, size_t param_size, int param_fla
if (param_flags & DM_WIPE_BUFFER)
memset(param, 0, param_size);
- if (param_flags & DM_PARAMS_KMALLOC)
- kfree(param);
- if (param_flags & DM_PARAMS_VMALLOC)
- vfree(param);
+ kvfree(param);
}
static int copy_params(struct dm_ioctl __user *user, struct dm_ioctl *param_kernel,
@@ -1716,8 +1711,6 @@ static int copy_params(struct dm_ioctl __user *user, struct dm_ioctl *param_kern
dmi = NULL;
if (param_kernel->data_size <= KMALLOC_MAX_SIZE) {
dmi = kmalloc(param_kernel->data_size, GFP_NOIO | __GFP_NORETRY | __GFP_NOMEMALLOC | __GFP_NOWARN);
- if (dmi)
- *param_flags |= DM_PARAMS_KMALLOC;
}
if (!dmi) {
@@ -1725,8 +1718,6 @@ static int copy_params(struct dm_ioctl __user *user, struct dm_ioctl *param_kern
noio_flag = memalloc_noio_save();
dmi = __vmalloc(param_kernel->data_size, GFP_NOIO | __GFP_REPEAT | __GFP_HIGH | __GFP_HIGHMEM, PAGE_KERNEL);
memalloc_noio_restore(noio_flag);
- if (dmi)
- *param_flags |= DM_PARAMS_VMALLOC;
}
if (!dmi) {
--
1.9.1
^ permalink raw reply related
* Re: dm: ioctl: use kvfree
From: Mike Snitzer @ 2016-04-11 15:17 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: Alasdair Kergon, Shaohua Li, linux-kernel, dm-devel, linux-raid
In-Reply-To: <1460387677-19948-1-git-send-email-sudipm.mukherjee@gmail.com>
On Mon, Apr 11 2016 at 11:14am -0400,
Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
> We can use kvfree() instead of calling kfree() and vfree() based on
> if-else and param_flags. kvfree() will check the type of address and
> will call the respective function to free it.
> Additionally we can also remove the use of DM_PARAMS_KMALLOC and
> DM_PARAMS_VMALLOC.
>
> Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Have you actually tested htis? Last time I looked to do this it exposed
crashes. I don't have time to dig into this again right now but this is
_not_ as simple as this patch implies.
^ permalink raw reply
* [PATCH] MAINTAINERS: correct entry for LVM
From: Sudip Mukherjee @ 2016-04-11 15:20 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, Alasdair Kergon, Mike Snitzer, Shaohua Li, dm-devel,
linux-raid, Sudip Mukherjee
The entry of dm-devel@redhat.com was duplicated and the duplicate entry
was marked as a Maintainer but it appears from the email address that it
is a List. So remove the entry of M and only keep the L entry.
Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 51891b2..1c32e82 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3557,7 +3557,6 @@ S: Maintained
DEVICE-MAPPER (LVM)
M: Alasdair Kergon <agk@redhat.com>
M: Mike Snitzer <snitzer@redhat.com>
-M: dm-devel@redhat.com
L: dm-devel@redhat.com
W: http://sources.redhat.com/dm
Q: http://patchwork.kernel.org/project/dm-devel/list/
--
1.9.1
^ permalink raw reply related
* Re: Recovery after failed chunk size change
From: Benjamin Meier @ 2016-04-11 15:29 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <56FED3F7.8080009@ferienwohnung-altenbeken.de>
Hi,
>
> # Create a seven disk RAID6 array with sparse files (1GiB each)
> declare -a LO_DEVICES
> for x in 0 1 2 3 4 5 6; do
> dd if=/dev/zero of=sparse$x bs=1G count=0 seek=1
> losetup -f sparse${x}
> LO_DEVICES[$x]=$(losetup -a|grep sparse${x}|cut -f1 -d" "|sed "s/://")
> done
> mdadm --create /dev/md/TestMD --chunk=4096 --bitmap=internal --level=6
> --raid-devices=7 \
> ${LO_DEVICES[*]}
> mdadm --wait /dev/md/TestMD
>
> # Provocate BUG.
> # Tested with Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u4
> (2016-02-29) x86_64 GNU/Linux
> # mdadm - v3.3.2 - 21st August 2014
> mdadm --grow /dev/md/TestMD --chunk=64 --backup-file=backup.file
>
Was this issue reproducible? Or do you need any additional information?
I have discovered that the problem is not limited to changing the chunk
size. It also happens with a RAID level change from say 6 to 5.
BR!
^ permalink raw reply
* Re: Setting up fakeraid with mdadm / dmraid
From: Jes Sorensen @ 2016-04-11 15:33 UTC (permalink / raw)
To: Christoph Pleger; +Cc: linux-raid
In-Reply-To: <b6ced30ee931f9a6faf2541db2462401.squirrel@postweb.cs.tu-dortmund.de>
"Christoph Pleger" <Christoph.Pleger@cs.tu-dortmund.de> writes:
> Hello,
>
> I have a machine with an LSI Megaraid Sofware RAID fakeraid, which uses
> ddf format. About two weeks ago, when I wanted to install the machine, I
> configured a RAID 1 array in the BIOS config utility and then booted the
> machine from PXE with an NFSROOT. mdadm and dmraid are installed in the
> NFSROOT, dracut is used for initrd generation. As dracut prefers mdadm
> over dmraid, mdadm was chosen for RAID management.
>
> But though mdadm detected the RAID (it created container device /dev/md127
> and raid device /dev/md126), it destroyed it - that is, though I did not
> perform any action on the raid disks, at the next boot, the BIOS RAID
> utility had "forgotten" about the RAID configuration it had created
> before.
>
> Why are the possible reasons for that?
The LSI uses DDF and requires mdmon etc. to be launched. It is not clear
from your posting what you created, but you would have to update dracut
to include mdmon etc. after creating the RAID.
Jes
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: correct entry for LVM
From: Alasdair G Kergon @ 2016-04-11 15:51 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: Andrew Morton, linux-kernel, Alasdair Kergon, Mike Snitzer,
Shaohua Li, dm-devel, linux-raid
In-Reply-To: <1460388039-20282-1-git-send-email-sudipm.mukherjee@gmail.com>
On Mon, Apr 11, 2016 at 08:50:39PM +0530, Sudip Mukherjee wrote:
> The entry of dm-devel@redhat.com was duplicated and the duplicate entry
> was marked as a Maintainer but it appears from the email address that it
> is a List. So remove the entry of M and only keep the L entry.
M and L are not mutually exclusive!
The definition of M is:
M: Mail patches to: FullName <address@domain>
and since we want patches to be sent to the mailing list, this entry is correct
as it stands.
Alasdair
^ permalink raw reply
* Re: dm: ioctl: use kvfree
From: Sudip Mukherjee @ 2016-04-11 16:09 UTC (permalink / raw)
To: Mike Snitzer
Cc: Alasdair Kergon, Shaohua Li, linux-kernel, dm-devel, linux-raid
In-Reply-To: <20160411151714.GB25938@redhat.com>
On Monday 11 April 2016 08:47 PM, Mike Snitzer wrote:
> On Mon, Apr 11 2016 at 11:14am -0400,
> Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
>
>> We can use kvfree() instead of calling kfree() and vfree() based on
>> if-else and param_flags. kvfree() will check the type of address and
>> will call the respective function to free it.
>> Additionally we can also remove the use of DM_PARAMS_KMALLOC and
>> DM_PARAMS_VMALLOC.
>>
>> Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
>
> Have you actually tested htis? Last time I looked to do this it exposed
> crashes. I don't have time to dig into this again right now but this is
> _not_ as simple as this patch implies.
>
No, it was just build tested. Is it possible to test it in qemu or kvm?
regards
sudip
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: correct entry for LVM
From: Sudip Mukherjee @ 2016-04-11 16:15 UTC (permalink / raw)
To: Andrew Morton, linux-kernel, Alasdair Kergon, Mike Snitzer,
Shaohua Li, dm-devel, linux-raid
Cc: Joe Perches
In-Reply-To: <20160411155147.GB9288@agk-dp.fab.redhat.com>
On Monday 11 April 2016 09:21 PM, Alasdair G Kergon wrote:
> On Mon, Apr 11, 2016 at 08:50:39PM +0530, Sudip Mukherjee wrote:
>> The entry of dm-devel@redhat.com was duplicated and the duplicate entry
>> was marked as a Maintainer but it appears from the email address that it
>> is a List. So remove the entry of M and only keep the L entry.
>
> M and L are not mutually exclusive!
>
> The definition of M is:
> M: Mail patches to: FullName <address@domain>
> and since we want patches to be sent to the mailing list, this entry is correct
> as it stands.
L stands for "Mailing list that is relevant to this area", and this is a
mailing list. :)
regards
sudip
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: correct entry for LVM
From: Alasdair G Kergon @ 2016-04-11 16:23 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: Andrew Morton, linux-kernel, Alasdair Kergon, Mike Snitzer,
Shaohua Li, dm-devel, linux-raid, Joe Perches
In-Reply-To: <570BCD85.6090807@gmail.com>
On Mon, Apr 11, 2016 at 09:45:01PM +0530, Sudip Mukherjee wrote:
> L stands for "Mailing list that is relevant to this area", and this is a
> mailing list. :)
Your proposed patch isn't changing the L entry, so this is of no relevance.
Alasdair
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: correct entry for LVM
From: Sudip Mukherjee @ 2016-04-11 16:39 UTC (permalink / raw)
To: Andrew Morton, linux-kernel, Alasdair Kergon, Mike Snitzer,
Shaohua Li, dm-devel, linux-raid, Joe Perches
In-Reply-To: <20160411162306.GC9288@agk-dp.fab.redhat.com>
On Monday 11 April 2016 09:53 PM, Alasdair G Kergon wrote:
> On Mon, Apr 11, 2016 at 09:45:01PM +0530, Sudip Mukherjee wrote:
>> L stands for "Mailing list that is relevant to this area", and this is a
>> mailing list. :)
>
> Your proposed patch isn't changing the L entry, so this is of no relevance.
Sorry, I am not understanding.
The current entry in MAINTAINERS is:
DEVICE-MAPPER (LVM)
M: Alasdair Kergon <agk@redhat.com>
M: Mike Snitzer <snitzer@redhat.com>
M: dm-devel@redhat.com
L: dm-devel@redhat.com
...
So my patch just removed the line : "M: dm-devel@redhat.com"
So now the entry becomes :
DEVICE-MAPPER (LVM)
M: Alasdair Kergon <agk@redhat.com>
M: Mike Snitzer <snitzer@redhat.com>
L: dm-devel@redhat.com
...
So, now it correctly shows dm-devel@redhat.com as a mailing list which
should have cc to all the patches related to LVM.
Or am I understanding this wrong?
regards
sudip
^ permalink raw reply
* Re: dm: ioctl: use kvfree
From: Guenter Roeck @ 2016-04-11 18:34 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: Alasdair Kergon, Mike Snitzer, Shaohua Li, linux-kernel, dm-devel,
linux-raid
In-Reply-To: <1460387677-19948-1-git-send-email-sudipm.mukherjee@gmail.com>
On Mon, Apr 11, 2016 at 08:44:37PM +0530, Sudip Mukherjee wrote:
> We can use kvfree() instead of calling kfree() and vfree() based on
> if-else and param_flags. kvfree() will check the type of address and
> will call the respective function to free it.
> Additionally we can also remove the use of DM_PARAMS_KMALLOC and
> DM_PARAMS_VMALLOC.
>
> Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
>
> ---
> drivers/md/dm-ioctl.c | 11 +----------
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c
> index 2adf81d..d5df3a5 100644
> --- a/drivers/md/dm-ioctl.c
> +++ b/drivers/md/dm-ioctl.c
> @@ -1670,8 +1670,6 @@ static int check_version(unsigned int cmd, struct dm_ioctl __user *user)
> return r;
> }
>
> -#define DM_PARAMS_KMALLOC 0x0001 /* Params alloced with kmalloc */
> -#define DM_PARAMS_VMALLOC 0x0002 /* Params alloced with vmalloc */
> #define DM_WIPE_BUFFER 0x0010 /* Wipe input buffer before returning from ioctl */
>
> static void free_params(struct dm_ioctl *param, size_t param_size, int param_flags)
> @@ -1679,10 +1677,7 @@ static void free_params(struct dm_ioctl *param, size_t param_size, int param_fla
> if (param_flags & DM_WIPE_BUFFER)
> memset(param, 0, param_size);
>
> - if (param_flags & DM_PARAMS_KMALLOC)
> - kfree(param);
> - if (param_flags & DM_PARAMS_VMALLOC)
> - vfree(param);
> + kvfree(param);
That won't work: param is not always allocated. See code path leading to
the "data_copied:" label in copy_params().
This is the second time this patch has been submitted. Maybe someone should
add a comment explaining why a conditional flag is needed.
Guenter
> }
>
> static int copy_params(struct dm_ioctl __user *user, struct dm_ioctl *param_kernel,
> @@ -1716,8 +1711,6 @@ static int copy_params(struct dm_ioctl __user *user, struct dm_ioctl *param_kern
> dmi = NULL;
> if (param_kernel->data_size <= KMALLOC_MAX_SIZE) {
> dmi = kmalloc(param_kernel->data_size, GFP_NOIO | __GFP_NORETRY | __GFP_NOMEMALLOC | __GFP_NOWARN);
> - if (dmi)
> - *param_flags |= DM_PARAMS_KMALLOC;
> }
>
> if (!dmi) {
> @@ -1725,8 +1718,6 @@ static int copy_params(struct dm_ioctl __user *user, struct dm_ioctl *param_kern
> noio_flag = memalloc_noio_save();
> dmi = __vmalloc(param_kernel->data_size, GFP_NOIO | __GFP_REPEAT | __GFP_HIGH | __GFP_HIGHMEM, PAGE_KERNEL);
> memalloc_noio_restore(noio_flag);
> - if (dmi)
> - *param_flags |= DM_PARAMS_VMALLOC;
> }
>
> if (!dmi) {
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox