summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* microblaze: Defconfig updateMichal Simek2010-05-062-13/+84
| | | | Signed-off-by: Michal Simek <monstr@monstr.eu>
* microblaze: Optimize CACHE_LOOP_LIMITS and CACHE_RANGE_LOOP macrosMichal Simek2010-05-061-27/+35
| | | | | | | | | | | | | | | | | | | | | | | 1. Remove CACHE_ALL_LOOP2 macro because it is identical to CACHE_ALL_LOOP 2. Change BUG_ON to WARN_ON 3. Remove end aligned from CACHE_LOOP_LIMITS. C implementation do not need aligned end address and ASM code do aligned in their macros 4. ASM optimized CACHE_RANGE_LOOP_1/2 macros needs to get aligned end address. Because end address is compound from start + size, end address is the first address which is exclude. Here is the corresponding code which describe it. + int align = ~(line_length - 1); + end = ((end & align) == end) ? end - line_length : end & align; a) end is aligned: it is necessary to subtruct line length because we don't want to work with next cacheline b) end address is not aligned: Just align it to be ready for ASM code. Signed-off-by: Michal Simek <monstr@monstr.eu>
* microblaze: Fix consistent-sync codeMichal Simek2010-05-061-1/+1
| | | | | | PCI_DMA_FROMDEVICE should call invalidation not flushing. Signed-off-by: Michal Simek <monstr@monstr.eu>
* microblaze: Define correct L1_CACHE_SHIFT valueMichal Simek2010-05-061-1/+1
| | | | | | | | | | | | | Microblaze cacheline length is configurable and current cpu uses two cacheline length 4 and 8. We are taking conservative maximum value to be sure that cacheline alignment is satisfied for all cases. Here is the calculation for cacheline lenght 8 32bit=4Byte values which is corresponding with SHIFT 5. Signed-off-by: Michal Simek <monstr@monstr.eu>
* microblaze: cpuinfo shows cache line lengthMichal Simek2010-05-061-4/+6
| | | | | | Show cache line length in /proc/cpuinfo. Signed-off-by: Michal Simek <monstr@monstr.eu>
* microblaze: Fix kmalloc alignment on non-coherent DMA platformsMichal Simek2010-05-061-0/+3
| | | | | | | | | | | | Based on PowerPC patche 52142e756e9bf6485d3d53596e8aff2e816a7253 PowerPC description: On platforms doing non-coherent DMA (4xx, 8xx, ...), it's important that the kmalloc minimum alignment is set to the cache line size, to avoid sharing cache lines between different objects, so that DMA to one of the objects doesn't corrupt the other. Signed-off-by: Michal Simek <monstr@monstr.eu>
* microblaze: Fix typo fault in cache codeMichal Simek2010-05-061-5/+5
| | | | | | Copy & paste error. Signed-off-by: Michal Simek <monstr@monstr.eu>
* microblaze: Fix consistent codeMichal Simek2010-05-063-92/+100
| | | | | | | | | | | | This patch fix consistent code which had problems with consistent_free function. I am not sure if we need to call flush_tlb_all after it but it keeps tlbs synced. I added noMMU and MMU version together. Uncached shadow feature is not tested. Signed-off-by: Michal Simek <monstr@monstr.eu>
* microblaze: pci-dma: use include/linux/dma-mapping.hMichal Simek2010-05-061-8/+0
| | | | | | | Based on af407c6db16aa9ca63559076dbe620220a822580 and f41b177157718abe9a93868bb76e47d4a6f3681d Signed-off-by: Michal Simek <monstr@monstr.eu>
* microblaze: page.h: Remove get_user_page and free_user_pageMichal Simek2010-05-061-5/+0
| | | | | | Remove ancient macros which are here from Linux-2.4 Signed-off-by: Michal Simek <monstr@monstr.eu>
* microblaze: Remove "cache" optimized copy_page functionMichal Simek2010-05-063-39/+2
| | | | | | | | | | | Current implementation doesn't handle dcache_line_length correctly that's why is better to use generic memcpy. Cache optimized function could be good way howto improve performance but must be based on benchmarking not blind function like this. Signed-off-by: Michal Simek <monstr@monstr.eu>
* microblaze: invoke oom-killer from page faultNick Piggin2010-05-061-9/+4
| | | | | | | | | | | | | As explained in commit 1c0fe6e3bd, we want to call the architecture independent oom killer when getting an unexplained OOM from handle_mm_fault, rather than simply killing current. Cc: microblaze-uclinux@itee.uq.edu.au Cc: Michal Simek <monstr@monstr.eu> Cc: linux-arch@vger.kernel.org Signed-off-by: Nick Piggin <npiggin@suse.de> Acked-by: David Rientjes <rientjes@google.com> Acked-by: Michal Simek <monstr@monstr.eu>
* microblaze: fix divide by zero exception messageRandy Dunlap2010-05-061-1/+1
| | | | | | | | | Fix divide exception message to say "divide by zero". Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Michal Simek <monstr@monstr.eu> Cc: microblaze-uclinux@itee.uq.edu.au Signed-off-by: Michal Simek <monstr@monstr.eu>
* microblaze: Add isa_dma_bridge_buggy to dma.hMichal Simek2010-05-061-0/+6
| | | | | | It is necessary for several drivers. Signed-off-by: Michal Simek <monstr@monstr.eu>
* microblaze: Remove ancient codeMichal Simek2010-05-065-111/+0
| | | | | | I found several function which we don't use that's why I am removing them. Signed-off-by: Michal Simek <monstr@monstr.eu>
* microblaze: Quiet section mismatch warnings for MMU versionMichal Simek2010-05-062-15/+16
| | | | | | | | | | | | | Remove section mismatch - based on ppc aproach. WARNING: vmlinux.o(.text+0x64834): Section mismatch in reference from the function __pte_alloc_kernel() to the function .init.text:early_get_page() The function __pte_alloc_kernel() references the function __init early_get_page(). This is often because __pte_alloc_kernel lacks a __init annotation or the annotation of early_get_page is wrong. Signed-off-by: Michal Simek <monstr@monstr.eu>
* microblaze: Quiet section mismatch warningsSteven J. Magnani2010-05-062-2/+4
| | | | | | | | _start is located in .text, which causes mismatch warnings with machine_early_init() and start_kernel() in .init.text. Signed-off-by: Steven J. Magnani <steve@digidescorp.com> Signed-off-by: Michal Simek <monstr@monstr.eu>
* microblaze: Fix IRQ entry/exit ftracingSteven J. Magnani2010-05-061-1/+2
| | | | | | | | | | | | | | | | | Function traces on Microblaze don't include IRQ entry and exit arrows, i.e. 0) | memcpy_toiovec() { 0) ==========> | 0) | do_IRQ() { ... 0) <========== | 0) ! 5414.000 us | } ...because do_IRQ() doesn't have the proper attributes. Signed-off-by: Steven J. Magnani <steve@digidescorp.com> Signed-off-by: Michal Simek <monstr@monstr.eu>
* microblaze: resource/PCI: align functions now return start of resourceMichal Simek2010-05-061-7/+6
| | | | | | | | | | | | | | This change should be part of b26b2d494b659f988b4d75eb394dfa0ddac415c9 Origin description: resource/PCI: align functions now return start of resource As suggested by Linus, align functions should return the start of a resource, not void. An update of "res->start" is no longer necessary. Signed-off-by: Michal Simek <monstr@monstr.eu>
* microblaze: PCI: add pci_bus_for_each_resource(), remove direct ↵Michal Simek2010-05-061-2/+2
| | | | | | | | | | | | | | | | | | | bus->resource[] refs This change should be part of 89a74ecccd1f78e51faf6287e5c0e93a92ac096e Origin description: PCI: add pci_bus_for_each_resource(), remove direct bus->resource[] refs No functional change; this converts loops that iterate from 0 to PCI_BUS_NUM_RESOURCES through pci_bus resource[] table to use the pci_bus_for_each_resource() iterator instead. This doesn't change the way resources are stored; it merely removes dependencies on the fact that they're in a table. Signed-off-by: Michal Simek <monstr@monstr.eu>
* Merge branch 'zerolen' of ↵Linus Torvalds2010-05-052-0/+0
|\ | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6 * 'zerolen' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6: [MTD] Remove zero-length files mtdbdi.c and internal.ho
| * [MTD] Remove zero-length files mtdbdi.c and internal.hoJeff Garzik2010-05-052-0/+0
| | | | | | | | | | | | Both were "removed" in commit a33eb6b91034c95b9b08576f68be170f995b2c7d. Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
* | Merge branch 'upstream-linus' of ↵Linus Torvalds2010-05-053-37/+20
|\ \ | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev * 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev: pata_pcmcia / ide-cs: Fix bad hashes for Transcend and kingston IDs libata: Fix several inaccuracies in developer's guide
| * | pata_pcmcia / ide-cs: Fix bad hashes for Transcend and kingston IDsKristoffer Ericson2010-05-052-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | This patch fixes the bad hashes for one Kingston and one Transcend card. Thanks to komuro for pointing this out. Signed-off-by: Kristoffer Ericson <kristoffer.ericson@gmail.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
| * | libata: Fix several inaccuracies in developer's guideSergei Shtylyov2010-05-051-33/+16
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 6bfff31e77cfa1b13490337e5a4dbaa3407e83ac (libata: kill probe_ent and related helpers) killed ata_device_add() but didn't remove references to it from the libata developer's guide. Commits 9363c3825ea9ad76561eb48a395349dd29211ed6 (libata: rename SFF functions) and 5682ed33aae05d10a25c95633ef9d9c062825888 (libata: rename SFF port ops) renamed the taskfile access methods but didn't update the developer's guide. Commit c9f75b04ed5ed65a058d18a8a8dda50632a96de8 (libata: kill ata_noop_dev_select()) didn't update the developer's guide as well. The guide also refers to the long gone ata_pio_data_xfer_noirq(), ata_pio_data_xfer(), and ata_mmio_data_xfer() -- replace those by the modern ata_sff_data_xfer_noirq(), ata_sff_data_xfer(), and ata_sff_data_xfer32(). Also, remove the reference to non-existant ata_port_stop()... Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
* | Merge branch 'slab-for-linus' of ↵Linus Torvalds2010-05-051-1/+1
|\ \ | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6 * 'slab-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6: slub: Fix bad boundary check in init_kmem_cache_nodes()
| * | slub: Fix bad boundary check in init_kmem_cache_nodes()Zhang, Yanmin2010-05-051-1/+1
| |/ | | | | | | | | | | | | | | | | Function init_kmem_cache_nodes is incorrect when checking upper limitation of kmalloc_caches. The breakage was introduced by commit 91efd773c74bb26b5409c85ad755d536448e229c ("dma kmalloc handling fixes"). Acked-by: Christoph Lameter <cl@linux-foundation.org> Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
* | Merge branch 'for-linus' of ↵Linus Torvalds2010-05-052-20/+23
|\ \ | |/ |/| | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6: KEYS: call_sbin_request_key() must write lock keyrings before modifying them KEYS: Use RCU dereference wrappers in keyring key type code KEYS: find_keyring_by_name() can gain access to a freed keyring
| * KEYS: call_sbin_request_key() must write lock keyrings before modifying themDavid Howells2010-05-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | call_sbin_request_key() creates a keyring and then attempts to insert a link to the authorisation key into that keyring, but does so without holding a write lock on the keyring semaphore. It will normally get away with this because it hasn't told anyone that the keyring exists yet. The new keyring, however, has had its serial number published, which means it can be accessed directly by that handle. This was found by a previous patch that adds RCU lockdep checks to the code that reads the keyring payload pointer, which includes a check that the keyring semaphore is actually locked. Without this patch, the following command: keyctl request2 user b a @s will provoke the following lockdep warning is displayed in dmesg: =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- security/keys/keyring.c:727 invoked rcu_dereference_check() without protection! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 2 locks held by keyctl/2076: #0: (key_types_sem){.+.+.+}, at: [<ffffffff811a5b29>] key_type_lookup+0x1c/0x71 #1: (keyring_serialise_link_sem){+.+.+.}, at: [<ffffffff811a6d1e>] __key_link+0x4d/0x3c5 stack backtrace: Pid: 2076, comm: keyctl Not tainted 2.6.34-rc6-cachefs #54 Call Trace: [<ffffffff81051fdc>] lockdep_rcu_dereference+0xaa/0xb2 [<ffffffff811a6d1e>] ? __key_link+0x4d/0x3c5 [<ffffffff811a6e6f>] __key_link+0x19e/0x3c5 [<ffffffff811a5952>] ? __key_instantiate_and_link+0xb1/0xdc [<ffffffff811a59bf>] ? key_instantiate_and_link+0x42/0x5f [<ffffffff811aa0dc>] call_sbin_request_key+0xe7/0x33b [<ffffffff8139376a>] ? mutex_unlock+0x9/0xb [<ffffffff811a5952>] ? __key_instantiate_and_link+0xb1/0xdc [<ffffffff811a59bf>] ? key_instantiate_and_link+0x42/0x5f [<ffffffff811aa6fa>] ? request_key_auth_new+0x1c2/0x23c [<ffffffff810aaf15>] ? cache_alloc_debugcheck_after+0x108/0x173 [<ffffffff811a9d00>] ? request_key_and_link+0x146/0x300 [<ffffffff810ac568>] ? kmem_cache_alloc+0xe1/0x118 [<ffffffff811a9e45>] request_key_and_link+0x28b/0x300 [<ffffffff811a89ac>] sys_request_key+0xf7/0x14a [<ffffffff81052c0b>] ? trace_hardirqs_on_caller+0x10c/0x130 [<ffffffff81394fb9>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff81001eeb>] system_call_fastpath+0x16/0x1b Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: James Morris <jmorris@namei.org>
| * KEYS: Use RCU dereference wrappers in keyring key type codeDavid Howells2010-05-051-10/+13
| | | | | | | | | | | | | | | | | | | | The keyring key type code should use RCU dereference wrappers, even when it holds the keyring's key semaphore. Reported-by: Vegard Nossum <vegard.nossum@gmail.com> Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Serge Hallyn <serue@us.ibm.com> Signed-off-by: James Morris <jmorris@namei.org>
| * KEYS: find_keyring_by_name() can gain access to a freed keyringToshiyuki Okajima2010-05-051-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | find_keyring_by_name() can gain access to a keyring that has had its reference count reduced to zero, and is thus ready to be freed. This then allows the dead keyring to be brought back into use whilst it is being destroyed. The following timeline illustrates the process: |(cleaner) (user) | | free_user(user) sys_keyctl() | | | | key_put(user->session_keyring) keyctl_get_keyring_ID() | || //=> keyring->usage = 0 | | |schedule_work(&key_cleanup_task) lookup_user_key() | || | | kmem_cache_free(,user) | | . |[KEY_SPEC_USER_KEYRING] | . install_user_keyrings() | . || | key_cleanup() [<= worker_thread()] || | | || | [spin_lock(&key_serial_lock)] |[mutex_lock(&key_user_keyr..mutex)] | | || | atomic_read() == 0 || | |{ rb_ease(&key->serial_node,) } || | | || | [spin_unlock(&key_serial_lock)] |find_keyring_by_name() | | ||| | keyring_destroy(keyring) ||[read_lock(&keyring_name_lock)] | || ||| | |[write_lock(&keyring_name_lock)] ||atomic_inc(&keyring->usage) | |. ||| *** GET freeing keyring *** | |. ||[read_unlock(&keyring_name_lock)] | || || | |list_del() |[mutex_unlock(&key_user_k..mutex)] | || | | |[write_unlock(&keyring_name_lock)] ** INVALID keyring is returned ** | | . | kmem_cache_free(,keyring) . | . | atomic_dec(&keyring->usage) v *** DESTROYED *** TIME If CONFIG_SLUB_DEBUG=y then we may see the following message generated: ============================================================================= BUG key_jar: Poison overwritten ----------------------------------------------------------------------------- INFO: 0xffff880197a7e200-0xffff880197a7e200. First byte 0x6a instead of 0x6b INFO: Allocated in key_alloc+0x10b/0x35f age=25 cpu=1 pid=5086 INFO: Freed in key_cleanup+0xd0/0xd5 age=12 cpu=1 pid=10 INFO: Slab 0xffffea000592cb90 objects=16 used=2 fp=0xffff880197a7e200 flags=0x200000000000c3 INFO: Object 0xffff880197a7e200 @offset=512 fp=0xffff880197a7e300 Bytes b4 0xffff880197a7e1f0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ Object 0xffff880197a7e200: 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b jkkkkkkkkkkkkkkk Alternatively, we may see a system panic happen, such as: BUG: unable to handle kernel NULL pointer dereference at 0000000000000001 IP: [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9 PGD 6b2b4067 PUD 6a80d067 PMD 0 Oops: 0000 [#1] SMP last sysfs file: /sys/kernel/kexec_crash_loaded CPU 1 ... Pid: 31245, comm: su Not tainted 2.6.34-rc5-nofixed-nodebug #2 D2089/PRIMERGY RIP: 0010:[<ffffffff810e61a3>] [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9 RSP: 0018:ffff88006af3bd98 EFLAGS: 00010002 RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88007d19900b RDX: 0000000100000000 RSI: 00000000000080d0 RDI: ffffffff81828430 RBP: ffffffff81828430 R08: ffff88000a293750 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000100000 R12: 00000000000080d0 R13: 00000000000080d0 R14: 0000000000000296 R15: ffffffff810f20ce FS: 00007f97116bc700(0000) GS:ffff88000a280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000001 CR3: 000000006a91c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process su (pid: 31245, threadinfo ffff88006af3a000, task ffff8800374414c0) Stack: 0000000512e0958e 0000000000008000 ffff880037f8d180 0000000000000001 0000000000000000 0000000000008001 ffff88007d199000 ffffffff810f20ce 0000000000008000 ffff88006af3be48 0000000000000024 ffffffff810face3 Call Trace: [<ffffffff810f20ce>] ? get_empty_filp+0x70/0x12f [<ffffffff810face3>] ? do_filp_open+0x145/0x590 [<ffffffff810ce208>] ? tlb_finish_mmu+0x2a/0x33 [<ffffffff810ce43c>] ? unmap_region+0xd3/0xe2 [<ffffffff810e4393>] ? virt_to_head_page+0x9/0x2d [<ffffffff81103916>] ? alloc_fd+0x69/0x10e [<ffffffff810ef4ed>] ? do_sys_open+0x56/0xfc [<ffffffff81008a02>] ? system_call_fastpath+0x16/0x1b Code: 0f 1f 44 00 00 49 89 c6 fa 66 0f 1f 44 00 00 65 4c 8b 04 25 60 e8 00 00 48 8b 45 00 49 01 c0 49 8b 18 48 85 db 74 0d 48 63 45 18 <48> 8b 04 03 49 89 00 eb 14 4c 89 f9 83 ca ff 44 89 e6 48 89 ef RIP [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9 This problem is that find_keyring_by_name does not confirm that the keyring is valid before accepting it. Skipping keyrings that have been reduced to a zero count seems the way to go. To this end, use atomic_inc_not_zero() to increment the usage count and skip the candidate keyring if that returns false. The following script _may_ cause the bug to happen, but there's no guarantee as the window of opportunity is small: #!/bin/sh LOOP=100000 USER=dummy_user /bin/su -c "exit;" $USER || { /usr/sbin/adduser -m $USER; add=1; } for ((i=0; i<LOOP; i++)) do /bin/su -c "echo '$i' > /dev/null" $USER done (( add == 1 )) && /usr/sbin/userdel -r $USER exit Note that the nominated user must not be in use. An alternative way of testing this may be: for ((i=0; i<100000; i++)) do keyctl session foo /bin/true || break done >&/dev/null as that uses a keyring named "foo" rather than relying on the user and user-session named keyrings. Reported-by: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com> Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com> Acked-by: Serge Hallyn <serue@us.ibm.com> Signed-off-by: James Morris <jmorris@namei.org>
* | Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wqLinus Torvalds2010-05-051-1/+1
|\ \ | | | | | | | | | | | | * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: workqueue: flush_delayed_work: keep the original workqueue for re-queueing
| * | workqueue: flush_delayed_work: keep the original workqueue for re-queueingOleg Nesterov2010-04-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | flush_delayed_work() always uses keventd_wq for re-queueing, but it should use the workqueue this dwork was queued on. Signed-off-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Tejun Heo <tj@kernel.org>
* | | Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6Linus Torvalds2010-05-0517-67/+256
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: FEC: Fix kernel panic in fec_set_mac_address. ipv6: Fix default multicast hops setting. net: ep93xx_eth stops receiving packets drivers/net/phy: micrel phy driver dm9601: fix phy/eeprom write routine ppp_generic: handle non-linear skbs when passing them to pppd ppp_generic: pull 2 bytes so that PPP_PROTO(skb) is valid net: fix compile error due to double return type in SOCK_DEBUG net/usb: initiate sync sequence in sierra_net.c driver net/usb: remove default in Kconfig for sierra_net driver r8169: Fix rtl8169_rx_interrupt() e1000e: Fix oops caused by ASPM patch. net/sb1250: register mdio bus in probe sctp: Fix skb_over_panic resulting from multiple invalid parameter errors (CVE-2010-1173) (v4) p54pci: fix bugs in p54p_check_tx_ring
| * | | FEC: Fix kernel panic in fec_set_mac_address.Mattias Walström2010-05-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix memory corruption that sometimes result in kernel panic. Signed-off-by: Mattias Walström <mattias@vmlinux.org> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | ipv6: Fix default multicast hops setting.David S. Miller2010-05-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As per RFC 3493 the default multicast hops setting for a socket should be "1" just like ipv4. Ironically we have a IPV6_DEFAULT_MCASTHOPS macro it just wasn't being used. Reported-by: Elliot Hughes <enh@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | net: ep93xx_eth stops receiving packetsDavid S. Miller2010-05-031-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Receiving small packet(s) in a fast pace leads to not receiving any packets at all after some time. After ethernet packet(s) arrived the receive descriptor is incremented by the number of frames processed. If another packet arrives while processing, this is processed in another call of ep93xx_rx. This second call leads that too many receive descriptors getting released. This fix increments, even in these case, the right number of processed receive descriptors. Signed-off-by: Stefan Agner <stefan@agner.ch> Acked-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | drivers/net/phy: micrel phy driverDavid J. Choi2010-05-033-0/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the first version of phy driver from Micrel Inc. Signed-off-by: David J. Choi <david.choi@micrel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | dm9601: fix phy/eeprom write routinePeter Korsgaard2010-05-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use correct bit positions in DM_SHARED_CTRL register for writes. Michael Planes recently encountered a 'KY-RS9600 USB-LAN converter', which came with a driver CD containing a Linux driver. This driver turns out to be a copy of dm9601.c with symbols renamed and my copyright stripped. That aside, it did contain 1 functional change in dm_write_shared_word(), and after checking the datasheet the original value was indeed wrong (read versus write bits). On Michaels HW, this change bumps receive speed from ~30KB/s to ~900KB/s. On other devices the difference is less spectacular, but still significant (~30%). Reported-by: Michael Planes <michael.planes@free.fr> CC: stable@kernel.org Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | ppp_generic: handle non-linear skbs when passing them to pppdSimon Arlott2010-05-031-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Frequently when using PPPoE with an interface MTU greater than 1500, the skb is likely to be non-linear. If the skb needs to be passed to pppd then the skb data must be read correctly. The previous commit fixes an issue with accidentally sending skbs to pppd based on an invalid read of the protocol type. When that error occurred pppd was reading invalid skb data too. Signed-off-by: Simon Arlott <simon@fire.lp0.eu> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | ppp_generic: pull 2 bytes so that PPP_PROTO(skb) is validSimon Arlott2010-05-031-11/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In ppp_input(), PPP_PROTO(skb) may refer to invalid data in the skb. If this happens and (proto >= 0xc000 || proto == PPP_CCPFRAG) then the packet is passed directly to pppd. This occurs frequently when using PPPoE with an interface MTU greater than 1500 because the skb is more likely to be non-linear. The next 2 bytes need to be pulled in ppp_input(). The pull of 2 bytes in ppp_receive_frame() has been removed as it is no longer required. Signed-off-by: Simon Arlott <simon@fire.lp0.eu> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | net: fix compile error due to double return type in SOCK_DEBUGJan Engelhardt2010-05-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix this one: include/net/sock.h: error: two or more data types in declaration specifiers Signed-off-by: Jan Engelhardt <jengelh@medozas.de> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | net/usb: initiate sync sequence in sierra_net.c driverElina Pasheva2010-05-011-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following patch adds the initiation of the sync sequence to "sierra_net_bind()". If this step is omitted, the modem will never sync up with the host and it will not be possible to establish a data connection. Signed-off-by: Elina Pasheva <epasheva@sierrawireless.com> Signed-off-by: Rory Filer <rfiler@sierrawireless.com> Tested-by: Elina Pasheva <epasheva@sierrawireless.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | net/usb: remove default in Kconfig for sierra_net driverElina Pasheva2010-04-301-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following patch removes the default from the Kconfig entry for sierra_net driver as recommended. Signed-off-by: Elina Pasheva <epasheva@sierrawireless.com> Signed-off-by: Rory Filer <rfiler@sierrawireless.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | r8169: Fix rtl8169_rx_interrupt()Eric Dumazet2010-04-301-5/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In case a reset is performed, rtl8169_rx_interrupt() is called from process context instead of softirq context. Special care must be taken to call appropriate network core services (netif_rx() instead of netif_receive_skb()). VLAN handling also corrected. Reported-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Tested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Diagnosed-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | Merge branch 'master' of ↵David S. Miller2010-04-301-1/+1
| |\ \ \ | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
| | * | | p54pci: fix bugs in p54p_check_tx_ringHans de Goede2010-04-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hans de Goede identified a bug in p54p_check_tx_ring: there are two ring indices. 1 => tx data and 3 => tx management. But the old code had a constant "1" and this resulted in spurious dma unmapping failures. Cc: stable@kernel.org Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=583623 Bug-Identified-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | | e1000e: Fix oops caused by ASPM patch.Anton Blanchard2010-04-301-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 6f461f6c7c961f0b1b73c0f27becf472a0ac606b ("e1000e: enable/disable ASPM L0s and L1 and ERT according to hardware errata") oopses on one of my ppc64 boxes with a NULL pointer (0x4a): Unable to handle kernel paging request for data at address 0x0000004a Faulting instruction address: 0xc0000000004d2f1c cpu 0xe: Vector: 300 (Data Access) at [c000000bec1833a0] pc: c0000000004d2f1c: .e1000e_disable_aspm+0xe0/0x150 lr: c0000000004d2f0c: .e1000e_disable_aspm+0xd0/0x150 dar: 4a [c000000bec1836d0] c00000000069b9d8 .e1000_probe+0x84/0xe8c [c000000bec1837b0] c000000000386d90 .local_pci_probe+0x4c/0x68 [c000000bec183840] c0000000003872ac .pci_device_probe+0xfc/0x148 [c000000bec183900] c000000000409e8c .driver_probe_device+0xe4/0x1d0 [c000000bec1839a0] c00000000040a024 .__driver_attach+0xac/0xf4 [c000000bec183a40] c000000000409124 .bus_for_each_dev+0x9c/0x10c [c000000bec183b00] c000000000409c1c .driver_attach+0x40/0x60 [c000000bec183b90] c0000000004085dc .bus_add_driver+0x150/0x328 [c000000bec183c40] c00000000040a58c .driver_register+0x100/0x1c4 [c000000bec183cf0] c00000000038764c .__pci_register_driver+0x78/0x128 Seems like pdev->bus->self == NULL. I haven't touched pci in a long time so I'm trying to remember what this means (no pcie bridge perhaps?) The patch below fixes the oops for me. Signed-off-by: Anton Blanchard <anton@samba.org> Reviewed-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | | net/sb1250: register mdio bus in probeSebastian Siewior2010-04-281-34/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "ifconfig eth0 up && ifconfig eth0 down" triggers: | kobject (a8000000cfa5a480): tried to init an initialized object, something is seriously wrong. | Call Trace: | [<ffffffff8010aabc>] dump_stack+0x8/0x34 | [<ffffffff80293128>] kobject_init+0xe8/0xf0 | [<ffffffff802d922c>] device_initialize+0x2c/0x98 | [<ffffffff802d9cfc>] device_register+0x14/0x28 | [<ffffffff80312cd4>] mdiobus_register+0xdc/0x1e0 | [<ffffffff80314cf0>] sbmac_open+0x58/0x220 | [<ffffffff803519bc>] __dev_open+0x11c/0x180 | [<ffffffff8034d578>] __dev_change_flags+0x120/0x180 | [<ffffffff80351848>] dev_change_flags+0x20/0x78 | [<ffffffff803a753c>] devinet_ioctl+0x7cc/0x820 | [<ffffffff80339ac8>] sock_do_ioctl+0x38/0x90 | [<ffffffff8033a258>] compat_sock_ioctl_trans+0x408/0x1030 | [<ffffffff8033af30>] compat_sock_ioctl+0xb0/0xd0 | [<ffffffff80208b08>] compat_sys_ioctl+0xa0/0x18b8 | [<ffffffff80102f94>] handle_sys+0x114/0x130 | | sb1250-mac-mdio: probed mdiobus_register() calls device_register() which initializes the kobj of the device. mdiobus_unregister() calls only device_del() so we have one reference left. That one is leaving with mdiobus_free() which is only called on remove. Since I don't see any reason why mdiobus_register()/mdiobus_unregister() should happen in ->open()/->close() I move them to probe & exit. Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | | sctp: Fix skb_over_panic resulting from multiple invalid parameter errors ↵Neil Horman2010-04-282-5/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (CVE-2010-1173) (v4) Ok, version 4 Change Notes: 1) Minor cleanups, from Vlads notes Summary: Hey- Recently, it was reported to me that the kernel could oops in the following way: <5> kernel BUG at net/core/skbuff.c:91! <5> invalid operand: 0000 [#1] <5> Modules linked in: sctp netconsole nls_utf8 autofs4 sunrpc iptable_filter ip_tables cpufreq_powersave parport_pc lp parport vmblock(U) vsock(U) vmci(U) vmxnet(U) vmmemctl(U) vmhgfs(U) acpiphp dm_mirror dm_mod button battery ac md5 ipv6 uhci_hcd ehci_hcd snd_ens1371 snd_rawmidi snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_ac97_codec snd soundcore pcnet32 mii floppy ext3 jbd ata_piix libata mptscsih mptsas mptspi mptscsi mptbase sd_mod scsi_mod <5> CPU: 0 <5> EIP: 0060:[<c02bff27>] Not tainted VLI <5> EFLAGS: 00010216 (2.6.9-89.0.25.EL) <5> EIP is at skb_over_panic+0x1f/0x2d <5> eax: 0000002c ebx: c033f461 ecx: c0357d96 edx: c040fd44 <5> esi: c033f461 edi: df653280 ebp: 00000000 esp: c040fd40 <5> ds: 007b es: 007b ss: 0068 <5> Process swapper (pid: 0, threadinfo=c040f000 task=c0370be0) <5> Stack: c0357d96 e0c29478 00000084 00000004 c033f461 df653280 d7883180 e0c2947d <5> 00000000 00000080 df653490 00000004 de4f1ac0 de4f1ac0 00000004 df653490 <5> 00000001 e0c2877a 08000800 de4f1ac0 df653490 00000000 e0c29d2e 00000004 <5> Call Trace: <5> [<e0c29478>] sctp_addto_chunk+0xb0/0x128 [sctp] <5> [<e0c2947d>] sctp_addto_chunk+0xb5/0x128 [sctp] <5> [<e0c2877a>] sctp_init_cause+0x3f/0x47 [sctp] <5> [<e0c29d2e>] sctp_process_unk_param+0xac/0xb8 [sctp] <5> [<e0c29e90>] sctp_verify_init+0xcc/0x134 [sctp] <5> [<e0c20322>] sctp_sf_do_5_1B_init+0x83/0x28e [sctp] <5> [<e0c25333>] sctp_do_sm+0x41/0x77 [sctp] <5> [<c01555a4>] cache_grow+0x140/0x233 <5> [<e0c26ba1>] sctp_endpoint_bh_rcv+0xc5/0x108 [sctp] <5> [<e0c2b863>] sctp_inq_push+0xe/0x10 [sctp] <5> [<e0c34600>] sctp_rcv+0x454/0x509 [sctp] <5> [<e084e017>] ipt_hook+0x17/0x1c [iptable_filter] <5> [<c02d005e>] nf_iterate+0x40/0x81 <5> [<c02e0bb9>] ip_local_deliver_finish+0x0/0x151 <5> [<c02e0c7f>] ip_local_deliver_finish+0xc6/0x151 <5> [<c02d0362>] nf_hook_slow+0x83/0xb5 <5> [<c02e0bb2>] ip_local_deliver+0x1a2/0x1a9 <5> [<c02e0bb9>] ip_local_deliver_finish+0x0/0x151 <5> [<c02e103e>] ip_rcv+0x334/0x3b4 <5> [<c02c66fd>] netif_receive_skb+0x320/0x35b <5> [<e0a0928b>] init_stall_timer+0x67/0x6a [uhci_hcd] <5> [<c02c67a4>] process_backlog+0x6c/0xd9 <5> [<c02c690f>] net_rx_action+0xfe/0x1f8 <5> [<c012a7b1>] __do_softirq+0x35/0x79 <5> [<c0107efb>] handle_IRQ_event+0x0/0x4f <5> [<c01094de>] do_softirq+0x46/0x4d Its an skb_over_panic BUG halt that results from processing an init chunk in which too many of its variable length parameters are in some way malformed. The problem is in sctp_process_unk_param: if (NULL == *errp) *errp = sctp_make_op_error_space(asoc, chunk, ntohs(chunk->chunk_hdr->length)); if (*errp) { sctp_init_cause(*errp, SCTP_ERROR_UNKNOWN_PARAM, WORD_ROUND(ntohs(param.p->length))); sctp_addto_chunk(*errp, WORD_ROUND(ntohs(param.p->length)), param.v); When we allocate an error chunk, we assume that the worst case scenario requires that we have chunk_hdr->length data allocated, which would be correct nominally, given that we call sctp_addto_chunk for the violating parameter. Unfortunately, we also, in sctp_init_cause insert a sctp_errhdr_t structure into the error chunk, so the worst case situation in which all parameters are in violation requires chunk_hdr->length+(sizeof(sctp_errhdr_t)*param_count) bytes of data. The result of this error is that a deliberately malformed packet sent to a listening host can cause a remote DOS, described in CVE-2010-1173: http://cve.mitre.org/cgi-bin/cvename.cgi?name=2010-1173 I've tested the below fix and confirmed that it fixes the issue. We move to a strategy whereby we allocate a fixed size error chunk and ignore errors we don't have space to report. Tested by me successfully Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
OpenPOWER on IntegriCloud