linux-toradex.git/include, branch v2.6.32.3

quota: decouple fs reserved space from quota reservation

2010-01-06T23:05:03+00:00

commit fd8fbfc1709822bd94247c5b2ab15a5f5041e103 upstream.

Currently inode_reservation is managed by fs itself and this
reservation is transfered on dquot_transfer(). This means what
inode_reservation must always be in sync with
dquot->dq_dqb.dqb_rsvspace. Otherwise dquot_transfer() will result
in incorrect quota(WARN_ON in dquot_claim_reserved_space() will be
triggered)
This is not easy because of complex locking order issues
for example http://bugzilla.kernel.org/show_bug.cgi?id=14739

The patch introduce quota reservation field for each fs-inode
(fs specific inode is used in order to prevent bloating generic
vfs inode). This reservation is managed by quota code internally
similar to i_blocks/i_bytes and may not be always in sync with
internal fs reservation.

Also perform some code rearrangement:
- Unify dquot_reserve_space() and dquot_reserve_space()
- Unify dquot_release_reserved_space() and dquot_free_space()
- Also this patch add missing warning update to release_rsv()
  dquot_release_reserved_space() must call flush_warnings() as
  dquot_free_space() does.

Signed-off-by: Dmitry Monakhov 
Signed-off-by: Jan Kara 
Signed-off-by: Greg Kroah-Hartman

Add unlocked version of inode_add_bytes() function

2010-01-06T23:05:01+00:00

commit b462707e7ccad058ae151e5c5b06eb5cadcb737f upstream.

Quota code requires unlocked version of this function. Off course
we can just copy-paste the code, but copy-pasting is always an evil.

Signed-off-by: Dmitry Monakhov 
Signed-off-by: Jan Kara 
Signed-off-by: Greg Kroah-Hartman

sched: Fix balance vs hotplug race

2010-01-06T23:04:49+00:00

commit 6ad4c18884e864cf4c77f9074d3d1816063f99cd upstream.

Since (e761b77: cpu hotplug, sched: Introduce cpu_active_map and redo
sched domain managment) we have cpu_active_mask which is suppose to rule
scheduler migration and load-balancing, except it never (fully) did.

The particular problem being solved here is a crash in try_to_wake_up()
where select_task_rq() ends up selecting an offline cpu because
select_task_rq_fair() trusts the sched_domain tree to reflect the
current state of affairs, similarly select_task_rq_rt() trusts the
root_domain.

However, the sched_domains are updated from CPU_DEAD, which is after the
cpu is taken offline and after stop_machine is done. Therefore it can
race perfectly well with code assuming the domains are right.

Cure this by building the domains from cpu_active_mask on
CPU_DOWN_PREPARE.

Signed-off-by: Peter Zijlstra 
LKML-Reference: 
Signed-off-by: Ingo Molnar 
Cc: Mike Galbraith 
Cc: Holger Hoffstätte 
Signed-off-by: Greg Kroah-Hartman

netfilter: fix crashes in bridge netfilter caused by fragment jumps

2010-01-06T23:04:40+00:00

commit 8fa9ff6849bb86c59cc2ea9faadf3cb2d5223497 upstream.

When fragments from bridge netfilter are passed to IPv4 or IPv6 conntrack
and a reassembly queue with the same fragment key already exists from
reassembling a similar packet received on a different device (f.i. with
multicasted fragments), the reassembled packet might continue on a different
codepath than where the head fragment originated. This can cause crashes
in bridge netfilter when a fragment received on a non-bridge device (and
thus with skb->nf_bridge == NULL) continues through the bridge netfilter
code.

Add a new reassembly identifier for packets originating from bridge
netfilter and use it to put those packets in insolated queues.

Fixes http://bugzilla.kernel.org/show_bug.cgi?id=14805

Reported-and-Tested-by: Chong Qiao 
Signed-off-by: Patrick McHardy 
Signed-off-by: Greg Kroah-Hartman

ipv6: reassembly: use seperate reassembly queues for conntrack and local delivery

2010-01-06T23:04:39+00:00

commit 0b5ccb2ee250136dd7385b1c7da28417d0d4d32d upstream.

Currently the same reassembly queue might be used for packets reassembled
by conntrack in different positions in the stack (PREROUTING/LOCAL_OUT),
as well as local delivery. This can cause "packet jumps" when the fragment
completing a reassembled packet is queued from a different position in the
stack than the previous ones.

Add a "user" identifier to the reassembly queue key to seperate the queues
of each caller, similar to what we do for IPv4.

Signed-off-by: Patrick McHardy 
Signed-off-by: Greg Kroah-Hartman

NOMMU: Optimise away the {dac_,}mmap_min_addr tests

2010-01-06T23:04:30+00:00

commit 6e1415467614e854fee660ff6648bd10fa976e95 upstream.

In NOMMU mode clamp dac_mmap_min_addr to zero to cause the tests on it to be
skipped by the compiler.  We do this as the minimum mmap address doesn't make
any sense in NOMMU mode.

mmap_min_addr and round_hint_to_min() can be discarded entirely in NOMMU mode.

Signed-off-by: David Howells 
Acked-by: Eric Paris 
Signed-off-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

vmalloc: conditionalize build of pcpu_get_vm_areas()

2009-12-18T22:05:35+00:00

No matching upstream commit as it was resolved differently there.


pcpu_get_vm_areas() is used only when dynamic percpu allocator is used
by the architecture.  In 2.6.32, ia64 doesn't use dynamic percpu
allocator and has a macro which makes pcpu_get_vm_areas() buggy via
local/global variable aliasing and triggers compile warning.

The problem is fixed in upstream and ia64 uses dynamic percpu
allocators, so the only left issue is inclusion of unnecessary code
and compile warning on ia64 on 2.6.32.

Don't build pcpu_get_vm_areas() if legacy percpu allocator is in use.

Signed-off-by: Tejun Heo 
Reported-by: Jan Beulich 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix sync to vblank when VGA output is turned off

2009-12-18T22:05:26+00:00

commit 778c902640530371a169ad1c03566e7c51b09874 upstream

In current vblank-wait implementation, if we turn off VGA output,
drm_wait_vblank will still wait on the disabled pipe until timeout,
because vblank on the pipe is assumed be enabled. This would cause
slow system response on some system such as moblin.

This patch resolve the issue by adding a drm helper function
drm_vblank_off which explicitly clear vblank_enabled[crtc], wake up
any waiting queue and save last vblank counter before turning off
crtc. It also slightly change drm_vblank_get to ensure that we will
will return immediately if trying to wait on a disabled pipe.

Signed-off-by: Li Peng 
Reviewed-by: Jesse Barnes 
[anholt: hand-applied for conflicts with overlay changes]
Signed-off-by: Eric Anholt 
Cc: Stefan Bader 
Signed-off-by: Greg Kroah-Hartman

tracing: Fix event format export

2009-12-18T22:05:16+00:00

commit 811cb50baf63461ce0bdb234927046131fc7fa8b upstream.

For some reason the export of the event print format to userspace
uses '#fmt' which breaks if the format string is anything but a plain
string, for example if it is built with macros then the macro names
are exported instead of their contents.

Use
	"\"%s\"", fmt
instead of
	"%s", #fmt
to export the string and not the way it is built.

For example, in net/mac80211/driver-trace.h for the trace event drv_start
there is:

        TP_printk(
                LOCAL_PR_FMT, LOCAL_PR_ARG
        )

Which use to produce:

 print fmt: LOCAL_PR_FMT, REC->wiphy_name

Now produces:

 print fmt: "%s", REC->wiphy_name

Signed-off-by: Johannes Berg 
LKML-Reference: <20091113224009.GB23942@elte.hu>
Signed-off-by: Steven Rostedt 
Cc: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

tcp: Stalling connections: Fix timeout calculation routine

2009-12-18T22:05:05+00:00

[ Upstream commit 07f29bc5bbae4e53e982ab956fed7207990a7786 ]

This patch fixes a problem in the TCP connection timeout calculation.
Currently, timeout decisions are made on the basis of the current
tcp_time_stamp and retrans_stamp, which is usually set at the first
retransmission.
However, if the retransmission fails in tcp_retransmit_skb(),
retrans_stamp is not updated and remains zero. This leads to wrong
decisions in retransmits_timed_out() if tcp_time_stamp is larger than
the specified timeout, which is very likely.
In this case, the TCP connection dies after the first attempted
(and unsuccessful) retransmission.

With this patch, tcp_skb_cb->when is used instead, when retrans_stamp
is not available.

This bug has been introduced together with retransmits_timed_out() in
2.6.32, as the number of retransmissions has been used for timeout
decisions before. The corresponding commit was
6fa12c85031485dff38ce550c24f10da23b0adaa (Revert Backoff [v3]:
Calculate TCP's connection close threshold as a time value.).

Thanks to Ilpo Järvinen for code suggestions and Frederic Leroy for
testing.

Reported-by: Frederic Leroy 
Signed-off-by: Damian Lukowski 
Acked-by: Ilpo Järvinen 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman