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

[MATH-EMU]: Fix underflow exception reporting.

2007-08-30T04:14:37+00:00

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 
Signed-off-by: Adrian Bunk

md: avoid possible BUG_ON in md bitmap handling

2007-08-23T00:13:17+00:00

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 
Signed-off-by: Adrian Bunk

md: allow SET_BITMAP_FILE to work on 64bit kernel with 32bit userspace

2007-08-22T23:37:54+00:00

..  so that you can use bitmaps with 32bit userspace on a 64 bit kernel.

Signed-off-by: Neil Brown 
Signed-off-by: Adrian Bunk

md: fix resync speed calculation for restarted resyncs

2007-08-22T22:57:45+00:00

We introduced 'io_sectors' recently so we could count the sectors that causes
io during resync separate from sectors which didn't cause IO - there can be a
difference if a bitmap is being used to accelerate resync.

However when a speed is reported, we find the number of sectors processed
recently by subtracting an oldish io_sectors count from a current
'curr_resync' count.  This is wrong because curr_resync counts all sectors,
not just io sectors.

So, add a field to mddev to store the curren io_sectors separately from
curr_resync, and use that in the calculations.

Signed-off-by: Neil Brown 
Signed-off-by: Adrian Bunk

md/bitmap: remove dead code from md/bitmap

2007-08-11T23:07:37+00:00

bitmap_active is never called, and the BITMAP_ACTIVE flag is never users or
tested, so discard them both.

Also remove some out-of-date 'todo' comments.

Signed-off-by: Neil Brown 
Signed-off-by: Adrian Bunk

ide: clear bmdma status in ide_intr() for ICHx controllers (revised #4)

2007-07-22T16:05:44+00:00

patch 1/2 (revised):
- Fix drive->waiting_for_dma to work with CDB-intr devices.
- Do the dma status clearing in ide_intr() and add a new
  hwif->ide_dma_clear_irq for Intel ICHx controllers.

Revised per Alan, Sergei and Bart's advice.

Patch against 2.6.20-rc6. Tested ok on my ICH4 and pdc20275 adapters.
Please review/apply, thanks.

Signed-off-by: Albert Lee 
Signed-off-by: Adrian Bunk

[NET]: Fix BMSR_100{HALF,FULL}2 defines in linux/mii.h

2007-07-22T15:39:23+00:00

Noticed by Matvejchikov Ilya.

Signed-off-by: David S. Miller 
Signed-off-by: Adrian Bunk

[NETPOLL]: Fix TX queue overflow in trapped mode.

2007-05-22T22:41:22+00:00

CONFIG_NETPOLL_TRAP causes the TX queue controls to be completely bypassed in
the netpoll's "trapped" mode which easily causes overflows in the drivers with
short TX queues (most notably, in 8139too with its 4-deep queue).  So, make
this option more sensible by making it only bypass the TX softirq wakeup.

Signed-off-by: Sergei Shtylyov 
Acked-by: Jeff Garzik 
Acked-by: Tom Rini 
Acked-by: Matt Mackall 
Signed-off-by: David S. Miller 
Signed-off-by: Adrian Bunk

[NETFILTER]: ip_nat_proto_gre: do not modify/corrupt GREv0 packets through NAT

2007-05-03T23:00:32+00:00

While porting some changes of the 2.6.21-rc7 pptp/proto_gre conntrack
and nat modules to a 2.4.32 kernel I noticed that the gre_key function
returns a wrong pointer to the GRE key of a version 0 packet thus
corrupting the packet payload.

The intended behaviour for GREv0 packets is to act like
ip_conntrack_proto_generic/ip_nat_proto_unknown so I have ripped the
offending functions (not used anymore) and modified the
ip_nat_proto_gre modules to not touch version 0 (non PPTP) packets.

Signed-off-by: Jorge Boncompte 
Signed-off-by: Patrick McHardy 
Signed-off-by: Adrian Bunk

[IPV6]: Disallow RH0 by default (CVE-2007-2242)

2007-04-30T23:31:47+00:00

A security issue is emerging.  Disallow Routing Header Type 0 by default
as we have been doing for IPv4.

This version already includes a fix for the original patch.

Signed-off-by: YOSHIFUJI Hideaki 
Signed-off-by: Adrian Bunk