ChangeSet@1.1564, 2004-09-18 12:12:06-03:00, dledford@redhat.com [PATCH] RAID1 error handling locking fix OK, basic problem is that if you use mdadm to fail a device in a raid1 array and then immediately remove that device, you can end up triggering a race condition in the raid1 code. This only shows up on SMP systems (and the one I have here which is a 2 physical, 4 logical processor system shows it very easily, but for some reason nmi_watchdog didn't ever help and the system always just locked hard and refused to do anything, so I didn't have an oops to work from, just a hardlock). In the raid1 code, we keep an array of devices that are part of the raid1 array. Each of these devices can have multiple states, but for the most part we check the operational bit of a device before deciding to use it. If we decide to use that device, then we grab the device number from the array (kdev_t, aka this is the device's major/minor and is what we are going to pass to generic_make_request in order to pass the buffer head on to the underlying device). When we fail a device, we set that operational bit to 0. When we remove a device, we also set the dev item in the struct to MKDEV(0,0). There is no locking whatsoever between the failing of a device (setting the operational bit to 0) and the make_request functions in the raid1 code. So, even though it's safe to fail a device without this locking, before we can safely remove the device we need to know that every possible context that might be checking that operational bit has in fact seen the failed operational bit. If not, then we can end up setting the dev to 0, then the other context grabs it and tries to pass that off to generic_make_request, unnice things ensue. So, this patch does these things: 1. Whenever we are calling mark_disk_bad(), hold the conf->device_lock 2. Whenever we are walking the device array looking for an operational device, always grab the conf->device_lock first and hold it until after we have gotten not only the operational bit but also the dev number for the device 3. Correct an accounting problem in the superblock. If we fail a device and it's currently counted as a spare device instead of an active device, then we failed to decrement the superblocks spare disk count. This accounting error is preserved across shutdown and restart of the array, and although it doesn't oops the kernel (the kernel will refuse to try and read beyond disk 26 even if the spare count indicates it should, although I'm not sure it doesn't try and write past 26 so this could be a disk corruptor when the spare count + active counts exceeds the amount of space available in the on disk superblock format) it does in fact cause mdadm to segfault on trying to read the superblock. So, that's the description. Testing. Well, without this patch, my test machine dies on the following command *very* quickly: while true; do mdadm /dev/md0 -f /dev/sdc1 -r /dev/sdc1 -a /dev/sdc1; sleep 1; done In addition, without the patch you can watch the superblock's spare count go up with every single invocation of that command. With my patch, the same machine survived the above command running over the weekend, and in addition I mounted the raid1 array and ran a continuous loop of bonnie++ sessions to generate as much load as possible. I've verified that the spare count stays consistent when failing a spare device, and I've verfied that once a device is synced up then the spare count is also decremented as the device is switched to being accounted as an active device. ChangeSet@1.1563, 2004-09-18 12:05:11-03:00, vda@port.imtp.ilyichevsk.odessa.ua [PATCH] trivial patch for 2.4: always inline __constant_* Of these, at least the following were intended to be always inlined: 12 __constant_c_and_count_memset 6 __constant_memcpy Prolly #include is missing in some files, or included too late to have desired effect. Let's find them: find -name '*.o' | xargs grep -lF '__constant_c_and_count_memset' find -name '*.o' | xargs grep -lF '__constant_memcpy' } | sort | uniq Redoing this with allyesconfig revealed some more files. Most of them can be fixed with a single #include in . Along the way, I fixed some non-compilation buglets. I will submit those patches as replies now. ChangeSet@1.1536.1.5, 2004-09-14 22:13:08-07:00, davem@nuts.davemloft.net [TG3]: Update driver version and reldate. ChangeSet@1.1536.1.4, 2004-09-14 22:12:20-07:00, davem@nuts.davemloft.net [TG3]: Recognize all onboard Sun variants, not just 5704. Based upon a report from Matthias Merz. Signed-off-by: David S. Miller ChangeSet@1.1536.1.3, 2004-09-14 22:06:21-07:00, michael.waychison@sun.com [TG3]: Fix thinko in 5704 fibre hw autoneg code. Signed-off-by: Mike Waychison Signed-off-by: David S. Miller ChangeSet@1.1543.1.7, 2004-09-14 22:40:21-04:00, ananth@broadcom.com [libata sata_svw] race condition fix, new device support * address race condition WRT order of DMA-start and ATA command issue (see code comment for more details) * Add support for Frodo 4/8 ChangeSet@1.1543.1.6, 2004-09-14 22:40:04-04:00, jgarzik@pobox.com [libata] minor comment updates, preparing for iomap merge ChangeSet@1.1560, 2004-09-14 16:01:44-03:00, khali@linux-fr.org [PATCH] Update Documentation/i2c/writing-clients Hi Marcelo, This is a quick update to the Documentation/i2c/writing-clients file. A similar change was accepted by Greg KH in 2.6 and was also applied to the i2c CVS repository. The changes are about i2c client driver IDs. It used to say that chip driver writers should ask for a unique ID. It now explains that such an ID is not required and they can go without it. The patch additionally features CodingStyle updates. Fell free to apply it if you want, thanks. Signed-off-by: Jean Delvare ChangeSet@1.1559, 2004-09-14 16:01:13-03:00, mikpe@csd.uu.se [PATCH] matrox framebuffer driver gcc-3.4 fix This patch fixes gcc-3.4 cast-as-lvalue warnings in the 2.4.28-pre3 kernel's matrox framebuffer driver. The changes are backports from the 2.6 kernel. The warnings don't appear for x86, but they do appear for ppc32. /Mikael ChangeSet@1.1558, 2004-09-14 16:00:45-03:00, mikpe@csd.uu.se [PATCH] PPC32 PReP residual data gcc-3.4 fix This patch fixes a gcc-3.4 cast-as-lvalue warning in the 2.4.28-pre3 kernel's arch/ppc/platform/residual.c. The change is a backport from the 2.6 kernel. /Mikael ChangeSet@1.1557, 2004-09-14 16:00:25-03:00, mikpe@csd.uu.se [PATCH] E100 driver gcc-3.4 fixes This patch fixes gcc-3.4 "`__packed__' attribute ignored" warnings in the 2.4.28-pre3 kernel's E100 ethernet driver. The changes are new since the 2.6 E100 driver is different. /Mikael ChangeSet@1.1556, 2004-09-14 15:59:43-03:00, mikpe@csd.uu.se [PATCH] RIVA driver gcc-3.4 fix This patch fixes a gcc-3.4 cast-as-lvalue warning in the 2.4.28-pre3 kernel's RIVA video driver. The change is new since the 2.6 code is different. /Mikael ChangeSet@1.1555, 2004-09-14 15:26:04-03:00, mikpe@csd.uu.se [PATCH] MTD drivers gcc-3.4 fixes This patch fixes gcc-3.4 cast-as-lvalue warnings in the 2.4.28-pre3 kernel's MTD drivers. The elan-104nc.c and sbc_gxx.c changes are backports from the 2.6 kernel. The cfi_cmdset_0001.c and cfi_cmdset_0020.c changes are new since the 2.6 code is different. /Mikael ChangeSet@1.1554, 2004-09-14 15:24:16-03:00, zaitcev@redhat.com [PATCH] USB drivers gcc-3.4 fixes ChangeSet@1.1553, 2004-09-14 15:21:26-03:00, mikpe@csd.uu.se [PATCH] ISDN drivers gcc-3.4 fixes This patch fixes gcc-3.4 cast-as-lvalue warnings in the 2.4.28-pre3 kernel's ISDN drivers. With the exception of eicon_idi.c, which doesn't seem to be in the 2.6 kernel, the changes are all backports from the 2.6 kernel. /Mikael ChangeSet@1.1552, 2004-09-14 15:06:34-03:00, mikpe@csd.uu.se [PATCH] IBM PCI hotplug controller driver gcc-3.4 fixes This patch fixes gcc-3.4 cast-as-lvalue warnings in the 2.4.28-pre3 kernel's IBM PCI hotplug controller driver. The changes are all backports from the 2.6 kernel. /Mikael ChangeSet@1.1551, 2004-09-14 15:01:22-03:00, mikpe@csd.uu.se [PATCH] ATM drivers gcc-3.4 fixes This patch fixes gcc-3.4 cast-as-lvalue warnings in the 2.4.28-pre3 kernel's ATM drivers. The changes are backports from the 2.6 kernel. Where the 2.4 and 2.6 kernels differ (->dev_data or ->phy_data for private data), I have chosen to preserve 2.4's behaviour. /Mikael ChangeSet@1.1550, 2004-09-14 14:55:33-03:00, mikpe@csd.uu.se [PATCH] pcmcia mem_op.h gcc-3.4 fixes This patch fixes gcc-3.4 cast-as-lvalue warnings in the 2.4.28-pre3 kernel caused by include/pcmcia/mem_op.h. The changes are all backports from the 2.6 kernel. /Mikael ChangeSet@1.1549, 2004-09-14 14:46:24-03:00, mikpe@csd.uu.se [PATCH] 53c700 scsi driver gcc-3.4 fixes This patch fixes gcc-3.4 cast-as-lvalue warnings in the 2.4.28-pre3 kernel's drivers/scsi/53c700.h. With the exception of NCR_700_set_SXFER(), the changes are all backports from the 2.6 kernel. /Mikael ChangeSet@1.1548, 2004-09-14 14:20:22-03:00, Jack_Hammer@adaptec.com [PATCH] broken ips update This patch replaces the patch I submitted ( and then rescinded ) earlier today. It fixes the compilation problem in 2.4.28 and includes the changes recommended by Arjan on my earlier proposal for this. ChangeSet@1.1543.1.5, 2004-09-13 23:31:21-04:00, jgarzik@pobox.com [libata] consolidate legacy/native mode init code into helpers Eliminates duplicate code in sata_nv, sata_sis, and sata_via. ChangeSet@1.1543.1.4, 2004-09-13 22:35:25-04:00, jgarzik@pobox.com [libata] remove distinction between MMIO/PIO helper functions Prepare for use of new generic iomap API. ChangeSet@1.1543.1.3, 2004-09-13 22:15:08-04:00, jgarzik@pobox.com [libata] resync with 2.6.x Only whitespace changes. ChangeSet@1.1543.1.2, 2004-09-13 21:47:35-04:00, jgarzik@pobox.com linux/compiler.h: dummy __iomem macro (an sparse annotation) ChangeSet@1.1543.1.1, 2004-09-13 21:46:53-04:00, torvalds@ppc970.osdl.org libata: initial PCI memory annotations ChangeSet@1.1536.1.2, 2004-09-13 16:09:23-07:00, martin.wilck@fujitsu-siemens.com [TG3]: Fix pause handling, we had duplicate flags for the same thing. Signed-off-by: David S. Miller ChangeSet@1.1547, 2004-09-10 15:55:20-03:00, marcelo@logos.cnet Changed EXTRAVERSION to -pre3 TAG: v2.4.28-pre3