- 24 Dec, 2011 21 commits
-
-
Greg Ungerer authored
The merge of m68knommu left the linker scripts a little disorganized. Some consistent naming and squashing two of scripts that just include others can simplify things a lot. So merge the two simple including scripts, and rename the nommu script to be consistent with the existing m68k linker scripts. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
The code that used the anchor.h include file has long been removed from the kernel. Remove it too. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
There is a race on reading the ColdFire slice timer current count and the total clock count so far. Interrupts are off, and we may have just missed getting a new timer wrap event interrupt. Check for this and adjust the cycle count and current read count accordingly. Also the slice timer counts down from the terminal count. So in read_clk() we need take the current clock count away from the terminal count. Reported-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
Disbale the CPU cache really early in the ColdFire startup code. We set up some variables for RAM sizing and we want to make they stick in RAM. Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
The traditional 68000 processors and the newer reduced instruction set ColdFire processors do not support the 32*32->64 multiply or the 64/32->32 divide instructions. This is not a difference based on the presence of a hardware MMU or not. Create a new config symbol to mark that a CPU type doesn't support the longer multiply/divide instructions. Use this then as a basis for using the fast 64bit based divide (in div64.h) and for linking in the extra libgcc functions that may be required (mulsi3, divsi3, etc). Signed-off-by: Greg Ungerer <gerg@uclinux.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
-
Greg Ungerer authored
We have two implementations of the IP checksuming code for the m68k arch. One uses the more advanced instructions available in 68020 and above processors, the other uses the simpler instructions available on the original 68000 processors and the modern ColdFire processors. This simpler code is pretty much the same as the generic lib implementation of the IP csum functions. So lets just switch over to using that. That means we can completely remove the checksum_no.c file, and only have the local fast code used for the more complex 68k CPU family members. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
There is no reason we can't make the saved fp registers the same for all m68k types and ColdFire. There is a little wasted space, but the code consistency and cleanliness is a big win. sigcontext.h is an exported header, but currently there is no in-mainline users of the !__uClinux__ and __mcoldfire__ case that this change effects. Even better this change actually makes this structure consistent with the out-of-mainline ColdFire/MMU code. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
-
Greg Ungerer authored
Commit 61619b12 ("m68k: merge mmu and non-mmu include/asm/entry.h files") made the trap entry code basically the same for mmu and non-mmu builds. This means we no longer need code to mark the stack frame as "system-call" type or other in the non-mmu trap handling entry points. This is done in the SAVE_ALL_INT macro now. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
The non-MMU builds of m68k allow a fixed kernel boot command line to be configured at configure time. Allow this MMU builds as well. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
Output a table of the kernel memory regions at boot time. This is taken directly from the ARM architecture code that does this. The table looks like this: Virtual kernel memory layout: vector : 0x00000000 - 0x00000400 ( 0 KiB) kmap : 0xd0000000 - 0xe0000000 ( 256 MiB) vmalloc : 0xc0000000 - 0xcfffffff ( 255 MiB) lowmem : 0x00000000 - 0x02000000 ( 32 MiB) .init : 0x00128000 - 0x00134000 ( 48 KiB) .text : 0x00020000 - 0x00118d54 ( 996 KiB) .data : 0x00118d60 - 0x00126000 ( 53 KiB) .bss : 0x00134000 - 0x001413e0 ( 53 KiB) This has been very useful while debugging the ColdFire virtual memory support code. But in general I think it is nice to know extacly where the kernel has layed everything out on boot. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
The mach_gettod function pointer is only called from the time_no.c code. So move its actual definition to there too. It is currently in setup_no.c for no particularly good reason. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
The selection of the CONFIG_GENERIC_ATOMIC64 option is not specific to the MMU being present and enabled. It is a property of certain CPU families. So select it based on those CPU types being selected. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
Currently on m68k we have a comeplete thread_info structure stored inside of the thread_struct, and we also have it in the initial part of the kernel stack. Mostly the code currently uses the one inside of the thread_struct, only using the "task" pointer from the stack based one. This is wasteful and confusing, we should only have the single instance of thread_info inside the stack page. And this is the norm for all other architectures. This change makes m68k handle thread_info consistently on both MMU enabled and non-MMU setups. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
We have a duplicate name and definition for the offset of the thread.info struct within the task struct in our asm-offsets.c code. Remove one of them, and consolidate to use a single define, TASK_INFO. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
-
Greg Ungerer authored
The init_task code can be the same for both mmu and non-mmu targets. None of the alignment carried out in the the current init_task code is necessary. The linker script takes care of aligning the init_thread structure to a THREAD SIZE boundary, and that is all we need. So use the init_task.c code for all target types, that makes m68k code consistent with what most other architectures do. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
-
Greg Ungerer authored
The fasthandler code was removed long ago. Remove the now unused declaration of it. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Mark Brown authored
gpiolib provides __gpio_to_irq() to map gpiolib gpios to interrupts - hook that up on m68k. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
john stultz authored
Updated to merge the valid bits of the two m68k patches. This converts the m86k clocksources to use clocksource_register_hz/khz This is untested, so any assistance in testing would be appreciated! CC: Geert Uytterhoeven <geert@linux-m68k.org> CC: Greg Ungerer <gerg@uclinux.org> Signed-off-by: John Stultz <johnstul@us.ibm.com> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: VFS: Fix race between CPU hotplug and lglocks
-
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/linuxLinus Torvalds authored
for linus: writeback reason binary tracing format fix * tag 'writeback' of git://git.kernel.org/pub/scm/linux/kernel/git/wfg/linux: writeback: show writeback reason with __print_symbolic
-
- 23 Dec, 2011 14 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuildLinus Torvalds authored
* 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild: kconfig: adapt update-po-config to new UML layout
-
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-mediaLinus Torvalds authored
* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: [media] omap3isp: Fix crash caused by subdevs now having a pointer to devnodes
-
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfsLinus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs: Btrfs: call d_instantiate after all ops are setup Btrfs: fix worker lock misuse in find_worker
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparcLinus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc: sparc64: Fix MSIQ HV call ordering in pci_sun4v_msiq_build_irq().
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: netfilter: xt_connbytes: handle negation correctly net: relax rcvbuf limits rps: fix insufficient bounds checking in store_rps_dev_flow_table_cnt() net: introduce DST_NOPEER dst flag mqprio: Avoid panic if no options are provided bridge: provide a mtu() method for fake_dst_ops
-
git://1984.lsi.us.es/netDavid S. Miller authored
-
Florian Westphal authored
"! --connbytes 23:42" should match if the packet/byte count is not in range. As there is no explict "invert match" toggle in the match structure, userspace swaps the from and to arguments (i.e., as if "--connbytes 42:23" were given). However, "what <= 23 && what >= 42" will always be false. Change things so we use "||" in case "from" is larger than "to". This change may look like it breaks backwards compatibility when "to" is 0. However, older iptables binaries will refuse "connbytes 42:0", and current releases treat it to mean "! --connbytes 0:42", so we should be fine. Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
-
Al Viro authored
This closes races where btrfs is calling d_instantiate too soon during inode creation. All of the callers of btrfs_add_nondir are updated to instantiate after the inode is fully setup in memory. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Chris Mason <chris.mason@oracle.com>
-
Chris Mason authored
Dan Carpenter noticed that we were doing a double unlock on the worker lock, and sometimes picking a worker thread without the lock held. This fixes both errors. Signed-off-by: Chris Mason <chris.mason@oracle.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
-
Eric Dumazet authored
skb->truesize might be big even for a small packet. Its even bigger after commit 87fb4b7b (net: more accurate skb truesize) and big MTU. We should allow queueing at least one packet per receiver, even with a low RCVBUF setting. Reported-by: Michal Simek <monstr@monstr.eu> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Xi Wang authored
Setting a large rps_flow_cnt like (1 << 30) on 32-bit platform will cause a kernel oops due to insufficient bounds checking. if (count > 1<<30) { /* Enforce a limit to prevent overflow */ return -EINVAL; } count = roundup_pow_of_two(count); table = vmalloc(RPS_DEV_FLOW_TABLE_SIZE(count)); Note that the macro RPS_DEV_FLOW_TABLE_SIZE(count) is defined as: ... + (count * sizeof(struct rps_dev_flow)) where sizeof(struct rps_dev_flow) is 8. (1 << 30) * 8 will overflow 32 bits. This patch replaces the magic number (1 << 30) with a symbolic bound. Suggested-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Xi Wang <xi.wang@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
Chris Boot reported crashes occurring in ipv6_select_ident(). [ 461.457562] RIP: 0010:[<ffffffff812dde61>] [<ffffffff812dde61>] ipv6_select_ident+0x31/0xa7 [ 461.578229] Call Trace: [ 461.580742] <IRQ> [ 461.582870] [<ffffffff812efa7f>] ? udp6_ufo_fragment+0x124/0x1a2 [ 461.589054] [<ffffffff812dbfe0>] ? ipv6_gso_segment+0xc0/0x155 [ 461.595140] [<ffffffff812700c6>] ? skb_gso_segment+0x208/0x28b [ 461.601198] [<ffffffffa03f236b>] ? ipv6_confirm+0x146/0x15e [nf_conntrack_ipv6] [ 461.608786] [<ffffffff81291c4d>] ? nf_iterate+0x41/0x77 [ 461.614227] [<ffffffff81271d64>] ? dev_hard_start_xmit+0x357/0x543 [ 461.620659] [<ffffffff81291cf6>] ? nf_hook_slow+0x73/0x111 [ 461.626440] [<ffffffffa0379745>] ? br_parse_ip_options+0x19a/0x19a [bridge] [ 461.633581] [<ffffffff812722ff>] ? dev_queue_xmit+0x3af/0x459 [ 461.639577] [<ffffffffa03747d2>] ? br_dev_queue_push_xmit+0x72/0x76 [bridge] [ 461.646887] [<ffffffffa03791e3>] ? br_nf_post_routing+0x17d/0x18f [bridge] [ 461.653997] [<ffffffff81291c4d>] ? nf_iterate+0x41/0x77 [ 461.659473] [<ffffffffa0374760>] ? br_flood+0xfa/0xfa [bridge] [ 461.665485] [<ffffffff81291cf6>] ? nf_hook_slow+0x73/0x111 [ 461.671234] [<ffffffffa0374760>] ? br_flood+0xfa/0xfa [bridge] [ 461.677299] [<ffffffffa0379215>] ? nf_bridge_update_protocol+0x20/0x20 [bridge] [ 461.684891] [<ffffffffa03bb0e5>] ? nf_ct_zone+0xa/0x17 [nf_conntrack] [ 461.691520] [<ffffffffa0374760>] ? br_flood+0xfa/0xfa [bridge] [ 461.697572] [<ffffffffa0374812>] ? NF_HOOK.constprop.8+0x3c/0x56 [bridge] [ 461.704616] [<ffffffffa0379031>] ? nf_bridge_push_encap_header+0x1c/0x26 [bridge] [ 461.712329] [<ffffffffa037929f>] ? br_nf_forward_finish+0x8a/0x95 [bridge] [ 461.719490] [<ffffffffa037900a>] ? nf_bridge_pull_encap_header+0x1c/0x27 [bridge] [ 461.727223] [<ffffffffa0379974>] ? br_nf_forward_ip+0x1c0/0x1d4 [bridge] [ 461.734292] [<ffffffff81291c4d>] ? nf_iterate+0x41/0x77 [ 461.739758] [<ffffffffa03748cc>] ? __br_deliver+0xa0/0xa0 [bridge] [ 461.746203] [<ffffffff81291cf6>] ? nf_hook_slow+0x73/0x111 [ 461.751950] [<ffffffffa03748cc>] ? __br_deliver+0xa0/0xa0 [bridge] [ 461.758378] [<ffffffffa037533a>] ? NF_HOOK.constprop.4+0x56/0x56 [bridge] This is caused by bridge netfilter special dst_entry (fake_rtable), a special shared entry, where attaching an inetpeer makes no sense. Problem is present since commit 87c48fa3 (ipv6: make fragment identifications less predictable) Introduce DST_NOPEER dst flag and make sure ipv6_select_ident() and __ip_select_ident() fallback to the 'no peer attached' handling. Reported-by: Chris Boot <bootc@bootc.net> Tested-by: Chris Boot <bootc@bootc.net> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Thomas Graf authored
Userspace may not provide TCA_OPTIONS, in fact tc currently does so not do so if no arguments are specified on the command line. Return EINVAL instead of panicing. Signed-off-by: Thomas Graf <tgraf@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
Commit 618f9bc7 (net: Move mtu handling down to the protocol depended handlers) forgot the bridge netfilter case, adding a NULL dereference in ip_fragment(). Reported-by: Chris Boot <bootc@bootc.net> CC: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Acked-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 22 Dec, 2011 5 commits
-
-
git://neil.brown.name/mdLinus Torvalds authored
* 'for-linus' of git://neil.brown.name/md: md/bitmap: It is OK to clear bits during recovery. md: don't give up looking for spares on first failure-to-add md/raid5: ensure correct assessment of drives during degraded reshape. md/linear: fix hot-add of devices to linear arrays.
-
NeilBrown authored
commit d0a4bb49 introduced a regression which is annoying but fairly harmless. When writing to an array that is undergoing recovery (a spare in being integrated into the array), writing to the array will set bits in the bitmap, but they will not be cleared when the write completes. For bits covering areas that have not been recovered yet this is not a problem as the recovery will clear the bits. However bits set in already-recovered region will stay set and never be cleared. This doesn't risk data integrity. The only negatives are: - next time there is a crash, more resyncing than necessary will be done. - the bitmap doesn't look clean, which is confusing. While an array is recovering we don't want to update the 'events_cleared' setting in the bitmap but we do still want to clear bits that have very recently been set - providing they were written to the recovering device. So split those two needs - which previously both depended on 'success' and always clear the bit of the write went to all devices. Signed-off-by: NeilBrown <neilb@suse.de>
-
NeilBrown authored
Before performing a recovery we try to remove any spares that might not be working, then add any that might have become relevant. Currently we abort on the first spare that cannot be added. This is a false optimisation. It is conceivable that - depending on rules in the personality - a subsequent spare might be accepted. Also the loop does other things like count the available spares and reset the 'recovery_offset' value. If we abort early these might not happen properly. So remove the early abort. In particular if you have an array what is undergoing recovery and which has extra spares, then the recovery may not restart after as reboot as the could of 'spares' might end up as zero. Reported-by: Anssi Hannula <anssi.hannula@iki.fi> Signed-off-by: NeilBrown <neilb@suse.de>
-
NeilBrown authored
While reshaping a degraded array (as when reshaping a RAID0 by first converting it to a degraded RAID4) we currently get confused about which devices are in_sync. In most cases we get it right, but in the region that is being reshaped we need to treat non-failed devices as in-sync when we have the data but haven't actually written it out yet. Reported-by: Adam Kwolek <adam.kwolek@intel.com> Signed-off-by: NeilBrown <neilb@suse.de>
-
NeilBrown authored
commit d70ed2e4 broke hot-add to a linear array. After that commit, metadata if not written to devices until they have been fully integrated into the array as determined by saved_raid_disk. That patch arranged to clear that field after a recovery completed. However for linear arrays, there is no recovery - the integration is instantaneous. So we need to explicitly clear the saved_raid_disk field. Signed-off-by: NeilBrown <neilb@suse.de>
-