The original xt_quota in the kernel is plain broken:
- counts quota at a per CPU level
(was written back when ubiquitous SMP was just a dream)
- provides no way to count across IPV4/IPV6.
This patch is the original unaltered code from:
http://sourceforge.net/projects/xtables-addons
at commit e84391ce665cef046967f796dd91026851d6bbf3
Change-Id: I19d49858840effee9ecf6cff03c23b45a97efdeb
Signed-off-by: JP Abgrall <jpa@google.com>
Allow the REJECT --reject-with icmp*blabla to also set the matching error
locally on the socket affected by the reject.
This allows the process to see an error almost as if it received it
via ICMP.
It avoids the local process who's ingress packet is rejected to have to
wait for a pseudo-eternity until some timeout kicks in.
Ideally, this should be enabled with a new iptables flag similar to
--reject-with-sock-err
For now it is enabled with CONFIG_IP*_NF_TARGET_REJECT_SKERR option.
Change-Id: I649a4fd5940029ec0b3233e5abb205da6984891e
Signed-off-by: JP Abgrall <jpa@google.com>
This module allows tracking stats at the socket level for given UIDs.
It replaces xt_owner.
If the --uid-owner is not specified, it will just count stats based on
who the skb belongs to. This will even happen on incoming skbs as it
looks into the skb via xt_socket magic to see who owns it.
If an skb is lost, it will be assigned to uid=0.
To control what sockets of what UIDs are tagged by what, one uses:
echo t $sock_fd $accounting_tag $the_billed_uid \
> /proc/net/xt_qtaguid/ctrl
So whenever an skb belongs to a sock_fd, it will be accounted against
$the_billed_uid
and matching stats will show up under the uid with the given
$accounting_tag.
Because the number of allocations for the stats structs is not that big:
~500 apps * 32 per app
we'll just do it atomic. This avoids walking lists many times, and
the fancy worker thread handling. Slabs will grow when needed later.
It use netdevice and inetaddr notifications instead of hooks in the core dev
code to track when a device comes and goes. This removes the need for
exposed iface_stat.h.
Put procfs dirs in /proc/net/xt_qtaguid/
ctrl
stats
iface_stat/<iface>/...
The uid stats are obtainable in ./stats.
Change-Id: I01af4fd91c8de651668d3decb76d9bdc1e343919
Signed-off-by: JP Abgrall <jpa@google.com>
The socket matching function has some nifty logic to get the struct sock
from the skb or from the connection tracker.
We export this so other xt_* can use it, similarly to ho how
xt_socket uses nf_tproxy_get_sock.
Change-Id: I11c58f59087e7f7ae09e4abd4b937cd3370fa2fd
Signed-off-by: JP Abgrall <jpa@google.com>
Without this change a saw an 18% increase in idle power consumption
on one deivce when trace support is compiled into the kernel. Now
I see the same increase only when tracing.
Change-Id: I21bb5ecf1b7d29ce3790ceeb5323409cc22d5a3b
Signed-off-by: Arve Hjønnevåg <arve@android.com>
If more than one ETM or PTM are present, configure all of them
and enable the formatter in the ETB. This allows tracing on dual
core systems (e.g. omap4).
Change-Id: I028657d5cf2bee1b23f193d4387b607953b35888
Signed-off-by: Arve Hjønnevåg <arve@android.com>
On some SOCs the read and write pointer are reset when the chip
resets, but the trace buffer content is preserved. If the status
bits indicates that the buffer is empty and we have never started
tracing, assume the buffer is full instead. This can be useful
if the system rebooted from a watchdog reset.
Change-Id: Iaf21c2c329c6059004ee1d38e3dfff66d7d28029
Signed-off-by: Arve Hjønnevåg <arve@android.com>
It is not safe to call etm_lock or etb_lock without holding the
mutex since another thread may also have unlocked the registers.
Also add some missing checks for valid etb_regs in the etm sysfs
entries.
Change-Id: I939f76a6ea7546a8fc0d4ddafa2fd2b6f38103bb
Signed-off-by: Arve Hjønnevåg <arve@android.com>
The old code enabled data tracing, but did not configure the
range. We now configure it to trace all data addresses by default,
and add a trace_data_range attribute to change the range or disable
data tracing.
Change-Id: I9d04e3e1ea0d0b4d4d5bcb93b1b042938ad738b2
Signed-off-by: Arve Hjønnevåg <arve@android.com>
Trace kernel text segment by default as before, allow tracing of other
ranges by writing a range to /sys/devices/etm/trace_range, or to trace
everything by writing 0 0.
Change-Id: Ibb734ca820fedf79560b20536247f1e1700cdc71
Signed-off-by: Arve Hjønnevåg <arve@android.com>
If the write address was at the end of the buffer, toggling the trace
capture bit would set the RAM-full status instead of clearing it, and
if any of the stop bits in the formatter is set toggling the trace
capture bit may not do anything.
Instead use the read position to find out if the data has already
been returned.
This also fixes the read function so it works when the trace buffer is
larger than the buffer passed in from user space. The old version
would reset the trace buffer pointers after every read, so the second
call to read would always return 0.
Change-Id: I75256abe2556adfd66fd5963e46f9e84ae4645e1
Signed-off-by: Arve Hjønnevåg <arve@android.com>
On some systems kernel code is considered secure, and this code
already limits tracing to the kernel text segment which results
in no trace data.
Change-Id: I098a0753e874859446d098e1ee209f67fc13cd5d
Signed-off-by: Arve Hjønnevåg <arve@android.com>
If clk_get fail, assume the etb does not need a separate clock.
Change-Id: Ia0bf3f5391e94a60ea45876aa7afc8a88a7ec3bf
Signed-off-by: Arve Hjønnevåg <arve@android.com>
PPP handles packet loss but does not work with out of order packets.
This change performs reordering of incoming data packets within a
sliding window of one second. Since sequence number is optional,
receiving a packet without it will drop all queued packets.
Currently the logic is triggered by incoming packets, so queued
packets have to wait till another packet is arrived. It is done for
simplicity since no additional locks or threads are required. For
reliable protocols, a retransmission will kick it. For unreliable
protocols, queued packets just seem like packet loss. Time-critical
protocols might be broken, but they never work with queueing anyway.
Signed-off-by: Chia-chi Yeh <chiachi@android.com>
Ensures that cpufreq_stats_free_table is called before
__cpufreq_remove_dev on cpu hotplug (which also occurs during
suspend on SMP systems) to make sure that sysfs_remove_group
can get called before the cpufreq kobj is freed. Otherwise,
the sysfs file structures are leaked.
Change-Id: I87e55277272f5cfad47e9e7c92630e990bb90069
Signed-off-by: Colin Cross <ccross@android.com>
This governor is designed for latency-sensitive workloads, such as
interactive user interfaces. The interactive governor aims to be
significantly more responsive to ramp CPU quickly up when CPU-intensive
activity begins.
Existing governors sample CPU load at a particular rate, typically
every X ms. This can lead to under-powering UI threads for the period of
time during which the user begins interacting with a previously-idle system
until the next sample period happens.
The 'interactive' governor uses a different approach. Instead of sampling
the CPU at a specified rate, the governor will check whether to scale the
CPU frequency up soon after coming out of idle. When the CPU comes out of
idle, a timer is configured to fire within 1-2 ticks. If the CPU is very
busy from exiting idle to when the timer fires then we assume the CPU is
underpowered and ramp to MAX speed.
If the CPU was not sufficiently busy to immediately ramp to MAX speed, then
the governor evaluates the CPU load since the last speed adjustment,
choosing the highest value between that longer-term load or the short-term
load since idle exit to determine the CPU speed to ramp to.
A realtime thread is used for scaling up, giving the remaining tasks the
CPU performance benefit, unlike existing governors which are more likely to
schedule rampup work to occur after your performance starved tasks have
completed.
The tuneables for this governor are:
/sys/devices/system/cpu/cpufreq/interactive/min_sample_time:
The minimum amount of time to spend at the current frequency before
ramping down. This is to ensure that the governor has seen enough
historic CPU load data to determine the appropriate workload.
Default is 80000 uS.
/sys/devices/system/cpu/cpufreq/interactive/go_maxspeed_load
The CPU load at which to ramp to max speed. Default is 85.
Change-Id: Ib2b362607c62f7c56d35f44a9ef3280f98c17585
Signed-off-by: Mike Chan <mike@android.com>
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Bug: 3152864
Move the x86_64 idle notifiers originally by Andi Kleen and Venkatesh
Pallipadi to generic.
Change-Id: Idf29cda15be151f494ff245933c12462643388d5
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Todd Poynor <toddpoynor@google.com>
This allows us to get a kernel stacktrace for a thread though /proc.
Also enable it by default.
Change-Id: If8c21cd02feaf9863f4841ace524fa30c7328d49
Signed-off-by: Arve Hjønnevåg <arve@android.com>
When enabled, tracks the frequency of network transmissions
(inbound and outbound) and buckets them accordingly.
Buckets are determined by time between network activity.
Each bucket represents the number of network transmisions that were
N sec or longer apart. Where N is defined as 1 << bucket index.
This network pattern tracking is particularly useful for wireless
networks (ie: 3G) where batching network activity closely together
is more power efficient than far apart.
New file: /proc/net/stat/activity
output:
Min Bucket(sec) Count
1 7
2 0
4 1
8 0
16 0
32 2
64 1
128 0
Change-Id: I4c4cd8627b872a55f326b1715c51bc3bdd6e8d92
Signed-off-by: Mike Chan <mike@android.com>
As it turns out, the CONFIG_PROFILING interfaces leak a
task struct if the notifier chain returns NOTIFY_OK.. doh.
This patch reworks lowmemkiller to use the new generic task
free notifier chain.
Signed-off-by: San Mehat <san@google.com>
This patch adds a notifier which can be used by subsystems that may
be interested in when a task has completely died and is about to
have it's last resource freed.
The Android lowmemory killer uses this to determine when a task
it has killed has finally given up its goods.
Signed-off-by: San Mehat <san@google.com>
For disk devices, a new uevent parameter 'NPARTS' specifies the number
of partitions detected by the kernel. Partition devices get 'PARTN' which
specifies the partitions index in the table, and 'PARTNAME', which
specifies PARTNAME specifices the partition name of a partition device
Signed-off-by: Dima Zavin <dima@android.com>
This improves compatbility with a lot of headset / chipset
combinations. Ideally this should not be needed.
Change-Id: I8b676701e12e416aa7d60801b9d353b15d102709
Signed-off-by: hyungseoung.yoo <hyungseoung.yoo@samsung.com>
Signed-off-by: Jaikumar Ganesh <jaikumarg@android.com>
__u16 sco_pkt_type is introduced to struct sockaddr_sco. It allows bitwise
selection of SCO/eSCO packet types. Currently those bits are:
0x0001 HV1 may be used.
0x0002 HV2 may be used.
0x0004 HV3 may be used.
0x0008 EV3 may be used.
0x0010 EV4 may be used.
0x0020 EV5 may be used.
0x0040 2-EV3 may be used.
0x0080 3-EV3 may be used.
0x0100 2-EV5 may be used.
0x0200 3-EV5 may be used.
This is similar to the Packet Type parameter in the HCI Setup Synchronous
Connection Command, except that we are not reversing the logic on the EDR bits.
This makes the use of sco_pkt_tpye forward portable for the use case of
white-listing packet types, which we expect will be the primary use case.
If sco_pkt_type is zero, or userspace uses the old struct sockaddr_sco,
then the default behavior is to allow all packet types.
Packet type selection is just a request made to the Bluetooth chipset, and
it is up to the link manager on the chipset to negiotiate and decide on the
actual packet types used. Furthermore, when a SCO/eSCO connection is eventually
made there is no way for the host stack to determine which packet type was used
(however it is possible to get the link type of SCO or eSCO).
sco_pkt_type is ignored for incoming SCO connections. It is possible
to add this in the future as a parameter to the Accept Synchronous Connection
Command, however its a little trickier because the kernel does not
currently preserve sockaddr_sco data between userspace calls to accept().
The most common use for sco_pkt_type will be to white-list only SCO packets,
which can be done with the hci.h constant SCO_ESCO_MASK.
This patch is motivated by broken Bluetooth carkits such as the Motorolo
HF850 (it claims to support eSCO, but will actually reject eSCO connections
after 5 seconds) and the 2007/2008 Infiniti G35/37 (fails to route audio
if a 2-EV5 packet type is negiotiated). With this patch userspace can maintain
a list of compatible packet types to workaround remote devices such as these.
Based on a patch by Marcel Holtmann.
Rebased to 2.6.39.
Change-Id: Ide1c89574fa4f6f1b9218282e1af17051eb86315
Signed-off-by: Nick Pelly <npelly@google.com>
This is to support the Motorola HF850 carkit which reports the error code 0x10
for an eSCO attempt, even though it advertises eSCO support. Here is the
hcidump:
2009-09-22 15:40:24.492391 < HCI Command: Setup Synchronous Connection
(0x01|0x0028) plen 17
handle 1 voice setting 0x0060
2009-09-22 15:40:24.493002 > HCI Event: Command Status (0x0f) plen 4
Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
2009-09-22 15:40:30.594869 > HCI Event: Synchronous Connect Complete (0x2c)
plen 17
status 0x10 handle 257 bdaddr 00:50:CD:20:C6:84 type eSCO
Error: Connection Accept Timeout Exceeded
With this patch we will retry with a SCO connection, which succeeds.
Unfortunately the Moto HF850 also takes 5 seconds to return the error for the
eSCO attempt, so it will still take 5 seconds to fallback to SCO with this
patch.
Signed-off-by: Nick Pelly <npelly@google.com>
Legacy pairing is a bit of a problem because on the incoming end it is
impossible to know pairing has begun:
2009-09-18 18:29:24.115692 > HCI Event: Connect Request (0x04) plen 10
bdaddr 00:23:D4:04:51:7A class 0x58020c type ACL
2009-09-18 18:29:24.115966 < HCI Command: Accept Connection Request (0x01|0x0009) plen 7
bdaddr 00:23:D4:04:51:7A role 0x00
Role: Master
2009-09-18 18:29:24.117065 > HCI Event: Command Status (0x0f) plen 4
Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
2009-09-18 18:29:24.282928 > HCI Event: Role Change (0x12) plen 8
status 0x00 bdaddr 00:23:D4:04:51:7A role 0x00
Role: Master
2009-09-18 18:29:24.291534 > HCI Event: Connect Complete (0x03) plen 11
status 0x00 handle 1 bdaddr 00:23:D4:04:51:7A type ACL encrypt 0x00
2009-09-18 18:29:24.291839 < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
handle 1
2009-09-18 18:29:24.292144 > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
bdaddr 00:23:D4:04:51:7A mode 1
2009-09-18 18:29:24.293823 > HCI Event: Command Status (0x0f) plen 4
Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
2009-09-18 18:29:24.303588 > HCI Event: Max Slots Change (0x1b) plen 3
handle 1 slots 5
2009-09-18 18:29:24.309448 > HCI Event: Read Remote Supported Features (0x0b) plen 11
status 0x00 handle 1
Features: 0xff 0xff 0x2d 0xfe 0x9b 0xff 0x79 0x83
2009-09-18 18:29:24.345916 < HCI Command: Remote Name Request (0x01|0x0019) plen 10
bdaddr 00:23:D4:04:51:7A mode 2 clkoffset 0x0000
2009-09-18 18:29:24.346923 > HCI Event: Command Status (0x0f) plen 4
Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
2009-09-18 18:29:24.375793 > HCI Event: Remote Name Req Complete (0x07) plen 255
status 0x00 bdaddr 00:23:D4:04:51:7A name 'test'
2009-09-18 18:29:34.332190 < HCI Command: Disconnect (0x01|0x0006) plen 3
handle 1 reason 0x13
There are some mainline patches such as "Add different pairing timeout for
Legacy Pairing" but they do not address the HCI sequence above.
I think the real solution is to avoid using CreateBond(), and instead make
the profile connection immediately. This way both sides will use a longer
timeout because there is a higher level connection in progress, and we will
not end up with the useless HCI sequence above.
Signed-off-by: Nick Pelly <npelly@google.com>
This fixes a bug where shutdown() and close() on a rfcomm socket during ACL
connection would not cause HCI Create Connection Cancel.
Signed-off-by: Nick Pelly <npelly@google.com>
Add wake_peer which is called before starting UART TX. The idea here
is to provide a mechanism where we can wakeup our peer before sending
data.
Change-Id: I42e0779b635f64ca99184b45d5b028de80197491
Signed-off-by: San Mehat <san@google.com>
Some platforms do not want to power down rfkill devices on suspend.
Change-Id: I62a11630521c636d54a4a02ab9037a43435925f5
Signed-off-by: Nick Pelly <npelly@google.com>
net: Fix a bitmask in PPPoPNS and rename constants in PPPoPNS and PPPoLAC.
Signed-off-by: Chia-chi Yeh <chiachi@android.com>
net: Fix a potential deadlock while releasing PPPoLAC/PPPoPNS socket.
PPP driver guarantees that no thread will be executing start_xmit() after
returning from ppp_unregister_channel(). To achieve this, a spinlock (downl)
is used. In pppolac_release(), ppp_unregister_channel() is called after sk_udp
is locked. At the same time, another thread might be running in pppolac_xmit()
with downl. Thus a deadlock will occur if the thread tries to lock sk_udp.
The same situation might happen on sk_raw in pppopns_release().
Signed-off-by: Chia-chi Yeh <chiachi@android.com>
net: Force PPPoLAC and PPPoPNS to bind an interface before creating PPP channel.
It is common to manipulate the routing table after configuring PPP device.
Since both PPPoLAC and PPPoPNS run over IP, care must be taken to make sure
that there is no loop in the routing table.
Although this can be done by adding a host route, it might still cause
problems when the interface is down for some reason.
To solve this, this patch forces both drivers to bind an interface before
creating PPP channel, so the system will not re-route the tunneling sockets
to another interface when the original one is down. Another benefit is that
now the host route is no longer required, so there is no need to remove it
when PPP channel is closed.
Signed-off-by: Chia-chi Yeh <chiachi@android.com>
net: Avoid sleep-inside-spinlock in PPPoLAC and PPPoPNS.
Since recv() and xmit() are called with a spinlock held, routines which might
sleep cannot be used. This issue is solved by following changes:
Incoming packets are now processed in backlog handler, recv_core(), instead of
recv(). Since backlog handler is always executed with socket spinlock held, the
requirement of ppp_input() is still satisfied.
Outgoing packets are now processed in workqueue handler, xmit_core(), instead of
xmit(). Note that kernel_sendmsg() is no longer used to prevent touching dead
sockets.
In release(), lock_sock() and pppox_unbind_sock() ensure that no thread is in
recv_core() or xmit(). Then socket handlers are restored before release_sock(),
so no packets will leak in backlog queue.
Signed-off-by: Chia-chi Yeh <chiachi@android.com>
net: Fix msg_iovlen in PPPoLAC and PPPoPNS.
Although any positive value should work (which is always true in both drivers),
the correct value should be 1.
Signed-off-by: Chia-chi Yeh <chiachi@android.com>
