summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2007-10-19hugetlbfs doc. updateRandy Dunlap
Fix typos, spelling, etc., in Doc/vm/hugetlbpage.txt. Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-19x86: HUGETLBFS and DEBUG_PAGEALLOC are incompatibleKen Chen
DEBUG_PAGEALLOC is not compatible with hugetlb page support. That debug option turns off PSE. Once it is turned off in CR4, the cpu will ignore pse bit in the pmd and causing infinite page-not- present faults. So disable DEBUG_PAGEALLOC if the user selected hugetlbfs. Signed-off-by: Ken Chen <kenneth.w.chen@intel.com> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-19[IA64] lazy_mmu_prot_update needs to be aware of huge pagesZhang Yanmin
Function lazy_mmu_prot_update is also used on huge pages when it is called by set_huge_ptep_writable, but it isn't aware of huge pages. Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com> Acked-by: Ken Chen <kenneth.w.chen@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-19SELinux: clear parent death signal on SID transitionsStephen Smalley
Clear parent death signal on SID transitions to prevent unauthorized signaling between SIDs. Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Acked-by: Eric Paris <eparis@parisplace.org> Signed-off-by: James Morris <jmorris@localhost.localdomain> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-18make UML compile (FC6/x86-64)Ulrich Drepper
I need this patch to get a UML kernel to compile. This is with the kernel headers in FC6 which are automatically generated from the kernel tree. Some headers are missing but those files don't need them. At least it appears so since the resuling kernel works fine. Tested on x86-64. Signed-off-by: Ulrich Drepper <drepper@redhat.com> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-18DVB: get_dvb_firmware: update script for new location of tda10046 firmwareAndreas Arens
cherry picked from commit c545d6adbcacd296f7457bd992556feb055379de Update get_dvb_firmware script for the new location of the tda10046 firmware. The old location doesn't work anymore. Signed-off-by: Andreas Arens <ari@goron.de> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-18DVB: get_dvb_firmware: update script for new location of sp8870 firmwareMichael Krufky
cherry picked from commit 302170a4b47e869372974abd885dd11d5536b64a get_dvb_firmware: update script for new location of sp8870 firmware This url is no longer valid: http://www.technotrend.de/new/217g/tt_Premium_217g.zip Replace with: http://www.softwarepatch.pl/9999ccd06a4813cb827dbb0005071c71/tt_Premium_217g.zip Thanks-to: Tobias Stoeber <tobi@to-st.de> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-18alpha: fix epoll syscall enumerationsMike Frysinger
We went and named them __NR_sys_foo instead of __NR_foo. It may be too late to change this, but we can at least add the proper names now. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-18m68knommu: ptrace.h typo fixJan Altenberg
Signed-off-by: Jan Altenberg <tb10alj@tglx.de> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-18[TCP]: Fix fastpath_cnt_hint when GSO skb is partially ACKedIlpo Järvinen
When only GSO skb was partially ACKed, no hints are reset, therefore fastpath_cnt_hint must be tweaked too or else it can corrupt fackets_out. The corruption to occur, one must have non-trivial ACK/SACK sequence, so this bug is not very often that harmful. There's a fackets_out state reset in TCP because fackets_out is known to be inaccurate and that fixes the issue eventually anyway. In case there was also at least one skb that got fully ACKed, the fastpath_skb_hint is set to NULL which causes a recount for fastpath_cnt_hint (the old value won't be accessed anymore), thus it can safely be decremented without additional checking. Reported by Cedric Le Goater <clg@fr.ibm.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-18[SPARC64]: Fix bugs in SYSV IPC handling in 64-bit processes.David S. Miller
Thanks to Tom Callaway for the excellent bug report and test case. sys_ipc() has several problems, most to due with semaphore call handling: 1) 'err' return should be a 'long' 2) "union semun" is passed in a register on 64-bit compared to 32-bit which provides it on the stack and therefore by reference 3) Second and third arguments to SEMCTL are swapped compared to 32-bit. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-18[NET]: Zero length write() on socket should not simply return 0.David S. Miller
This fixes kernel bugzilla #5731 It should generate an empty packet for datagram protocols when the socket is connected, for one. The check is doubly-wrong because all that a write() can be is a sendmsg() call with a NULL msg_control and a single entry iovec. No special semantics should be assigned to it, therefore the zero length check should be removed entirely. This matches the behavior of BSD and several other systems. Alan Cox notes that SuSv3 says the behavior of a zero length write on non-files is "unspecified", but that's kind of useless since BSD has defined this behavior for a quarter century and BSD is essentially what application folks code to. Based upon a patch from Stephen Hemminger. Adrian Bunk: Backported to 2.6.16. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-18[PKT_SCHED] cls_u32: error code isn't been propogated properlyStephen Hemminger
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-18[POWERPC] Fix handling of stfiwx math emulationKumar Gala
Its legal for the stfiwx instruction to have RA = 0 as part of its effective address calculation. This is illegal for all other XE form instructions. Add code to compute the proper effective address for stfiwx if RA = 0 rather than treating it as illegal. Adrian Bunk: Backported to 2.6.16. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-18[PKT_SCHED] RED: Fix overflow in calculation of queue averageIlpo Järvinen
Overflow can occur very easily with 32 bits, e.g., with 1 second us_idle is approx. 2^20, which leaves only 11-Wlog bits for queue length. Since the EWMA exponent is typically around 9, queue lengths larger than 2^2 cause overflow. Whether the affected branch is taken when us_idle is as high as 1 second, depends on Scell_log, but with rather reasonable configuration Scell_log is large enough to cause p->Stab to have zero index, which always results zero shift (typically also few other small indices result in zero shift). Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-12Linux 2.6.16.55v2.6.16.55Adrian Bunk
2007-10-12Revert "TCP: Fix TCP handling of SACK in bidirectional flows"Adrian Bunk
This reverts commit 3198d0f16dec0c87071cf26f3f11af9c8f0a009b.
2007-10-07Linux 2.6.16.55-rc1v2.6.16.55-rc1Adrian Bunk
2007-10-07Convert snd-page-alloc proc file to use seq_file (CVE-2007-4571)Takashi Iwai
Commit ccec6e2c4a74adf76ed4e2478091a311b1806212 in mainline. Use seq_file for the proc file read/write of snd-page-alloc module. This automatically fixes bugs in the old proc code. Adrian Bunk: Backported to 2.6.16. Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-07snd_mem_proc_read(): convert to list_for_each_entry*Adrian Bunk
Stolen from a patch by Johannes Berg <johannes@sipsolutions.net>. Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-07sysfs: store sysfs inode nrs in s_ino to avoid readdir oopses (CVE-2007-3104)Eric Sandeen
Backport of ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc1/2.6.22-rc1-mm1/broken-out/gregkh-driver-sysfs-allocate-inode-number-using-ida.patch For regular files in sysfs, sysfs_readdir wants to traverse sysfs_dirent->s_dentry->d_inode->i_ino to get to the inode number. But, the dentry can be reclaimed under memory pressure, and there is no synchronization with readdir. This patch follows Tejun's scheme of allocating and storing an inode number in the new s_ino member of a sysfs_dirent, when dirents are created, and retrieving it from there for readdir, so that the pointer chain doesn't have to be traversed. Tejun's upstream patch uses a new-ish "ida" allocator which brings along some extra complexity; this -stable patch has a brain-dead incrementing counter which does not guarantee uniqueness, but because sysfs doesn't hash inodes as iunique expects, uniqueness wasn't guaranteed today anyway. Adrian Bunk: Backported to 2.6.16. Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-07random: fix bound check ordering (CVE-2007-3105)Matt Mackall
If root raised the default wakeup threshold over the size of the output pool, the pool transfer function could overflow the stack with RNG bytes, causing a DoS or potential privilege escalation. (Bug reported by the PaX Team <pageexec@freemail.hu>) Signed-off-by: Matt Mackall <mpm@selenic.com> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-07random: fix seeding with zero entropy (CVE-2007-2453 2 of 2)Matt Mackall
Add data from zero-entropy random_writes directly to output pools to avoid accounting difficulties on machines without entropy sources. Tested on lguest with all entropy sources disabled. Signed-off-by: Matt Mackall <mpm@selenic.com> Acked-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-07random: fix error in entropy extraction (CVE-2007-2453 1 of 2)Matt Mackall
Fix cast error in entropy extraction. Add comments explaining the magic 16. Remove extra confusing loop variable. Signed-off-by: Matt Mackall <mpm@selenic.com> Acked-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-07Reset current->pdeath_signal on SUID binary execution (CVE-2007-3848)Marcel Holtmann
This fixes a vulnerability in the "parent process death signal" implementation discoverd by Wojciech Purczynski of COSEINC PTE Ltd. and iSEC Security Research. http://marc.info/?l=bugtraq&m=118711306802632&w=2 Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-06fix buffer overflow in the moxa driver (CVE-2005-0504)Dann Frazier
Signed-off-by: Dann Frazier <dannf@hp.com> Signed-off-by: Andres Salomon <dilinger@debian.org> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-06[POWERPC] Flush registers to proper task contextKumar Gala
When we flush register state for FP, Altivec, or SPE in flush_*_to_thread we need to respect the task_struct that the caller has passed to us. Most cases we are called with current, however sometimes (ptrace) we may be passed a different task_struct. This showed up when using gdbserver debugging a simple program that used floating point. When gdb tried to show the FP regs they all showed up as 0, because the child's FP registers were never properly flushed to memory. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-06x86_64: Zero extend all registers after ptrace in 32bit entry path ↵Andi Kleen
(CVE-2007-4573) Strictly it's only needed for eax. It actually does a little more than strictly needed -- the other registers are already zero extended. Also remove the now unnecessary and non functional compat task check in ptrace. Found by Wojciech Purczynski Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-06unexport ip_conntrack_{,un}register_notifierAdrian Bunk
Static functions mustn't be exported. Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-06sound/core/pcm_lib.c: don't export static functionsAdrian Bunk
Static functions mustn't be exported. Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-06unexport csr1212_release_keyvalAdrian Bunk
A static function mustn't be exported. Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-06unexport cpufreq_parse_governorAdrian Bunk
A static function mustn't be exported. Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-06unexport neigh_update_hhsAdrian Bunk
A static function mustn't be exported. Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-06[SPARC]: fix sparc64 gcc 4.2 compile failureMikael Pettersson
Compiling 2.6.21-rc5 with gcc-4.2.0 20070317 (prerelease) for sparc64 fails as follows: gcc -Wp,-MD,arch/sparc64/kernel/.time.o.d -nostdinc -isystem /home/mikpe/pkgs/linux-sparc64/gcc-4.2.0/lib/gcc/sparc64-unknown-linux-gnu/4.2.0/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -m64 -pipe -mno-fpu -mcpu=ultrasparc -mcmodel=medlow -ffixed-g4 -ffixed-g5 -fcall-used-g7 -Wno-sign-compare -Wa,--undeclared-regs -fomit-frame-pointer -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -Werror -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(time)" -D"KBUILD_MODNAME=KBUILD_STR(time)" -c -o arch/sparc64/kernel/time.o arch/sparc64/kernel/time.c cc1: warnings being treated as errors arch/sparc64/kernel/time.c: In function 'kick_start_clock': arch/sparc64/kernel/time.c:559: warning: overflow in implicit constant conversion make[1]: *** [arch/sparc64/kernel/time.o] Error 1 make: *** [arch/sparc64/kernel] Error 2 gcc gets unhappy when the MSTK_SET macro's u8 __val variable is updated with &= ~0xff (MSTK_YEAR_MASK). Making the constant unsigned fixes the problem. [ I fixed up the sparc32 side as well -DaveM ] Signed-off-by: Mikael Pettersson <mikpe@it.uu.se> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-06unexport ktime_get_realAdrian Bunk
A static function mustn't be exported. Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-06[IPSEC] AH4: Update IPv4 options handling to conform to RFC 4302.Nick Bowler
In testing our ESP/AH offload hardware, I discovered an issue with how AH handles mutable fields in IPv4. RFC 4302 (AH) states the following on the subject: For IPv4, the entire option is viewed as a unit; so even though the type and length fields within most options are immutable in transit, if an option is classified as mutable, the entire option is zeroed for ICV computation purposes. The current implementation does not zero the type and length fields, resulting in authentication failures when communicating with hosts that do (i.e. FreeBSD). I have tested record route and timestamp options (ping -R and ping -T) on a small network involving Windows XP, FreeBSD 6.2, and Linux hosts, with one router. In the presence of these options, the FreeBSD and Linux hosts (with the patch or with the hardware) can communicate. The Windows XP host simply fails to accept these packets with or without the patch. I have also been trying to test source routing options (using traceroute -g), but haven't had much luck getting this option to work *without* AH, let alone with. Signed-off-by: Nick Bowler <nbowler@ellipticsemi.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-09-25Linux 2.6.16.54v2.6.16.54Adrian Bunk
2007-09-24Linux 2.6.16.54-rc1v2.6.16.54-rc1Adrian Bunk
2007-09-24TCP: Fix TCP handling of SACK in bidirectional flowsIlpo Järvinen
It's possible that new SACK blocks that should trigger new LOST markings arrive with new data (which previously made is_dupack false). In addition, I think this fixes a case where we get a cumulative ACK with enough SACK blocks to trigger the fast recovery (is_dupack would be false there too). I'm not completely pleased with this solution because readability of the code is somewhat questionable as 'is_dupack' in SACK case is no longer about dupacks only but would mean something like 'lost_marker_work_todo' too... But because of Eifel stuff done in CA_Recovery, the FLAG_DATA_SACKED check cannot be placed to the if statement which seems attractive solution. Nevertheless, I didn't like adding another variable just for that either... :-) Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-09-24[PPP]: Fix output buffer size in ppp_decompress_frame().Konstantin Sharlaimov
This patch addresses the issue with "osize too small" errors in mppe encryption. The patch fixes the issue with wrong output buffer size being passed to ppp decompression routine. -------------------- As pointed out by Suresh Mahalingam, the issue addressed by ppp-fix-osize-too-small-errors-when-decoding patch is not fully resolved yet. The size of allocated output buffer is correct, however it size passed to ppp->rcomp->decompress in ppp_generic.c if wrong. The patch fixes that. -------------------- Signed-off-by: Konstantin Sharlaimov <konstantin.sharlaimov@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-09-24[PPP]: Fix osize too small errors when decoding mppe.Konstantin Sharlaimov
The mppe_decompress() function required a buffer that is 1 byte too small when receiving a message of mru size. This fixes buffer allocation to prevent this from occurring. Signed-off-by: Konstantin Sharlaimov <konstantin.sharlaimov@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-08-30[MATH-EMU]: Fix underflow exception reporting.David S. Miller
The underflow exception cases were wrong. This is one weird area of ieee1754 handling in that the underflow behavior changes based upon whether underflow is enabled in the trap enable mask of the FPU control register. As a specific case the Sparc V9 manual gives us the following description: -------------------- If UFM = 0: Underflow occurs if a nonzero result is tiny and a loss of accuracy occurs. Tininess may be detected before or after rounding. Loss of accuracy may be either a denormalization loss or an inexact result. If UFM = 1: Underflow occurs if a nonzero result is tiny. Tininess may be detected before or after rounding. -------------------- What this amounts to in the packing case is if we go subnormal, we set underflow if any of the following are true: 1) rounding sets inexact 2) we ended up rounding back up to normal (this is the case where we set the exponent to 1 and set the fraction to zero), this should set inexact too 3) underflow is set in FPU control register trap-enable mask The initially discovered example was "DBL_MIN / 16.0" which incorrectly generated an underflow. It should not, unless underflow is set in the trap-enable mask of the FPU csr. Another example, "0x0.0000000000001p-1022 / 16.0", should signal both inexact and underflow. The cpu implementations and ieee1754 literature is very clear about this. This is case #2 above. However, if underflow is set in the trap enable mask, only underflow should be set and reported as a trap. That is handled properly by the prioritization logic in arch/sparc{,64}/math-emu/math.c:record_exception(). Based upon a report and test case from Jakub Jelinek. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-08-30[SPARC32]: Fix rounding errors in ndelay/udelay implementation.Mark Fortescue
__ndelay and __udelay have not been delayung >= specified time. The problem with __ndelay has been tacked down to the rounding of the multiplier constant. By changing this, delays > app 18us are correctly calculated. The problem with __udelay has also been tracked down to rounding issues. Changing the multiplier constant (to match that used in sparc64) corrects for large delays and adding in a rounding constant corrects for trunctaion errors in the claculations. Many short delays will return without looping. This is not an error as there is the fixed delay of doing all the maths to calculate the loop count. Signed-off-by: Mark Fortescue <mark@mtfhpc.demon.co.uk> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-08-30[SPARC32]: Fix bug in sparc optimized memset.Alexander Shmelev
Sparc optimized memset (arch/sparc/lib/memset.S) does not fill last byte of the memory area, if area size is less than 8 bytes and start address is not word (4-bytes) aligned. Here is code chunk where bug located: /* %o0 - memory address, %o1 - size, %g3 - value */ 8: add %o0, 1, %o0 subcc %o1, 1, %o1 bne,a 8b stb %g3, [%o0 - 1] This code should write byte every loop iteration, but last time delay instruction stb is not executed because branch instruction sets "annul" bit. Patch replaces bne,a by bne instruction. Error can be reproduced by simple kernel module: -------------------- #include <linux/module.h> #include <linux/config.h> #include <linux/kernel.h> #include <linux/errno.h> #include <string.h> static void do_memset(void **p, int size) { memset(p, 0x00, size); } static int __init memset_test_init(void) { char fooc[8]; int *fooi; memset(fooc, 0xba, sizeof(fooc)); do_memset((void**)(fooc + 3), 1); fooi = (int*) fooc; printk("%08X %08X\n", fooi[0], fooi[1]); return -1; } static void __exit memset_test_cleanup(void) { return; } module_init(memset_test_init); module_exit(memset_test_cleanup); MODULE_LICENSE("GPL"); EXPORT_NO_SYMBOLS; -------------------- Signed-off-by: Alexander Shmelev <ashmelev@task.sun.mcst.ru> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-08-23md: avoid possible BUG_ON in md bitmap handlingNeil Brown
md/bitmap tracks how many active write requests are pending on blocks associated with each bit in the bitmap, so that it knows when it can clear the bit (when count hits zero). The counter has 14 bits of space, so if there are ever more than 16383, we cannot cope. Currently the code just calles BUG_ON as "all" drivers have request queue limits much smaller than this. However is seems that some don't. Apparently some multipath configurations can allow more than 16383 concurrent write requests. So, in this unlikely situation, instead of calling BUG_ON we now wait for the count to drop down a bit. This requires a new wait_queue_head, some waiting code, and a wakeup call. Tested by limiting the counter to 20 instead of 16383 (writes go a lot slower in that case...). Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-08-23md: fix a few problems with the interface (sysfs and ioctl) to mdNeil Brown
While developing more functionality in mdadm I found some bugs in md... - When we remove a device from an inactive array (write 'remove' to the 'state' sysfs file - see 'state_store') would should not update the superblock information - as we may not have read and processed it all properly yet. - initialise all raid_disk entries to '-1' else the 'slot sysfs file will claim '0' for all devices in an array before the array is started. - all '\n' not to be present at the end of words written to sysfs files - when we use SET_ARRAY_INFO to set the md metadata version, set the flag to say that there is persistant metadata. - allow GET_BITMAP_FILE to be called on an array that hasn't been started yet. Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-08-23md: assorted md and raid1 one-linersNeil Brown
Fix few bugs that meant that: - superblocks weren't alway written at exactly the right time (this could show up if the array was not written to - writting to the array causes lots of superblock updates and so hides these errors). - restarting device recovery after a clean shutdown (version-1 metadata only) didn't work as intended (or at all). 1/ Ensure superblock is updated when a new device is added. 2/ Remove an inappropriate test on MD_RECOVERY_SYNC in md_do_sync. The body of this if takes one of two branches depending on whether MD_RECOVERY_SYNC is set, so testing it in the clause of the if is wrong. 3/ Flag superblock for updating after a resync/recovery finishes. 4/ If we find the neeed to restart a recovery in the middle (version-1 metadata only) make sure a full recovery (not just as guided by bitmaps) does get done. Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-08-23md: allow SET_BITMAP_FILE to work on 64bit kernel with 32bit userspaceNeil Brown
.. so that you can use bitmaps with 32bit userspace on a 64 bit kernel. Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-08-23md: fix some small races in bitmap plugging in raid5Neil Brown
The comment gives more details, but I didn't quite have the sequencing write, so there was room for races to leave bits unset in the on-disk bitmap for short periods of time. Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-08-23md: fix a plug/unplug race in raid5Neil Brown
When a device is unplugged, requests are moved from one or two (depending on whether a bitmap is in use) queues to the main request queue. So whenever requests are put on either of those queues, we should make sure the raid5 array is 'plugged'. However we don't. We currently plug the raid5 queue just before putting requests on queues, so there is room for a race. If something unplugs the queue at just the wrong time, requests will be left on the queue and nothing will want to unplug them. Normally something else will plug and unplug the queue fairly soon, but there is a risk that nothing will. Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Adrian Bunk <bunk@kernel.org>
generated by cgit v1.2.3 (git 2.0.4) at 2025-06-10 21:21:32 +0000