With x86-32 and -64 using the same mechanism for managing the
tss io permissions bitmap, large chunks of process*.c are
trivially unifyable, including:
- exit_thread
- flush_thread
- __switch_to_xtra (along with tsc enable/disable)
and as bonus pickups:
- sys_fork
- sys_vfork
(Note: asmlinkage expands to empty on x86-64)
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Impact: remove 32-bit optimization to prepare unification
x86-32 and -64 differ in the way they context-switch tasks
with io permission bitmaps. x86-64 simply copies the next
tasks io bitmap into place (if any) on context switch. x86-32
invalidates the bitmap on context switch, so that the next
IO instruction will fault; at that point it installs the
appropriate IO bitmap.
This makes context switching IO-bitmap-using tasks a bit more
less expensive, at the cost of making the next IO instruction
slower due to the extra fault. This tradeoff only makes sense
if IO-bitmap-using processes are relatively common, but they
don't actually use IO instructions very often.
However, in a typical desktop system, the only process likely
to be using IO bitmaps is the X server, and nothing at all on
a server. Therefore the lazy context switch doesn't really win
all that much, and its just a gratuitious difference from
64-bit code.
This patch removes the lazy context switch, with a view to
unifying this code in a later change.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Gerrit Renker [Fri, 27 Feb 2009 22:38:29 +0000 (22:38 +0000)]
dccp: Do not let initial option overhead shrink the MPS
This fixes a problem caused by the overlap of the connection-setup and
established-state phases of DCCP connections.
During connection setup, the client retransmits Confirm Feature-Negotiation
options until a response from the server signals that it can move from the
half-established PARTOPEN into the OPEN state, whereupon the connection is
fully established on both ends (RFC 4340, 8.1.5).
However, since the client may already send data while it is in the PARTOPEN
state, consequences arise for the Maximum Packet Size: the problem is that the
initial option overhead is much higher than for the subsequent established
phase, as it involves potentially many variable-length list-type options
(server-priority options, RFC 4340, 6.4).
Applying the standard MPS is insufficient here: especially with larger
payloads this can lead to annoying, counter-intuitive EMSGSIZE errors.
On the other hand, reducing the MPS available for the established phase by
the added initial overhead is highly wasteful and inefficient.
The solution chosen therefore is a two-phase strategy:
If the payload length of the DataAck in PARTOPEN is too large, an Ack is sent
to carry the options, and the feature-negotiation list is then flushed.
This means that the server gets two Acks for one Response. If both Acks get
lost, it is probably better to restart the connection anyway and devising yet
another special-case does not seem worth the extra complexity.
The result is a higher utilisation of the available packet space for the data
transmission phase (established state) of a connection.
The patch (over-)estimates the initial overhead to be 32*4 bytes -- commonly
seen values were around 90 bytes for initial feature-negotiation options.
It uses sizeof(u32) to mean "aligned units of 4 bytes".
For consistency, another use of 4-byte alignment is adapted.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
Gerrit Renker [Fri, 27 Feb 2009 22:38:28 +0000 (22:38 +0000)]
dccp: Minimise header option overhead in setting the MPS
This patch resolves a long-standing FIXME to dynamically update the Maximum
Packet Size depending on actual options usage.
It uses the flags set by the feature-negotiation infrastructure to compute
the required header option size.
Most options are fixed-size, a notable exception are Ack Vectors (required
currently only by CCID-2). These can have any length between 3 and 1020
bytes. As a result of testing, 16 bytes (2 bytes for type/length plus 14 Ack
Vector cells) have been found to be sufficient for loss-free situations.
There are currently no CCID-specific header options which may appear on data
packets, thus it is not necessary to define a corresponding CCID field as
suggested in the old comment.
Further changes:
----------------
Adjusted the type of 'cur_mps' to match the unsigned return type of the
function.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk> Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz> Signed-off-by: David S. Miller <davem@davemloft.net>
Kyle McMartin [Mon, 2 Mar 2009 01:41:41 +0000 (20:41 -0500)]
debug_objects: add boot-parameter toggle to turn object debugging off again
While trying to debug why my Atom netbook is falling over booting
rawhide debug-enabled kernels, I stumbled across the fact that we've
been enabling object debugging by default. However, once you default it
to on, you've got no way to turn it back off again at runtime.
Add a boolean toggle to turn it off. I would just make it an int
module_param, however people may already expect the boolean enable
behaviour, so just add an analogue for disabling.
Ilpo Järvinen [Sat, 28 Feb 2009 04:44:42 +0000 (04:44 +0000)]
tcp: get rid of two unnecessary u16s in TCP skb flags copying
I guess these fields were one day 16-bit in the struct but
nowadays they're just using 8 bits anyway.
This is just a precaution, didn't result any change in my
case but who knows what all those varying gcc versions &
options do. I've been told that 16-bit is not so nice with
some cpus.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
Ilpo Järvinen [Sat, 28 Feb 2009 04:44:33 +0000 (04:44 +0000)]
tcp: separate timeout marking loop to it's own function
Some comment about its current state added. So far I have
seen very few cases where the thing is actually useful,
usually just marginally (though admittedly I don't usually
see top of window losses where it seems possible that there
could be some gain), instead, more often the cases suffer
from L-marking spike which is certainly not desirable
(I'll bury improving it to my todo list, but on a low
prio position).
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
Ilpo Järvinen [Sat, 28 Feb 2009 04:44:32 +0000 (04:44 +0000)]
tcp: remove redundant code from tcp_mark_lost_retrans
Arnd Hannemann <hannemann@nets.rwth-aachen.de> noticed and was
puzzled by the fact that !tcp_is_fack(tp) leads to early return
near the beginning and the later on tcp_is_fack(tp) was still
used in an if condition. The later check was a left-over from
RFC3517 SACK stuff (== !tcp_is_fack(tp) behavior nowadays) as
there wasn't clear way how to handle this particular check
cheaply in the spirit of RFC3517 (using only SACK blocks, not
holes + SACK blocks as with FACK). I sort of left it there as
a reminder but since it's confusing other people just remove
it and comment the missing-feature stuff instead.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Cc: Arnd Hannemann <hannemann@nets.rwth-aachen.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Ilpo Järvinen [Sat, 28 Feb 2009 04:44:31 +0000 (04:44 +0000)]
tcp: fix corner case issue in segmentation during rexmitting
If cur_mss grew very recently so that the previously G/TSOed skb
now fits well into a single segment it would get send up in
parts unless we calculate # of segments again. This corner-case
could happen eg. after mtu probe completes or less than
previously sack blocks are required for the opposite direction.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
Ilpo Järvinen [Sat, 28 Feb 2009 04:44:28 +0000 (04:44 +0000)]
tcp: fix lost_cnt_hint miscounts
It is possible that lost_cnt_hint gets underflow in
tcp_clean_rtx_queue because the cumulative ACK can cover
the segment where lost_skb_hint points to only partially,
which means that the hint is not cleared, opposite to what
my (earlier) comment claimed.
Also I don't agree what I ended up writing about non-trivial
case there to be what I intented to say. It was not supposed
to happen that the hint won't get cleared and we underflow
in any scenario.
In general, this is quite hard to trigger in practice.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
Ilpo Järvinen [Sat, 28 Feb 2009 04:44:27 +0000 (04:44 +0000)]
tcp: don't backtrack to sacked skbs
Backtracking to sacked skbs is a horrible performance killer
since the hint cannot be advanced successfully past them...
...And it's totally unnecessary too.
In theory this is 2.6.27..28 regression but I doubt anybody
can make .28 to have worse performance because of other TCP
improvements.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
Remove es7000_cpu_mask_to_apicid_cluster completely, because it's
almost the same as es7000_cpu_mask_to_apicid except 2 code paths.
One of them is about to be removed soon, the another should be
BAD_APICID (it's a fail path).
The _cluster one was not invoked on apic->cpu_mask_to_apicid_and
anyway, since there was no _cluster_and variant.
Ingo Molnar [Mon, 2 Mar 2009 10:00:57 +0000 (11:00 +0100)]
x86, mm: dont use non-temporal stores in pagecache accesses
Impact: standardize IO on cached ops
On modern CPUs it is almost always a bad idea to use non-temporal stores,
as the regression in this commit has shown it:
30d697f: x86: fix performance regression in write() syscall
The kernel simply has no good information about whether using non-temporal
stores is a good idea or not - and trying to add heuristics only increases
complexity and inserts fragility.
The regression on cached write()s took very long to be found - over two
years. So dont take any chances and let the hardware decide how it makes
use of its caches.
The only exception is drivers/gpu/drm/i915/i915_gem.c: there were we are
absolutely sure that another entity (the GPU) will pick up the dirty
data immediately and that the CPU will not touch that data before the
GPU will.
Also, keep the _nocache() primitives to make it easier for people to
experiment with these details. There may be more clear-cut cases where
non-cached copies can be used, outside of filemap.c.
David S. Miller [Mon, 2 Mar 2009 09:49:28 +0000 (01:49 -0800)]
rds: Fix build on powerpc.
As reported by Stephen Rothwell.
> Today's linux-next build (powerpc allyesconfig) failed like this:
>
> net/rds/cong.c: In function 'rds_cong_set_bit':
> net/rds/cong.c:284: error: implicit declaration of function 'generic___set_le_bit'
> net/rds/cong.c: In function 'rds_cong_clear_bit':
> net/rds/cong.c:298: error: implicit declaration of function 'generic___clear_le_bit'
> net/rds/cong.c: In function 'rds_cong_test_bit':
> net/rds/cong.c:309: error: implicit declaration of function 'generic_test_le_bit'
Signed-off-by: David S. Miller <davem@davemloft.net>
Takashi Iwai [Mon, 2 Mar 2009 09:46:03 +0000 (10:46 +0100)]
ALSA: hda - Don't return a fatal error at PCM-creation errors
Don't return a fatal error to the driver but continue to probe when
any error occurs at creating PCM streams for each codec.
It's often non-fatal and keeping it would help debugging.
Takashi Iwai [Mon, 2 Mar 2009 09:44:15 +0000 (10:44 +0100)]
ALSA: hda - Revert the codec probe at control-creation errors
Revert the codec probe instead of returning the error to the driver
when any error occurs at creating the control elements.
The control element conflict can be non-fatal in many cases,
especially if it comes from the digital-only codec.
Pekka Paalanen [Tue, 24 Feb 2009 19:44:15 +0000 (21:44 +0200)]
x86 mmiotrace: fix race with release_kmmio_fault_page()
There was a theoretical possibility to a race between arming a page in
post_kmmio_handler() and disarming the page in
release_kmmio_fault_page():
cpu0 cpu1
------------------------------------------------------------------
mmiotrace shutdown
enter release_kmmio_fault_page
fault on the page
disarm the page
disarm the page
handle the MMIO access
re-arm the page
put the page on release list
remove_kmmio_fault_pages()
fault on the page
page not known to mmiotrace
fall back to do_page_fault()
*KABOOM*
(This scenario also shows the double disarm case which is allowed.)
Fixed by acquiring kmmio_lock in post_kmmio_handler() and checking
if the page is being released from mmiotrace.
Signed-off-by: Pekka Paalanen <pq@iki.fi> Cc: Stuart Bennett <stuart@freedesktop.org> Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Stuart Bennett [Thu, 5 Feb 2009 11:02:02 +0000 (11:02 +0000)]
x86 mmiotrace: improve handling of secondary faults
Upgrade some kmmio.c debug messages to warnings.
Allow secondary faults on probed pages to fall through, and only log
secondary faults that are not due to non-present pages.
Patch edited by Pekka Paalanen.
Signed-off-by: Stuart Bennett <stuart@freedesktop.org> Signed-off-by: Pekka Paalanen <pq@iki.fi> Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Split set_page_presence() in kmmio.c into two more functions set_pmd_presence()
and set_pte_presence(). Purely code reorganization, no functional changes.
Signed-off-by: Pekka Paalanen <pq@iki.fi> Cc: Stuart Bennett <stuart@freedesktop.org> Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Stuart Bennett [Fri, 30 Jan 2009 17:38:59 +0000 (17:38 +0000)]
x86 mmiotrace: WARN_ONCE if dis/arming a page fails
Print a full warning once, if arming or disarming a page fails.
Also, if initial arming fails, do not handle the page further. This
avoids the possibility of a page failing to arm and then later claiming
to have handled any fault on that page.
WARN_ONCE added by Pekka Paalanen.
Signed-off-by: Stuart Bennett <stuart@freedesktop.org> Signed-off-by: Pekka Paalanen <pq@iki.fi> Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Pekka Paalanen [Sun, 1 Mar 2009 14:10:08 +0000 (16:10 +0200)]
x86: add far read test to testmmiotrace
Apparently pages far into an ioremapped region might not actually be
mapped during ioremap(). Add an optional read test to try to trigger a
multiply faulting MMIO access. Also add more messages to the kernel log
to help debugging.
This patch is based on a patch suggested by
Stuart Bennett <stuart@freedesktop.org>
who discovered bugs in mmiotrace related to normal kernel space faults.
Signed-off-by: Pekka Paalanen <pq@iki.fi> Cc: Stuart Bennett <stuart@freedesktop.org> Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Pekka Paalanen [Sun, 1 Mar 2009 14:09:14 +0000 (16:09 +0200)]
x86: count errors in testmmiotrace.ko
Check the read values against the written values in the MMIO read/write
test. This test shows if the given MMIO test area really works as
memory, which is a prerequisite for a successful mmiotrace test.
Signed-off-by: Pekka Paalanen <pq@iki.fi> Cc: Stuart Bennett <stuart@freedesktop.org> Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Takashi Iwai [Mon, 2 Mar 2009 07:06:11 +0000 (08:06 +0100)]
ALSA: hda - Remove Toshiba probe_mask quirk
Revert the Toshiba probe_mask quirk for 2.6.29 kernel
(commit 38f1df27e3191d76e983cb9c6b4392582fd32fda).
In the current tree, the digital-only codec is handled properly so
no codec conflict should occur.
Takashi Iwai [Mon, 2 Mar 2009 07:04:35 +0000 (08:04 +0100)]
ALSA: hda - Don't create a beep control for digital-only ALC268
When an ALC268 codec is set up as the digital-only (as found in Toshiba
laptops), it shouldn't contain any beep control that conflict with the
primary codec.
Takashi Iwai [Sun, 1 Mar 2009 09:55:44 +0000 (10:55 +0100)]
ALSA: hda - Add probe_mask default for Toshiba laptop with ALC268
Some Toshiba laptops have another ALC268 codec on slot#3 that conflicts
with the primary codec. The codec#3 is for the digital I/O, and should
be fixed by the driver, but it'd need a bunch of changes.
So, let's fix the probe problem temporarily by setting the default
probe_mask value.
The Motorola MOTOMAGX phones (Z6, E8, Zn5 so far) are providing
combined ACM/BLAN USB configuration. Since it has Vendor Specific
class, the corresponding drivers (cdc-acm, zaurus) can't find it just
by interface info. This patch adds usb id so the zaurus driver can
properly handle this combined device.
Signed-off-by: Dmitriy Taychenachev <dimichxp@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Bjørn Mork [Mon, 2 Mar 2009 04:45:40 +0000 (20:45 -0800)]
usbnet: make usbnet_get_link() fall back to ethtool_op_get_link()
Make usbnet_get_link() fall back to ethtool_op_get_link() instead of
defaulting to 1.
This makes usbnet_get_link return valid results without the need for a
driver specific check_connect or mii ops as long as the driver calls
netif_carrier_{on,off}() as appropriate. cdc_ether is an example of
such a driver.
Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net>
The current implementation of carrier detect in veth is broken.
It reports the link is down until both sides of the veth pair
are administatively up and then forever after it reports link up.
So fix veth so that it only reports link up when both interfaces
of the pair are administratively up.
Signed-off-by: Eric Biederman <ebiederm@aristanetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Bjørn Mork [Wed, 25 Feb 2009 04:33:58 +0000 (04:33 +0000)]
cdc_ether: add usb id for Ericsson F3507g
The Ericsson F3507g wireless broadband module provides a CDC Ethernet
compliant interface, but identifies it as a "Mobile Direct Line" CDC
subclass, thereby preventing the CDC Ethernet class driver from picking
it up. This patch adds the device id to cdc_ether.c as a workaround.
Ericsson has provided a "class" driver for this device:
http://kerneltrap.org/mailarchive/linux-net/2008/10/28/3832094
But closer inspection of that driver reveals that it adds little more
than duplication of code from cdc_ether.c. See also
http://marc.info/?l=linux-usb&m=123334979706403&w=2
Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net>
Guo-Fu Tseng [Fri, 27 Feb 2009 17:59:44 +0000 (17:59 +0000)]
jme: Adding {64,40}bits DMA mask back
All JMC250 chips have no problem with higher bits support.
Adding it back.
Found-by: Ethan Hsiao <ethanhsiao@jmicron.com> Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Guo-Fu Tseng [Fri, 27 Feb 2009 17:58:16 +0000 (17:58 +0000)]
jme: Clear all modified GHC register flags
Clear all modified GHC register flags.
Fixed-by: Ethan Hsiao <ethanhsiao@jmicron.com> Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Guo-Fu Tseng [Fri, 27 Feb 2009 17:57:01 +0000 (17:57 +0000)]
jme: Fix pci sync
We should sync ring descriptor to pci device after modifying it. Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Guo-Fu Tseng [Fri, 27 Feb 2009 17:54:07 +0000 (17:54 +0000)]
jme: Modifies messages to display correct hardware version
This patch modifies messages to display correct hardware version. Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Ivan Vecera [Mon, 2 Mar 2009 04:34:48 +0000 (20:34 -0800)]
r8169: read MAC address from EEPROM on init (2nd attempt)
This is 2nd attempt to implement the initialization/reading of MAC address
from EEPROM. The first used PCI's VPD and there were some problems, some
devices are not able to read EEPROM content by VPD. The 2nd one uses direct
access to EEPROM through bit-banging interface and my testing results seem
to be much better.
I tested 5 systems each with different Realtek NICs and I didn't find any
problem. AFAIK Francois's NICs also works fine.
Original description:
This fixes the problem when MAC address is set by ifconfig or by
ip link commands and this address is stored in the device after
reboot. The power-off is needed to get right MAC address.
This is problem when Xen daemon is running because it renames the device
name from ethX to pethX and sets its MAC address to FE:FF:FF:FF:FF:FF.
After reboot the device is still using FE:FF:FF:FF:FF:FF.
Signed-off-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Mon, 2 Mar 2009 04:32:39 +0000 (20:32 -0800)]
ixgbe: Fix some compiler warnings.
'pap' is never used in ixgbe_dcb_hw_config_82599()
and 'eec' in ixgbe_acquire_eeptom() is only used when
status == 0 but GCC has some trouble seeing that.
Signed-off-by: David S. Miller <davem@davemloft.net>
Paul Moore [Fri, 27 Feb 2009 20:00:03 +0000 (15:00 -0500)]
selinux: Fix a panic in selinux_netlbl_inode_permission()
Rick McNeal from LSI identified a panic in selinux_netlbl_inode_permission()
caused by a certain sequence of SUNRPC operations. The problem appears to be
due to the lack of NULL pointer checking in the function; this patch adds the
pointer checks so the function will exit safely in the cases where the socket
is not completely initialized.
Signed-off-by: Paul Moore <paul.moore@hp.com> Signed-off-by: James Morris <jmorris@namei.org>
PJ Waskiewicz [Fri, 27 Feb 2009 15:45:05 +0000 (15:45 +0000)]
ixgbe: Add 82599 device id's, hook it up into the main driver.
With the hardware-specific code in place, add all supported device id's,
along with base driver changes to enable 82599 devices. The devices
being enabled are:
The device 8086:10fb is a fully-pluggable SFP+ NIC.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
PJ Waskiewicz [Fri, 27 Feb 2009 15:44:48 +0000 (15:44 +0000)]
ixgbe: Add DCB for 82599, remove BCN support
This patch adds the DCB (Data Center Bridging) support for 82599 hardware.
This is similar to how the 82598 DCB code works.
This patch also removes the BCN (Backwards Congestion Notification) netlink
configuration code from the driver. BCN was a pre-standard congestion
notification framework, and was not what the IEEE body decided upon for
standard congestion management. QCN (802.1Qau), Quantized Congestion
Notification is the accepted standard, which is not supported by 82599,
hence we remove the support altogether.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
PJ Waskiewicz [Fri, 27 Feb 2009 15:44:30 +0000 (15:44 +0000)]
ixgbe: Add hardware specific initialization code for 82599 devices
This patch adds the hardware initialization code specific to 82599. This
is similar to the 82598 hardware initialization code. It also includes all
changes to the existing hardware init code to support 82599.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ilpo Järvinen [Sun, 1 Mar 2009 08:21:36 +0000 (00:21 -0800)]
tcp: fix retrans_out leaks
There's conflicting assumptions in shifting, the caller assumes
that dupsack results in S'ed skbs (or a part of it) for sure but
never gave a hint to tcp_sacktag_one when dsack is actually in
use. Thus DSACK retrans_out -= pcount was not taken and the
counter became out of sync. Remove obstacle from that information
flow to get DSACKs accounted in tcp_sacktag_one as expected.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Tested-by: Denys Fedoryshchenko <denys@visp.net.lb> Signed-off-by: David S. Miller <davem@davemloft.net>
Chris Leech [Fri, 27 Feb 2009 10:01:36 +0000 (10:01 +0000)]
net headers: cleanup dcbnl.h
1) add an include for <linux/types.h>
2) change dcbmsg.dcb_family from unsigned char to __u8 to be more
consistent with use of kernel types
Signed-off-by: Chris Leech <christopher.leech@intel.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Herbert Xu [Sun, 1 Mar 2009 08:11:52 +0000 (00:11 -0800)]
netpoll: Add drop checks to all entry points
The netpoll entry checks are required to ensure that we don't
receive normal packets when invoked via netpoll. Unfortunately
it only ever worked for the netif_receive_skb/netif_rx entry
points. The VLAN (and subsequently GRO) entry point didn't
have the check and therefore can trigger all sorts of weird
problems.
This patch adds the netpoll check to all entry points.
I'm still uneasy with receiving at all under netpoll (which
apparently is only used by the out-of-tree kdump code). The
reason is it is perfectly legal to receive all data including
headers into highmem if netpoll is off, but if you try to do
that with netpoll on and someone gets a printk in an IRQ handler
you're going to get a nice BUG_ON.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Tejun Heo [Sun, 1 Mar 2009 07:06:56 +0000 (16:06 +0900)]
bootmem, x86: further fixes for arch-specific bootmem wrapping
Impact: fix new breakages introduced by previous fix
Commit c132937556f56ee4b831ef4b23f1846e05fde102 tried to clean up
bootmem arch wrapper but it wasn't quite correct. Before the commit,
the followings were broken.
* reserve_bootmem(...) can't be mapped into
reserve_bootmem_node(NODE_DATA(0)->bdata, ...) because the node is
not preference here. The region specified MUST fall into the
specified region; otherwise, it will panic.
After the commit,
* If allocation fails for the arch preferred node, it should fallback
to whatever is available. Instead, it simply failed allocation.
There are too many internal details to allow generic wrapping and
still keep things simple for archs. Plus, all that arch wants is a
way to prefer certain node over another.
This patch drops the generic wrapping around alloc_bootmem_core() and
add alloc_bootmem_core() instead. If necessary, arch can define
bootmem_arch_referred_node() macro or function which takes all
allocation information and returns the preferred node. bootmem
generic code will always try the preferred node first and then
fallback to other nodes as usual.
Breakages noted and changes reviewed by Johannes Weiner.
Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Tejun Heo [Sun, 1 Mar 2009 06:42:36 +0000 (15:42 +0900)]
percpu: kill compile warning in pcpu_populate_chunk()
Impact: remove compile warning
Mark local variable map_end in pcpu_populate_chunk() with
uninitialized_var(). The variable is always used in tandem with
map_start and guaranteed to be initialized before use but gcc doesn't
understand that.
Grant Likely [Sun, 1 Mar 2009 04:30:38 +0000 (21:30 -0700)]
powerpc/4xx: Enable SERIAL_OF support by default for Virtex platforms
Virtex FPGA designs have two serial port logic cores to choose from; the
simple uartlite, and the full featured uart16550. Both cores are in
common use so the defconfig should support both of them. Currently
only console on uartlite is supported in the defconfig. This patch adds
console support for the 16550 core.
The Virtex reference designs do not work without this patch.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Theodore Ts'o [Sun, 1 Mar 2009 00:39:58 +0000 (19:39 -0500)]
ext4: Track lifetime disk writes
Add a new superblock value which tracks the lifetime amount of writes
to the filesystem. This is useful in estimating the amount of wear on
solid state drives (SSD's) caused by writes to the filesystem.
ext4: Fix discard of inode prealloc space with delayed allocation.
With delayed allocation we should not/cannot discard inode prealloc
space during file close. We would still have dirty pages for which we
haven't allocated blocks yet. With this fix after each get_blocks
request we check whether we have zero reserved blocks and if yes and
we don't have any writers on the file we discard inode prealloc space.
Some Logitech mice react to the magic knock like Elantech touchpad would.
This leads to those mice being misdetected as Elantech touchpads. Add a
version query to elantech_detect() to distinguish the two.
[dtor@mail.ru:
- lower severity of some messages - when we are not sure yet if
device is Elantech or not not responding to knock is not an error.
]
Andy Whitcroft [Sat, 28 Feb 2009 20:51:01 +0000 (12:51 -0800)]
Input: synaptics - ensure we reset the device on resume
When resuming from suspend newer Synaptics touchpads do not recover
correctly. Analysis of the resume sequence as applied in Linux was
compared to that of other operating systems. This indicated that the
other OSs were resetting the mouse before attempting to detect it (for
all Synaptics touchpads, old and new). Applying this same modification
fixes these newer Synaptics touchpads and brings the driver into line
with common OS reset behaviour.
Signed-off-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Devices confirmed to be real HID have the class set to HID and the protocol
set to 'mouse'. Some have HID class but protocol set to 'none'. Those are
not HID and should be driven by usbtouchscreen.
Fix the device ignoring macro by adding match for the protocol too.
Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Mark Brown [Sat, 28 Feb 2009 21:14:20 +0000 (21:14 +0000)]
ASoC: Add SND_SOC_DAPM_PIN_SWITCH controls for exposing DAPM pins
On some systems it is desirable for control for DAPM pins to be provided
to user space. This is the case with things like GSM modems which are
controlled primarily from user space, for example. Provide a helper which
exposes the state of a DAPM pin to user space for use in cases like this.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Steven Rostedt [Sat, 28 Feb 2009 07:41:25 +0000 (02:41 -0500)]
tracing: add raw fast tracing interface for trace events
This patch adds the interface to enable the C style trace points.
In the directory /debugfs/tracing/events/subsystem/event
We now have three files:
enable : values 0 or 1 to enable or disable the trace event.
available_types: values 'raw' and 'printf' which indicate the tracing
types available for the trace point. If a developer does not
use the TRACE_EVENT_FORMAT macro and just uses the TRACE_FORMAT
macro, then only 'printf' will be available. This file is
read only.
type: values 'raw' or 'printf'. This indicates which type of tracing
is active for that trace point. 'printf' is the default and
if 'raw' is not available, this file is read only.
# echo raw > /debug/tracing/events/sched/sched_wakeup/type
# echo 1 > /debug/tracing/events/sched/sched_wakeup/enable
Will enable the C style tracing for the sched_wakeup trace point.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
projects / linux-2.6-omap-h63xx.git / log